Android Telephony, RIL & Modem

The big picture: app to antenna

Android telephony is a stack of six layers. You should be able to draw it in about a minute and, more importantly, say what mechanism crosses each boundary: Binder, plain Java calls, a HAL interface, a vendor IPC protocol, or radio frequency (RF). Almost every interview question in this area is a request to trace something through this stack.

+----------------------------------------------------------------------+
| APPS: Dialer, Messaging, Settings, carrier apps                      |
|   TelephonyManager, SubscriptionManager, SmsManager, TelecomManager  |
+----------------------------------------------------------------------+
        |  Binder (AIDL): ITelephony, ISub, ITelecomService ...
+----------------------------------------------------------------------+
| FRAMEWORK: Telecom (system_server) + Telephony (com.android.phone)   |
|   Phone/GsmCdmaPhone, ServiceStateTracker, DataNetworkController,    |
|   SubscriptionManagerService, UiccController, TelephonyRegistry,     |
|   CarrierConfigLoader, ImsPhone                                      |
+----------------------------------------------------------------------+
        |  in-process Java calls, Message/Handler
+----------------------------------------------------------------------+
| RIL JAVA (RILJ): RIL.java, RILRequest, RadioResponse, RadioIndication|
+----------------------------------------------------------------------+
        |  Stable AIDL Binder (Android 13+) or HIDL HwBinder (legacy)
+----------------------------------------------------------------------+
| RADIO HAL: IRadioNetwork/Data/Voice/Sim/Modem/Messaging/Ims/Config   |
|            + matching *Response and *Indication interfaces           |
+----------------------------------------------------------------------+
        |  vendor process boundary
+----------------------------------------------------------------------+
| VENDOR RIL DAEMON: Qualcomm qcrild (QCRIL) / MediaTek rild (Rfx/Rmm) |
+----------------------------------------------------------------------+
        |  QMI over QRTR/GLINK/SMEM (QC), MIPC/AT over CCCI (MTK), PCIe/MHI
+----------------------------------------------------------------------+
| MODEM FIRMWARE (baseband): NAS, RRC, PDCP, RLC, MAC, PHY             |
+----------------------------------------------------------------------+
        |  RF over the Uu air interface
   eNB (LTE) / gNB (5G NR)  ──▶  core network (EPC / 5GC)  ──▶  internet / IMS

Two processes you must know

Where the source lives

The telephony framework

The framework turns radio events into Android state (service state, signal bars, call state) and turns app requests into radio commands. It is built from long-lived objects, each owned by one thread's Handler/Looper, that talk to each other with Messages and RegistrantLists.

Telecom vs Telephony

Core classes

ServiceStateTracker in detail

SST answers "am I in service, on what network, with what technology?" It consumes unsolicited networkStateChanged, signal strength and NITZ indications, and then polls the modem because the indication itself carries no details.

1. Indication The modem sends IRadioNetworkIndication.networkStateChanged (legacy: RIL_UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED).
2. pollState() SST fires four requests in parallel: getOperator, getVoiceRegistrationState, getDataRegistrationState, getNetworkSelectionMode.
3. Build a new ServiceState When all replies arrive, SST combines them into a new ServiceState with one NetworkRegistrationInfo per domain (CS/PS) and transport (WWAN/WLAN).
4. Apply policy Roaming overrides from carrier config, out-of-service hysteresis, operator-name (SPN/PLMN) display rules, emergency-only detection.
5. Notify DefaultPhoneNotifier → TelephonyRegistry → every registered TelephonyCallback.ServiceStateListener, plus the ACTION_SERVICE_STATE broadcast. Status-bar icons update.

Modem registration states reported to SST include REG_HOME, REG_ROAMING, NOT_REG_MT_SEARCHING_OP, NOT_REG_MT_NOT_SEARCHING_OP, REG_DENIED (with a reject cause) and UNKNOWN, plus "emergency calls allowed" variants. REG_DENIED with a cause is the first thing to look for in a "no service" bug.

Signal strength, radio power and NITZ

• Signal SignalStrength holds per-RAT values (CellSignalStrengthLte: RSRP, RSRQ, RSSNR; CellSignalStrengthNr: SS-RSRP, SS-RSRQ, SS-SINR). Bars come from carrier-configurable thresholds. The framework sets reporting criteria (setSignalStrengthReportingCriteria) so the modem only reports when a threshold is crossed, which saves power. Rough LTE field estimates (not 3GPP pass/fail limits; carriers remap them to bars): RSRP greater than about -80 dBm is excellent, -80 to -100 dBm is usable, below about -110 dBm is cell-edge / poor; RSRQ above about -10 dB is strong and below about -20 dB is poor; SINR above about 20 dB is excellent and below 0 dB is poor.
• Radio power Airplane mode, SIM power-down and radio-off all end in IRadioModem.setRadioPower. The radio state is RADIO_OFF, RADIO_ON or RADIO_UNAVAILABLE (HAL or modem not ready).
• NITZ Network Identity and Time Zone: the network sends time and zone; NitzStateMachine feeds Android's time and time-zone detectors.

TelephonyRegistry and CarrierConfig

SIM, eSIM and subscriptions

The SIM (technically the UICC, Universal Integrated Circuit Card) is a small secure computer that holds the subscriber identity (IMSI), the secret key used for authentication, and operator files. Android models it as a tree of objects and maps each active SIM profile to a subscription with a stable subscription ID.

The UICC object tree

UiccController  (singleton, listens to IRadioSim status indications)
   └── UiccSlot          (physical or eUICC slot; card present / absent)
         └── UiccCard / UiccPort   (one card; eUICC cards may expose several ports)
               └── UiccProfile     (the active profile; exposes aggregated SIM state)
                     ├── UiccCardApplication  USIM  → SIMRecords  (IMSI, MSISDN, SPN, PLMN lists)
                     ├── UiccCardApplication  ISIM  → IsimUiccRecords (IMPI, IMPU, domain)
                     └── UiccCardApplication  CSIM/RUIM → RuimRecords (CDMA, legacy)
   Each application reads files through an IccFileHandler → RIL iccIoForApp → modem → card APDUs

SIM states

Important elementary files (EFs)

SIM access uses APDUs (smart-card command/response units). SIM Toolkit (STK) proactive commands arrive as indications and are handled by CatService. A simRefresh indication tells the framework that files changed (for example after an over-the-air SIM update) so records must be reread.

Carrier privileges

An app whose signing certificate is listed in the UICC access-rule applet (ARA-M / ARF) is treated as a carrier-privileged app for that subscription. TelephonyManager.hasCarrierPrivileges() is the check. Privileged apps can use APIs that ordinary apps cannot: open UICC logical channels (iccOpenLogicalChannel, iccTransmitApduLogicalChannel), manage some APN and IMS provisioning, and call other carrier-only telephony methods. This is not the same as being a privileged system app, and it is not the same as holding READ_PHONE_STATE. A missing or stale access rule on the SIM is a common reason a carrier app "works on the operator's reference phone but not on ours".

Subscriptions and IDs

SubscriptionManagerService owns the database and the defaults: default data subscription (DDS), default voice and default SMS subscription. Apps use SubscriptionManager and TelephonyManager.createForSubscriptionId(subId) to target one SIM.

Multi-SIM: DSDS vs DSDA

Temporary data switch: when a voice call starts on the non-DDS SIM, PhoneSwitcher can move data to that SIM (calls IRadioConfig.setPreferredDataModem) for the call's duration, then switch back. Newer releases also support automatic data switching to the other SIM when the DDS has poor service, controlled by user setting and carrier policy.

eSIM basics

