Application initialization call flow

TelSDK initializes various sub-systems during start-up. It marks each sub-system as ready once the initialization procedures are completed for that sub-system. The application has to wait until the corresponding sub-system is ready on which it needs to make API requests. TelSDK provides APIs to check whether sub-system is ready or not.

Example:

Phone manager initialization

1. Application can use IPhoneManager::isSubsystemReady to determine if the system is ready.
2. The application receives the status i.e. either true or false whether sub-system is ready or not.
3. If it is not ready, then the application could use onSubsystemReady which returns std::future.
4. PhoneManager notifies the application when the subsystem is ready through the std::future object.
5. The application waits until the asynchronous operation i.e onSubsystemReady completes.
6. PhoneManager updates the application once sub-system initialization completes.

Telephony

Dial call flow

1. The application gets the PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to get Phone.
3. The application gets the Phone object for given phone identifier using PhoneManager.
4. PhoneManager returns Phone object to application. In case phone identifier is not specified, it returns default phone.
5. The application registers a listener with CallManager to listen to the call info change notifications like DIALING, ALERTING, ACTIVE and ENDED.
6. The application receives the status like SUCCESS or INVALIDPARAM based on registration of listener to CallManager.
7. The application dials a number by using makeCall API, optionally specifying callback to get asynchronous response.
8. The application receives the status like SUCCESS, INVALIDPARAM and FAILED etc based on the execution of makeCall API.
9. Optionally, the application gets asynchronous response for makeCall using makeCallResponseCallback.
10. The application receives callback on call info change like DIALING/ALERTING/ACTIVE when other party accepts the call.
11. The application sends hangup command to hangup the call, optionally specifying callback to get asynchronous response.
12. The application receives the status like SUCCESS, FAILED etc based on the execution of hangup API.
13. Optionally, the application gets asynchronous response for hangup using CommandResponseCallback.
14. The application receives callback on call info change i.e Call Ended from CallManager.

ECall call flow

1. The application gets the PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to get Phone.
3. The application gets the Phone object optionally specifying phone identifier using PhoneManager.
4. PhoneManager returns Phone object to application, returns default phone in case phone identifier is not specified.
5. The application registers a listener with CallManager to listen to the call info change notifications like DIALING, ALERTING, ACTIVE etc.
6. The application receives the status like SUCCESS, FAILED etc based on registration of listener from CallManager.
7. The application dials an emergency call by using makeECall API, optionally specifying callback to get asynchronous response.
8. The application receives the status like SUCCESS, FAILED etc based on the execution of makeECall API.
9. Optionally, the application gets asynchronous response for makeECall using makeCallResponseCallback.
10. CallManager sends ecall msd transmission status to the application by using onECallMsdTransmissionStatus API.
11. The application sends hangup command to hangup the call, optionally gets asynchronous response using callback.
12. The application receives the status like SUCCESS, FAILED etc based on the execution of hangup API.
13. Optionally, the application gets asynchronous response for hangup using CommandResponseCallback.
14. CallManager sends call info change i.e Call Ended to the application by using onCallInfoChange callback function.

Signal strength call flow

1. The application gets PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to get Phone instance.
3. The application gets phone instance for a given phone identifier using PhoneManager object.
4. PhoneManager returns IPhone object to the application.
5. Application registers the listener to get notification for signal strength change.
6. The application receives the status i.e. either SUCCESS or FAILED based on the registration of the listener.
7. The application requests for signal strength and optionally, gets asynchronous response using ISignalStrengthCallback.
8. The application receives the status i.e. either SUCCESS or FAILED based on execution of requestSignalStrength API in SapCardManager.
9. Optionally, the response for signal strength request is received by the application.
10. Application receives a notification when there is a change in signal strength.

Answer, Reject, RejectWithSMS call flow

1. The application gets the PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to register listener.
3. The application registers a listener with CallManager to listen incoming call notifications.
4. The application receives the status like SUCCESS, FAILED etc based on registration of listener from CallManager.
5. The application receives onIncomingCall notification when there is an incoming call.
6. The application performs answer/reject/rejectWithSMS operation using ICall.
7. The application receives the status like SUCCESS, FAILED etc based on execution of answer/reject/rejectWithSMS.
8. Optionally, the application gets asynchronous response for answer/reject/rejectWithSMS using CommandResponseCallback.
9. The CallManager sends call info change i.e CALL_ACTIVE or CALL_ENDED to the application by using onCallInfoChange callback function.

Hold call flow

1. The application gets the PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to get Phone.
3. The application gets the Phone object for given phone identifier using PhoneManager.
4. PhoneManager returns Phone object to application, returns default phone in case phone identifier is not specified.
5. The application registers a listener with CallManager to listen to the call info change notifications like DIALING, ALERTING, ACTIVE etc.
6. The application receives the status like SUCCESS or INVALIDPARAM based on registration of listener to CallManager.
7. The application dials a number by using makeCall API, optionally specifying callback to get asynchronous response.
8. The application receives the status like SUCCESS, INVALIDPARAM and FAILED etc based on the execution of makeCall API.
9. Optionally, the application gets asynchronous response for makeCall using makeCallResponseCallback.
10. The CallManager sends call info change i.e CALL_ACTIVE to application by using onCallInfoChange API.
11. The application sends hold command to hold the call, optionally specifying callback to get asynchronous response.
12. The application receives the status like SUCCESS, FAILED etc based on the execution of hold API.
13. Optionally, the application gets asynchronous response for hold using CommandResponseCallback.
14. The application receives call info change i.e CALL_ON_HOLD from CallManager.

Hold, Conference, Swap call flow

1. The application makes first call using ICall.
2. The application receives the status like SUCCESS, FAILED etc based on execution of makeCall operation.
3. Optionally, the application gets asynchronous response for makeCall using makeCallResponseCallback.
4. The CallManager sends call info change i.e CALL_ACTIVE to application by using onCallInfoChange API.
5. The application sends hold command to hold the call, optionally specifying callback to get asynchronous response.
6. The application receives the status like SUCCESS, FAILED etc based on the execution of hold API.
7. Optionally, the application gets asynchronous response for hold using CommandResponseCallback.
8. The application receives call info change i.e CALL_ON_HOLD from CallManager.
9. The application makes second call using ICall.
10. The application receives the status like SUCCESS, FAILED etc based on execution of makeCall operation.
11. Optionally, the application gets asynchronous response for makeCall using makeCallResponseCallback.
12. The CallManager sends call info change i.e CALL_ACTIVE to application by using onCallInfoChange API.
13. The application requests the PhoneFactory to get ICallManager object.
14. The application receives the ICallManager object using PhoneFactory.
15. The application performs conference/swap operation using ICallManager by passing first call and second call. optionally application can pass callback to receive hold response asynchronously.
16. The application receives the status like SUCCESS, FAILED etc based on the execution of conference/swap API.
17. Optionally, the application gets asynchronous response for conference/swap using CommandResponseCallback.

SMS call flow

1. Application gets PhoneManager object using PhoneFactory.
2. PhoneFactory returns the PhoneManager object to application in order to get list of phone identifiers.
3. The application retrieves the list of phone identifier on the device using PhoneManager object.
4. Application receives the status i.e. either SUCCESS or FAILED based on the execution of getPhoneIds API in PhoneManager.
5. Application registers the listener for incoming SMS with IPhoneManager.
6. The application receives the status i.e. either SUCCESS or INVALIDPARAM based on successful registration of the listener.
7. The application gets SmsManager object corresponding to specific phone identifier.
8. PhoneFactory returns the SmsManager object to application in order to perform operations like send SMS and get SMSC address.
9. The application sends SMS to the receiver address and optionally gets asynchronous response using CommandResponseCallback.
10. Application receives the status i.e. either SUCCESS or FAILED based on execution of sendSms API in SmsManager.
11. Optionally, the response for send SMS is received by the application.
12. Application gets notified for incoming SMS.
13. The application requests for SmscAddress and optionally gets asynchronous response using ISmscAddressCallback.
14. Application receives the status i.e. either SUCCESS or FAILED based on successful execution of requestSmscAddress API in SmsManager.
15. Optionally, the application receives the SMSC address on success or gets error on failure in the command response callback.

Radio and Service state call flow

1. The application gets PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to get Phone instance.
3. The application gets phone instance for a given phone identifier using PhoneManager object.
4. PhoneManager returns IPhone object to the application.
5. Application registers the listener to get notifications for radio and service state change.
6. The application receives the status i.e. either SUCCESS or FAILED based on the registration of the listener.
7. The application request the Phone to get radio state.
8. The application receives the radio state like RADIO_STATE_ON, OFF or UNAVAILABLE.
9. Application receives a notification when there is a change in radio state.
10. The application request the Phone to get service state.
11. The application receives the service state like IN_SERVICE, OUT_OF_SERVICE, EMERGENCY_ONLY or RADIO_OFF.
12. Application receives a notification when there is a change in service state.

Network Selection Manager call flow

Network selection manager provides APIs to get and set network selection mode, get and set preferred networks and perform network scan for availbale networks. Registered listener will get notified for the change in network selection mode.

1. Application requests phone factory for network selection manager.
2. Phone factory returns INetworkSelectionManager object using which application will register or deregister a listener.
3. Application can register a listener to get notifications for network selection mode change.
4. Status of register listener i.e. either SUCCESS or other status will be returned to the application.
5. Application requests for network selection mode using INetworkSelectionManager object and gets asynchronous response using SelectionModeResponseCallback.
6. The application receives the status i.e. either SUCCESS or other status based on the execution of requestNetworkSelectionMode API.
7. The response for get network selection mode request is received by the application.
8. The application can also set network selection mode and optionally gets asynchronous response using ResponseCallback. MCC and MNC are optional for AUTOMATIC network selection mode.
9. Application receives the status i.e. either SUCCESS or other status based on the execution of setNetworkSelectionMode API.
10. Optionally the response for set network selection mode request is received by the application.
11. Registered listener will get notified for the network selection mode change.
12. Similarly, the application requests for preferred networks using INetworkSelectionManager object and gets asynchronous response using PreferredNetworksCallback.
13. The application receives the status i.e. either SUCCESS or other status based on the execution of requestPreferredNetworks API.
14. The response for get preferred networks request i.e. 3GPP preferred network list and static 3GPP preferred network list is received by the application asynchronously. Higher priority networks appear first in the list. The networks that appear in the 3GPP Preferred Networks list get higher priority than the networks in the static 3GPP preferred networks list.
15. The application can set 3GPP preferred network list and optionally gets asynchronous response using ResponseCallback. If clear previous networks flag is false then new 3GPP preferred network list is appended to existing preferred network list. If flag is true then old list is flushed and new 3GPP preferred network list is added.
16. Application receives the status i.e. either SUCCESS or other status based on the execution of setPreferredNetworks API.
17. Optionally the response for set preferred networks request is received by the application.
18. The application can perform network scan for available networks using INetworkSelectionManager object and gets asynchronous response using NetworkScanCallback.
19. Application receives the status i.e. either SUCCESS or other status based on the execution of performNetworkScan API.
20. Network name, MCC, MNC and status of the operator will be received by the application.
21. Application can deregister a listener there by it would not get notifications.
22. Status of deregister listener i.e. either SUCCESS or other status will be returned to the application.

Serving System Manager Call Flow

Serving system manager provides APIs to get and set RAT mode preference and get and set service domain preference. Registered listener will get notified for the change in RAT mode and service domain preference change.

1. Application requests phone factory for serving system manager.
2. Phone factory returns IServingSystemManager object using which application will register or deregister a listener.
3. Application can register a listener to get notifications for RAT mode and service domain preference changes.
4. Status of register listener i.e. either SUCCESS or other status will be returned to the application.
5. Application requests for RAT mode preference using IServingSystemManager object and gets asynchronous response using RatPreferenceCallback.
6. The application receives the status i.e. either SUCCESS or other status based on the execution of requestRatPreference API.
7. The response for get RAT preference request is received by the application.
8. The application can also set RAT mode preference and optionally gets asynchronous response using ResponseCallback.
9. Application receives the status i.e. either SUCCESS or other status based on the execution of setRatPreference API.
10. Optionally the response for set RAT preference request is received by the application.
11. Registered listener will get notified for the RAT mode preference change.
12. Application requests for service domain preference using IServingSystemManager object and gets asynchronous response using ServiceDomainPreferenceCallback.
13. The application receives the status i.e. either SUCCESS or other status based on the execution of requestServiceDomainPreference API.
14. The response for get service domain preference request is received by the application.
15. The application can also set service domain preference and optionally gets asynchronous response using ResponseCallback.
16. Application receives the status i.e. either SUCCESS or other status based on the execution of setServiceDomainPreference API.
17. Optionally the response for set service domain preference request is received by the application.
18. Registered listener will get notified for the service domain preference change.
19. Application can deregister a listener there by it would not get notifications.
20. Status of deregister listener i.e. either SUCCESS or other status will be returned to the application.

