Architecture¶
This is a brief introduction to the CM architecture. It explains the different types of layers used in the CM architecture. Each layer has been explained with its functional flow and diagram, wherever applicable. Reading this page will enhance your understanding about the CM architecture. To learn more about the CM architecture, refer the Resources and Tools page.
Overview¶
The Connection Manager (CM) architecture supports the requests from multiple clients simultaneously. CM runs as an HTTP service on the system; exposes a set of public APIs to a client. The client uses these APIs and provides the Connection Manager functionality to end users. This approach also allows rewriting the UI without modifying the core Connection Manager functionality. Similarly, CM abstracts the lower level device-driver calls and moves the calls to the WiMAX common API. The network-specific details are kept in the OMA tree. An OMA client reads the network-specific parameters from the OMA tree and provides the parameters to the SDK.
The following figure shows the device platform software stack.
Device Platform Software Stack
Connection Manager Service Architecture¶
The Connection Manager Service runs as a system service and starts when the computer boots up. The service listens for the client requests on port 9824 that is configurable and modifiable from the config.xml file. Connection Manager contains a set of separate modules for managing each wireless network type. Each module contains a manager that manages all the requests for the network type.
Connection Manager currently features the following two managers:
The following diagram depicts the complete architecture of the Connection Manager Service.
Connection Manager Service Architecture
When the CM service receives a request, the service first checks if the request should be processed inside the daemon. If not, the service forwards the command to the respective module manager based on the network type and then the manager processes the request. This flow enables to have a set of network-specific commands without changing the daemon interface.
Before performing any other operation, the client starts the required wireless network module using the start API. Similarly, when the client doesn’t want to manage a wireless network, it stops the module using the stop API to free up resources.
The following sequence diagram shows the flow of start/stop commands.
Start / Stop Request
WiMAX Manager¶
WiMAX Manager manages the WiMAX networks. Before using any other API, the client starts the WiMAX Manager first using the start API. Once the manager is up, it performs the following operations:
- Initialize the thread pool for the worker threads.
- Initialize the multi controller.
- Add sessions to the multi controller for all CAPI libraries installed on the system.
- Start listening on a configurable port for the WiMAX-related commands. Default port: 9825.
- Add a notification listener to the multi controller.
The WiMAX Manager layer constitutes the following components in the CM architecture:
Multi Controller¶
The WiMAX Multi Controller performs the following tasks:
- Enable WiMAX manager to manage multiple devices at same time.
- Provide a set of functions to manage the state of sessions.
- Ensure that the WiMAX Manager always receives notifications from the currently active interface.
- Identify the active interface based on routing table.
- Associate the notification listener to the corresponding session.
- Re-associate the listener to the next active WiMAX interface when the active device is removed.
Session¶
The WiMAX Session represents a state machine. Each session is associated with a device and it’s responsible to get the device connected to a network. The State Monitor class is responsible for initializing all the states.
The state machine comprises the following states:
- Ready – indicates that state machine is ready.
- Initialized – indicates that a network is available to connected.
- Connected – indicates that device is connected to a network.
- Disconnected – indicates that device is disconnected from a network.
When a session is initialized, the state monitor initializes all the states. The following diagram shows the interaction between different states.
To move from one state to another, the machine executes a set of CAPI commands defined for the new state. The following are the list of commands defined for each state:
- Initialized
- WiMaxAPIOpen
- GetListDevice
- WiMaxDeviceOpen
- SubscribeConnectToNetwork
- SubscribeDeviceInsertRemove
- SubscribeDisconnectToNetwork
- SubscribeControlPowerManagement
- SubscribeNetworkSearchWideScan
- SubscribePackageUpdate
- SubscribeProvisioningOperation
- SubscribeDeviceStatusChange
- GetDeviceStatus
- CmdControlPowerManagementOn
- GetDeviceStatus
- GetNetworkList
- GetDeviceStatus
- Connected
- CmdConnectToNetwork
- GetDeviceStatus
- GetLinkStatus
- GetIPInterfaceIndex
- Disconnected
- UnsubscribeDeviceStatusChange
- UnsubscribeDeviceInsertRemove
- UnsubscribeControlPowerManagement
- UnsubscribeConnectToNetwork
- UnsubscribeDisconnectToNetwork
- UnsubscribeNetworkSearchWideScan
- UnsubscribeProvisioningOperation
- UnsubscribePackageUpdate
- CmdDisconnectFromNetwork
- WiMaxDeviceClose
- WiMaxAPIClose
The session controller behaves like a watchdog to the state machine. Meaning, whenever the machine gets disconnected without user intervention due to loss of network coverage, the controller operates the state machine from ‘connected’ state to ‘disconnected’ state. The controller keeps checking for the network coverage if the last connected network is available. If the network is available, then it notifies the state machine to change into ‘connected’ state.
Base Layer¶
The WiMAX base layer is a Java wrapper over the CAPI native calls. The layer uses JNA to call the CAPI native functions.
WiFi Manager¶
WiFi Manager manages the WiFi profiles and networks. Before calling other WiFi APIs, the client first calls the Start API to start the WiFi Manager. When the network starts, the manager performs the following operations:
- Initialize the thread pool for the worker threads.
- Start listening on a configurable port for the WiFi-related commands. Default port: 9826.
NOTE: The WiFi functionality in the current version is implemented for Windows only.
The WiFi Manager layer represents the following components in the CM architecture:
- OS Adaptation Layer
- Base Layer
OS Adaptation Layer¶
Different types of operating systems use different libraries and functions to manage the WiFi device. In case of the adaptation layer, the layer abstracts the OS-specific functions and enables the upper layer to execute commands irrespective of the underlying operating system.
Base Layer¶
The WiFi base layer is a Java wrapper over the WLAN native calls. The layer implements only some of the WLAN APIs required by the WiFi manager. The layer uses JNA to call the WLAN native functions.
The following are the list of WLAN APIs implemented for Windows:
- WlanOpenHandle
- WlanCloseHandle
- WlanEnumInterfaces
- WlanQueryInterface
- wlanOpcodeValueType);
- WlanScan
- WlanGetAvailableNetworkList
- WlanGetNetworkBssList
- WlanConnectionParameters
- Wlanconnect
- WlanDisconnect
- WlanGetProfile
- WlanGetProfileList
- WlanSetProfile
- WlanReasonCodeToString
- WlanFreeMemory
Database¶
Connection Manager uses Derby as its database to store user profiles and other network information.
Update Manager¶
The Update Manager enables the Connection Manager (CM) Service to check, download, and install updates when the CM service is started. The manager also provides the functionality to perform on-demand update check when ‘check for updates’ is called. In addition, the manager communicates with the software upgrade server (OPOP) to check if any updates are available. If available, the manager downloads and installs the updates on the client machine.
The Update Manager also provides the download status while downloading. To get the live update from the download process, register the download listener to the update manager.
The 'check for updates' diagram explains how the OPOP (software update) server responds to a request for check updates. When the client requests for check update, the web server forwards the request to the ‘worker’ and instantiates the ‘Update Manager’. The ‘Update Manager’ sends the ‘check update’ request to the OPOP server. The OPOP Server processes the SOAP request and sends the response back to the client through ‘worker’ and ‘web server’. The same logic applies to the download and install requests using the download progress listener, downloader, and installer respectively.
The following diagram depicts the check for updates request.
Check Update Request
OS Utilities¶
CM is a platform-independent application; sometimes it performs as the OS-dependent operations as well. The OS Utilities functionality helps CM perform the OS-dependent operations. The OS utilities perform the following tasks:
- Read registry on Windows, plist on Mac, and text file on Linux.
- Support PING on all OSs.
- Support open default browser.
- Identify the active interface.
- Collect the MAC address of the interface.
- Check if CM is running or not.
- Collect the IP / gateway addresses of the interface.
Logging¶
The Logging layer is used for storing logs information.
Properties¶
The Properties layer provide values to the specific components by reading the ‘config.xml’ file.
Next Topics