• eUICC: an embedded, soldered UICC that can store several operator profiles. Identified by its EID.
• ISD-R: the on-card security domain that manages profiles; the device talks to it over a logical channel.
• LPA (Local Profile Assistant): the on-device component (an app implementing EuiccService) that downloads, enables, disables and deletes profiles. Apps use EuiccManager.
• SM-DP+: the operator-side server that prepares and delivers encrypted profiles; SM-DS is a discovery server. An activation code (often a QR code) points the LPA to the SM-DP+.
• The GSMA Remote SIM Provisioning specs (consumer: SGP.21/SGP.22; IoT: SGP.31/SGP.32) define the flow. Android 13+ supports Multiple Enabled Profiles (MEP), so one eUICC can host two active profiles for dual-SIM on eSIM only.
• Wearables use eSIM because there is no room for a tray; number sharing (one number on phone and watch) is a carrier feature. See Wear OS.

User scans QR (activation code)
   └── LPA app (EuiccService) ── HTTPS (ES9+) ──▶ SM-DP+  (mutual authentication, profile binding)
          │  downloads encrypted Bound Profile Package
          └── APDUs over logical channel (ES10) ──▶ eUICC ISD-R ──▶ installs profile
   Enable profile → card refresh → UiccController sees new ICCID → new subId → carrier config → registration

Data framework: APNs and DataNetworkController

A mobile data connection is called a PDN connection on LTE and a PDU session on 5G. Each one is set up against an APN (Access Point Name; called DNN on 5G) that tells the core network which gateway and service to use. The framework decides when to bring connections up or down; the modem does the actual signalling.

APN types

