My 33.128 Notes - Revision history

Paul: /* 6.2.2 LI at AMF */

2024-04-27T19:04:43Z

6.2.2 LI at AMF

← Older revision		Revision as of 14:04, 27 April 2024
Line 300:		Line 300:
	=== 6.2.2 LI at AMF ===		=== 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>		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.		See 33.128 § 6.2.2.2.7 AMF identifier association for details of how AMF reports subscription identifier associations.

Paul: /* 6.2 5G */

2024-04-27T19:04:13Z

6.2 5G

← Older revision		Revision as of 14:04, 27 April 2024
Line 299:		Line 299:

	=== 6.2.2 LI at AMF ===		=== 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.		See 33.128 § 6.2.2.2.7 AMF identifier association for details of how AMF reports subscription identifier associations.
Line 304:		Line 306:
	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).		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).

	'''6.2.2.4 Identity privacy'''		<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.		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.

Paul: /* 5.7.2.2 Request parameters */

2023-02-21T17:33:15Z

5.7.2.2 Request parameters

← Older revision		Revision as of 12:33, 21 February 2023
Line 156:		Line 156:
	! Format Owner !! Format Name !! Description !! Format		! Format Owner !! Format Name !! Description !! Format
	\|-		\|-
	\| 3GPP \|\| SUCI \|\| Subscription Concealed Identifier as per TS 23.003 clause 2.2B. \|\| TS 29.509 clause 6.1.6.3.2		\| 3GPP \|\| SUCI \|\| Subscription Concealed Identifier as per TS 23.003 clause 2.2B. \|\| From TS 29.509 V18.0.0 clause 6.1.6.3.2: String containing a SUCI.
			Pattern: "<code>^(suci-(0-[0-9]{3}-[0-9]{2,3}\|[1-7]-.+)-[0-9]{1,4}-(0-0-.+\|[a-fA-F1-9]-([1-9]\|[1-9][0-9]\|1[0-9]{2}\|2[0-4][0-9]\|25[0-5])-[a-fA-F0-9]+)\|.+)$</code>"

	\|-		\|-
	\| 3GPP \|\| 5GSTMSI \|\| Shortened form of the 5G-GUTI as defined in TS 23.003 clause 2.11.		\| 3GPP \|\| 5GSTMSI \|\| Shortened form of the 5G-GUTI as defined in TS 23.003 clause 2.11.

Paul: /* 5.7.2.1 Request structure */

2023-02-15T17:57:49Z

5.7.2.1 Request structure

← Older revision		Revision as of 12:57, 15 February 2023
Line 75:		Line 75:
	\| DesiredStatus		\| DesiredStatus
	\| Shall be set to "AwaitingDisclosure".		\| Shall be set to "AwaitingDisclosure".
			\| M
			\|-
			\| RequestDetails
			\| Set according to RequestDetails structure grid below.
	\| M		\| M
	\|-		\|-
	\| DeliveryDetails		\| DeliveryDetails
	\| ~~Set according~~ to ~~RequestDetails structure grid below~~.		\| Shall be set to indicate the delivery destination for the LI_HIQR records (see clause 5.7.2.3 and ETSI TS 103 120 clause 8.3.6.2) unless the delivery destination is known via other means.
	\| M		\| M
	\|}		\|}

Paul: /* 5.7.2.3 Response structure */

2022-10-07T13:52:40Z

5.7.2.3 Response structure

← Older revision		Revision as of 08:52, 7 October 2022
Line 186:		Line 186:
	LI_HIQR responses and updates are represented as XML following the IdentityResponseDetails type definition (see Annex E).		LI_HIQR responses and updates are represented as XML following the IdentityResponseDetails type definition (see Annex E).

	Responses and updates are delivered within a DELIVER Request (see ETSI TS 103 120 clause 6.4.10) containing a DeliveryObject (see ETSI TS 103 120 clause 10).		''Responses and updates are delivered within a DELIVER Request'' (see ETSI TS 103 120 clause 6.4.10) containing a DeliveryObject (see ETSI TS 103 120 clause 10).

	IdentityResponseDetails contain IdentityAssociation records. The fields of each IdentityAssociationRecord shall be set as follows:		IdentityResponseDetails contain IdentityAssociation records. The fields of each IdentityAssociationRecord shall be set as follows:

Paul: /* 6.2.2 LI at AMF */

2022-10-05T19:30:52Z

6.2.2 LI at AMF

← Older revision		Revision as of 14:30, 5 October 2022
Line 301:		Line 301:

	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.		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 Identifier Reporting for AMF ====

Paul: /* 5.7.2.1 Request structure */

2022-10-04T17:16:37Z

5.7.2.1 Request structure

