7.1.2 Integrity Management Sequence Diagrams

29.198-033GPPOpen Service Access (OSA) Application Programming Interface (API)Part 3: FrameworkTS

7.1.2.1 Load Management: Suspend/resume notification from application

This sequence diagram shows the scenario of suspending or resuming notifications from the application based on the evaluation of the load balancing policy as a result of the detection of a change in load level of the framework.

7.1.2.2 Load Management: Framework queries load statistics

This sequence diagram shows how the framework requests load statistics for an application.

7.1.2.3 Load Management: Framework callback registration and Application load control

This sequence diagram shows how the framework registers itself and the application invokes load management function to inform the framework of application load.

7.1.2.4 Load Management: Application reports current load condition

This sequence diagram shows how an application reports its load condition to the framework load manager.

7.1.2.5 Load Management: Application queries load statistics

This sequence diagram shows how an application requests load statistics for the framework.

7.1.2.6 Load Management: Application callback registration and load control

This sequence diagram shows how an application registers itself and the framework invokes load management function based on policy.

7.1.2.7 Heartbeat Management: Start/perform/end heartbeat supervision of the application

In this sequence diagram, the framework has decided that it wishes to monitor the application, and has therefore requested the application to commence sending its heartbeat. The application responds by sending its heartbeat at the specified interval. The framework then decides that it is satisfied with the application’s health and disables the heartbeat mechanism. If the heartbeat was not received from the application within the specified interval, the framework can decide that the application has failed the heartbeat and can then perform some recovery action.

7.1.2.8 Fault Management: Framework detects a Service failure

The framework has detected that a service instance has failed (probably by the use of the heartbeat mechanism). The framework informs the client application.

1: The framework informs the client application that is using the service instance that the service is unavailable. The client application may wait to receive a new call to the svcAvailStatusInd with the reason SVC_AVAILABLE when the Service has become available again. The different Unavailability reasons used by the Framework (TpSvcAvailStatusReason) guides the client application developers to make the decision.

7.1.2.9 Fault Management: Application requests a Framework activity test

1: The client application asks the framework to do an activity test. The client identifies that it would like the activity test done for the framework, rather then a service, by supplying an empty string value for the svcId parameter.

2: The framework does the requested activity test and sends the result to the client application.