Remote SIM Provisioning Call Flow

Remote SIM provisioning provides API to add profile, delete profile, activate/deactivate profile on the embedded SIMs (eUICC) , get list of profiles, get server address like SMDP+ and SMDS and update SMDP+ address, update nick name of profile and retrieve Embedded Identity Document(EID) of the SIM.

Download and deletion of profile call flow

1. Application requests Phonefactory for SimProfileManager object.
2. Phonefactory returns shared pointer to SimProfileManager object to application using which application performs profile related operations. Wait for subsystem to get ready.
3. If subsystem is ready, create a listener of type ISimProfileListener which would receive notifications about profile download status, user display info and confirmation code is required. Register the created listener with the ISimProfileManager object.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application can send a request to add profile with activation code. The confirmation code can be optional and user consent supported can be specified in order to receive user consent info.
6. Application receives synchronous status which indicates if the add profile request was sent successfully.
7. The response of addProfile request can be received by application in the application-supplied callback. The modem sends indication about the HTTP request in order to download profile to AP and the AP performs HTTP transaction on behalf of modem and sends HTTP request to SMDP+/SMDS server and response of HTTP request from SMDP+/SMDS is sent back to AP and then to modem. The HTTP response contains information related to profile.
8. Optionally, the application receives notification about user consent required and profile policy rules. The application needs to provide the user consent and also reason (if in case consent not provided) in order to proceed with downloading of profile. The application receives the synchronous status which indicates provide user consent sent successfully and response of provide user consent can be received by application in the application-supplied callback. Optionally, the application receives notification about confirmation code required. The application needs to provide the code in order to proceed with downloading of profile. The application receives the synchronous status which indicates confirmation code required sent successfully and response of provide user consent can be received by application in the application-supplied callback.
9. The application receives notification about the download and installation status of profile on the eUICC. When download and installation of profile is completed, notification is also sent to SMDP+/SMDS server.
10. Application can send a delete request associated with profile identifier on SimProfileManager object.
11. Application receives synchronous status which indicates if the delete profile request was sent successfully.
12. The response of delete request can be received by application in the application-supplied callback. Once deletion of profile is completed notification is sent to SMDP+/SMDS server in order to synchronise the profile state on the server.
13. De-register the listener with the ISimProfileManager object.
14. Application receives the status i.e. either SUCCESS or FAILED based on the execution of de-register listener.

SIM profile management operations call flow

The SIM profile sub-system should have been initialized successfully with SERVICE_AVAILABLE as a pre-requisite for remote SIM provisioning operations and a valid SimProfileManager object is available.

1. Application can send a set profile request associated with profile identifier on SimProfileManager object. This allows to enable or disable the profile on the eUICC.
2. Application receives synchronous status which indicates if the set profile request was sent successfully.
3. The response of set profile request can be received by application in the application-supplied callback. Once enable or disable of profile is completed notification is sent to SMDP+/SMDS server in order to synchronise the profile state on the server.
4. Application can send a get profile list request on SimProfileManager object to retrieve the all available profiles on the eUICC with all profile related details like service provider name(SPN), ICCID etc.
5. Application receives synchronous status which indicates if the get profile list request was sent successfully.
6. The response of get profile list request can be received by application in the application-supplied callback along with all the profile details.
7. Application can send a get EID request on SimProfileManager.
8. Application receives synchronous status which indicates if the get EID request was sent successfully.
9. The response of get EID request can be received by application in the application-supplied callback along with EID details.
10. Application can send update nickname of profile request on SimProfileManager.
11. Application receives synchronous status which indicates if the update nickname request was sent successfully.
12. The response of update nickname request can be received by application in the application supplied callback.
13. Application can send memory reset request on SimProfileManager to delete test or operational profiles or set SMDP address to default.
14. Application receives synchronous status which indicates if the memory reset request was sent successfully.
15. The response of memory reset request can be received by application in the application-supplied callback. Once deletion of profiles happens notification is sent to SMDP+/SMDS to synchronise profile state on the server.
16. Application can send set address name on SimProfileManager in order to set SMDP+ address.
17. Application receives synchronous status which indicates if the set address request was sent successfully.
18. The response of set address request can be received by application in the application-supplied callback.
19. Application can send get address name on SimProfileManager in order to get SMDP+/SMDS address.
20. Application receives synchronous status which indicates if the get address request was sent successfully.
21. The response of get address request can be received by application in the application-supplied callback along with SMDP+/SMDS address.

HttpTransaction subsystem readiness and handling of indication from modem call flow

1. Get the reference to the PhoneFactory, with which we can further acquire other remote SIM provisioning sub-system objects.
2. The reference daemon gets the Phonefactory object.
3. Reference daemon requests Phonefactory for HttpTransactionManager object along with init callback which gets called once initialization is completed.
4. Phonefactory returns shared pointer to HttpTransactionManager object to reference daemon using which reference daemon sends HTTP response to modem and register the listener to listen for HTTP transaction indication. If HttpTransactionManager does not exists then create new object.
5. Wait for subsystem to be ready and get the Service status.
6. The reference daemon check the service status whether service is UNAVAILABLE, AVAILABLE or FAILED. If the service status is not AVAILABLE, then wait for init callaback to be called. The subsystem either gets AVAILABLE or FAILED and Service status is recieved in init callback. If the service status is notified as SERVICE_FAILED, retry intitialization starting with step (3).
7. If subsystem is AVAILABLE , then create a listener of type IHttpListener which would receive notifications about HTTP transaction indication. Register the created listener with the IHttpTransactionManager object.
8. Status of register listener i.e. either SUCCESS or FAILED will be returned to the reference daemon.
9. Modem sends the HTTP transaction indication with HTTP request payload and other details to HTTPTransactionManager.
10. The reference daemon on AP receives notification about HTTP transaction which process HTTP request.
11. The reference daemon sends HTTP request result (SUCCESS or FAILURE) with HTTP response back to HTTPTransactionManager.
12. Steps (9-11) keep repeating for multiple HTTP Transaction indication for add, delete, set profile and memory reset operations.

Card Services

Get applications call flow

1. Application gets the CardManager object from PhoneFactory.
2. Application receives CardManager object in order to perform operations like getSlotIds and getCard.
3. The application registers a listener for Card info change event with CardManager.
4. Application receives the status i.e. either SUCCESS or INVALIDPARAM based on the registration of listener.
5. The response from onCardInfoChanged is received by the application whenever there is card info change.
6. The application gets the slotIds from the sub-system using CardManager.
7. Application receives the status i.e. either SUCCESS or NOTREADY along with the updated slotIds.
8. Then, the application sends request to CardManager to get Card object for a specific slotId.
9. Application receives Card object from CardManager in order to perform card operation like getApplications.
10. The application gets the CardApps from Card object.
11. The application receives CardApps which contain information such as AppId, AppType and AppState.
12. Now the application removes the listener associated with CardManager.
13. Application receives the status i.e. either SUCCESS or NOSUCH for the removal of listener.

Transmit APDU call flow

On logical channel

1. The Application requests CardApp for the SIM application identifier.
2. The application receives the application identifier to perform open logical channel.
3. Application sends request to open the logical channel with the application identifier and optionally, gets asynchronous response in OpenLogicalChannelCallback.
4. The application receives the status i.e. either SUCCESS or FAILED based on execution of openLogicalChannel API.
5. Optionally, the application receives the response which contains either channel number on success or error in case of failure.
6. Then, the application transmits the APDU data on logical channel using the channel obtained earlier. Optionally, gets asynchronous response in TransmitApduResponseCallback.
7. The application receives the status i.e. either SUCCESS or FAILED based on execution of transmitApduLogicalChannel API.
8. Optionally, the application receives the response which contains either result on success or error in case of failure.
9. Finally, the application closes the logical channel that is opened to transmit APDU and optionally, gets asynchronous response in CommandResponseCallback.
10. The application receives the status i.e. either SUCCESS or FAILED based on execution of closeLogicalChannel API.
11. Optionally, the application receives the response which contains error in case of failure.

On basic channel

1. Application gets the ICardManager object from PhoneFactory.
2. Application receives ICardManager object in order to perform operation like getCard.
3. The application gets ICard object for a specific slotId from ICardManager.
4. Application receives ICard object in order to perform card operation like transmitApduBasicChannel.
5. The application transmits APDU data on basic channel and optionally, gets asynchronous response in TransmitApduResponseCallback.
6. The application receives the status i.e. either SUCCESS or FAILED based on execution of transmitApduBasicChannel API.
7. Optionally, the application receives the response which contains either result on success or error in case of failure.

SAP card manager call flow

Request card reader status, Request ATR, Transmit APDU call flow

{sap_card_operations.png,Request card reader status, Request ATR, Transmit APDU call flow,80,80,Request card reader status, Request ATR, Transmit APDU call flow}

1. The application gets SapCardManager object corresponding to slotId using PhoneFactory.
2. The application receives the SapCardManager object in order to perform SAP operations like request ATR, Card Reader Status and transmit APDU.
3. The application opens SIM Access Profile(SAP) connection with SIM card using default SAP condition (i.e. SAP_CONDITION_BLOCK_VOICE_OR_DATA) and optionally, gets asynchronous response using CommandResponseCallback.
4. The application receives the status i.e. either SUCCESS or FAILED based on execution of openConnection API in SapCardManager.
5. Optionally, the response for openConnection is received by the application.
6. The application sends request card reader status command and optionally, gets asynchronous response using ICardReaderCallback.
7. The application receives the status i.e. either SUCCESS or FAILED based on execution of requestCardReaderStatus API in SapCardManager.
8. Optionally, the response for card reader status is received by the application.
9. Similarly, the application can send SAP Answer To Reset command and optionally, gets asynchronous response using IAtrResponseCallback.
10. The application receives the status i.e. either SUCCESS or FAILED based on execution of requestAtr API in SapCardManager.
11. Optionally, the response for SAP Answer To Reset is received by the application.
12. Similarly, the application sends the APDU on SAP mode and optionally, gets asynchronous response using ISapTransmitApduResponseCallback.
13. The application receives the status i.e. either SUCCESS or FAILED based on execution of transmitApdu API in SapCardManager.
14. Optionally, the response for transmit APDU is received by the application.
15. Now the application closes the SAP connection with SIM and optionally, gets asynchronous response using CommandResponseCallback.
16. The application receives the status i.e. either SUCCESS or FAILED based on execution of closeConnection API in SapCardManager.
17. Optionally, the response for SAP close connection is received by the application.

SIM Turn off, Turn on and Reset call flow

{sap_mgr_sim_call_flow.png,SIM Turn off, Turn on and Reset call flow,80,80,SIM Turn off, Turn on and Reset call flow}

1. Application gets SapCardManager object corresponding to slotID using PhoneFactory.
2. PhoneFactory returns the SapCardManager object to application in order to perform SAP operations like SIM power off, on or reset.
3. The application opens SIM Access Profile(SAP) connection with SIM card using default SAP condition (i.e. SAP_CONDITION_BLOCK_VOICE_OR_DATA) and optionally, gets asynchronous response using CommandResponseCallback.
4. Application receives the status i.e. either SUCCESS or FAILED based on execution of openConnection API in SapCardManager.
5. Optionally, the response for openConnection is received by the application.
6. The application sends SIM Power Off command to turn off the SIM and optionally, gets asynchronous response using CommandResponseCallback.
7. The application receives the status i.e. either SUCCESS or FAILED based on execution of requestSimPowerOff API in SapCardManager.
8. Optionally, the response for SIM Power Off is received by the application.
9. Similarly, the application can send SIM Power On command to turn on the SIM and optionally, gets asynchronous response using CommandResponseCallback.
10. The application receives the status i.e. either SUCCESS or FAILED based on execution of requestSimPowerOn API in SapCardManager.
11. Optionally, the response for SIM Power On is received by the application.
12. Similarly, the application sends SIM Reset command to perform SIM Reset and optionally, gets asynchronous response.
13. The application receives the status i.e. either SUCCESS or FAILED based on execution of requestSimReset API in SapCardManager.
14. Optionally, the response for SIM Reset is received by the application.
15. Now the application closes the SAP connection with SIM and optionally, gets asynchronous response using CommandResponseCallback.
16. The application receives the status i.e. either SUCCESS or FAILED based on execution of closeConnection API in SapCardManager.
17. Optionally, the response for SAP close connection is received by the application.

