Loading radio/aidl/android/hardware/radio/network/IRadioNetworkIndication.aidl +78 −17 Original line number Diff line number Diff line Loading @@ -221,6 +221,12 @@ oneway interface IRadioNetworkIndication { * - If a device uses a 2G network to send a AUTHENTICATION_AND_CIPHERING_RESPONSE message on * the NAS and the message includes an IMEISV. * * cellularIdentifierDisclosure indications must be sent to Android regardless of the screen * state. If the screen is off, the indications must still be sent to Android. * * Note: in the NRSA scenario, only a SUCI generated by a null scheme should be considered as a * plain-text identifier. * * @param type Type of radio indication * @param disclosure A CellularIdentifierDisclosure as specified by * IRadioNetwork.setCellularIdentifierTransparencyEnabled. Loading @@ -232,23 +238,78 @@ oneway interface IRadioNetworkIndication { /* * Indicates that a new ciphering or integrity algorithm was used for a particular voice, * signaling, or data connection for a given PLMN and/or access network. Due to power * concerns, once a connection type has been reported on, follow-up reports about that * connection type are only generated if there is any change to the most-recently reported * encryption or integrity, or if the value of SecurityAlgorithmUpdate#isUnprotectedEmergency * changes. A change only in cell ID should not trigger an update, as the design is intended * to be agnostic to dual connectivity ("secondary serving cells"). * * Sample scenario to further clarify "most-recently reported": * * 1. Modem reports user is connected to a null-ciphered 3G network. * 2. User then moves and connects to a well-ciphered 5G network, and modem reports this. * 3. User returns to original location and reconnects to the null-ciphered 3G network. Modem * should report this as it's different than the most-recently reported data from step (2). * * State is reset when (1) RadioState is transitioned to ON from any other state (e.g. radio * is turned on during device boot, or modem boot), and (2) when CardState is transitioned * to PRESENT from any other state (e.g. when SIM is inserted), or (3) if there is a change in * access network (PLMN). * concerns, once a ConnectionEvent has been reported on, follow-up reports about that * ConnectionEvent are only generated if there is any change to the most-recently reported * encryption or integrity, if there is a RAT change, or if the value of * SecurityAlgorithmUpdate#isUnprotectedEmergency changes. A change only in cell ID should not * trigger an update, as the design is intended to be agnostic to dual connectivity ("secondary * serving cells"). * * Example to further clarify "most-recently reported": * 1. After booting up, the UE is in ENDC with LTE. Modem reports NAS_SIGNALLING_LTE and * AS_SIGNALLING_LTE are well-ciphered but AS_SIGNALLING_5G is null-ciphered. * 2. UE moves to 3G and enters the connected mode. Modem reports indications of PS_SERVICE_3G * and SIGNALLING_3G to Android. * 3. UE moves to LTE. UE enters the connected mode and there is no ENDC. The algorithms of * NAS_SIGNALLING_LTE and AS_SIGNALLING_LTE are the same as in Step 1. The UE should send * this indication to AP as it’s a RAT switch. * 4. Later, UE establishes ENDC. AS_SIGNALLING_5G is null-ciphered. The UE should send this * indication as well, as it is a RAT switch. * 5. The UE enter IDLE mode, and later connected mode in ENDC. There are no changes to security * algorithms, so the modem does not need to send any updates. * * Most recently reported state is reset when (1) RadioState is transitioned to ON from any * other state (e.g. radio is turned on during device boot, or modem boot), and (2) when * CardState is transitioned to PRESENT from any other state (e.g. when SIM is inserted), or (3) * if there is a change in access network (PLMN) or RAT. * * securityAlgorithmUpdate indications must be sent to Android regardless of the screen state. * If the screen is off, the indications must still be sent to Android. * * * 5G TS 38.331 cipheringDisabled and integrityProtection * ====================================================== * For most connections, generally what is reported by the network is what ends up being used. * There are two significant cases where this may not be the case. In 5G, per the introduction * of network configuration options cipheringDisabled and integrityProtection (TS 38.331), the * network can have declared certain security algorithms to be used while also requiring a null * algorithm via those parameters. * * * Exceptions for DRBs with null integrity (pre-5G Rel 16) * ======================================================= * When reporting the SecurityAlgorithm for a ConnectionType which includes a DRB, there is an * exception where a DRB with null integrity is not to be considered/included in reporting * except for 5G Rel 16 connections and newer. Because DRBs almost always use null integrity in * practice, and thus if included the report would always be null, rendering the report * useless. For anything 5G Rel 16 or newer, accurate reporting for the DRB's integrity is * required. * * * NRDC MCG and SCGs * ================= * In the NRDC case, there can be two sets of algorithms, one for the MCG (Master Cell Group) * and one for the SCG (Secondary Cell Group). In this case, always send a combined update that * reflects the weaker of the algorithms, e.g. (weakest) NEA0 < NEA1 < NEA2 < NEA3 (strongest). * This applies to both the ciphering and integrity algorithms. * * * Determining the value of isUnprotectedEmergency * =============================================== * 2G: isUnprotectedEmergency is true if the ciphering algorithm is NULL. * 3G: isUnprotectedEmergency is true if the ciphering and integrity algorithm are NULL. * 4G: isUnprotectedEmergency is true if the ciphering algorithm is NULL. * 5G: isUnprotectedEmergency is true if the ciphering algorithm is NULL. * Notes: * - On integrity: In 4G, PDCP can be LTE-based or NR-based. Starting from 5G Rel 17, only * the NR-based PDCP supports DRB integrity. As the PDCP version can change during a DRB's * operation, it becomes complicated when integrity is used to determine whether an * emergency call is protected or not, hence its exclusion to simplify implementation. * - 4G and 5G with multiple DRBs : emergency calls are protected under that RAT only if all * DRBs are protected (including IMS DRB). * - 4G and 5G DRB integrity: Since DRB integrity is not enabled in most networks, if both * ciphering and integrity are taken into account to determine the value of * isUnprotectedEmergency, the value will mostly be false, hence why it is excluded. * * @param type Type of radio indication * @param securityAlgorithmUpdate SecurityAlgorithmUpdate encapsulates details of security Loading Loading
radio/aidl/android/hardware/radio/network/IRadioNetworkIndication.aidl +78 −17 Original line number Diff line number Diff line Loading @@ -221,6 +221,12 @@ oneway interface IRadioNetworkIndication { * - If a device uses a 2G network to send a AUTHENTICATION_AND_CIPHERING_RESPONSE message on * the NAS and the message includes an IMEISV. * * cellularIdentifierDisclosure indications must be sent to Android regardless of the screen * state. If the screen is off, the indications must still be sent to Android. * * Note: in the NRSA scenario, only a SUCI generated by a null scheme should be considered as a * plain-text identifier. * * @param type Type of radio indication * @param disclosure A CellularIdentifierDisclosure as specified by * IRadioNetwork.setCellularIdentifierTransparencyEnabled. Loading @@ -232,23 +238,78 @@ oneway interface IRadioNetworkIndication { /* * Indicates that a new ciphering or integrity algorithm was used for a particular voice, * signaling, or data connection for a given PLMN and/or access network. Due to power * concerns, once a connection type has been reported on, follow-up reports about that * connection type are only generated if there is any change to the most-recently reported * encryption or integrity, or if the value of SecurityAlgorithmUpdate#isUnprotectedEmergency * changes. A change only in cell ID should not trigger an update, as the design is intended * to be agnostic to dual connectivity ("secondary serving cells"). * * Sample scenario to further clarify "most-recently reported": * * 1. Modem reports user is connected to a null-ciphered 3G network. * 2. User then moves and connects to a well-ciphered 5G network, and modem reports this. * 3. User returns to original location and reconnects to the null-ciphered 3G network. Modem * should report this as it's different than the most-recently reported data from step (2). * * State is reset when (1) RadioState is transitioned to ON from any other state (e.g. radio * is turned on during device boot, or modem boot), and (2) when CardState is transitioned * to PRESENT from any other state (e.g. when SIM is inserted), or (3) if there is a change in * access network (PLMN). * concerns, once a ConnectionEvent has been reported on, follow-up reports about that * ConnectionEvent are only generated if there is any change to the most-recently reported * encryption or integrity, if there is a RAT change, or if the value of * SecurityAlgorithmUpdate#isUnprotectedEmergency changes. A change only in cell ID should not * trigger an update, as the design is intended to be agnostic to dual connectivity ("secondary * serving cells"). * * Example to further clarify "most-recently reported": * 1. After booting up, the UE is in ENDC with LTE. Modem reports NAS_SIGNALLING_LTE and * AS_SIGNALLING_LTE are well-ciphered but AS_SIGNALLING_5G is null-ciphered. * 2. UE moves to 3G and enters the connected mode. Modem reports indications of PS_SERVICE_3G * and SIGNALLING_3G to Android. * 3. UE moves to LTE. UE enters the connected mode and there is no ENDC. The algorithms of * NAS_SIGNALLING_LTE and AS_SIGNALLING_LTE are the same as in Step 1. The UE should send * this indication to AP as it’s a RAT switch. * 4. Later, UE establishes ENDC. AS_SIGNALLING_5G is null-ciphered. The UE should send this * indication as well, as it is a RAT switch. * 5. The UE enter IDLE mode, and later connected mode in ENDC. There are no changes to security * algorithms, so the modem does not need to send any updates. * * Most recently reported state is reset when (1) RadioState is transitioned to ON from any * other state (e.g. radio is turned on during device boot, or modem boot), and (2) when * CardState is transitioned to PRESENT from any other state (e.g. when SIM is inserted), or (3) * if there is a change in access network (PLMN) or RAT. * * securityAlgorithmUpdate indications must be sent to Android regardless of the screen state. * If the screen is off, the indications must still be sent to Android. * * * 5G TS 38.331 cipheringDisabled and integrityProtection * ====================================================== * For most connections, generally what is reported by the network is what ends up being used. * There are two significant cases where this may not be the case. In 5G, per the introduction * of network configuration options cipheringDisabled and integrityProtection (TS 38.331), the * network can have declared certain security algorithms to be used while also requiring a null * algorithm via those parameters. * * * Exceptions for DRBs with null integrity (pre-5G Rel 16) * ======================================================= * When reporting the SecurityAlgorithm for a ConnectionType which includes a DRB, there is an * exception where a DRB with null integrity is not to be considered/included in reporting * except for 5G Rel 16 connections and newer. Because DRBs almost always use null integrity in * practice, and thus if included the report would always be null, rendering the report * useless. For anything 5G Rel 16 or newer, accurate reporting for the DRB's integrity is * required. * * * NRDC MCG and SCGs * ================= * In the NRDC case, there can be two sets of algorithms, one for the MCG (Master Cell Group) * and one for the SCG (Secondary Cell Group). In this case, always send a combined update that * reflects the weaker of the algorithms, e.g. (weakest) NEA0 < NEA1 < NEA2 < NEA3 (strongest). * This applies to both the ciphering and integrity algorithms. * * * Determining the value of isUnprotectedEmergency * =============================================== * 2G: isUnprotectedEmergency is true if the ciphering algorithm is NULL. * 3G: isUnprotectedEmergency is true if the ciphering and integrity algorithm are NULL. * 4G: isUnprotectedEmergency is true if the ciphering algorithm is NULL. * 5G: isUnprotectedEmergency is true if the ciphering algorithm is NULL. * Notes: * - On integrity: In 4G, PDCP can be LTE-based or NR-based. Starting from 5G Rel 17, only * the NR-based PDCP supports DRB integrity. As the PDCP version can change during a DRB's * operation, it becomes complicated when integrity is used to determine whether an * emergency call is protected or not, hence its exclusion to simplify implementation. * - 4G and 5G with multiple DRBs : emergency calls are protected under that RAT only if all * DRBs are protected (including IMS DRB). * - 4G and 5G DRB integrity: Since DRB integrity is not enabled in most networks, if both * ciphering and integrity are taken into account to determine the value of * isUnprotectedEmergency, the value will mostly be false, hence why it is excluded. * * @param type Type of radio indication * @param securityAlgorithmUpdate SecurityAlgorithmUpdate encapsulates details of security Loading