← Older revision		Revision as of 12:16, 4 October 2022
Line 128:		Line 128:
	\| A request for an ongoing series of IdentityResponseDetails responses matching the query provided. May only be used when the RequestValues contains a permanent identifier. The request shall be terminated by updating the LDTaskObject DesiredStatus to "Disclosed".		\| A request for an ongoing series of IdentityResponseDetails responses matching the query provided. May only be used when the RequestValues contains a permanent identifier. The request shall be terminated by updating the LDTaskObject DesiredStatus to "Disclosed".
	\|}		\|}

			Grid Defined DictionaryEntries is formatted in accordance with ETSI TS 103 120 Annex F.

	==== 5.7.2.2 Request parameters ====		==== 5.7.2.2 Request parameters ====

Paul: /* 5.7.2.1 Request structure */

2022-10-04T17:15:13Z

5.7.2.1 Request structure

@@ Line 62: / Line 62: @@
 ==== 5.7.2.1 Request structure ====
-LI_HIQR requests are represented by issuing a CREATE request for an LDTaskObject (see ETSI TS 103 120 clause 8.3). See spec for how LDTaskObject is populated.
+LI_HIQR requests are represented by issuing a CREATE request for an LDTaskObject (see ETSI TS 103 120 clause 8.3). LDTaskObject is populated as follows:
 ==== 5.7.2.2 Request parameters ====

Paul: added link to my ETSI 103 120 notes

2022-10-04T15:51:25Z

added link to my ETSI 103 120 notes

← Older revision		Revision as of 10:51, 4 October 2022
Line 52:		Line 52:

	=== 5.7.1 General ===		=== 5.7.1 General ===
	Functions having an LI_HIQR interface shall support the use of ETSI TS 103 120 to realise the interface.		Functions having an LI_HIQR interface shall support the use of ETSI TS 103 120 to realise the interface. [[My ETSI TS 103 120 Notes]]

	In the event of a conflict between ETSI TS 103 120 and 33.128 document, the terms of 33.128 document shall apply.		In the event of a conflict between ETSI TS 103 120 and 33.128 document, the terms of 33.128 document shall apply.

Paul: /* 6.2.2A.2.3 Transmission to the ICF */

2022-10-03T22:05:21Z

6.2.2A.2.3 Transmission to the ICF