Subscription Call flow

Subscription initialization

1. Application can use ISubscriptionManager::isSubsystemReady to determine if the SubscriptionManager is ready.
2. The application receives the status i.e either true or false whether sub-system is ready or not.
3. If it is not ready, then the application could use onSubsystemReady which returns std::future.
4. SubscriptionManager notifies the application when the subsystem is ready through the std::future object.
5. The application waits until the asynchronous operation i.e onSubsystemReady completes.
6. SubscriptionManager uses ICardManager::isSubsystemReady to determine if the CardManager is ready.
7. The SubscriptionManager receives the status i.e either true or false whether sub-system is ready or not.
8. If it is not ready, then the SubscriptionManager could use onSubsystemReady which returns std::future.
9. CardManager notifies the SubscriptionManager when the subsystem is ready through the std::future object.
10. The SubscriptionManager waits until the asynchronous operation i.e onSubsystemReady completes.
11. CardManager updates the SubscriptionManager once the card manager sub-system is ready
12. SubscriptionManager uses ISubscription::isReady to determine if the Subscription is ready.
13. The SubscriptionManager receives the status i.e either true or false whether sub-system is ready or not.
14. If it is not ready, then the SubscriptionManager could use onSubsystemReady which returns std::future.
15. Subscription notifies the SubscriptionManager when the subsystem is ready through the std::future object.
16. The SubscriptionManager waits until the asynchronous operation i.e onSubsystemReady completes.
17. Subscription updates the SubscriptionManager when the subscription is ready.
18. SubscriptionManager updates the application once subscription manager initialization completes.

Subscription call flow

1. The application gets the PhoneManager object using PhoneFactory.
2. The application receives the PhoneManager object in order to get Subscription.
3. The application gets the Subscription object for given slot identifier using SubscriptionManager.
4. SubscriptionManager returns Subscription object to application. Subscription can be used to get subscription details like countryISO, operator details etc.
5. The Subscription manager registers a listener with CardManager to listen to the card info change notifications like card state PRESENT, ABSENT, UNKNOWN, ERROR and RESTRICTED.
6. The SubscriptionManager receives the status like SUCCESS or INVALIDPARAM based on registration of listener to CardManager.
7. The SubscriptionManager receives callback card info change i.e subscription info changed or removed.
8. The SubscriptionManager updates the application once the subscription info is updated.

Call flow for location services

Application will get the location manager object from location factory. The caller needs to register a listener. Application would then need to start the reports using one of 2 APIs depending on if the detailed or basic reports are needed. When reports are no longer required, the app needs to stop the report and de-register the listener.

NOTE: Applications need to have "locclient" Linux group permissions to be able to operate successfully with underlying services.

Call flow to register/remove listener for generating basic reports

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object using which application will register or remove a listener.
3. Application can register a listener for getting notifications for location updates.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application starts the basic reports using startBasicReports API for getting location updates.
6. Status of startBasicReports i.e. either SUCCESS or FAILED will be returned to the application.
7. The response for startBasicReports is received by the application.
8. Application will get location updates like latitude, longitude and altitude etc.
9. Application stops receiving the report through stopReports API.
10. Status of stopReports i.e. either SUCCESS or FAILED will be returned to the application.
11. The response for stopReports is received by the application.
12. Application can remove listener and when the number of listeners are zero then location service will get stopped automatically.
13. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Call flow to register/remove listener for generating detailed reports

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object using which application will register or remove a listener.
3. Application can register a listener for getting notifications for location, satellite vehicle, jammer signal, nmea and measurements updates.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application starts the detailed reports using startDetailedReports API for getting location, satellite vehicle, jammer signal, nmea and measurements updates.
6. Status of startDetailedReports i.e. either SUCCESS or FAILED will be returned to the application.
7. The response for startDetailedReports is received by the application.
8. Application will get location updates like latitude, longitude and altitude etc.
9. Application will receive satellite vehicle information like SV status and constellation etc.
10. Application will receive nmea information.
11. Application will receive jammer information etc.
12. Application will receive measurement information.
13. Application stops receiving all the reports through stopReports API.
14. Status of stopReports i.e. either SUCCESS or FAILED will be returned to the application.
15. The response for stopReports is received by the application.
16. Application can remove listener and when the number of listeners are zero then location service will get stopped automatically.
17. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Call flow to register/remove listener for generating detailed engine reports

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object using which application will register or remove a listener.
3. Application can register a listener for getting notifications for location, satellite vehicle and jammer signal, nmea and measurements updates.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application starts the detailed engine reports using startDetailedEngineReports API for getting location, satellite vehicle, jammer signal, nmea and measurements updates.
6. Status of startDetailedReports i.e. either SUCCESS or FAILED will be returned to the application.
7. The response for startDetailedReports is received by the application.
8. Application will get location updates like latitude, longitude and altitude etc from the requested engine type(SPE/PPE/Fused).
9. Application will receive satellite vehicle information like SV status and constellation etc depending on the requested SPE/PPE/Fused engine type.
10. Application will receive nmea information depending on the requested SPE/PPE/Fused engine type
11. Application will receive jammer information etc depending on the requested SPE/PPE/Fused engine type.
12. Application will receive measurement information etc depending on the requested SPE/PPE/Fused engine type.
13. Application stops receiving all the reports through stopReports API.
14. Status of stopReports i.e. either SUCCESS or FAILED will be returned to the application.
15. The response for stopReports is received by the application.
16. Application can remove listener and when the number of listeners are zero then location service will be stopped automatically.
17. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Call flow to register/remove listener for system info updates

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object using which application will register or remove a listener.
3. Application can register a listener for system information updates with registerForSystemInfoUpdates.
4. Status of registerForSystemInfoUpdates i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for registerForSystemInfoUpdates is received by the application.
6. Application will get system information update.
7. Application can remove listener with deRegisterForSystemInfoUpdates.
8. Status of deRegisterForSystemInfoUpdates i.e. either SUCCESS or FAILED will be returned to the application.
9. The response for deRegisterForSystemInfoUpdates is received by the application.

Call flow to request energy consumed information

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object.
3. Application can request for energy consumed information with requestEnergyConsumedInfo.
4. Status of requestEnergyConsumedInfo i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for requestEnergyConsumedInfo is received by the application.

Call flow to get year of hardware information

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object.
3. Application can request for year of hardware information with getYearOfHw.
4. Status of getYearOfHw i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for getYearOfHw is received by the application.

Call flow to get terrestrial positioning information

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object.
3. Application can request for terrestrial positioning information with getTerrestrialPosition API.
4. Status of getTerrestrialPosition i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for getTerrestrialPosition is received by the application.
6. Single shot terrestrial position information is received by the application.

Call flow to cancel terrestrial positioning information

1. Application requests location factory for location manager object.
2. Location factory returns ILocationManager object.
3. Application can cancel request for terrestrial positioning information with cancelTerrestrialPositionRequest API.
4. Status of cancelTerrestrialPositionRequest i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for cancelTerrestrialPositionRequest is received by the application.

Call flow to enable/disable constraint time uncertainty

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application enables/disables constraint tunc using configureCTunc API.
4. Status of configureCTunc i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureCTunc is received by the application.

Call flow to enable/disable PACE

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application enables/disables PACE using configurePACE API.
4. Status of configurePACE i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configurePACE is received by the application.

Call flow to delete all aiding data

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application deletes all aiding data using deleteAllAidingData API.
4. Status of deleteAllAidingData i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for deleteAllAidingData is received by the application.

Call flow to configure lever arm parameters

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures lever arm parameters using configureLeverArm API.
4. Status of configureLeverArm i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureLeverArm is received by the application.

Call flow to configure blacklisted constellations

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures blacklisted constellations using configureConstellations API.
4. Status of configureConstellations i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureConstellations is received by the application.

Call flow to configure robust location

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures robust location using configureRobustLocation API.
4. Status of configureRobustLocation i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureRobustLocation is received by the application.

Call flow to configure min gps week

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures min gps week using configureMinGpsWeek API.
4. Status of configureMinGpsWeek i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureMinGpsWeek is received by the application.

Call flow to request min gps week

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application requests min gps week using requestMinGpsWeek API.
4. Status of requestMinGpsWeek i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for requestMinGpsWeek is received by the application.

Call flow to delete specified data

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application requests delete specified data using deleteAidingData API.
4. Status of deleteAidingData i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for deleteAidingData is received by the application.

Call flow to configure min sv elevation

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures min SV elevation using configureMinSVElevation API.
4. Status of configureMinSVElevation i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureMinSVElevation is received by the application.

Call flow to request min sv elevation

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application requests min SV elevation using requestMinSVElevation API.
4. Status of requestMinSVElevation i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for requestMinSVElevation is received by the application.

Call flow to request robust location

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application requests robust location using requestRobustLocation API.
4. Status of requestRobustLocation i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for requestRobustLocation is received by the application.

Call flow to configure dead reckoning engine

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures dead reckoning engine using configureDR API.
4. Status of configureDR i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureDR is received by the application.

Call flow to configure secondary band

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures secondary band using configureSecondaryBand API.
4. Status of configureSecondaryBand i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureSecondaryBand is received by the application.

Call flow to request secondary band

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application requests secondary band using requestSecondaryBandConfig API.
4. Status of requestSecondaryBandConfig i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for requestSecondaryBandConfig is received by the application.

Call flow to configure engine state

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures engine state using configureEngineState API.
4. Status of configureEngineState i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureEngineState is received by the application.

Call flow to provide user consent for terrestrial positioning

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application provides user consent for terrestrial positioning using provideConsentForTerrestrialPositioning API.
4. Status of provideConsentForTerrestrialPositioning i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for provideConsentForTerrestrialPositioning is received by the application.

Call flow to configure NMEA sentence type

1. Application requests location factory for location configurator object.
2. Location factory returns ILocationConfigurator object.
3. Application configures NMEA sentence type using configureNmeaTypes API.
4. Status of configureNmeaTypes i.e. either SUCCESS or FAILED will be returned to the application.
5. The response for configureNmeaTypes is received by the application.

Data Services

Applications need to have "radio" Linux group permissions to be able to operate successfully with underlying services.

Start/Stop for data connection manager call flow

1. Application requests Data Connection Manager object associated with sim id from data factory. Application can optionally provide callback to be called when manager initialization is completed.
2. Data factory returns shared pointer to data connection manager object to application.
3. Application request current service status of data connection manager returned by data factory.
4. Data connection manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Data connection manager calls application callback with initialization result (success/failure).
5. Application registers as listener to get notifications for data call change.
6. The application receives the status i.e. either SUCCESS or FAILED based on the registration of the listener.
7. Application requests for start data call and optionally gets asynchronous response using startDataCallback.
8. Application receives the status i.e. either SUCCESS or FAILED based on the execution of startDataCall.
9. Optionally, the application gets asynchronous response for startDataCall using startDataCallback.
10. Application requests for stop data call and optionally gets asynchronous response using stopDataCallback.
11. Application receives the status i.e. either SUCCESS or FAILED based on the execution of stopDataCall.
12. Optionally, the application gets asynchronous response for stopDataCall using stopDataCallback.

Request data profile list call flow

1. Application requests Data profile Manager object associated with sim id from data factory. Application can optionally provide callback to be called when manager initialization is completed.
2. Data factory returns shared pointer to data profile manager object to application.
3. Application request current service status of data profile manager returned by data factory.
4. Data profile manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Data profile manager calls application callback with initialization result (success/failure).
5. Application creates listener class of type IDataProfileListener
6. Application register created object in step 5 as listener to data profile changes
7. Application receives the status i.e. either SUCCESS or FAILED based on the execution of registerListener
8. Application requests list of profile
9. Application receives the status i.e. either SUCCESS or FAILED based on the execution of requestProfileList
10. Application gets callback with list of all profiles

