diff --git a/radio/aidl/android/hardware/radio/network/IRadioNetworkIndication.aidl b/radio/aidl/android/hardware/radio/network/IRadioNetworkIndication.aidl
index da82b78..34948fb 100644
--- a/radio/aidl/android/hardware/radio/network/IRadioNetworkIndication.aidl
+++ b/radio/aidl/android/hardware/radio/network/IRadioNetworkIndication.aidl
@@ -221,6 +221,12 @@
      * - 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.
@@ -232,23 +238,78 @@
     /*
      * 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").
+     * 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").
      *
-     * Sample scenario to further clarify "most-recently reported":
+     * 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.
      *
-     * 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).
+     * 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.
      *
-     * 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).
+     * 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