APN definitions come from the device APN database (apns-conf.xml → telephony provider, content://telephony/carriers), filtered by carrier ID / MCC-MNC, and can be edited by the user or a carrier app. Each becomes a DataProfile. The framework sends the initial attach APN (setInitialAttachApn) and the full profile list (setDataProfile) to the modem.

DcTracker → DataNetworkController

How a data call is brought up

1. Network request An app or the system asks ConnectivityService for a network with capabilities (for example INTERNET, or IMS, or MMS).
2. Routing to telephony The telephony network factory (TelephonyNetworkFactory, activated on the preferred data phone by PhoneSwitcher) passes it to DataNetworkController.
3. Evaluation Checks: SIM loaded, in service on PS domain, data enabled (user/policy/carrier), roaming allowed, correct DDS, not throttled, no conflicting call on DSDS, radio on.
4. Profile choice DataProfileManager picks the DataProfile (APN) that satisfies the capabilities.
5. Setup DataNetwork calls RIL.setupDataCall() → IRadioData.setupDataCall(serial, accessNetwork, dataProfile, roamingAllowed, reason, addresses, dnses, pduSessionId, sliceInfo, matchAllRuleAllowed).
6. Modem signalling The modem sends an ESM PDN Connectivity Request (LTE) or 5GSM PDU Session Establishment Request (5G).
7. Response SetupDataCallResult returns a cause (DataFailCause), interface name (rmnet_data0 / ccmni0), addresses, DNS, gateways, MTU, P-CSCF addresses, and optionally QoS and slice information.
8. Network agent DataNetwork creates a TelephonyNetworkAgent, netd configures the interface and routes, and ConnectivityService calls onAvailable(Network) on the requesting app.
9. Teardown When no request needs it, deactivateDataCall. The modem can also drop it and report through dataCallListChanged.

Retry and throttling

• Failed setups are retried by DataRetryManager according to carrier-config retry rules (per cause, with back-off intervals).
• The network can impose back-off through T3396 (per-APN, after an ESM reject such as #26 insufficient resources) or T3346 (mobility-management congestion). The modem reports the suggested retry time in the response; the framework must honour it.
• Permanent failures (for example #27 unknown APN, #33 not subscribed) should stop automatic retries until something changes (new APN, SIM, or settings).
• IRadioData.setDataThrottling lets the framework ask the modem to reduce throughput (for example for thermal mitigation).

RIL: the Radio Interface Layer

The RIL is the translator between the Java framework and the vendor radio software. On the framework side it is RIL.java (usually called RILJ), which implements CommandsInterface; there is one instance per logical modem/SIM slot. Its job is to turn method calls into HAL requests, match responses back to the caller, deliver unsolicited events, keep the device awake while requests are pending, and recover when the vendor side dies.

Solicited vs unsolicited

Solicited request lifecycle

// Simplified from frameworks/opt/telephony RIL.java
RILRequest rr = obtainRequest(RIL_REQUEST_SETUP_DATA_CALL, result, mRILDefaultWorkSource);
    // RILRequest.obtain(): take from pool, assign mSerial (atomic counter),
    // store the caller's result Message
    // acquireWakeLock(rr, FOR_WAKELOCK): mWakeLockCount++ (acquire on 0 -> 1),
    // post a WAKE_LOCK_TIMEOUT message
    // mRequestList.append(rr.mSerial, rr)
riljLog(rr.serialString() + "> " + RILUtils.requestToString(rr.mRequest));
dataProxy.setupDataCall(rr.mSerial, accessNetwork, dataProfile, ...);   // HAL call, returns at once

        ... modem works; seconds may pass ...

// Vendor calls back on IRadioDataResponse.setupDataCallResponse(info, result)
RILRequest rr = mRil.processResponse(HAL_SERVICE_DATA, info);
    // findAndRemoveRequestFromList(info.serial)
    // if info.type == SOLICITED_ACK_EXP: send ack, switch to ack wakelock
if (rr != null) {
    if (info.error == RadioError.NONE) sendMessageResponse(rr.mResult, result);
    mRil.processResponseDone(rr, info, result);   // logs "<", completes rr.onError/onReceived,
                                                  // decrementWakeLock(rr), rr.release() back to pool
}

Key RIL types

Wakelocks and acknowledgements

• RIL holds a partial wakelock (tag *telephony-radio*) while any solicited request is outstanding, so the application processor (AP) does not suspend mid-request. It is not reference-counted by PowerManager; RIL keeps its own mWakeLockCount, acquiring on 0→1 and releasing on return to 0.
• A timeout (WAKE_LOCK_TIMEOUT, configurable) releases the lock if the modem never answers, so a lost response cannot pin the CPU awake forever.
• A second short ack wakelock covers the acknowledgement protocol: if the vendor returns SOLICITED_ACK ("received, still working"), RIL can drop the main wakelock; for indications of type UNSOLICITED_ACK_EXP, RIL briefly holds the ack wakelock and calls responseAcknowledgement() so the vendor can release its own wakelock.
• Every request carries a WorkSource so battery stats blame the right app.

Reading RILJ logs

RILJ : [0342]> SETUP_DATA_CALL,reason=NORMAL,accessNetwork=EUTRAN,dataProfile=...  [PHONE0]
RILJ : [0342]< SETUP_DATA_CALL DataCallResponse: { cause=NONE ifname=rmnet_data1
       addresses=[10.x.x.x/32, 2001:db8::/64] dnses=[...] mtuV4=1500 mtuV6=1500 ... }  [PHONE0]
RILJ : [UNSL]< UNSOL_RESPONSE_NETWORK_STATE_CHANGED  [PHONE0]
RILJ : [0343]> VOICE_REGISTRATION_STATE  [PHONE0]
RILJ : [0343]< VOICE_REGISTRATION_STATE error: RADIO_NOT_AVAILABLE  [PHONE0]
RILJ : [0344]> SETUP_DATA_CALL ... (no matching "<" line = response never came)

The number in brackets is the serial; > is a request, < a response, [UNSL] an indication. A request with no matching response line points below the RIL (vendor daemon or modem). [PHONE0]/[PHONE1] tells you the slot.

Death and recovery

1. Link to death RIL registers a death recipient on every HAL service binder.
2. serviceDied() If the vendor process dies, the callback fires for each affected service.
3. Flush RIL completes every pending RILRequest with RADIO_NOT_AVAILABLE, clears the request list, releases wakelocks and resets the proxies.
4. Radio state The framework sees radio state UNAVAILABLE; service state and data calls are torn down.
5. Reconnect RIL waits for the HAL service to be registered again, re-sends response/indication callbacks (setResponseFunctions) and the framework resynchronizes (SIM status, radio power, data profiles).

Legacy native RIL (before Treble)

Older devices ran AOSP rild, which loaded a vendor library (librilvendor.so) through RIL_Init. Framework requests arrived over a Unix socket as parcels; libril dispatched them to the vendor's onRequest, and the vendor answered with RIL_onRequestComplete or pushed events with RIL_onUnsolicitedResponse. The request IDs (RIL_REQUEST_DIAL, RIL_UNSOL_RESPONSE_NEW_SMS...) still appear in logs and in RILConstants. HIDL (Android 8) replaced the socket with HwBinder; AIDL (Android 13) replaced HIDL.

Radio HAL (AIDL) and the vendor RIL daemon

The Radio HAL is the stable contract between AOSP and the chipset vendor. AOSP defines the interfaces and calls them; the vendor implements them inside its RIL daemon. Because the contract is versioned and frozen, Google can update the framework without the vendor rebuilding its radio stack (the Project Treble idea).

Three interface families per domain

• IRadioX: requests the framework calls (implemented by the vendor). Every method takes a serial and returns immediately (oneway).
• IRadioXResponse: solicited replies (implemented by the framework, called by the vendor), each carrying RadioResponseInfo.
• IRadioXIndication: unsolicited events (implemented by the framework, called by the vendor).

At startup RIL calls setResponseFunctions(response, indication) on each service to hand its callback binders to the vendor, so Binder runs in both directions.

RIL (client)                                   vendor rild (server for IRadioVoice)
  |-- IRadioVoice.dial(serial=42, dialInfo) --------->|   returns immediately (oneway)
  |                                                   |-- QMI VOICE dial / ATD --> modem
  |<-- IRadioVoiceResponse.dialResponse(info{serial=42, error=NONE}) --|   reverse Binder call
  |   RadioResponse matches serial 42, completes RILRequest            |
  |                                                   |<-- modem: call state change
  |<-- IRadioVoiceIndication.callStateChanged(type) ---|   unsolicited
  |   GsmCdmaCallTracker.pollCallsWhenSafe() -> getCurrentCalls(serial=43) ...

The AIDL modules

Per-slot services are registered as android.hardware.radio.network.IRadioNetwork/slot1, .../slot2 and so on; IRadioConfig is a single /default instance. IRadioIms exists because on modern designs the IMS stack may run on the AP (vendor ImsService) while the modem still needs to know about IMS traffic for access barring, SRVCC and EPS fallback.

HIDL vs stable AIDL

RIL.java supports both at runtime: each RadioServiceProxy wraps either an AIDL or a HIDL handle, and RIL tracks the HAL version per service so it can reply REQUEST_NOT_SUPPORTED for methods the vendor does not implement.

How the HAL is found at boot

1. Declaration The vendor's VINTF manifest fragment declares, for example, android.hardware.radio.data.IRadioData/slot1 with a version.
2. Compatibility The framework compatibility matrix lists which versions it accepts; a mismatch fails the VTS/compatibility check.
3. Start init starts the vendor daemon from its .rc file (or on demand for lazy HALs through ctl.interface_start).
4. Register The daemon registers each service with servicemanager.
5. Bind RIL calls ServiceManager.waitForDeclaredService(...), gets the binder, links to death and calls setResponseFunctions.

Vendor implementations

Everything from Dialer down to RIL.java is the same AOSP code on both vendors; divergence starts at the HAL implementation. OEMs may add hooks above the HAL (extended phone or call-tracker classes), which is why stack traces sometimes show OEM class names inside the phone process.

The modem and AP interface

The modem (baseband) is a separate processor, usually a DSP cluster inside the same SoC (Qualcomm MPSS on a Hexagon core; MediaTek MD1) or a separate chip connected by PCIe. It runs its own real-time OS and the full 3GPP stack. The application processor (AP) running Android talks to it on two separate paths: a control path for commands and events, and a data path for IP packets.

          APPLICATION PROCESSOR (Android)                        MODEM
 +-----------------------------------------+       +------------------------------+
 | vendor RIL daemon (qcrild / MTK rild)   |       |  modem RTOS                  |
 |   QMI clients / MIPC / AT               |       |  QMI services / AT parser    |
 +-------------------+---------------------+       |  NAS / RRC / PDCP / RLC /    |
 | kernel: QRTR sockets (QC)  or           |       |  MAC / PHY                   |
 |         /dev/ccci_* char devices (MTK)  | <===> |                              |
 |   transport: GLINK / SMD over SMEM,     |control|                              |
 |              or MHI over PCIe           |       |                              |
 +-----------------------------------------+       |                              |
 | net: rmnet_data* over rmnet_ipa0/mhi    | <===> |  user-plane buffers          |
 |      (QMAP mux + aggregation, IPA HW)   | data  |                              |
 |      ccmni* over CCCI/DPMAIF (MTK)      |       |                              |
 +-----------------------------------------+       +------------------------------+
   shared DDR memory regions, doorbell interrupts, SMMU-protected DMA

QMI (Qualcomm MSM Interface)

• A service-oriented, binary request/response/indication protocol between AP clients and modem services. Messages are TLV (type-length-value) encoded, identified by service ID, message ID and a transaction ID.
• Transport: the IPC router, exposed in upstream Linux as QRTR (AF_QIPCRTR sockets), running over GLINK/SMD on shared memory for on-chip modems, or over MHI (Modem Host Interface) on PCIe for external modems. Older stacks used the qmuxd daemon.
• Conceptually mirrors the HAL: a HAL request usually maps to one or more QMI requests; QMI indications become HAL indications.

AT commands

• Text commands defined by 3GPP TS 27.007 (general and network) and TS 27.005 (SMS). Common on external USB/M.2 modems and IoT modules, and used internally by MediaTek alongside MIPC.
• Responses end with OK or ERROR/+CME ERROR: n; unsolicited result codes (URCs) such as +CREG: or RING arrive at any time.

MediaTek: CCCI, MIPC and ccmni

• CCCI (Cross Core Communication Interface) is MediaTek's kernel driver for AP-modem communication. It exposes channels as character devices (/dev/ccci_*) for control, AT/MIPC, logging and file system services, plus network devices for data.
• Userspace helpers include ccci_mdinit (modem boot/init and monitoring) and ccci_fsd (serves modem file-system requests such as NV data from the AP side).
• MIPC is MTK's structured IPC protocol replacing much raw AT traffic; logs still often show AT> / AT< pairs.
• ccmni interfaces carry user-plane packets; a hardware data mover (for example CLDMA on older chips, DPMAIF on newer ones) moves packets between AP memory and the modem.
• Modem crashes are reported as md1 exception / MD_EE through CCCI and the AEE exception framework, with a modem memory dump.

Shared memory, interrupts and security

• AP and modem share carved-out DDR regions (SMEM on Qualcomm). Messages are written into ring buffers; a doorbell interrupt tells the other side to read.
• DMA from the modem is restricted by the SMMU/IOMMU and memory firewalls (Qualcomm xPU), so a compromised modem cannot read arbitrary AP memory.
• The modem firmware is loaded and authenticated by the AP at boot: on Qualcomm the kernel's remote-processor driver (historically PIL, today remoteproc with qcom_q6v5_mss/_pas) loads the images from the modem partition, and TrustZone verifies signatures before the modem runs.

NV items, EFS and modem configuration

• NV items / EFS: the modem's persistent store for RF calibration, IMEI (protected), band settings, feature flags and certificates. Corruption can leave the device without radio; IMEI and calibration are specially protected.
• MBN / carrier configuration: Qualcomm modems load a carrier-specific configuration package (MBN) selected by PDC based on the SIM, setting modem-side behaviour (bands, IMS, timers). MediaTek has equivalent modem carrier configurations. Framework CarrierConfig and modem configuration must agree, or features like VoLTE break.

Modem crash and restart (SSR)

1. Fault The modem hits a fatal error (assert, "err_fatal"), its watchdog expires, or the AP requests a restart.
2. Notify The kernel remote-processor / subsystem-restart framework is notified; if enabled, a ramdump of modem memory is collected.
3. Tear down clients Registered notifiers (rmnet/IPA data path, QRTR, RIL daemon, IMS) are told the modem went down; data interfaces go down and pending requests fail.
4. Reload Firmware is reloaded and restarted; the modem re-initializes.
5. Recover upward The RIL daemon reports radio state UNAVAILABLE then back, may send a modemReset indication with a reason string; the framework re-reads SIM status, re-registers, and re-establishes data and IMS.

User-visible effect: a few seconds of "no service", dropped calls, lost data connections. MediaTek follows the same idea with an md1 exception, CCCI notification and modem reset.

3GPP protocol layers inside the modem

These layers run in modem firmware, but telephony engineers must be conversant because cause codes and logs come from them. The stack is split into the Non-Access Stratum (NAS), which talks end to end to the core network, and the Access Stratum (AS), which talks only to the base station.

  CONTROL PLANE                          USER PLANE
 +------------------+                   +------------------+
 | NAS (EMM/ESM,    |  UE <-> MME/AMF    |  IP packets      |  UE <-> P-GW/UPF
 |      5GMM/5GSM)  |                   +------------------+
 +------------------+                   |  SDAP (5G only)  |  QoS flow -> DRB mapping
 | RRC              |  UE <-> eNB/gNB    +------------------+
 +------------------+                   |  PDCP            |
 | PDCP             |                   +------------------+
 +------------------+                   |  RLC             |
 | RLC              |                   +------------------+
 +------------------+                   |  MAC             |
 | MAC              |                   +------------------+
 +------------------+                   |  PHY             |
 | PHY              |                   +------------------+
 +------------------+
   Signalling radio bearers (SRB0/1/2)    Data radio bearers (DRBs)

RRC states and procedures

• RRC_IDLE: no radio connection; the UE does cell selection/reselection and listens for paging at DRX occasions. Lowest power.
• RRC_CONNECTED: dedicated resources; the network controls mobility via handover.
• RRC_INACTIVE (NR): context kept in the network and UE, radio released; resume is much faster than a fresh setup. Saves power and signalling.
• Key procedures: RRC connection setup (LTE RRCConnectionRequest/Setup/SetupComplete; NR RRCSetupRequest/RRCSetup/RRCSetupComplete), Security Mode Command, RRC Reconfiguration (adds bearers, measurements, handover), RRC Release (optionally with redirection), re-establishment after failure.
• RLF (Radio Link Failure): declared on T310 expiry after out-of-sync indications, maximum RLC retransmissions, or random-access problems; the UE tries RRC re-establishment, otherwise it goes idle.

Mobility and power saving

• Idle mode: PLMN selection, cell selection (S-criterion) and reselection by priority and thresholds, paging reception, tracking-area updates.
• Connected mode: measurement events A1–A6 (intra-RAT: serving better/worse than threshold, neighbour better than serving...), B1/B2 (inter-RAT); handover over X2/Xn directly between base stations or via the core (S1/N2); conditional handover (CHO) where the UE executes a pre-prepared handover when conditions are met.
• DRX / eDRX: the UE sleeps between paging or PDCCH monitoring occasions; eDRX stretches cycles to seconds or minutes for IoT and wearables at the cost of reachability latency.
• PSM (Power Saving Mode): the UE stays registered but unreachable for long periods (timers T3324/T3412 extended); used by IoT devices.

From boot to "in service": registration and attach

Before a phone can call or use data it must find a network, prove who it is, and register. On LTE this is the Attach procedure (which also creates the first data connection); on 5G it is Registration (with data connections set up separately as PDU sessions). This section ties the framework, RIL, SIM and 3GPP pieces together into one timeline.

Boot to in service: the Android timeline

1. Phone process starts PhoneFactory.makeDefaultPhones() creates RIL and GsmCdmaPhone per slot; RIL binds to the Radio HAL services and registers callbacks.
2. rilConnected / radio state The vendor daemon reports readiness; radio state moves from UNAVAILABLE to OFF.
3. SIM UiccController calls getIccCardStatus; the card tree is built, PIN checked, records loaded; subscription and carrier config are finalized.
4. Radio on Unless airplane mode is on, SST calls setRadioPower(true). The framework also sends allowed network types, initial attach APN and data profiles.
5. Modem registers PLMN search → cell selection → RRC connection → NAS Attach / Registration (below).
6. Framework sees service networkStateChanged → pollState() → STATE_IN_SERVICE → notifications.
7. Data and IMS DataNetworkController sets up internet and IMS data connections; the vendor ImsService performs IMS registration; the VoLTE/VoNR indicator appears.

PLMN and cell selection

• Automatic mode order: last registered PLMN → home PLMN / equivalent home (EHPLMN) → user-controlled list (EF_PLMNwAcT) → operator-controlled list (EF_OPLMNwAcT) → other PLMNs by signal quality. Forbidden PLMNs (EF_FPLMN) are skipped.
• Manual mode: the user picks from a network scan (startNetworkScan → setNetworkSelectionModeManual).
• The modem camps on a suitable cell (S-criterion satisfied, not barred, PLMN allowed, tracking area not forbidden). If only a non-allowed network is available it camps in "limited service" for emergency calls (STATE_EMERGENCY_ONLY).
• Allowed RATs come from setAllowedNetworkTypesBitmap (combination of user preference, carrier restrictions, power/thermal reasons).

LTE Attach

UE                        eNB                    MME                 HSS / S-GW / P-GW
 |-- RRCConnectionRequest -->|                       |                        |
 |<-- RRCConnectionSetup ----|                       |                        |
 |-- RRCConnectionSetupComplete [NAS: Attach Request + PDN Connectivity Request] -->|
 |                           |-- Initial UE Message ->|                        |
 |<================ NAS Authentication Request (RAND, AUTN) ====|<-- auth vectors -|
 |   USIM runs AKA: checks AUTN (network is genuine), computes RES               |
 |================= NAS Authentication Response (RES) ========>|                  |
 |<================ NAS Security Mode Command / Complete =====>|                  |
 |                           |                       |-- Update Location ----->| HSS
 |                           |                       |-- Create Session ------>| S-GW/P-GW (IP allocated)
 |<-- AS Security Mode Command / Complete, UE Capability Enquiry --|             |
 |<-- RRCConnectionReconfiguration [NAS: Attach Accept + Activate Default EPS Bearer Context Request] --|
 |-- RRCConnectionReconfigurationComplete -->|        |                        |
 |-- [NAS: Attach Complete + Activate Default EPS Bearer Context Accept] ------>|
 |   Registered (EMM-REGISTERED), default bearer up, IP address assigned         |

Because LTE attach always creates a default bearer, an LTE phone is "always on IP". The APN used is the initial attach APN the framework pushed (or one the network chooses). If the default bearer is rejected, attach fails with an ESM cause wrapped in an EMM reject.

5G Registration and PDU sessions

• UE sends Registration Request (types: initial, mobility update, periodic, emergency) with a concealed identity SUCI (the encrypted form of the permanent SUPI/IMSI).
• Authentication: 5G-AKA or EAP-AKA' via AUSF/UDM; then NAS security mode.
• Registration Accept carries the temporary identity (5G-GUTI), registration area (TAI list), allowed NSSAI (slices) and timers; UE replies Registration Complete.
• Data is a separate step: PDU Session Establishment with the SMF, selecting a DNN (APN) and slice (S-NSSAI); the UPF is the user-plane gateway.

Staying registered

CS services on LTE: CSFB and combined attach

On LTE networks without VoLTE, the UE does a combined EPS/IMSI attach so the MSC knows about it. For a call it performs CS Fallback (CSFB): it leaves LTE for 2G/3G, places the CS call, then returns. On the air interface the marker is a NAS EXTENDED SERVICE REQUEST followed by RRC release with redirection (or PS handover / cell change order). The framework only sees a normal CS dial plus a RAT change in ServiceStateTracker. There is no AOSP class named CsFallbackHelper; some vendor trees add extra helper log tags that are not in AOSP. Combined-attach rejects with EMM #18 ("CS domain not available") push devices to rely on IMS for voice. The AOSP IMS-to-CS redial path is covered in CS & IMS Call Flows.

NAS states, paging, TAU and radio mobility

After attach, interviewers expect you to separate registration state (am I known to the core?) from connection state (is there a signalling path right now?) and from RRC state (is the radio up?). Mixing those three is the usual stumble. This section also covers the high-frequency procedures that move a UE between those states: paging and Service Request, Tracking Area Update, access barring, AKA failure types, and intra-LTE X2 handover.

EMM, ECM, 5GMM and CM states

Paging and Service Request (idle to connected)

Downlink data, an incoming IMS INVITE, or an MT CS/CSFB call all start the same way if the UE is idle: the network pages, the UE brings up RRC, then it sends a NAS Service Request so the core can restore the user plane.

UE (ECM-IDLE / RRC_IDLE)                 eNB                         MME / S-GW
 |  listens at DRX paging occasions        |                            |
 |<----------- Paging (S-TMSI) ------------|  (from MME paging)         |
 |-- RRCConnectionRequest (mt-Access) ---->|                            |
 |<-- RRCConnectionSetup ------------------|                            |
 |-- RRCConnectionSetupComplete [NAS: Service Request] ---------------->|
 |<-- Security / RRC reconfiguration [user-plane bearers restored] -----|
 |   ECM-CONNECTED, RRC_CONNECTED; downlink data or INVITE / CS SETUP   |

MO data or signalling while idle uses the same Service Request,
with establishment cause mo-Data or mo-Signalling instead of mt-Access.
CSFB uses EXTENDED SERVICE REQUEST rather than a plain Service Request.
T3417 supervises the Service Request (typical 3GPP default 5 s).

On Android you see this as a networkStateChanged plus a brief radio-connected period, then (for MT IMS) notifyIncomingCall, or (for MT CS) callStateChanged. If paging never arrives, the callee never rings even though the device looks in service.

Tracking Area Update

• Normal / TA-change TAU: the UE camps on a cell whose TAI is not in the last TAI list from Attach/TAU Accept.
• Periodic TAU: T3412 expires (typical default 54 minutes). If the UE never updates, the MME implicitly detaches it (EMM #10).
• Other common triggers: load balancing, recovery after a failed Service Request, and some capability or bearer changes.
• Ladder: RRC setup (if idle) → NAS Tracking Area Update Request → (possible auth / security) → TAU Accept (new TAI list, maybe new GUTI) → TAU Complete. T3430 supervises the request (typical default 15 s).
• 5G equivalent: mobility or periodic Registration Update; T3512 is the periodic timer (typical default 54 minutes).

Access barring and UAC

The network can stop UEs from starting traffic even when RF looks fine. LTE uses AC barring / SSAC (separate flags for MMTEL voice and video) in system information. 5G uses Unified Access Control (UAC): each access attempt has an access category (for example emergency, MMTEL voice, MO data) and an access identity; the gNB broadcasts barring parameters per category. That is why the modem must be told when IMS traffic starts (IRadioIms.startImsTraffic): it applies the right category before it tries RRC. On Android, IRadioNetworkIndication.barringInfoChanged and getBarringInfo surface this to the framework; a "VoLTE registered but INVITE never leaves" bug is often barring, not SIP.

LTE AKA: MAC failure vs sync failure

The network sends RAND and AUTN. The USIM checks AUTN in two steps:

1. MAC check first. If the message-authentication code is wrong, the UE sends AUTHENTICATION FAILURE with cause MAC failure. That usually means the wrong key (wrong SIM, cloned IMSI, or the HSS vector does not match this USIM). The network does not recover by retrying the same vector.
2. Sequence-number check next. If the MAC is good but SQN is outside the acceptable window, the UE sends AUTHENTICATION FAILURE with cause synch failure and an AUTS token. The HSS resynchronises SQN and the network retries with a fresh vector. This is a recoverable desync, not a "bad SIM".

Do not treat every AKA failure as "illegal UE". MAC failure and sync failure are different next steps. After a successful RES match, NAS Security Mode Command activates the derived keys.

X2 handover (intra-LTE sketch)

UE                    Source eNB                         Target eNB              MME / S-GW
 |-- meas config ---->|                                    |                      |
 |-- A3 (neighbour better than serving) ----------------->|                      |
 |                    |-- X2 HANDOVER REQUEST ------------->|                      |
 |                    |<-- X2 HANDOVER REQUEST ACK ---------|  (prepared RRC)     |
 |<-- RRC Reconfiguration (handover command) --------------|                      |
 |   sync + RACH to target, RRC Reconfiguration Complete ->|                      |
 |                    |                                    |-- Path Switch ------>|
 |                    |   SN status / data forward         |<-- Path Switch Ack --|
 |                    |<-- UE context release --------------|                      |
 |   still EMM-REGISTERED; RRC stays CONNECTED on the new cell                    |

X2 is eNB-to-eNB. If there is no X2, the same move goes over S1 through the MME (slower). NR uses Xn between gNBs, or N2 through the AMF. Interviewers want the idea: prepare on the target, command the UE, path-switch the user plane, then release the source. Conditional handover (CHO) pre-loads that command and lets the UE execute it when a condition is met.

IMS, 5G and call flows at a glance

Voice on modern networks is carried by IMS (IP Multimedia Subsystem): a SIP session with RTP media over a dedicated IP bearer. 5G adds a new core and radio. Both have their own detailed pages; this section gives the overview a RIL/modem engineer needs and shows where they touch the stack described here.

IMS in the Android stack

• A vendor or carrier ImsService is bound by ImsResolver per slot and provides MmTelFeature (voice, video, SMS over IMS) and RcsFeature.
• GsmCdmaPhone delegates calls to ImsPhone / ImsPhoneCallTracker when IMS is registered; otherwise it uses the CS path through GsmCdmaCallTracker and IRadioVoice.
• IMS needs the IMS PDN (brought up by DataNetworkController) and a P-CSCF address (from PCO in the setupDataCall response, or DHCP).
• Registration: SIP REGISTER → 401 Unauthorized with an AKA challenge (computed by ISIM/USIM) → re-REGISTER → 200 OK.
• Bearers: QCI 5 for SIP signalling (default bearer on IMS APN), QCI 1 guaranteed-bit-rate bearer for voice, QCI 2 for video; 5G uses 5QI 5 and 5QI 1 QoS flows.
• Continuity: SRVCC moves an active VoLTE call to CS when LTE coverage ends; EPS fallback moves a call setup from 5G SA to LTE when VoNR is not available; Wi-Fi calling uses an ePDG tunnel and can hand over to and from cellular.

VoLTE MO call (condensed):
UE ── INVITE (SDP offer) ──▶ P-CSCF ──▶ S-CSCF ──▶ ... ──▶ callee
   ◀── 100 Trying
   ◀── 183 Session Progress (SDP answer, preconditions)
   ; P-CSCF typically starts dedicated QCI 1 setup from the SDP answer (around 183, not strictly at PRACK)
   ── PRACK ──▶
   ── UPDATE (preconditions met) ──▶ ; ◀── 200 OK
   ◀── 180 Ringing ; ◀── 200 OK (INVITE) ; ── ACK ──▶
   ═══ RTP/RTCP voice on QCI 1 ═══   ; hang up: BYE / 200 OK

5G essentials that touch RIL and the framework

Call flows through the stack

CS / IMS outgoing call through every process boundary:
Dialer ──Binder──▶ TelecomService / CallsManager            [system_server]
   ──bind──▶ TelephonyConnectionService.onCreateOutgoingConnection  [com.android.phone]
      ──▶ GsmCdmaPhone.dial()  (domain selection: IMS or CS)
          IMS: ImsPhone ─▶ ImsPhoneCallTracker ─▶ ImsService/MmTelFeature ─▶ SIP INVITE
          CS : GsmCdmaCallTracker ─▶ RIL.dial ─▶ IRadioVoice.dial(serial) ─▶ rild
                 ─▶ QMI VOICE dial (Qualcomm) / ATD or MIPC (MediaTek) ─▶ modem CC/MM signalling
   state flows back: callStateChanged ─▶ getCurrentCalls ─▶ Connection ─▶ Telecom ─▶ InCallService UI

The data plane: APN, PDN, rmnet, routing and tethering

A "data call" has two halves that people often confuse. The control plane negotiates the bearer: which APN, which IP addresses, which QoS. The user plane is the highway the IP packets drive on afterwards; on modern SoCs it is hardware-accelerated and mostly bypasses the CPU.

Step 1: control plane (set up the pipe)

App / ConnectivityService          Telephony (phone process)                 Modem
  | NetworkRequest(INTERNET) ------> |                                        |
  |                                  | DataNetworkController picks            |
  |                                  | DataProfile (APN), checks data         |
  |                                  | enabled / roaming / DDS / throttling   |
  |                                  | RIL.setupDataCall -------------------> | QMI WDS start network
  |                                  |                                        | NAS: PDN / PDU activation
  |                                  | <--------- SetupDataCallResult -------- | (cause, ifname, addrs,
  |                                  |                                        |  dns, gw, mtu, pcscf)
  |                                  | DataNetwork + TelephonyNetworkAgent;    |
  |                                  | netd: bring up rmnet_data1, add         |
  |                                  | addresses, per-network routing table   |
  | <--- onAvailable(Network) ------- |                                        |
  | (sockets bind to this Network)                                            |

Step 2: user plane (the packet's journey)

App socket write()
   │  syscall
Kernel TCP/UDP/IP stack
   │  routing: ip rule (fwmark carries netId / UID) ──▶ per-network table ──▶ dev rmnet_data1
   │  netfilter / eBPF: per-UID firewall, data saver, accounting, tethering NAT
rmnet_data1  (logical netdev, one per PDN)
   │  rmnet driver adds QMAP header (mux ID = which PDN), aggregates packets, flow control
rmnet_ipa0 (on-chip)  or  rmnet_mhi0 (PCIe modem)          MediaTek: ccmni1 over CCCI / DPMAIF
   │  IPA hardware: DMA through SMMU, header processing, filtering, NAT, aggregation
Modem: PDCP (cipher, ROHC) ─▶ RLC ─▶ MAC (schedule, HARQ) ─▶ PHY
   │  RF over Uu
eNB / gNB ─▶ S-GW/P-GW or UPF ─▶ internet          (downlink is the exact reverse)

IP routing on Android

• Each Network gets its own routing table (named after the interface, for example rmnet_data1). ip rule entries select the table using a fwmark that encodes the network ID, set on sockets by netd based on the app's default network or explicit Network.bindSocket().
• This is how IMS traffic uses the IMS PDN while apps use the internet PDN, and how an app can use cellular while Wi-Fi is the default.
• Useful commands: ip addr, ip rule, ip route show table all, dumpsys connectivity.

IPv4, IPv6 and 464XLAT

• PDN types: IPv4, IPv6 or IPv4v6. The network may restrict (ESM #50 "IPv4 only allowed", #51 "IPv6 only allowed").
• IPv6 on cellular gets a /64 prefix via router advertisement after the PDN is up; the modem-provided interface identifier forms the address.
• On IPv6-only networks, Android runs clatd (464XLAT): a v4-rmnet_data1 interface translates app IPv4 traffic to IPv6, with NAT64 in the network.

Multiple PDNs and MTU

• Each APN (internet, IMS, MMS, DUN) is a separate PDN with its own interface, addresses and bearer.
• MTU comes from the network in the data call response (or PCO). A wrong MTU causes fragmentation or silent "black-hole" drops of large packets: pages half-load, TLS handshakes hang. A classic symptom is "small pings work, large downloads stall".
• Flow control: the modem signals the kernel to pause and resume uplink so the radio buffer is not overrun.

Tethering

• The Tethering module (a Mainline module) sets up the hotspot/USB/Bluetooth interface, DHCP, and NAT from the tethered clients to the upstream cellular network.
• Some carriers require a DUN APN for tethered traffic, so tethering may bring up a separate PDN; carrier config controls this and whether tethering is allowed at all (entitlement checks).
• Forwarding can be offloaded: Qualcomm IPA through the tethering offload HAL, or eBPF-based forwarding in the kernel on newer releases, so the CPU does not touch every packet.

Why hardware offload matters

Copying every packet through the CPU at hundreds of megabits per second would keep big cores awake and burn battery, and would cap throughput. With IPA-style offload, the AP sets up the path once and then can sleep while packets move by DMA; interrupts are coalesced and packets aggregated. This is a central power topic for phones and wearables (see Power, Thermal & Battery).

System-design concepts in Android telephony

Telephony is a real-time, multi-actor, partly unreliable distributed system inside one device: several processes and processors, an external network that can refuse or delay you, and hardware that can crash and restart. The patterns it uses map directly onto generic system-design vocabulary, which lets you answer design questions with concrete, real examples.

Design prompt: multi-SIM data-switch arbiter

"Design the component that decides which SIM carries internet data on a dual-SIM phone."

• Inputs: user DDS choice, active call on the non-DDS SIM, foreground app needs, roaming/cost policy, signal quality and service state per subscription, carrier restrictions.
• State machine with hysteresis to avoid flapping; debounce switch triggers; minimum dwell time.
• Atomic switch: tear down the old PDN and bring up the new one without leaking a stale default network; make "set preferred data modem" idempotent.
• Failure handling: if the new subscription fails to get data within a timeout, roll back to the previous one (transactional switch).
• Observability: switch latency, failure rate, flap count, time on each SIM.

Design prompt: resilient RIL to modem channel

"Make the framework survive a flaky or crashing radio HAL."

• Death recipient on each HAL service; on death, fail all in-flight requests with RADIO_NOT_AVAILABLE so no caller hangs.
• Timeouts on every solicited request, plus a wakelock timeout, so a lost response can neither deadlock a state machine nor pin power.
• Idempotent re-initialization on HAL restart (re-send profiles, radio power, indication filters); bounded retry with back-off.
• Never crash the persistent process on a transient failure or on a telemetry path; catch, recover, log.
• Back-pressure: cap outstanding requests, coalesce duplicate polls.

Design prompt: carrier-config delivery

"Deliver per-carrier settings to millions of devices, overridable per SIM."

• Layered config: platform defaults → carrier bundle keyed by carrier ID → server-pushed override → runtime cache.
• Invalidation on SIM swap, roaming change, OTA; versioned so devices detect staleness.
• Safe rollout: staged percentage, kill switch, rollback; validate keys and types before applying.

Design prompt: telephony metrics and modem-log pipeline

"Collect call-drop and registration-failure KPIs (and modem logs) from a device fleet."

• On device: bounded ring buffer, local aggregation and sampling instead of shipping every event, privacy scrubbing (no IMSI, phone numbers or precise location).
• Upload in batches on Wi-Fi and charging; back-off on failure; triggered full modem-log capture only for targeted cohorts.
• Server: partition by build, region, carrier and chipset; compare against a baseline to tell a real regression from a handful of noisy devices.

Debugging playbook

Telephony bugs cross many layers and two processors, and the first obvious explanation is often wrong. The method below is evidence-first: establish the environment, check modem health, find protocol cause codes at the exact timestamp, then read framework evidence, and only then conclude with a stated confidence.

The toolbox

Mandatory first check

1. Chipset and log family MediaTek (mipc, md1, ccci, Rfx) or Qualcomm (qcril, QMI, subsys/remoteproc, DIAG)? This decides which keywords and tools apply.
2. Environment Is the device in usable RF? RSRP/RSRQ/SINR, serving PLMN, roaming, SIM state, airplane-mode transitions, user actions around the event.
3. Modem health Any reset near the event? Qualcomm SSR/ramdump, MediaTek md1 exception, RIL serviceDied, radio state UNAVAILABLE, phone-process restart.

Decision priorities (apply in order)

Hypothesis and evidence matrix

List every plausible hypothesis with evidence for and against before concluding. This prevents confirmation bias.

Contradiction-detection rules

• SIP error + healthy modem → IMS/operator/provisioning layer, not the modem.
• NAS cause + modem reset → the reset may be a consequence of the reject handling (or unrelated); compare timestamps.
• Stack deadlock + no radio evidence → app-side ANR; route to ANR analysis.
• Strong RF + persistent failure → suspect IMS, provisioning or configuration, not coverage.
• One slot fails on dual-SIM → slot- or subscription-specific, not a platform-wide bug.
• Reproduces on only one build → code regression; diff against a known-good build.

Symptom-driven checklists

Useful log markers

Worked case study A: fatal RIL wakelock crash

Symptom: the persistent com.android.phone process dies repeatedly. The crash-reporting tool labelled it with a vendor IWLAN service package, because that package shares the phone process and happened to be last in the process's package list.

FATAL EXCEPTION: main   Process: com.android.phone
java.lang.IllegalArgumentException: Wakelock.mLock is already dead.
  at android.os.PowerManager$WakeLock.acquire(...)
  at com.android.internal.telephony.RIL.acquireWakeLock(RIL.java)
  at com.android.internal.telephony.RIL.obtainRequest(RIL.java)
  at com.android.internal.telephony.RIL.getModemActivityInfo(RIL.java)
  at <OEM modem-activity telemetry manager>.poll(...)
  at com.android.phone.PhoneInterfaceManager$MainThreadHandler.handleMessage(...)
Caused by: android.os.RemoteException
  at com.android.server.power.PowerManagerService$WakeLock.linkToDeath(...)

Worked case study B: "no radio" that is not a modem fault

Symptom: thousands of serviceProxy == null lines from an IMS radio adapter and "modem disabled" messages; it looks as if the modem is down.

Cause-code cheat sheets

Cause codes are the single most valuable debugging evidence: they say who refused what and why. NAS codes come from the core network (3GPP TS 24.301 for LTE, TS 24.501 for 5G), SIP codes from the IMS network (RFC 3261), RIL errors from the vendor HAL, and call-control causes from CS signalling (TS 24.008). Android surfaces data causes as DataFailCause constants whose values usually equal the 3GPP numbers.

NAS EMM (LTE mobility) reject causes

NAS ESM (LTE session / PDN) causes

5GSM mirrors many of these (for example #27 missing or unknown DNN, #26 insufficient resources, #33 not subscribed).

5GMM (5G mobility) reject causes

SIP response codes (IMS)

RIL errors and NAS timers

CS call-control disconnect causes (TS 24.008)

Quick revision

• Stack: apps → Telecom (system_server) + Telephony (com.android.phone) → RIL.java → Radio HAL → vendor daemon → modem → Uu air interface.
• Telecom routes calls with PhoneAccount/ConnectionService/InCallService; Telephony owns the radio and plugs in as TelephonyConnectionService.
• PhoneFactory creates one RIL and one GsmCdmaPhone per slot; ImsPhone handles IMS calls when registered.
• ServiceStateTracker reacts to networkStateChanged by polling operator, voice reg, data reg and selection mode, then notifies via TelephonyRegistry.
• DataNetworkController (Android 13+) replaced DcTracker/DataConnection/ApnContext; DataNetwork = one connection, DataProfile = APN.
• SubscriptionManagerService (Android 14+) replaced SubscriptionController and owns DDS and default voice/SMS subscriptions.
• UICC tree: UiccController → UiccSlot → UiccCard/UiccPort → UiccProfile → applications (USIM, ISIM) → records.
• CarrierConfigLoader merges platform defaults, carrier-config app values by carrier ID and carrier-app overrides; broadcasts ACTION_CARRIER_CONFIG_CHANGED.
• Solicited = request with serial + response callback + wakelock; unsolicited = indication fanned out through RegistrantList.
• RILJ log: [serial]> request, [serial]< response, [UNSL]< indication; a missing response means the problem is below RIL.
• RIL holds the *telephony-radio* partial wakelock with its own count and a timeout; an ack wakelock covers the acknowledgement protocol.
• On HAL death, RIL fails every pending request with RADIO_NOT_AVAILABLE, resets proxies and reconnects when the service returns.
• serviceDied (vendor process died) is not the same as modem SSR / md1 exception (baseband crashed); timestamps decide cause and effect.
• Radio HAL: HIDL radio@1.0–1.6 monolithic IRadio → stable AIDL (Android 13) split into Network, Data, Voice, Sim, Modem, Messaging, Ims, Config.
• Each HAL domain has request, Response and Indication interfaces; setResponseFunctions hands callback binders to the vendor.
• HAL discovery: VINTF declaration → init starts daemon → registers with servicemanager → RIL waitForDeclaredService; declared-but-not-started gives a permanent null proxy.
• Qualcomm: qcrild → QMI (NAS, WDS, VOICE, UIM, WMS, DMS, IMSA...) over QRTR on GLINK/SMEM or MHI/PCIe.
• MediaTek: rild (Rfx/Rmm) → MIPC/AT over CCCI; data on ccmni; crashes are md1 exceptions.
• AT commands (TS 27.007/27.005): +CFUN, +COPS, +CEREG, +CGDCONT, +CGACT, ATD.
• NAS (EMM/ESM, 5GMM/5GSM) talks to the core; RRC, PDCP, RLC, MAC, PHY talk to the base station; SDAP maps QoS flows in 5G.
• PDCP = ciphering, integrity, ROHC; RLC = segmentation + ARQ; MAC = scheduling + HARQ; PHY = coding, modulation, MIMO.
• RRC states: IDLE, CONNECTED, and INACTIVE on NR; RLF triggers include T310 expiry, max RLC retransmissions, random-access failure.
• LTE attach creates a default bearer (always-on IP); 5G registration and PDU session establishment are separate steps.
• Authentication is AKA using the SIM's secret key; 5G hides the IMSI as SUCI.
• Control plane sets up the PDN/PDU and returns ifname, IP, DNS, MTU, P-CSCF; user plane uses rmnet_data* + QMAP + IPA offload so the CPU can sleep.
• Android routes per network with fwmark and per-network routing tables; IPv6-only networks use clatd (464XLAT).
• The IMS PDN stays up with mobile data off; QCI 5 carries SIP, QCI 1 carries voice (QCI 1 is typically started from the SDP answer around 183, not strictly at PRACK).
• DSDS shares one RF chain; DSDA runs both SIMs concurrently; PhoneSwitcher + setPreferredDataModem implement data switching.
• eSIM: eUICC (EID) + ISD-R + LPA (EuiccService) + SM-DP+; Android 13+ supports multiple enabled profiles.
• Debug order: chipset/log family → RF environment → modem health → cause codes at timestamp → framework evidence → hypothesis matrix.
• Key causes: EMM #11 PLMN not allowed (adds EF_FPLMN), EMM #13/#15 forbid a tracking area (not the whole PLMN), ESM #27 unknown APN, ESM #33 not subscribed, SIP 403 forbidden, SIP 488 codec mismatch.
• EMM-REGISTERED is not the same as ECM-CONNECTED: a camped LTE phone is usually registered and idle until paging or a Service Request (T3417).
• Typical 3GPP NAS timer defaults: T3410/T3430 15 s, T3411 10 s, T3412/T3512 54 min, T3417 5 s, T3402 12 min (network can override).
• AKA MAC failure means the AUTN is not for this USIM; sync failure (AUTS) is an SQN desync the HSS can recover.
• X2 handover: source prepares target, UE gets RRC handover command, target path-switches through the MME, source releases.
• Carrier privileges come from the UICC access-rule applet, checked by hasCarrierPrivileges(); they are not ordinary app permissions.
• Voice can be OOS while data is in service on LTE-only without IMS; read both ServiceState domains plus IMS registration.
• Back-off timers T3346 (mobility congestion), T3396 (per APN) and T3402 (after repeated failures) must be honoured.
• Big telephony dump: dumpsys activity service com.android.phone/.TelephonyDebugService; also telephony.registry, isub, carrier_config.

Glossary

5GMM / 5GSM

5G mobility management and session management; the NAS protocols for registration and PDU sessions.

AKA

Authentication and Key Agreement; challenge-response using the secret key in the USIM/ISIM, which also authenticates the network.

AMF / SMF / UPF

5G core functions for mobility, session management and the user-plane gateway.

AP

Application processor: the CPU cluster running Android, as opposed to the modem.

APN / DNN

Access Point Name (LTE) / Data Network Name (5G): names the gateway and service for a data connection.

ARQ / HARQ

Automatic Repeat reQuest in RLC (reliable, slower) and Hybrid ARQ in MAC (fast, with soft combining).

AT commands

Text modem commands standardized in 3GPP TS 27.007 and 27.005.

AUTS

Resynchronisation token the USIM returns on AKA sync failure so the HSS can realign SQN.

Carrier ID

Android's canonical identifier for a carrier, resolved from SIM attributes by CarrierResolver.

Carrier privileges

UICC-granted rights for an app whose signing certificate is listed in the SIM access-rule applet; checked with hasCarrierPrivileges().

CarrierConfig

Per-subscription bundle of carrier-specific settings exposed by CarrierConfigManager.

CCCI

Cross Core Communication Interface: MediaTek's kernel framework for AP to modem channels.

ccmni

MediaTek cellular network interfaces carrying user-plane IP traffic.

CSFB

Circuit-Switched Fallback: leaving LTE for 2G/3G to make a CS voice call.

DataNetworkController

Android 13+ framework class managing all data connections of one phone.

DDS

Default Data Subscription: the SIM that carries internet data on a multi-SIM phone.

DSDS / DSDA

Dual SIM Dual Standby (shared radio) / Dual SIM Dual Active (both SIMs active at once).

ECM

EPS Connection Management: ECM-IDLE (no NAS signalling connection) versus ECM-CONNECTED (NAS connection up). Distinct from EMM registration state.

EMM / ESM

EPS Mobility Management and EPS Session Management: the LTE NAS protocols.

EN-DC

E-UTRA NR Dual Connectivity: 5G NSA with an LTE anchor and NR secondary cell group.

eUICC / EID

Embedded UICC that stores downloadable profiles, and its unique identifier.

GLINK / SMD / SMEM

Qualcomm shared-memory transports and memory region used between processors.

ICCID

Integrated Circuit Card Identifier: the SIM card serial number.

IMS

IP Multimedia Subsystem: SIP-based core network for VoLTE, VoNR, Wi-Fi calling and RCS.

IMSI / SUPI / SUCI

Permanent subscriber identity (IMSI; SUPI in 5G) and its concealed 5G form (SUCI).

IPA

Qualcomm IP Accelerator: hardware that moves user-plane packets between AP memory and the modem.

IRadio*

Radio HAL interfaces (Network, Data, Voice, Sim, Modem, Messaging, Ims, Config) with Response and Indication partners.

LPA

Local Profile Assistant: on-device component that downloads and manages eSIM profiles.

MHI

Modem Host Interface: Qualcomm protocol for talking to a modem over PCIe.

MIPC

MediaTek's structured IPC protocol between the RIL daemon and the modem.

MTU

Maximum Transmission Unit: largest IP packet size on a link; provided by the network for cellular.

NAS

Non-Access Stratum: signalling between UE and core network, carried transparently by the radio.

NITZ

Network Identity and Time Zone: time, zone and network name sent by the network.

NV / EFS

Modem non-volatile items and embedded file system for calibration, IMEI and configuration.

P-CSCF

Proxy Call Session Control Function: the IMS entry point, learned via PCO or DHCP.

PCO

Protocol Configuration Options: extra parameters (DNS, P-CSCF, MTU) exchanged during PDN/PDU setup.

PDCP

Packet Data Convergence Protocol: ciphering, integrity, header compression, reordering.

PDN connection / PDU session

A data connection to an APN/DNN in LTE / 5G, with its own IP address and bearers or QoS flows.

PLMN

Public Land Mobile Network: an operator network identified by MCC + MNC.

QCI / 5QI

QoS class identifiers in LTE / 5G (1 = conversational voice, 5 = IMS signalling).

QMAP

Qualcomm multiplexing protocol that carries several PDNs over one data link with aggregation.

QMI

Qualcomm MSM Interface: service-based binary protocol between AP clients and modem services.

QRTR

Qualcomm IPC router: kernel socket family (AF_QIPCRTR) that transports QMI messages.

QXDM / QCAT

Qualcomm tools to capture and decode modem logs over the DIAG interface.

RadioResponseInfo

Header on every HAL response: type (solicited or solicited-ack), serial and error.

RAT

Radio Access Technology: GSM, UMTS, LTE, NR and so on.

RIL / RILJ

Radio Interface Layer; RILJ is the Java side (RIL.java) in the framework.

rild

The vendor RIL daemon implementing the Radio HAL (for example qcrild).

RLC

Radio Link Control: segmentation, reassembly and ARQ in TM, UM or AM mode.

RLF

Radio Link Failure: loss of the radio connection, followed by re-establishment or idle.

rmnet

Qualcomm cellular data network interfaces (rmnet_data0..N), one per PDN.

RRC

Radio Resource Control: sets up, reconfigures and releases the radio connection.

RSRP / RSRQ / SINR

Reference signal received power, quality, and signal-to-interference-plus-noise ratio.

Service Request

NAS procedure that takes an idle UE to connected so the core can restore the user plane after paging or for MO data.

ServiceStateTracker

Framework class that tracks registration, operator, RAT, roaming and signal.

SM-DP+

Subscription Manager Data Preparation: server that prepares and delivers eSIM profiles.

SRVCC

Single Radio Voice Call Continuity: hands an active VoLTE call over to CS.

SSR

Subsystem Restart: Qualcomm mechanism to crash-dump and restart the modem without rebooting the phone.

TAU

Tracking Area Update: NAS procedure when the UE enters a new TA or when periodic timer T3412 expires.

TelephonyRegistry

System service that publishes telephony state to registered TelephonyCallbacks.

UAC

Unified Access Control (5G): barring of access attempts by category and identity; LTE used AC barring / SSAC.

UICC / USIM / ISIM

The smart card and its 3GPP and IMS applications.

VINTF

Vendor Interface object: manifests and compatibility matrices that declare which HALs a device provides.

X2 / Xn

Direct interface between neighbour base stations used for intra-RAT handover (X2 on LTE, Xn on NR).

Interview questions