Data Serving System Manager Call Flow

Data Serving System manager provides the interface to access network and modem low level services. It provides APIs to get current dedicated radio bearer, get current service status and preferred RAT, and get current roaming status. Serving System Listener provides an interface for application to receive data serving system notification events such as change in dedicated radio bearer, change in service status, or change in roaming status. The application must register as a listener for Serving System updates.

Get Dedicated Radio Bearer Call Flow

1. Application requests data factory for data serving system manager object with slot Id and init callback.
2. Data factory returns IServingSystemManager object to application.
3. Serving System Manager calls application callback provided in step 1 with initialization result pass/fail.
4. Application register itself as listener with Serving System manager to receive dedicated radio bearer changes notification.
5. Application gets success for registering as listener.
6. Application calls getDrbStatus to get current dedicated radio bearer status.
7. Application receives the current dedicated bearer status.
8. Dedicated radio bearer changes in modem
9. Application gets onDrbStatusChanged indication with new status

Request Service Status Call Flow

1. Application requests data factory for data serving system manager object with slot Id and init callback.
2. Data factory returns IServingSystemManager object to application.
3. Serving System Manager calls application callback provided in step 1 with initialization result pass/fail.
4. Application register itself as listener with Serving System manager to receive service status changes notification.
5. Application gets success for registering as listener.
6. Application calls requestServiceStatus to get current service status and provides callback.
7. Application receives the status i.e. either SUCCESS or FAILED based on the execution of requestServiceStatus.
8. Application gets asynchronous response for requestServiceStatus through callback provided in step 4 with current service status.
9. Service status changes in modem
10. Application gets onServiceStateChanged indication with new status

Request Roaming Status Call Flow

1. Application requests data factory for data serving system manager object with slot Id and init callback.
2. Data factory returns IServingSystemManager object to application.
3. Serving System Manager calls application callback provided in step 1 with initialization result pass/fail.
4. Application register itself as listener with Serving System manager to receive roaming status changes notification.
5. Application gets success for registering as listener.
6. Application calls requestRoamingStatus to get current service status and provides callback.
7. Application receives the status i.e. either SUCCESS or FAILED based on the execution of requestRoamingStatus.
8. Application gets asynchronous response for requestRoamingStatus through callback provided in step 4 with current service status.
9. Roaming status changes in modem
10. Application gets onRoamingStatusChanged indication with new status

Data Filter Manager Call Flow

Data Filter manager provides APIs to get/set data filter mode, add/remove data restrict filters. Its API can used per data call or globally to apply the same changes to all the underlying currently up data call. It also has listener interface for notifications for data filter status update. Application will get the Data Filter manager object from data factory. The application can register a listener for data filter mode change updates.

Call flow to Set/Get data filter mode

1. Application requests data factory for data connection manager object.
2. Data factory returns IDataConnectionManager object to application.
3. Application requests data factory for data filter manager object.
4. Data factory returns IDataFilterManager object to application.
5. Application requests for start data call and optionally gets asynchronous response using startDataCallback.
6. Application receives the status i.e. either SUCCESS or FAILED based on the execution of startDataCall.
7. Optionally, the application gets asynchronous response for startDataCall using startDataCallback.
8. Application requests for set data filter mode to enable and optionally gets asynchronous response using ResponseCallback.
9. Application receives the status i.e. either SUCCESS or FAILED based on the execution of setDataRestrictMode.
10. Optionally, the application gets asynchronous response for setDataRestrictMode using ResponseCallback.
11. Application requests for get data filter mode and optionally gets asynchronous response using DataRestrictModeCb.
12. Application receives the status i.e. either SUCCESS or FAILED based on the execution of requestDataRestrictMode.
13. Optionally, the application gets asynchronous response for requestDataRestrictMode using DataRestrictModeCb.

Call flow to Add data restrict filter

1. Application requests data factory for data connection manager object.
2. Data factory returns IDataConnectionManager object to application.
3. Application requests data factory for data filter manager object.
4. Data factory returns IDataFilterManager object to application.
5. Application requests for start data call and optionally gets asynchronous response using startDataCallback.
6. Application receives the status i.e. either SUCCESS or FAILED based on the execution of startDataCall.
7. Optionally, the application gets asynchronous response for startDataCall using startDataCallback.
8. Application requests for add data filter and optionally gets asynchronous response using ResponseCallback.
9. Application receives the status i.e. either SUCCESS or FAILED based on the execution of addDataRestrictFilter.
10. Optionally, the application gets asynchronous response for addDataRestrictFilter using ResponseCallback.

Call flow to Remove data restrict filter

1. Application requests data factory for data connection manager object.
2. Data factory returns IDataConnectionManager object to application.
3. Application requests data factory for data filter manager object.
4. Data factory returns IDataFilterManager object to application.
5. Application requests for start data call and optionally gets asynchronous response using startDataCallback.
6. Application receives the status i.e. either SUCCESS or FAILED based on the execution of startDataCall.
7. Optionally, the application gets asynchronous response for startDataCall using startDataCallback.
8. Application requests for add data filter and optionally gets asynchronous response using ResponseCallback.
9. Application receives the status i.e. either SUCCESS or FAILED based on the execution of removeAllDataRestrictFilters.
10. Optionally, the application gets asynchronous response for removeAllDataRestrictFilters using ResponseCallback.

Data Networking Call Flow

Application will get the following manager objects from data factory to configure networking. IVlanManager is used to access all VLAN APIs. INatManager is used to access all Static NAT APIs. IFirewallManager is used to access all Firewall APIs.

Create VLAN and Bind it to PDN in data vlan manager call flow

1. Application requests data factory for data IVlanManager object. Application can optionally provide callback to be called when manager initialization is completed. 1.1. If IVlanManager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to IVlanManager object to application.
3. Application request current service status of vlan manager returned by data factory
4. The application receives the Status i.e. either true or false to indicate whether sub-system is ready or not. 4.1. If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1 4.2. Vlan manager calls application callback with initialization result (success/failure).
5. On success, application calls IVlanManager::createVlan with assigned id, interface, and acceleration type.
6. Application receives synchronous Status which indicates if the IVlanManager::createVlan request was sent successfully.
7. Application is notified of the Status of the IVlanManager::createVlan request (either SUCCESS or FAILED) via the application-supplied callback.
8. Application calls IVlanManager::bindWithProfile with Vlan id and profile id.
9. Application receives synchronous Status which indicates if the IVlanManager::bindWithProfile request was sent successfully.

1. Application is notified of the Status of the IVlanManager::bindWithProfile request (either SUCCESS or FAILED) via the application-supplied callback.

LAN-LAN VLAN Configuration from EAP usecase call flow

1. Application requests data factory for data IVlanManager for local operation object. Aplication can optionally provide callback to be called when manager initialization is completed.
2. Data factory returns shared pointer to local vlan manager object to application.
3. Application request current service status of local vlan manager returned by data factory.
4. Vlan manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Vlan manager calls application callback with initialization result (success/failure).
5. On success, application calls IVlanManager::createVlan with USB interface, Vlan id 1 and no acceleration.
6. Vlan manager returns synchronous response to application (success/fail).
7. Vlan manager calls application provided callback in step 5 with createVlan results
8. Application requests data factory for data IVlanManager for remote operation object. Aplication can optionally provide callback to be called when manager initialization is completed.
9. Data factory returns shared pointer to remote vlan manager object to application.
10. Application request current service status of remote vlan manager returned by data factory.
11. Vlan manager returns current service status. 11.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 11.2 Vlan manager calls application callback with initialization result (success/failure).
12. On success, application calls IVlanManager::createVlan with USB interface, Vlan id 1 and acceleration.
13. Vlan manager returns synchronous response to application (success/fail).
14. Vlan manager calls application provided callback in step 12 with createVlan results.
15. Application calls IVlanManager::createVlan with ETH interface, Vlan id 1 and acceleration.
16. Vlan manager returns synchronous response to application (success/fail).
17. Vlan manager calls application provided callback in step 15 with createVlan results.

LAN-LAN VLAN Configuration from A7 usecase call flow

1. Application requests data factory for data IVlanManager for local operation object. Aplication can optionally provide callback to be called when manager initialization is completed.
2. Data factory returns shared pointer to local vlan manager object to application.
3. Application request current service status of local vlan manager returned by data factory.
4. Vlan manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Vlan manager calls application callback with initialization result (success/failure).
5. On success, application calls IVlanManager::createVlan with USB interface, Vlan id 1 and acceleration.
6. Vlan manager returns synchronous response to application (success/fail).
7. Vlan manager calls application provided callback in step 5 with createVlan results.
8. Application calls IVlanManager::createVlan with ETH interface, Vlan id 1 and acceleration.
9. Vlan manager returns synchronous response to application (success/fail).
10. Vlan manager calls application provided callback in step 8 with createVlan results.

LAN-WAN VLAN Configuration from EAP usecase call flow

1. Application requests data factory for local data vlan manager object.
2. Data factory returns shared pointer to local vlan manager to application.
3. Application request current service status of local vlan manager returned by data factory.
4. Vlan manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Vlan manager calls application callback with initialization result (success/failure).
5. On success, application calls IVlanManager::createVlan with USB interface, Vlan id 1 and no acceleration.
6. Vlan manager returns synchronous response to application (success/fail).
7. Vlan manager calls application provided callback in step 5 with createVlan results.
8. Application requests data factory for remote data vlan manager object.
9. Data factory returns shared pointer to remote vlan manager to application.
10. Application request current service status of remote vlan manager returned by data factory.
11. Vlan manager returns current service status. 11.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 8. 11.2 Vlan manager calls application callback with initialization result (success/failure).
12. On success, application calls IVlanManager::createVlan with USB interface, Vlan id 1 and acceleration.
13. Vlan manager returns synchronous response to application (success/fail).
14. Vlan manager calls application provided callback in step 12 with createVlan results.
15. Application calls IVlanManager::createVlan with ETH interface, Vlan id 1 and acceleration.
16. Vlan manager returns synchronous response to application (success/fail).
17. Vlan manager calls application provided callback in step 15 with createVlan results.
18. Application calls IVlanManager::bindWithProfile with profile id to bind with.
19. Vlan manager returns synchronous response to application (success/fail).
20. Vlan manager calls application provided callback in step 18 with bindWithProfile results. If DMZ is needed:
    1. Application requests data factory for firewall manager object.
    2. Data factory returns shared pointer to firewall manager to application.
    3. Application request current service status of firewall manager returned by data factory.
    4. Firewall manager returns current service status. 24.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 21. 24.2 Firewall manager calls application callback with initialization result (success/failure).
    5. Application calls firewall manager enableDmz with profile id and local address to be enable Dmz on.
    6. Firewall manager returns synchronous response to application (success/fail).
    7. Firewall manager calls application provided callback in step 25 with enableDmz results.
21. Application requests data factory for data connection manager object.
22. Data factory returns shared pointer to data connection manager to application.
23. Application request current service status of data connection manager returned by data factory.
24. Data connection manager returns current service status. 31.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 28. 31.2 Data connection manager calls application callback with initialization result (success/failure).
25. Application can call data Connection manager startDataCall with profile id to start data call on, Ip Family type, operation Type and APN Name.
26. Data connection Manager returns synchronous response to application (success/fail).
27. Data connection Manager returns notification to application with data call details.

LAN-WAN VLAN Configuration from A7 usecase call flow

1. Application requests data factory for local data vlan manager object.
2. Data factory returns shared pointer to local vlan manager to application.
3. Application request current service status of local vlan manager returned by data factory.
4. Vlan manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Vlan manager calls application callback with initialization result (success/failure).
5. On success, application calls IVlanManager::createVlan with USB interface, Vlan id 1 and acceleration.
6. Vlan manager returns synchronous response to application (success/fail).
7. Vlan manager calls application provided callback in step 5 with createVlan results.
8. Application calls IVlanManager::createVlan with ETH interface, Vlan id 1 and acceleration.
9. Vlan manager returns synchronous response to application (success/fail).
10. Vlan manager calls application provided callback in step 8 with createVlan results.
11. Application calls IVlanManager::bindWithProfile with profile id to bind with.
12. Vlan manager returns synchronous response to application (success/fail).
13. Vlan manager calls application provided callback in step 11 with bindWithProfile results. If DMZ is needed:
    1. Application requests data factory for firewall manager object.
    2. Data factory returns shared pointer to firewall manager to application.
    3. Application request current service status of firewall manager returned by data factory.
    4. Firewall manager returns current service status. 17.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 14. 17.2 Firewall manager calls application callback with initialization result (success/failure).
    5. Application calls firewall manager enableDmz with profile id and local address to be enable Dmz on.
    6. Firewall manager returns synchronous response to application (success/fail).
    7. Firewall manager calls application provided callback in step 25 with enableDmz results.