← Older revision		Revision as of 17:05, 3 October 2022
Line 324:		Line 324:

	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.		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.

			== 7.6 Identifier Association Reporting ==
			Sometimes referred as "identifier mapping reporting."

			=== 7.6.1 General ===

			The IEF, ICF and IQF are responsible for detecting, storing and providing to the LEA permanent to temporary identifier associations, requested by the LEA in authorized requests. The IEF as defined in clause 6.2.2A is responsible for detecting and generating identifier associations records. The ICF is responsible for caching identifier associations for short duration and the IQF is responsible for handling requests from the LEA and providing those requests to the ICF in order to identify the matching identifier associations.

			=== 7.6.2 ICF ===

			==== 7.6.2.1 General ====
			The ICF is responsible for caching identifier associations provided in event records from the IEF over LI_XER and handling queries and subsequent responses from the IQF for responses over LI_XQR.

			==== 7.6.2.2 ICF receipt of records over LI_XER ====
			When the ICF receives an identifier association event record over LI_XER from an IEF (see clause 5.9), the ICF shall use the records to update the identifier associations cached by the ICF. The ICF shall handle the event records as described in clause 7.6.2.4.

			==== 7.6.2.3 ICF Query and Response over LI_XQR ====
			When the ICF receives an identifier association query request from the IQF, the ICF shall search the cached identifier associations to establish a match, based on RequestValues received in the request (see clause 5.8), subject to clause 7.6.2.4.

			Upon successful matching of one or more identifier associations which were active at or around (within a pre-defined search time window) the observed time specified in the query, the ICF shall provide a response to the IQF using the IdentityAssociationResponse message as defined in clause 5.8. Where the ICF is not able to provide a single identifier association based on the RequestValues, the IQF is responsible for any subsequent handling of multiple identifier associations in terms of whether to provide all associations to the LEA over LI_HIQR.

			==== 7.6.2.4 ICF Identifier Association Event Handling ====
			Upon receipt of an Association event as defined in clause 6.2.2A.2, the ICF shall cache the identifier association(s) contained within the record as followings:
			* SUPI to 5G-GUTI association received, in an IEFAssociationRecord is stored by ICF as an active association. The previous active association for the same SUPI, if any, is marked as a previously active association and cached until the cache time limit is reached.
			* If the IEFAssociationRecord also contains a SUCI, the SUCI is stored as a part of the received SUPI to 5G-GUTI association, for the lifetime of that association.
			* Where the IEFDeassociationRecord corresponds to an active SUPI to 5G-GUTI association at ICF, the association is marked as a previously active association and cached until the cache time limit is reached.

			The ICF shall have a CSP defined maximum active association lifetime (upon expiry of which the association is deleted from the ICF).

			:NOTE 1: The maximum active association lifetime is needed to prevent an association from being deleted from ICF under some error conditions (e.g. a loss of IEF message carrying IEFDeassociationRecord caused by the implicit deregistration of an out-of-service UE). The selection of the maximum active association lifetime value needs to ensure that no valid active associations are deleted upon the lifetime expiry, i.e. the longest possible association refresh time supported by CSP’s network needs to be accommodated.

			For previous associations placed in the cache, the ICF shall store the times of association and disassociation, respectively.

			Where an IEFAssociationRecord contains a PEI, Generic Public Subscription Identifier (GPSI) or a TAI list, the ICF shall store the received values and associate them both the current received SUPI to 5G-GUTI association and any future association until:
			* A subsequent IEFAssociationRecord is received which updates the PEI, GPSI or TAI list values.
			** The old PEI / GPSI / TAI list shall be retained in association with previous SUPI to 5G-GUTI associations until those associations are deleted from cache.
			** New PEI / GPSI / TAI list shall be used in association with both the association(s) with which it was received and any subsequent associations until another update is received.
			* All SUPI associations for which the PEI / GPSI / TAI list is valid are deleted from the cache.

			When the ICF receives a query request from the IQF as defined in clause 7.6.2.3, the ICF shall search available identifier associations (both active associations and those marked for deletion in the cache) for a match. The ICF shall be able to use both time and TAI (as a single TAI and in relation to a TAI list) to identify the correct SUPI to 5G-GUTI association(s). For associations which have been disassociated (and will be deleted once the cache time limit is reached), the time of disassociation is used by the ICF to identify the correct association match (based on observed time in LEA request), where multiple associations are held in the cache.
			:NOTE 2: Use of nCGI to match associations based on physical location for SUCI / 5G-S-TMSI to SUPI requests, is out of scope of the present document.

			As the LEA and CSP are unlikely to have synchronised the time of identifier observation / association provided by the LEA in the query request, with NF time of the IEFs, the ICF shall search the cached identifier associations using a short window time duration both before and after (subject to overall cache duration) the observed time provided by the LEA in the RequestValues over LI_XQR.
			:NOTE 3: While the search window duration before and after the LEA provided observed time value is outside the scope of 33.128 V18.0.0, selection of this value by the CSP needs to take into consideration, among other aspects, the duration of a potential period of recovery from a 5G-GUTI update error, in order to prevent missing of otherwise matching associations due to discrepancies between their stored association/disassociation time and the observed time provided by LEA.
			:NOTE 4: While the value of the short-term caching time is outside the scope of 33.128 V18.0.0, selection of this value by the CSP needs to take into consideration, among other aspects, the duration of potential period of recovery from a 5G-GUTI update error, in order to prevent previous associations being deleted before they have been fully disassociated by both the UE and AMF.

			=== 7.6.3 IQF ===

			==== 7.6.3.1 General ====
			The IQF is responsible for receiving and responding to LEA requests over LI_HIQR. Following receipt of a request over LI_HIQR, the IQF shall validate the request and ensure that the request is within the cache period of associations stored in the ICF. If the request is valid and within the ICF cache period, the IQF shall send an association search request to the ICF over LI_XQR. If the request is not within the ICF cache period or overwise invalid, the IQF shall reject the request and respond to the LEA over LI_HIQR.

			Following receipt of an association search request response from the ICF over LI_XQR, the IQF shall forward any matching identifier association(s) to the LEA over LI_HIQR. If the ICF indicates zero matches were found based on the information provided in the initial request over LI_HIQR, the IQF shall respond to the LEA over LI_HIQR indicating that no identifier associations were found based on the request from the LEA.

			If the ICF responds with multiple associations of 5G-GUTIs / SUCIs to a single SUPI, the IQF shall provide all matched associations to the LEA over LI_HIQR. Handling in the case of multiple SUPIs to a single 5G-GUTI (where the initial request over LI_HIQR is based on 5G-S-TMSI or SUCI) is outside the scope of 33.128 V18.0.0.

			==== 7.6.3.2 IQF Query and Response over LI_HIQR ====
			The IQF is responsible for receiving query requests from and providing query responses to the LEA over LI_HIQR. Further details of LI_HIQR messages are defined in clause 5.7.

			==== 7.6.3.3 IQF Query and Response over LI_XQR ====
			The IQF is responsible for generating queries to and receiving query responses requests from the ICF over LI_XQR, based on queries received from the LEA over LI_HIQR. Further details of LI_XQR messages are defined in clause 5.8.


	<center>[[Telecommunications info\|To Telecommunications info]]</center>		<center>[[Telecommunications info\|To Telecommunications info]]</center>