Editing My 33.128 Notes (section)

== 6.2 5G ==

=== 6.2.2 LI at AMF ===

The AMF shall generate an xIRI containing AMF Registration, Deregistration, Location Update, Start Of Interception With Registered UE, and Unsuccessful Procedure record when specific AMF events occur (described in 33.128). The SUPI and SUCI used in the event are either mandatory or conditional for including in the xIRI record. <span style="color:blue">'''Included since V15+'''</span> 

See 33.128 § 6.2.2.2.7 AMF identifier association for details of how AMF reports subscription identifier associations.

Summary is that the IRI-POI present in the AMF shall generate an xIRI containing an AMFIdentifierAssociation record when the IRI-POI present in the AMF detects a new identifier association for a UE matching one of the target identifiers provided via LI_X1. Generation of this record is subject to this record type being enabled for a specific target (see clause 6.2.2.2.1).

<span style="color:blue">'''6.2.2.4 Identity privacy''' Included since V15+</span> 

The AMF shall ensure for every registration (including re-registration) that SUPI has been provided by the UDM to the AMF and that the SUCI to SUPI mapping has been verified as defined in TS 33.501. This shall be performed regardless of whether the SUPI is a target of interception, and whether the null encryption algorithm is used for the SUCI. The AMF shall maintain the SUPI to SUCI mapping for at least the lifetime of the registration in order to allow interception based on SUPI after the initial registration.

'''6.2.2.2.7 AMF identifier association''' added 3GPP TS 33.128 V16.5+, V17+, and V18+. Not in V15.9.0 (2022-06-16).

==== 6.2.2A	Identifier Reporting for AMF ====

===== 6.2.2A.1	Activation of reporting over LI_XEM1 =====
The IEF in the AMF is activated and deactivated over LI_XEM1 by the LIPF using the LI_XEM1 protocol described in clause 5.2.7.
:NOTE:	Since the IEF reports association events for all UEs registered in the IEF’s parent AMF, unlike POIs there is no concept of provisioning an IEF with target identifiers.

Upon receiving a valid activate task message over LI_XEM1, the IEF shall start generating records as defined in clause 6.2.2A.2.

Upon receiving a valid deactivate task message over LI_XEM1, the IEF shall stop generating records as defined in clause 6.2.2A.2.

===== 6.2.2A.2	Generation of records over LI_XER =====

====== 6.2.2A.2.1	Events ======
The IEF in the AMF shall generate an IEFIdentifierAssociation record whenever the IEF present in the AMF detects a change in association between a SUPI and a 5G-GUTI for any UE registered with the AMF. The IEF shall send the IEFIdentifierAssociation records to the ICF over LI_XER as defined in clause 5.9.

Accordingly, the IEF in the AMF generates IEFIdentifierAssociation records when any of the following events are detected:
* IEFAssociationRecord: Association of a 5G-GUTI to a SUPI, (this may also include SUCI to SUPI association).
* IEFDeassociationRecord: De-association of a 5G-GUTI from a SUPI.
:NOTE1:	The de-association of 5G-GUTI from a SUPI event record is only generated if a new 5G-GUTI is not allocated to a SUPI to update a previous association (e.g. at inter-AMF handover).
:NOTE 2:	As SUCIs are single use and only valid for a single authentication, they are only valid at the single point in time when the association event is detected and reported to the ICF by the IEF.

''In addition, when an IEF is activated as per clause 6.2.2A.1, the IEF shall generate associations event for all SUPIs which are registered in the AMF, where those identifier associations allocated prior to IEF activation remain current and are still available in the AMF'' (See NOTE 2).
:NOTE 3:	Only identifier associations which have been maintained by the AMF as part of normal network operations will be available.
In the case where the IEF in the AMF detects that a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE (5G-GUTI) message as defined in TS 24.501 has been sent by the AMF towards a UE, the IEF shall immediately generate an IEFIdentifierAssociation record. This record shall be generated regardless of whether the CONFIGURATION UPDATE (5G-GUTI) or REGISTRATION ACCEPT procedure is subsequently successfully completed or not.