14. Application requests data factory for data connection manager object.
15. Data factory returns shared pointer to data connection manager to application.
16. Application request current service status of data connection manager returned by data factory.
17. Data connection manager returns current service status. 24.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 21. 24.2 Data connection manager calls application callback with initialization result (success/failure).
18. Application can call data Connection manager startDataCall with profile id to start data call on, Ip Family type, operation Type and APN Name.
19. Data connection Manager returns synchronous response to application (success/fail).
20. Data connection Manager returns notification to application with data call details.

Create Static NAT entry in data Static NAT manager call flow

1. Application requests data factory for data nat manager object. 1.1. If nat manager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to nat manager object to application.
3. Application request current service status of nat manager returned by data factory.
4. Nat manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Nat manager calls application callback with initialization result (success/failure).
5. On success, application calls nat manager addStaticNatEntry with profileId, private IP address port, private port, global port and IP Protocol.
6. Application receives synchronous Status which indicates if the nat manager addStaticNatEntry request was sent successfully.
7. Application is notified of the result of the nat manager addStaticNatEntry request (either SUCCESS or FAILED) via the application-supplied callback.

Firewall Enablement in data Firewall manager call flow

1. Application requests data factory for data firewall manager object. 1.1. If firewall manager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to firewall manager object to application.
3. Application request current service status of firewall manager returned by data factory.
4. Firewall manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Firewall manager calls application callback with initialization result (success/failure).
5. On success, application calls firewall manager setFirewall with enable/disable and allow/drop packets.
6. Application receives synchronous Status which indicates if the firewall manager setFirewall request was sent successfully.
7. Application is notified of the Status of the firewall manager setFirewall request (either SUCCESS or FAILED) via the application-supplied callback.

Add Firewall Entry in data Firewall manager call flow

1. Application requests data factory for data firewall manager object. 1.1. If firewall manager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to firewall manager object to application.
3. Application request current service status of data profile manager returned by data factory.
4. Firewall manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Firewall manager calls application callback with initialization result (success/failure).
5. On success, application calls firewall manager getNewFirewallEntry to get FirewallEntry object.
6. Application receives Firewall Entry object.
7. Using Firewall Entry object, application calls IFirewallEntry::getIProtocolFilter to get protocol filter object
8. Application receives IpFilter object.
9. Application populates FirewallEntry and IpFilter objects.
10. Application calls IFirewallManager::addFirewallEntry with profileId and FirewallEntry to add firewall entry
11. Application receives synchronous Status which indicates if addFirewallEntry was sent successfully
12. Application is notified of the Status of the IFirewallManager::addFirewallEntry request (either SUCCESS or FAILED) via the application-supplied callback.

Set Firewall DMZ in data Firewall manager call flow

1. Application requests data factory for data firewall manager object. 1.1. If firewall manager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to firewall manager object to application.
3. Application request current service status of firewall manager returned by data factory.
4. Firewall manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Firewall manager calls application callback with initialization result (success/failure).
5. On success, application calls firewall manager enableDmz with profileId and IP Address.
6. Application receives synchronous Status which indicates if the firewall manager enableDmz request was sent successfully.
7. Application is notified of the Status of the firewall manager enableDmz request (either SUCCESS or FAILED) via the application-supplied callback.

Socks Enablement in data Socks manager call flow

1. Application requests data factory for data socks manager object. 1.1. If socks manager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to socks manager object to application.
3. Application request current service status of socks manager returned by data factory.
4. Socks manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Socks manager calls application callback with initialization result (success/failure).
5. On success, application calls socks manager enableSocks with enable/disable.
6. Application receives synchronous Status which indicates if the socks manager enableSocks request was sent successfully.
7. Application is notified of the Status of the socks manager enableSocks request (either SUCCESS or FAILED) via the application-supplied callback.

L2TP Enablement and Configuration in data L2TP manager call flow

1. Application requests data factory for data l2tp manager object. 1.1. If l2tp manager object does not exist, data factory will create new object.
2. Data factory returns shared pointer to l2tp manager object to application.
3. Application request current service status of l2tp manager returned by data factory.
4. L2tp manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 L2tp manager calls application callback with initialization result (success/failure).
5. On success, application calls l2tp manager setConfig with enable/disable, enable/disable Mss, enable/disable MTU size and MTU size
6. Application receives synchronous Status which indicates if the l2tp manager setConfig request was sent successfully.
7. Application is notified of the Status of the l2tp manager setConfig request (either SUCCESS or FAILED) via the application-supplied callback.
8. Application calls l2tp manager setConfig with all required configurations to setup tunnel and session
9. Application receives synchronous Status which indicates if the l2tp manager setConfig request was sent successfully.
10. Application is notified of the Status of the l2tp manager setConfig request (either SUCCESS or FAILED) via the application-supplied callback.

Call flow to add and enable software bridge

1. Application requests data factory for bridge manager object.
2. Data factory returns shared pointer to bridge manager object to application.
3. Application request current service status of bridge manager returned by data factory.
4. Bridge manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Bridge manager calls application callback with initialization result (success/failure).
5. On success, application requests to add software bridge configuration for an interface, providing an optional asynchronous response callback using addBridge API.
6. Application receives the synchronous status i.e. either SUCCESS or FAILED which indicates if the request was sent successfully.
7. Optionally, the application gets asynchronous response for addBridge via the application-supplied callback.
8. If the software bridge management is not enabled already, application requests to enable it, providing an optional asynchronous response callback using enableBridge API. Please note that this step affects all the software bridges configured in the system.
9. Application receives the status i.e. either SUCCESS or FAILED which indicates if the request was sent successfully.
10. Optionally, the application gets asynchronous response for enableBridge via the application-supplied callback.

Call flow to remove and disable software bridge

1. Application requests data factory for bridge manager object.
2. Data factory returns shared pointer to bridgeManager object to application.
3. Application request current service status of bridge manager returned by data factory.
4. Bridge manager returns current service status. 4.1 If status returned is SERVICE_UNAVAILABLE (manager is not ready), application should wait for init callback provided in step 1. 4.2 Bridge manager calls application callback with initialization result (success/failure).
5. On success, application requests to get the list of software bridge configurations, providing an asynchronous response callback using requestBridgeInfo API.
6. Application receives the synchronous status i.e. either SUCCESS or FAILED which indicates if the request was sent successfully.
7. The application gets asynchronous response for requestBridgeInfo via the application-supplied callback.
8. Application requests to remove software bridge configuration for an interface, providing an optional asynchronous response callback using removeBridge API.
9. Application receives the synchronous status i.e. either SUCCESS or FAILED which indicates if the request was sent successfully.
10. Optionally, the application gets asynchronous response for removeBridge via the application-supplied callback.
11. If the software bridge management needs to be disabled, application requests to disable it, providing an optional asynchronous response callback using enableBridge API. Please note that this step affects all the software bridges configured in the system.
12. Application receives the status i.e. either SUCCESS or FAILED which indicates if the request was sent successfully.
13. Optionally, the application gets asynchronous response for enableBridge via the application-supplied callback.

C-V2X

Applications need to have "radio" Linux group permissions to be able to operate successfully with underlying services.

Retrieve/Update C-V2X configuration

1. Application requests C-V2X factory for a C-V2X Config instance.
2. C-V2X factory creates ICv2xConfig object and calls init() method of ICv2xConfig.
3. C-V2X config starts initialization asynchronously.
4. C-V2X factory return ICv2xConfig object to application.
5. C-V2X factory is asynchronously notified of the readiness status of the C-V2X config via the initialization callback.
6. C-V2X factory calls application-supplied callback to notify the readiness status of C-V2X config (either SERVICE_AVAILABLE or SERVICE_FAILED). If the status is SERVICE_AVAILABLE, application can then request to retrieve or update C-V2X configuration.
7. Application requests to retrieve C-V2X configuration by calling retrieveConfiguration and supplying it with a path for the storing of config XML file.
8. C-V2X config sends request to modem and waits for response asynchronously.
9. Application receives synchronous status.
10. Application is asynchronously notified of the status of the request (either SUCCESS or FAILED) via the application-supplied callback.
11. Application requests to update C-V2X configuration by calling updateConfiguration and supplying it with a path to the new config XML file.
12. C-V2X config sends request to modem and waits for response asynchronously.
13. Application receives synchronous status.
14. Application is asynchronously notified of the status of the request (either SUCCESS or FAILED) via the application-supplied callback.

C-V2X radio manager initialization

This call flow diagram describes the sequence of steps for initialing the ICv2xRadioManager object. Applications must perform this sequence before calling any other methods on the object.

1. Application requests C-V2X factory for a C-V2X radio manager instance.
2. C-V2X factory creates ICv2xRadioManager object and calls init() method of ICv2xRadioManager.
3. C-V2X radio manager starts initialization asynchronously.
4. C-V2X factory returns ICv2xRadioManager object to application.
5. C-V2X factory is asynchronously notified of the readiness status of the C-V2X radio manager via the initialization callback.
6. C-V2X factory calls application-supplied callback to notify the readiness status of C-V2X radio manager (either SERVICE_AVAILABLE or SERVICE_FAILED).

Get C-V2X status

Note: Application must perform C-V2X radio manager initialization before calling any methods of ICv2xRadioManager.

1. Application requests current C-V2X status using requestCv2xStatus method.
2. Application receives synchronous status (either SUCCESS or FAILED) which indicates if the request was sent successfully.
3. Application is asynchronously notified of the status of the request (either SUCCESS or FAILED) via the application-supplied callback. If SUCCESS, the requested C-V2X status is returned in the callback.
4. Application register a listener for getting notifications of C-V2X status update.
5. Status of register listener (either SUCCESS or FAILED) will be returned to the application.
6. Application will get C-V2X status updates.
7. Application deregister the listener.
8. Status of deregistering listener (either SUCCESS or FAILED) will be returned to the application.

Start/Stop C-V2X Mode

Note: Application must perform C-V2X radio manager initialization before calling any methods of ICv2xRadioManager. In normal operation, applications do not need to start or stop C-V2X mode. The system is configured by default to start C-V2X mode at boot. We include the call flow below for the sake of completeness.

1. Application requests to put modem into C-V2X mode using startCv2x method.
2. Application receives synchronous status which indicates if the start request was sent successfully.
3. Application is notified of the status of the start request (either SUCCESS or FAILED) via the application-supplied callback.
4. Application requests to disable C-V2X mode using stopCv2x method.
5. Application receives synchronous status which indicates if the stop request was sent successfully.
6. Application is asynchronously notified of the status of the stop request (either SUCCESS or FAILED) via the application-supplied callback.

C-V2X radio Initialization

This call flow diagram describes the sequence of steps for initialing the ICv2xRadio object. Applications must perform this sequence before calling any other methods on the object. Note: for simplicity's sake, we omit this sequence in the remaining C-V2X Radio call flow diagrams but it's inclusion is implied.

1. Application requests C-V2X Radio from ICv2xRadioManager.
2. C-V2X radio manager creates ICv2xRadio object and calls method init().
3. C-V2X radio starts initialization asynchronously.
4. C-V2X radio manager returns ICv2xRadio object to application.
5. Application queries C-V2X radio's readiness state using isReady() method.
6. C-V2X radio returns a bool indicating whether it is ready to be used.
7. If C-V2X radio is not ready, the application calls onReady() method.
8. C-V2X radio returns a future object.
9. Application calls future's get() method and blocks until C-V2X radio has completed its initialization steps. The return value of get() indicates the status of the initialization (either SUCCESS or FAILED).

C-V2X radio RX subscription

Note: Application must perform C-V2X radio initialization before calling any methods of ICv2xRadio.

