USSD Quiz

Explanation: USSD stands for "Unstructured Supplementary Service Data" according to GSM 02.90 specifications. It is a protocol used by GSM cellular telephones to communicate with the mobile network operator's computers in real-time. The term "unstructured" refers to the fact that the data format is not predefined by the GSM standards, allowing operators to implement custom services.

Explanation: USSD uses the signaling channel (specifically SDCCH - Standalone Dedicated Control Channel or DCCH in UMTS/LTE) rather than traffic channels. This is a fundamental difference from voice calls which use traffic channels (TCH). Using signaling channels allows USSD to maintain real-time bidirectional communication even during active voice calls, as signaling and traffic channels operate independently in GSM architecture.

Explanation: USSD messages support up to 182 characters using the SMS default alphabet (7-bit encoding). This is slightly higher than SMS's 160 character limit because USSD uses a different protocol structure. When using UCS2 encoding (16-bit), the limit reduces to approximately 90 characters. This character constraint is defined in GSM 03.38 specifications and is important for menu-driven interface design in USSD applications.

Explanation: In traditional GSM/UMTS core networks, USSD uses MAP (Mobile Application Part) protocol layered over SS7 (Signaling System No. 7). Key MAP operations include MAP_PROCESS_UNSTRUCTURED_SS_REQUEST (for mobile-initiated USSD), MAP_UNSTRUCTURED_SS_REQUEST, and MAP_UNSTRUCTURED_SS_NOTIFY (for network-initiated USSD). While modern LTE/5G networks may use SIP-based solutions for USSD over IMS, the classical implementation relies on MAP/SS7 for communication between MSC, VLR, and HLR.

Explanation: USSD Phase 1 (GSM 02.90) only supports mobile-initiated (PULL/MO-USSD) operations where the user dials a code like *123#. USSD Phase 2 (GSM 03.90) introduced network-initiated (PUSH/MT-USSD) capabilities, allowing the network to send unsolicited messages to mobile devices for promotional services, emergency alerts, or callback notifications. This bidirectional capability significantly expanded USSD's application scope beyond simple query-response mechanisms.

Explanation: In the USSD format defined in GSM 02.30 and GSM 02.90, NNN represents the service code that identifies the specific supplementary service or application. The format is: [*, #, or *#] followed by 1-3 digits (service code), optionally followed by * and additional parameters, ending with #. For example, in *123*1*0987654321#, "123" is the service code (e.g., balance transfer), "1" might indicate the action type, and "0987654321" is the recipient number. Service codes are standardized internationally for certain services but operators can define custom codes for PLMN-specific applications.

Explanation: USSD does NOT require an internet connection—it operates entirely over the GSM signaling network. This is actually one of USSD's major advantages, making it accessible on basic feature phones and in areas without data coverage. The key differences are: (1) USSD is session-based (real-time) vs. SMS store-and-forward; (2) USSD messages are "flash" messages not stored on the device vs. SMS stored in memory; (3) USSD uses dedicated signaling channels vs. SMS which uses the Short Message Control Channel (SMCCH). USSD works on 2G GSM networks without any data connectivity.

Explanation: According to GSM 03.90 specifications, handover has no impact on USSD operations. The session is maintained transparently across cell boundaries because USSD signaling is handled at the core network level (MSC/VLR/HLR) rather than the radio access level. The MAP protocol transactions remain active regardless of radio channel changes. This is a critical design feature ensuring service continuity for mobile banking and other interactive USSD applications where users might be moving between cells during transactions.

Explanation: The USSD Gateway (USSDC - USSD Center) acts as the interface between the mobile network core (MSC/VLR/HLR) and external application servers. It parses incoming USSD requests, authenticates service access codes, maintains session state information, and routes messages to appropriate application servers (banks, stock exchanges, email servers, etc.). The USSDC handles conversation management, service transfer functions, and message-level billing. While the HLR stores subscriber data, it does not store USSD-specific information or handle application routing—that is the specialized function of the USSD Gateway.

Explanation: Traditional USSD lacks end-to-end encryption. While GSM provides radio interface encryption (A5 algorithms) and SS7 networks have security mechanisms, USSD data is transmitted in plaintext within the core network between MSC, USSD Gateway, and application servers. This makes it vulnerable to interception at SS7 network nodes or through SS7 signaling attacks. This is particularly concerning for mobile banking applications. Modern implementations are addressing this through quantum-resistant cryptography proposals and additional application-layer encryption, but legacy USSD remains vulnerable to man-in-the-middle attacks within the operator's core network infrastructure.

Explanation: In LTE/5G networks, USSD is supported through two mechanisms: (1) IMS-based USSD using SIP signaling for VoLTE/VoNR subscribers, where USSD messages are encapsulated in SIP INFO messages or dedicated USSD over IMS procedures; (2) Circuit Switched Fallback (CSFB) or SGs interface for 4G, allowing the device to fall back to 2G/3G circuits to process USSD. In 5G SA (Standalone), native USSD support is being standardized through IMS integration. This ensures backward compatibility for essential services like emergency callbacks and banking while evolving the underlying transport technology.

Explanation: According to GSM 02.90 specifications, mobile-initiated USSD operations must use the SMS default alphabet (7-bit GSM alphabet) with the alphabet indicator set accordingly and language indicator set to "language unspecified." This ensures maximum compatibility across all GSM devices. However, for backward compatibility with Phase 1 networks that don't support the default alphabet indicator, the mobile station may fall back to IA5 encoding if the initial attempt fails. The SMS default alphabet supports basic Latin characters, numbers, and common symbols essential for USSD menu navigation and data entry.