====== 6.2.2A.2.2	Association Events ======
For each association event, the IEF shall create an IEFAssociationRecord, as defined below.
{| class="wikitable sortable"
|+ Payload for IEFAssociationRecord
|-
! Field name !! Description !! M/C/O
|-
| sUPI || SUPI associated with detected association event. || M
|-
| fiveGGUTI || 5G-GUTI shall be provided. Encoded as per TS 24.501 figure 9.11.3.4.1, omitting the first four octets. || M
|-
| timeStamp || Time at which the identifier association event occurred. Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time). || M
|-
| tAI || Last known TAI associated with the SUPI. Encoded as per TS 24.501 clause 9.11.3.8, omitting the first octet. || M
|-
| nCGI || Last known nCGI(s) available when identifier association event detected. Given as a sequence of PLMNID (encoded as per TS 38.413 clause 9.3.3.5) and NCI (encoded as per TS 38.413 clause 9.3.1.7). || M
|-
| nCGITime || ueLocationTimestamp(s) of nCGIs if available in AMF as per TS 29 .571 clause 5.4.4.9. If ueLocationTimestamp(s) is not available, shall be populated with timeStamp(s) of when last known nCGI(s), were obtained and stored by the AMF. || M
|-
| sUCI || SUCI shall be provided when event is triggered by association of a SUCI to a SUPI. Encoded as per TS 24.501 clause 9.11.3.4, omitting the first 3 octets. || C
|-
| pEI || PEI, (see NOTE 1). || C
|-
| fiveGSTAIList || List of tracking areas associated with the registration area within which the UE is current registered, see TS 24.501, clause 9.11.3.9. (see NOTE 2) || C
|-
| gPSI || GPSI, (see NOTE 1). || C
|-
|colspan="3"|
:NOTE 1: Shall be provided in first association record to ICF after PEI or GPSI is available and following any change of PEI or GPSI.
:NOTE 2: As a minimum, list of tracking areas shall be included in the first association event for each SUPI registered (per UE session) with the AMF and additionally whenever the TAI list changes due to a change in registration area.
|}

For each de-association event, the IEF shall create an IEFDeassociationRecord, as defined below.

{| class="wikitable sortable"
|+ Payload for IEFDeassociationRecord
|-
! Field name !! Description !! M/C/O
|-
| sUPI || SUPI associated with detected de-association event. || M
|-
| fiveGGUTI || 5G-GUTI shall be provided. Encoded as per TS 24.501 [13] figure 9.11.3.4.1, omitting the first four octets. || M
|-
| timeStamp
| Time at which the identifier de-association event occurred.
Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time).
| M
|-
| nCGI
| Last known nCGI(s) available when identifier de-association event detected. Given as a sequence of PLMNID (encoded as per TS 38.413 clause 9.3.3.5) and NCI (encoded as per TS 38.413 clause 9.3.1.7).
| M
|-
| nCGITime
| ueLocationTimestamp(s) of nCGIs if available in AMF as per TS 29 .571 clause 5.4.4.9.
If ueLocationTimestamp(s) is not available, shall be populated with timeStamp(s) of when last known nCGI(s), were obtained and stored by the AMF.	
| M
|}

====== 6.2.2A.2.3	Transmission to the ICF ======
When activated (see clause 5.2.7), the IEF shall establish a TLS connection to the ICF as given over LI_XEM1. If the IEF fails to establish a TLS connection, it shall report an error over LI_XEM1 using the error reporting mechanisms described in ETSI TS 103 221-1 and attempt to reconnect after a configurable period of time.

When a record has been generated as described in clause 6.2.2A.2.2, the IEF shall encode the IEFAssociationRecord or IEFDeassociationRecord as a BER-encoded IEFMessage structure, following the ASN.1 schema given in Annex F, and transmit it to the ICF over the established TLS connection.

The IEF may transmit a keepalive request using the keepalive record defined in Annex F. Upon receiving a keepalive request, the ICF shall respond with a keepaliveResponse record containing the same sequence number used in the request. The circumstances under which the IEF transmits keepalive requests is out of scope of the 33.128 V18.0.0 (2022-06) document.