1. Application requests a new RX subscription from the C-V2X radio using createRxSubscription method.
2. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
3. C-V2X radio sends asynchronous notification via the callback function on the status of the request. If SUCCESS, the RX subscription is returned in the callback.
4. Application requests to close the RX subscription.
5. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
6. C-V2X radio sends asynchronous notification via the callback (if a callback was specified) indicating the status of the request.

C-V2X radio TX event flow

Note: Application must perform C-V2X radio initialization before calling any methods of ICv2xRadio.

1. Application requests a new TX event flow from the C-V2X radio using createTxEventFlow method.
2. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
3. C-V2X radio sends asynchronous notification via the callback function on the status of the request. If SUCCESS, the TX event flow is returned in the callback.
4. Application requests to close the TX event flow.
5. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
6. C-V2X radio sends asynchronous notification via the callback (if a callback was specified) indicating the status of the request.

C-V2X radio TX SPS flow

Note: Application must perform C-V2X radio initialization before calling any methods of ICv2xRadio.

1. Application requests a new TX SPS flow from the C-V2X radio using createTxSPSFlow method. The application can also specify an optional Tx event flow.
2. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
3. C-V2X radio sends asynchronous notification via the callback function. The callback will return the Tx SPS flow and its status as well as the optional Tx event flow and its status.
4. Application requests to change the SPS parameters using the changeSpsFlowInfo method.
5. Application received synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
6. C-V2X radio sends asynchronous notification via the callback (if callback was specified) indicating the status of the request.
7. Application requests to close the SPS flow.
8. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
9. C-V2X radio sends asynchronous notification via the callback (if a callback was specified) indicating the status of the request.
10. Application requests to close optional Tx event flow (if one was created).
11. Application receives synchronous status (either SUCCESS or FAILED) indicating whether the request was sent successfully.
12. C-V2X radio sends asynchronous notification via the callback (if a callback was specified) indicating the status of the request.

C-V2X Throttle Manager Filer rate adjustment notification flow

1. Application requests C-V2X factory for a C-V2X Throttle Manager.
2. C-V2X factory return ICv2xThrottleManager object to application.
3. Application register a listener for getting notifications of filter rate update.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application will get filter rate updates, positive value indicates to the application to filter more messages, and negative value indicates to the application to filter less messages
6. Application deregister the listener.
7. Status of deregistering listener, i.e. either SUCCESS or FAILED will be returned.

C-V2X Throttle Manager set verification load flow

1. Application requests C-V2X factory for a C-V2X Throttle Manager.
2. C-V2X factory return ICv2xThrottleManager object to application.
3. Application set verification load using setVerificationLoad method.
4. Application receives synchronous status which indicates if the request was sent successfully.
5. Application is notified of the status of the request (either SUCCESS or FAILED) via the application-supplied callback.

Audio

Audio Manager API call flow

