After being installed on the target hardware, QWF runs several realtime processes to support the phone service, cellular network services, and cellular modem control.
The interaction between QWF processes and other system services is shown in this diagram:
Figure 1. QWF Process DeploymentThese processes perform the following functions:
- qwf-phone-service
- The phone service handles client commands related to phone calls, publishes the phone state, and manages audio resources
- qwf-voice-service
- The cellular voice service contains the cellular line-provider and performs voice-handling
- qwf-cellular-services
- Provides many cellular services, including:
- UICC service—publishes UICC attributes and SIM state information (e.g., ready, not ready), provides controls for clients, and manages SIM Personal Identification Number (PIN), PIN Unlock Key (PUK), and Operator Name String (ONS) determination
- SMS service—enables clients to send SMS messages and register to receive SMS messages
- SIM toolkit—supports Over The Air (OTA) updates to change data in the SIM card
- qwf-carrier-mgr
- Performs mobile network carrier management, which involves:
- determining the Serving Carrier ID, by using SIM information (e.g., IMSI, GID, ICCID) and Carrier ID XML (e.g., IMSI Ranges, ICCID prefix)
- determining if the serving carrier is a home carrier, roaming carrier, or mobile virtual network operator (MVNO)
- providing the serving carrier with device configuration information, including the data connectivity APN and carrier Emergency Numbers
- The carrier manager process uses configuration files in /etc/carrier/config. The exact .xml configuration file used depends on the SIM inserted in the target board. For instance, if an AT&T SIM is inserted, the 50.xml file is used; if a T-Mobile SIM is inserted, the 450.xml file is used. Clients can view the carrier configuration by outputting the file currently used (i.e., cat /etc/carrier/config/450.xml).
- The carrier ID file (/etc/carrier/ids/carrierIds.xml) maps carrier IDs to the configuration files.
- qwf-cellular-control
- Supports radio control and cellular data services.
- The radio control provides:
- automatic re-establishment of lost data connections
- cellular radio initialization and configuration
- radio network services selection
- network status control and reporting (i.e., signal level, RATs, network services)
- The cellular data services:
- provide logical service names used by sockets over cellular network connections; these APN-based names allow for independent billing
- can be configured to allow or prohibit data roaming
- qwf-crm-*
- The Cellular Resource Manager (CRM) handles client requests, which are sent through the service layer and the Common Cellular Radio Libraries, by translating the requests into AT or vendor commands used by the underlying modem. When it receives indications from the modem, the process translates them into the hardware-independent format used by the radio libraries. These two functions can be done synchronously or asynchronously.
- The CRM process is specific to the modem type used. For example, for Telit modems, the process that runs is named qwf-crm-telit; for Gemalto modems, it's qwf-crm-gemalto.
- The resource manager process also performs other functions:
- command queuing
- modem startup
- data caching (to save power)
- mitigation of behavioral differences between modems
- handling of modem timeouts
- modem reset and recovery
- net_pps
- Offers a PPS interface to control and view the status of networking interfaces. Through this service, QWF processes can read interface availability.
- tetherman
- Allows clients to tether (connect) one networking connection to another (e.g., a Wi-Fi MHS connection to a cellular connection).
- wpa_pps
- Provides control logic for station mode, mobile hotspot, and peer-to-peer roles as well as coordination between roles. The wpa_pps service also configures and controls the WPA Supplicant for each role.
- wpa_supplicant
- Implements the WPA Supplicant component that runs in client stations. This component handles WPA key negotiation (with a WPA Authenticator) and EAP authentication (with an Authentication Server). It also controls roaming and IEEE 802.11 authentication and association of the WLAN driver.
- The wpa_supplicant utility is a daemon (which runs in the background) and acts as the backend component for controlling the wireless connection. It supports separate front-end programs, including a sample text-based client (wpa_cli), which is included with the utility.
- Before wpa_supplicant can do its work, the network interface must be available. That means that the physical device must be present and enabled, and the driver for the device must have been loaded. The daemon exits immediately if the device isn't already available.
- After the network device has been configured, higher-level configuration such as DHCP may proceed. There are several ways to integrate the WPA Supplicant into networking scripts; for information, see the wpa_supplicant entry in the QNX Neutrino Utilities Reference.
- io-pkt-v4-hc or io-pkt-v6-hc
- Implements the TCP/IP stack and handles packets that transport wireless data.
- The QNX Neutrino RTOS supports IPv4 and IPv6 over Ethernet, Wi-Fi 802.11, and Cellular. The io-pkt-* services provide standard network services, including DNS, DHCP, inetd, firewall, FTP, HTTP, PPP, and more.
- Both hc stack variants (io-pkt-v4-hc and io-pkt-v6-hc) have built-in 802.11 a/b/g Wi-Fi capability. The stack includes its own separate 802.11 MAC layer and typically, the vendor Wireless LAN (WLAN) driver. The Wi-Fi networking functionality lets you join or host WLAN networks.
- Using io-pkt-*, you can:
- connect using a peer-to-peer mode called ad hoc mode, also referred to as Independent Basic Service Set (IBSS) configuration
- either act as a client for a Wireless Access Point (WAP, also known as a base station) or configure QNX Neutrino to act as a WAP. This second mode is referred to as infrastructure mode or Basic Service Set (BSS).
- For full details on the io-pkt-* services, refer to the Networking Manager entry in the QNX Neutrino Utilities Reference.
- pppd
- Point-to-point protocol (PPP) daemon that establishes TCP/IP serial connections using PPP.
- QNX Hardware Drivers
- Interact with low-level modules that support specific wireless connection types (i.e., cellular or Wi-Fi).
- A USB driver is used to interface with cellular modules. For example, the devc-serusb driver is used for USB-to-serial adaptors and Communications Device Class Abstract Control Model (CDC ACM) devices. This driver is part of the QNX SDP and automatically detects ACM devices, based on their USB Class code.
- An SDIO driver (e.g., devnp-ti18xx_imx6x.so) can be used to support Wi-Fi connections, by providing a Secure Digital Input Output (SDIO) interface to connect Wi-Fi modules to a host processor.
- Note: Wi-Fi modules can use other interfaces, such as PCI Express or UARTs, for communication and control.