29.198-033GPPOpen Service Access (OSA) Application Programming Interface (API)Part 3: FrameworkTS
18.104.22.168 Load Management: Service callback registration and load control
This sequence diagram shows how a service registers itself and the framework invokes load management function based on policy.
22.214.171.124 Load Management: Framework callback registration and service load control
This sequence diagram shows how the framework registers itself and the service invokes load management function to inform the framework of service load.
126.96.36.199 Load Management: Client and Service Load Balancing
188.8.131.52 Heartbeat Management: Start/perform/end heartbeat supervision of the service
In this sequence diagram, the framework has decided that it wishes to monitor the service, and has therefore requested the service to commence sending its heartbeat. The service responds by sending its heartbeat at the specified interval. The framework then decides that it is satisfied with the service’s health and disables the heartbeat mechanism. If the heartbeat was not received from the service within the specified interval, the framework can decide that the service has failed the heartbeat and can then perform some recovery action.
184.108.40.206 Fault Management: Service requests Framework activity test
1: The service asks the framework to carry out its activity test. The service denotes that it requires the activity test done for the framework, rather than an application, by supplying an appropriate parameter.
2: The framework carries out the test and returns the result to the service.
220.127.116.11 Fault Management: Service requests Application activity test
1: The service instance asks the framework to invoke an activity test on the client application.
2: The framework asks the application to do the activity test. It is assumed that there is internal communication between the service facing part of the framework (i.e. IpFwFaultManager interface) and the part that faces the client application.
3: The application does the activity test and returns the result to the framework.
4: The framework internally passes the result from its application facing interface (IpFaultManager) to its service facing side, and sends the result to the service.
18.104.22.168 Fault Management: Application requests Service activity test
1: The client application asks the framework to invoke an activity test on a service, the service is identified by the svcId parameter.
2: The framework asks the service to do the activity test. It is assumed that there is internal communication between the application facing part of the framework (i.e. IpFaultManager interface) and the part that faces the service.
3: The service does the activity test and returns the result to the framework.
4: The framework internally passes the result from its service facing interface (IpFwFaultManager) to its application facing side, and sends the result to the client application.
22.214.171.124 Fault Management: Application detects service is unavailable
1: The client application detects that the service instance is currently not available, i.e. the service instance is not responding to the client application in the normal way, so it informs the framework.
2: The framework informs the service instance that the client application was unable to get a response from it and can no longer use the service instance. The service or framework may then decide to carry out an activity test to see whether there is a general problem with the service instance that requires further action.