1. Application requests Audio factory for an Audio Manager and passes callback pointer.
2. Audio factory return IAudioManager object to application.
3. Application can use IAudioManager::getServiceStatus to determine the state of sub system.
4. The application receives the ServiceStatus of sub system which indicates the state of service.
5. AudioManager notifies the application when the subsystem is ready through the callback mechanism.
6. On Readiness, Application requests supported device types using getDevices method.
7. Application receives synchronous Status which indicates if the getDevices request was sent successfully.
8. Application is notified of the Status of the getDevices request (either SUCCESS or FAILED) via the application-supplied callback, with array of supported device types.
9. Application requests supported stream types using getStreamTypes method.
10. Application receives synchronous Status which indicates if the getStreamTypes request was sent successfully.
11. Application is notified of the Status of the getStreamTypes request (either SUCCESS or FAILED) via the application-supplied callback, with array of supported stream types.
12. Application requests create audio stream using createStream method.
13. Application receives synchronous Status which indicates if the createStream request was sent successfully.
14. Application is notified of the Status of the createStream request (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface.
15. Application requests delete audio stream using deleteStream method.
16. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
17. Application is notified of the Status of the deleteStream request (either SUCCESS or FAILED) via the application-supplied callback.

Audio Voice Call Start/Stop call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests create audio voice stream using createStream method with streamType as VOICE_CALL.
4. Application receives synchronous Status which indicates if the createStream request was sent successfully.
5. Application is notified of the Status of the createStream request (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioVoiceStream.
6. Application requests start audio stream using startAudio method on IAudioVoiceStream.
7. Application receives synchronous Status which indicates if the startAudio request was sent successfully.
8. Application is notified of the Status of the startAudio request (either SUCCESS or FAILED) via the application-supplied callback.
9. Application requests stop audio stream using stopAudio method on IAudioVoiceStream.
10. Application receives synchronous Status which indicates if the stopAudio request was sent successfully.
11. Application is notified of the Status of the stopAudio request (either SUCCESS or FAILED) via the application-supplied callback.
12. Application requests delete audio stream using deleteStream method.
13. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
14. Application is notified of the Status of the deleteStream request (either SUCCESS or FAILED) via the application-supplied callback.

Audio Voice Call Device Switch call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests create audio voice stream using createStream method with streamType as VOICE_CALL.
4. Application receives synchronous Status which indicates if the createStream request was sent successfully.
5. Application is notified of the Status of the createStream request (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioVoiceStream.
6. Application requests start audio stream using startAudio method on IAudioVoiceStream.
7. Application receives synchronous Status which indicates if the startAudio request was sent successfully.
8. Application is notified of the Status of the startAudio request (either SUCCESS or FAILED) via the application-supplied callback.
9. Application requests new device routing of stream using setDevice method on IAudioVoiceStream.
10. Application receives synchronous Status which indicates if the setDevice request was sent successfully.
11. Application is notified of the Status of the setDevice request (either SUCCESS or FAILED) via the application-supplied callback.
12. Application query device stream routed to using getDevice method on IAudioVoiceStream.
13. Application receives synchronous Status which indicates if the getDevice request was sent successfully.
14. Application is notified of the Status of the getDevice request (either SUCCESS or FAILED) via the application-supplied callback, along with device types.
15. Application requests stop audio stream using stopAudio method on IAudioVoiceStream.
16. Application receives synchronous Status which indicates if the stopAudio request was sent successfully.
17. Application is notified of the Status of the stopAudio request (either SUCCESS or FAILED) via the application-supplied callback.
18. Application requests delete audio stream using deleteStream method.
19. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
20. Application is notified of the Status of the deleteStream request (either SUCCESS or FAILED) via the application-supplied callback.

Audio Voice Call Volume/Mute control call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests create audio voice stream using createStream method with streamType as VOICE_CALL.
4. Application receives synchronous Status which indicates if the createStream request was sent successfully.
5. Application is notified of the Status of the createStream request (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioVoiceStream.
6. Application requests start audio stream using startAudio method on IAudioVoiceStream.
7. Application receives synchronous Status which indicates if the startAudio request was sent successfully.
8. Application is notified of the Status of the startAudio request (either SUCCESS or FAILED) via the application-supplied callback.
9. Application requests new volume on stream using setVolume method on IAudioVoiceStream for specified direction.
10. Application receives synchronous Status which indicates if the setVolume request was sent successfully.
11. Application is notified of the Status of the setVolume request (either SUCCESS or FAILED) via the application-supplied callback.
12. Application query volume on stream using getVolume method on IAudioVoiceStream for specified direction.
13. Application receives synchronous Status which indicates if the getVolume request was sent successfully.
14. Application is notified of the Status of the getVolume request (either SUCCESS or FAILED) via the application-supplied callback for specified direction with volume details.
15. Application requests new mute on stream using setMute method on IAudioVoiceStream for specified direction.
16. Application receives synchronous Status which indicates if the setMute request was sent successfully.
17. Application is notified of the Status of the setMute request (either SUCCESS or FAILED) via the application-supplied callback.
18. Application query mute details on stream using getMute method on IAudioVoiceStream for specified direction.
19. Application receives synchronous Status which indicates if the getMute request was sent successfully.
20. Application is notified of the Status of the getMute request (either SUCCESS or FAILED) via the application-supplied callback for specified direction with mute details.
21. Application requests stop audio stream using stopAudio method on IAudioVoiceStream.
22. Application receives synchronous Status which indicates if the stopAudio request was sent successfully.
23. Application is notified of the Status of the stopAudio request (either SUCCESS or FAILED) via the application-supplied callback.
24. Application requests delete audio stream using deleteStream method.
25. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
26. Application is notified of the Status of the deleteStream request (either SUCCESS or FAILED) via the application-supplied callback.

Call flow to play DTMF tone

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a voice stream with streamType as VOICE_CALL.
4. Application receives synchronous status which indicates if the createStream request was sent successfully.
5. Application is notified of the createStream request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioVoiceStream.
6. Application requests to start voice session using startAudio method on IAudioVoiceStream.
7. Application receives synchronous status which indicates if the startAudio request was sent successfully.
8. Application is notified of the startAudio request status (either SUCCESS or FAILED) via the application-supplied callback.
9. Application requests to play a DTMF tone associated with the voice session
10. Application receives synchronous status which indicates if the playDtmfTone request was sent successfully.
11. Application is notified of the playDtmfTone request status (either SUCCESS or FAILED) via the application-supplied callback.
12. Application can optionally stop the DTMF tone being played, before its duration expires.
13. Application receives synchronous status which indicates if the stopDtmfTone request was sent successfully.
14. Application is notified of the stopDtmfTone request status (either SUCCESS or FAILED) via the application-supplied callback.
15. Application requests to stop the voice session using stopAudio method on IAudioVoiceStream.
16. Application receives synchronous Status which indicates if the stopAudio request was sent successfully.
17. Application is notified of the stopAudio request status(either SUCCESS or FAILED) via the application-supplied callback.
18. Application requests delete audio stream using deleteStream method.
19. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
20. Application is notified of the deleteStream request status(either SUCCESS or FAILED) via the application-supplied callback.

Call flow to detect DTMF tones

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a voice stream with streamType as VOICE_CALL.
4. Application receives synchronous status which indicates if the createStream request was sent successfully.
5. Application is notified of the createStream request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioVoiceStream.
6. Application requests to start voice session using startAudio method on IAudioVoiceStream.
7. Application receives synchronous status which indicates if the startAudio request was sent successfully.
8. Application is notified of the startAudio request status (either SUCCESS or FAILED) via the application-supplied callback.
9. Application registers a listener for getting notifications when DTMF tones are detected
10. Application receives synchronous status which indicates if the registerListener request was sent successfully.
11. Application is notified of the registerListener request status (either SUCCESS or FAILED) via the application-supplied callback.
12. Application receives onDtmfToneDetection notification when a DTMF tone is detected in the active voice call session
13. Application deregisters a listener to stop getting notifications
14. Application receives synchronous status which indicates if the deRegisterListener request was sent successfully.
15. Application requests to stop the voice session using stopAudio method on IAudioVoiceStream.
16. Application receives synchronous Status which indicates if the stopAudio request was sent successfully.
17. Application is notified of the stopAudio request status(either SUCCESS or FAILED) via the application-supplied callback.
18. Application requests delete audio stream using deleteStream method.
19. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
20. Application is notified of the deleteStream request status(either SUCCESS or FAILED) via the application-supplied callback.

Audio Playback call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests create audio playback stream using createStream method with streamType as PLAY.
4. Application receives synchronous Status which indicates if the createStream request was sent successfully.
5. Application is notified of the Status of the createStream request (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioPlayStream.
6. Application requests stream buffer#1 using getStreamBuffer method on IAudioPlayStream.
7. Application receives IStreamBuffer if Success.
8. Application requests stream buffer#2 using getStreamBuffer method on IAudioPlayStream.
9. Application receives IStreamBuffer if Success.
10. Application writes audio samples on buffer#1 using getRawBuffer method on IStreamBuffer.
11. Application writes buffer#1 on Playback session using write method on IAudioPlayStream.
12. Application receives synchronous Status which indicates if the write request was sent successfully.
13. Application writes audio samples on buffer#2 using getRawBuffer method on IStreamBuffer.
14. Application writes buffer#2 on Playback session using write method on IAudioPlayStream.
15. Application receives synchronous Status which indicates if the write request was sent successfully.
16. Application is notified of the buffer#1 write Status (either SUCCESS or FAILED) via the application-supplied write callback with successful bytes written.
17. Application is notified of the buffer#2 write Status (either SUCCESS or FAILED) via the application-supplied write callback with successful bytes written.
18. Application requests delete audio stream using deleteStream method.
19. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
20. Application is notified of the Status of the deleteStream request (either SUCCESS or FAILED) via the application-supplied callback.

Audio Capture call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests create audio capture stream using createStream method with streamType as CAPTURE.
4. Application receives synchronous Status which indicates if the createStream request was sent successfully.
5. Application is notified of the Status of the createStream request (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioCaptureStream.
6. Application requests stream buffer#1 using getStreamBuffer method on IAudioCaptureStream.
7. Application receives IStreamBuffer if Success.
8. Application requests stream buffer#2 using getStreamBuffer method on IAudioCaptureStream.
9. Application receives IStreamBuffer if Success.
10. Application decides read sample size.
11. Application issue read audio samples on buffer#1 using read method on IAudioCaptureStream.
12. Application receives synchronous Status which indicates if the read request was sent successfully.
13. Application issue read audio samples on buffer#2 using read method on IAudioCaptureStream.
14. Application receives synchronous Status which indicates if the read request was sent successfully.
15. Application is notified of the buffer#1 write Status (either SUCCESS or FAILED) via the application-supplied read callback with successful bytes read.
16. Application is notified of the buffer#2 write Status (either SUCCESS or FAILED) via the application-supplied read callback with successful bytes read.
17. Application requests delete audio stream using deleteStream method.
18. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
19. Application is notified of the Status of the deleteStream request (either SUCCESS or FAILED) via the application-supplied callback.

Audio Tone Generator call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a tone generator stream with streamType as TONE_GENERATOR.
4. Application receives synchronous status which indicates if the createStream request was sent successfully.
5. Application is notified of the createStream request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioToneGeneratorStream.
6. Application requests to play tone using playTone method on IAudioToneGeneratorStream.
7. Application receives synchronous status which indicates if the playTone request was sent successfully.
8. Application is notified of the playTone request status (either SUCCESS or FAILED) via the application-supplied callback.
9. Application can optionally stop the tone being played, before its duration expires.
10. Application receives synchronous status which indicates if the stopTone request was sent successfully.
11. Application is notified of the stopTone request status (either SUCCESS or FAILED) via the application-supplied callback.
12. Application requests delete audio stream using deleteStream method.
13. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
14. Application is notified of the deleteStream request status(either SUCCESS or FAILED) via the application-supplied callback.

Audio Loopback call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a loopback stream with streamType as LOOPBACK.
4. Application receives synchronous status which indicates if the createStream request was sent successfully.
5. Application is notified of the createStream request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioLoopbackStream.
6. Application requests to start loopback using startLoopback method on IAudioLoopbackStream.
7. Application receives synchronous status which indicates if the startLoopback request was sent successfully.
8. Application is notified of the startLoopback request status (either SUCCESS or FAILED) via the application-supplied callback.
9. Application requests to stop loopback using stopLoopback method on IAudioLoopbackStream.
10. Application receives synchronous status which indicates if the stopLoopback request was sent successfully.
11. Application is notified of the stopLoopback request status (either SUCCESS or FAILED) via the application-supplied callback.
12. Application requests delete audio stream using deleteStream method.
13. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
14. Application is notified of the deleteStream request status(either SUCCESS or FAILED) via the application-supplied callback.

Compressed audio format playback call flow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a play stream with streamType as PLAY.
4. Application receives synchronous status which indicates if the createStream request was sent successfully.
5. Application is notified of the createStream request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioPlayStream.
6. Application requests to write buffer using write method on IAudioPlayStream.
7. Application receives synchronous status which indicates if the write request was sent successfully.
8. Application is notified of the write request status (either SUCCESS or FAILED) via the application-supplied callback along with number of bytes written.
9. Application is notified of when pipeline is ready to accept new buffer if callback returns with error that number of bytes written are not equal to bytes requested.
10. Application send request to stop playback using stopAudio method of IAudioPlayStream.
11. Application receives synchronous status which indicates if the stopAudio request was sent successfully.
12. Application is notified of the stopAudio request status (either SUCCESS or FAILED) via the application-supplied callback.
13. Appication is notified via indication that playback is stopped if StopType is STOP_AFTER_PLAY.
14. Application requests delete audio stream using deleteStream method.
15. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
16. Application is notified of the deleteStream request status(either SUCCESS or FAILED) via the application-supplied callback.

Audio Transcoding Operation Callflow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a transcoder.
4. Application receives synchronous status which indicates if the createTranscoder request was sent successfully.
5. Application is notified of the createTranscoder request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to transcoder interface refering to ITranscoder.
6. Application requests to read buffer using read method on ITranscoder.
7. Application receives synchronous status which indicates if the read request was sent successfully.
8. Application is notified of the read request status (either SUCCESS or FAILED) via the application-supplied callback along with isLastBuffer flag which indicates whether the buffer is last buffer to read or not.
9. Application requests to write buffer using write method on ITranscoder.
10. Application receives synchronous status which indicates if the write request was sent successfully.Application need to mark the isLastBuffer flag, whenever it is providing the last buffer to be write.
11. Application is notified of the write request status (either SUCCESS or FAILED) via the application-supplied callback along with number of bytes written.
12. Application is notified of when pipeline is ready to accept new buffer if callback returns with error that number of bytes written are not equal to bytes requested.
13. Once transcoding done, Application requests to tearDown transcoder as transcoder can not be used for multiple transcoding operations.
14. Application receives synchronous status which indicates if the tearDown request was sent successfully.
15. Application is notified of the tearDown request status (either SUCCESS or FAILED) via the application-supplied callback.

Compressed audio format playback on Voice Paths Callflow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to create a play stream with streamType as PLAY, voicePaths direction as TX or RX and no device is selected.
4. Application receives synchronous status which indicates if the createStream request was sent successfully.
5. Application is notified of the createStream request status (either SUCCESS or FAILED) via the application-supplied callback, with pointer to stream interface refering to IAudioPlayStream.
6. Application requests to write buffer using write method on IAudioPlayStream. It needs an active voice session to play over voice paths, refer IAudioVoiceStream for more details on how to create voice stream.
7. Application receives synchronous status which indicates if the write request was sent successfully.
8. Application is notified of the write request status (either SUCCESS or FAILED) via the application-supplied callback along with number of bytes written.
9. Application is notified of when pipeline is ready to accept new buffer if callback returns with error that number of bytes written are not equal to bytes requested.
10. Application send request to stop playback using stopAudio method of IAudioPlayStream.
11. Application receives synchronous status which indicates if the stopAudio request was sent successfully.
12. Application is notified of the stopAudio request status (either SUCCESS or FAILED) via the application-supplied callback.
13. Appication is notified via indication that playback is stopped if StopType is STOP_AFTER_PLAY.
14. Application requests delete audio play stream using deleteStream method.
15. Application receives synchronous Status which indicates if the deleteStream request was sent successfully.
16. Application is notified of the deleteStream request status(either SUCCESS or FAILED) via the application-supplied callback.

Audio Subsystem Restart Callflow

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On Readiness, Application requests to register listener to IAudioManager object.
4. Application receives synchronous status which indicates registerListener request was sent successfully.
5. IAudioManager is notified that audio service is unavailable.
6. Application receives a notification from the IAudioManager regarding service status as unavailable. Application is supposed to relealse references to all the IAudioStream/ITranscoder objects and related resources. Application should not send any new request to IAudioManager or IAudioStream/ITranscoder objects.
7. IAudioManager is notified that audio service is available.
8. Application receives a notification from the IAudioManager regarding service status as available. IAudioManager object is now ready to accept new requests from application.

Audio calibration configuration status

1. Application requests Audio factory for an Audio Manager.
2. Audio factory return IAudioManager object to application.
3. On sub system Readiness, application requests for calibration init status using getCalibrationInitStatus API to IAudioManager.
4. Application receives synchronous status which indicates if the getCalibrationInitStatus request was sent successfully.
5. Application is notified with CalibrationInitStatus and suitable error code via the application supplied callback.

Thermal manager call flow

Thermal manager provides APIs to get list of thermal zones and cooling devices. It also contains APIs to get a particular thermal zone and a particular cooling device details with the given Id.

1. Application requests Thermal factory for Thermal Manager.
2. Thermal factory returns IThermalManager object to application.
3. Application sends request to get all thermal zones using IThermalManager object.
4. Thermal manager returns the list of thermal zones to the application.
5. Application requests for a particular thermal zone details by mentioning the thermal zone Id.
6. Application receives thermal zone details with the given Id from thermal manager.
7. Application sends request to get all cooling devices using IThermalManager object.
8. Thermal manager returns the list of cooling devices to the application.
9. Application requests for a particular cooling device details by passing the cooling device Id.
10. Thermal Manager sends cooling device details with the given Id to the application.

Thermal shutdown management

Thermal shutdown manager provides APIs to set/get auto thermal shutdown modes. It also has listener interface for notifications. Application will get the Thermal-shutdown manager object from thermal factory. The application can register a listener for updates in thermal auto shutdown modes and its management service status. Also there is provision to set the desired thermal auto-shutdown mode.

When application is notifed of service being unavailable, the thermal auto-shutdown mode updates are inactive. After service becomes available, the existing listener registrations will be maintained.

As a reference, auto-shutdown management in an eCall application is described in the below sections.

Call flow to register/remove listener for Thermal auto-shutdown mode updates.

1. Application requests thermal factory for Thermal Shutdown Manager.
2. Thermal factory returns IThermalShutdownManager object using which application will register or remove a listener.
3. Application can register a listener for getting notifications on Thermal auto-shutdown mode updates.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application recieves a notification that thermal auto-shutdown mode is disabled.
6. Application recieves a notification that thermal auto-shutdown mode is going to enabled soon. The exact duration is also recieved as part of notification.
7. Application recieves a notification that thermal auto-shutdown mode is enabled.
8. Application can remove listener.
9. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Call flow to set/get the Thermal auto-shutdown mode

1. Application requests thermal factory for Thermal Shutdown Manager object using which application will set/get the thermal auto-shutdown mode.
2. Thermal factory returns IThermalShutdownManager object.
3. Application can query the thermal auto-shutdown mode.
4. Application receives synchronous status which indicates if the request was sent successfully.
5. Application receives the auto-shutdown mode asynchronously.
6. Application can set the thermal auto-shutdown mode to ENABLE or DISABLE.
7. Application receives synchronous status which indicates if the request was sent successfully.
8. Optionally, the response to setAutoShutdownMode request can be received by the application.

Call flow to manage thermal auto-shutdown from an eCall application.

1. When eCall is triggered, application requests thermal factory for Thermal Shutdown Manager.
2. Thermal factory returns IThermalShutdownManager object.
3. Application can register a listener for getting notifications on Thermal auto-shutdown mode updates.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application disables auto-shutdown using setAutoShutdownMode API, to prevent a possible thermal auto-shutdown during eCall.
6. Application receives synchronous status which indicates if the request was sent successfully.
7. Optionally, the response to setAutoShutdownMode request can be received by the application.
8. Application recieves a notification that thermal auto-shutdown mode is disabled.
9. Application receives an imminent auto-shutdown enable notification and system will attempt to enable auto-shutdown after a certain period. This notification is received if application does not enable auto-shutdown due to an active eCall.
10. If the eCall is still active, the application disables auto-shutdown before it gets enabled automatically.
11. Application receives synchronous status which indicates if the request was sent successfully.
12. Optionally, the response to setAutoShutdownMode request can be received by the application.
13. Application recieves a notification that thermal auto-shutdown mode is disabled. Steps 9 to 13 are repeated as long as the eCall is active.
14. When the eCall is completed, the application immediately enables auto-shutdown using setAutoShutdownMode API.
15. Application receives synchronous status which indicates if the request was sent successfully.
16. Optionally, the response to setAutoShutdownMode request can be received by the application.
17. Application recieves a notification that thermal auto-shutdown mode is enabled.
18. Application can remove listener.
19. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

TCU Activity Management

Application will get appropriate TCU-activity manager object from power factory. A Master/Slave client can register a listener for updates on TCU-activity state and its management service status. A Master client application can also set the system to a desired activity state. When the application is notified about the service being unavailable, the TCU-activity state notifications will be inactive. After the service becomes available, the existing listener registrations will be maintained.

The framework can work in ACTIVE or PASSIVE mode, based on the configuration of TCU-activity management service. In ACTIVE mode, the management service leads the system into desired activity state after receiving the acknowledgements from all the clients or after the configured timeout. However, in PASSIVE mode, the framework just notifies the clients about the state transition and conveys their acknowledgement status back to the Master application that triggered the transition.

Call flow to register/remove listener for TCU-activity manager

1. Application requests power factory for TCU-activity manager object, with clientType as SLAVE.
2. Power factory returns ITcuActivityManager object using which application will register or remove a listener.
3. Application can register a listener for getting notifications on TCU-activity state updates.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application will get TCU-activity state notifications like SUSPEND, RESUME and SHUTDOWN.
6. Application will send one(despite multiple listeners) acknowledgement, after processing(save any required information) SUSPEND/SHUTDOWN notifications. This indicates the readiness of application for state-transition. However the TCU-activity management service doesn't wait for acknowledgement indefinitely, before performing the state transition.
7. Application receives synchronous status which indicates if the acknowledgement was sent successfully.
8. Application can remove listener.
9. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Call flow to set the TCU-activity state in ACTIVE mode

1. Application requests power factory for TCU-activity manager object, with clientType as MASTER.
2. Power factory returns ITcuActivityManager object using which application will set the TCU-activity state.
3. Application can register a listener for getting notifications on TCU-activity state.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application
5. Application can set the TCU-activity state to SUSPEND, RESUME or SHUTDOWN.
6. Application receives synchronous status which indicates if the request was sent successfully.
7. Optionally, the response to setActivityState request can be received by the application.
8. Application waits for TCU-activity state update to confirm the state change.
9. Application will send one(despite multiple listeners) acknowledgement, after processing(save any required information) SUSPEND/SHUTDOWN notifications. This indicates the readiness of application for state-transition. However the TCU-activity management service doesn't wait for acknowledgement indefinitely, before performing the state transition.
10. Application receives synchronous status which indicates if the acknowledgement was sent successfully.
11. Application can remove listener.
12. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Call flow to set the TCU-activity state in PASSIVE mode

1. Application requests power factory for TCU-activity manager object, with clientType as MASTER.
2. Power factory returns ITcuActivityManager object using which application will set the TCU-activity state.
3. Application can register a listener for getting notifications on TCU-activity state.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application
5. Application can set the TCU-activity state to SUSPEND, RESUME or SHUTDOWN.
6. Application receives synchronous status which indicates if the request was sent successfully.
7. Optionally, the response to setActivityState request can be received by the application.
8. Application waits for TCU-activity state update to confirm the state change.
9. Application will send one(despite multiple listeners) acknowledgement, after processing(save any required information) SUSPEND/SHUTDOWN notifications. This indicates the readiness of application for state-transition. However the TCU-activity management service doesn't wait for acknowledgement indefinitely, before performing the state transition.
10. Application receives synchronous status which indicates if the acknowledgement was sent successfully.
11. Application waits for the acknowledgement status of all the clients, for the state transition in the system
12. Application can remove listener.
13. Status of remove listener i.e. either SUCCESS or FAILED will be returned to the application.

Remote SIM call flow

Application will get the remote SIM manager object from phone factory. The application must register a listener to receive commands/messages from the modem to send to the SIM. After sending the connection available message, a onCardConnect() notification tells the application to connect to the SIM and perform an Answer to Reset. After sending the card reset message (with the AtR bytes), APDU messages will begin to be sent/received.

1. Application requests remote SIM manager object from phone factory, specifying a slot id.
2. Phone factory returns IRemoteSimManager object.
3. Application registers a listener to receive commands/messages from the modem to send to the SIM.
4. Status of register listener i.e. either SUCCESS or FAILED will be returned to the application.
5. Application sends a connection available message indicating that a SIM is available for use.
6. Status of send connection available i.e. either SUCCESS or FAILED will be returned to the application.
7. Optionally, the response to send connection available request can be received by the application.
8. Application will receive a card connect notification by the listener.
9. After the application successfully connects to the SIM and requests an AtR, it sends a card reset message with the AtR bytes.
10. Status of send card reset i.e. either SUCCESS or FAILED will be returned to the application.
11. Optionally, the response to send card reset request can be received by the application.
12. Application will receive an APDU transfer notification by the listener (with APDU message id).
13. After forwarding the APDU transfer to the SIM and receiving the response, application will send APDU response.
14. Status of send APDU i.e. either SUCCESS or FAILED will be returned to the application.
15. Optionally, the response to send APDU request can be received by the application.
16. To close the connection, application will send connection unavailable message.
17. Status of send connection unavailable i.e. either SUCCESS or FAILED will be returned to the application.
18. Optionally, the response to send connection unavailable can be received by the application.

Modem Config Call Flow

Modem Config manager provides APIs to request all configs from modem, load/delete modem config files from modem's storage, activate/deactivate a modem config file, get the active config details, set and get auto config selection mode. It also has listener interface for notifications for config activation update status. Application will get the Modem Config manager object from config factory. The application can register a listener for updates reagrding modem config activation.

Call flow to load and activate a modem config file.

1. Application requests modem config manager object from config factory.
2. Config factory returns IModemConfigManager object.
3. Application sends a request to load config file in modem's storage.
4. Application receives synchronous Status which indicates if the request to load config file was sent successfully.
5. Application is notified of the Status of the loadConfigFile request (either SUCCESS or FAILED) via the application-supplied callback.
6. Application sends a request to get list of all modem configs from modem's storage.
7. Application receives synchronous Status which indicates if the request to get config list was sent successfully.
8. Application is notified of the Status of the requestConfigList request (either SUCCESS or FAILED) via the application-supplied callback along with list of modem configs.
9. Application sends a request to activate config file.
10. Application receives synchronous Status which indicates if the request to activate config file was sent successfully.
11. Application is notified of the Status of the activateConfig request (either SUCCESS or FAILED) via the application-supplied callback.

Call flow to deactivate and delete a modem config file.

1. Application requests modem config manager object from config factory.
2. Config factory returns IModemConfigManager object.
3. Application sends a request to deactivate config file.
4. Application receives synchronous Status which indicates if the request to deactivate config file was sent successfully.
5. Application is notified of the Status of the deactivateConfig request (either SUCCESS or FAILED) via the application-supplied callback.
6. Application sends a request to get list of all modem configs from modem's storage.
7. Application receives synchronous Status which indicates if the request to get config list was sent successfully.
8. Application is notified of the Status of the requestConfigList request (either SUCCESS or FAILED) via the application-supplied callback along with list of modem configs.
9. Application sends a request to delete config file.
10. Application receives synchronous Status which indicates if the request to delete config file was sent successfully.
11. Application is notified of the Status of the deleteConfig request (either SUCCESS or FAILED) via the application-supplied callback.

Call flow to set and get config auto selection mode

1. Application requests modem config manager object from config factory.
2. Config factory returns IModemConfigManager object.
3. Application sends a request to set config auto selection mode.
4. Application receives synchronous Status which indicates if the request to set config auto selection mode was sent successfully.
5. Application is notified of the Status of the request setAutoSelectionMode (either SUCCESS or FAILED) via the application-supplied callback.
6. Application sends a request to get config auto selection mode.
7. Application receives synchronous Status which indicates if the request to get config auto selection mode was sent successfully.
8. Application is notified of the Status of the request setAutoSelectionMode (either SUCCESS or FAILED) via the application-supplied callback, along with mode and slot id.

Sensor

The sensor sub-system provides APIs to configure and acquire continuous stream of data from an underlying sensor, create multiple clients for a given sensor, each of which can have their own configuration (sampling rate, batch count) for data acquisition.

The sensor sub-system APIs are synchronous in nature.

Call flow for sensor sub-system start-up

1. Get the reference to the SensorFactory, with which we can further acquire other sensor sub-system objects.
2. Prepare an initialization callback method or lambda which will be called by the sensor sub-system once the initialization is complete.
3. Request for the SensorManager from SensorFactory and provide the initalization callback. Retain the SensorManager shared_ptr as long as necessary. SensorFactory does not hold on to the returned instance. If the received shared_ptr is released, SensorManager would be destroyed and requesting SensorFactory for SensorManager again would result in the creation of a new instance. Similar is the approach for SensorFeatureManager.
4. Wait for the initialization callback to be invoked.
5. The sensor sub-system invokes the callback once the underlying sub-system and sensor framework is available for usage. If the service status is notified as SERVICE_FAILED, retry intitialization starting with step (3). If the service status is notified as SERVICE_AVAILABLE, the sensor sub-system is ready for usage.

Call flow for sensor data acquisition

The sensor sub-system should have been initialized successfully with SERVICE_AVAILABLE as a pre-requisite for sensor data acquisition and a valid SensorManager object is available.

1. Get the information about available sensors from ISensorManager. The information will be provided in the sensorInfo parameter that would be passed by reference.
2. Given the information about different sensors, identify the required sensor (name of the sensor) using the provided attributes - type, name, vendor or required sampling frequency. Having identified the required sensor, request for the sensor object from ISensorManager with the required name of the sensor. If the request was successful, the provided reference to shared_ptr<ISensor> would be set by the ISensorManager which can be used to further configure and acquire data from the sensor. The ownership of the sensor object is with the application. SensorManager does not hold a reference to the returned instance. So, requesting ISensorManager for a sensor with the same name would result in a new sensor object being returned.
3. Create a listener of type ISensorEventListener which would receive notifications about updates to sensor configuration and sensor events. Register the created listener with the sensor object.
4. Create the desired sensor configuration. For continous data acquisition samplingRate and batchCount are necessary attributes to be set in the configuration. Be sure to set the validityMask in the SensorConfiguration structure.
5. On successful configuration, a notification is sent to the registered listeners indicating the configuration set.
6. Activate the sensor for acquiring sensor data.
7. When the sensor is activated successfully, the sensor data is sent to the registered listeners.

Call flow for sensor reconfiguration

When the sensor sub-system has been initialized successfully with SERVICE_AVAILABLE and is already activated, reconfiguring the sensors involves the following steps.

1. Deactivate the sensor. This will stop the notifications about sensor events to the registered listeners.
2. Configure the sensor with the required attributes. Be sure to set the validityMask for the all required attributes in SensorConfiguration.
3. The underlying sub-system notifies the registered listeners about the new configuration set.
4. Activate the sensor.
5. When the sensor is activated successfully, the sensor data is sent to the registered listeners as per the new configuration.

Call flow for sensor sub-system cleanup

When the sensor sub-system has been initialized successfully with SERVICE_AVAILABLE and sensor objects have been created, the following steps ensure a cleanup of the sensor sub-system.

1. Deactivate all the sensors. With this, the registered listeners will no longer be notified of the sensor events.
2. Release all the sensor objects created by setting them to nullptr. Since the application owns the objects, this would result in all the sensor objects getting destroyed.
3. Disable all the sensor features that were previously enabled.
4. Release the instance of ISensorManager by setting it to nullptr. Since the application owns the object, this would result in the sensor manager getting destroyed.
5. Release the instance of ISensorFeatureManager by setting it to nullptr. Since the application owns the object, this would result in the sensor feature manager getting destroyed.

Call flow for sensor power control

The below points are to be noted for sensor power control a) Power control is not offered by all sensor manufacturers. If the underlying hardware sensor does not support power control, the power control APIs fail. b) Enabling or disabling low power mode for the sensor is only possible when the sensor is not activated.

For achieving power control, the following steps are to be followed

1. Deactivate the sensor. This will stop the notifications about sensor events to the registered listeners.
2. Perform the required power control by enabling or disabling low power mode for the sensor.
3. Activate the sensor.
4. When the sensor is activated successfully, the sensor data is sent to the registered listeners.

Call flow for sensor feature control

The sensor sub-system offers certain features in addition to the data acquisition and these could be features offered by the underlying sensor hardware or the sensor software framework. If there are no features offered collectively, the sensor feature manager initialization would fail.

1. Retrieve a list of features offered by the sensor sub-system and identify the required feature that needs to be enabled. If the feature that needs to be enabled is known, this step is optional.
2. Create a sensor feature event listener, which would be notified of the different events that occur. Register this listener with the sensor feature manager.
3. Enable the required feature.
4. Once the feature is enabled and an event related to the feature occurs, the listener is notified.