6.2 5G
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
6.2.1 General
This clause describes the LI interfaces specific to LI for 5G networks.
6.2.2 LI at AMF
6.2.2.1 Provisioning over LI_X1
The IRI-POI present in the AMF is provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The POI in the AMF shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– SUPIIMSI.
– SUPINAI.
– PEIIMEI.
– PEIIMEISV.
– GPSIMSISDN.
– GPSINAI.
Table 6.2.2-0A shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI in the AMF.
Table 6.2.2-0A: ActivateTask message for the IRI-POI in the AMF
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
XID assigned by LIPF. |
M |
TargetIdentifiers |
One of the target identifiers listed in the paragraph above. |
M |
DeliveryType |
Set to "X2Only". |
M |
ListOfDIDs |
Delivery endpoints for LI_X2 for the IRI-POI in the AMF. These delivery endpoints are configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
TaskDetailsExtensions/ IdentifierAssociationExtensions |
This field shall be included if the IRI POI is required to generate AMFIdentifierAssociation records (see clause 6.2.2.2.1). If the field is absent, AMFIdentifierAssociation records shall not be generated. |
C |
ListOfServiceTypes |
Shall be included when the explicit identification of specific CSP service types to be intercepted by the task as described in clause 5.2.4 is required. This parameter is defined in ETSI TS 103 221-1 [7], clause 6.2.1.2, table 4. |
C |
Table 6.2.2-0B: IdentifierAssociationExtensions Parameters
Field Name |
Description |
M/C/O |
EventsGenerated |
One of the following values: – IdentifierAssociation – All See clause 6.2.2.2.1 for the interpretation of this field. |
M |
6.2.2.2 Generation of xIRI over LI_X2
6.2.2.2.1 General
The IRI-POI present in the AMF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 6.2.2.4, the details of which are described in the following clauses.
If the AMF receives one or more cell IDs in an N2 message (as specified in TS 38.413 [23]), the IRI-POI in the AMF shall report all of them.
The IRI-POI in the AMF shall only generate xIRI containing AMFIdentifierAssociation records when the IdentifierAssocationExtensions parameter has been received over LI_X1 (see clause 6.2.2.1). The IRI-POI in the AMF shall generate records according to the value of the EventsGenerated sub-parameter (see table 6.2.2-0B) as follows:
– IdentifierAssociation: AMFIdentifierAssociation and AMFLocationUpdate records shall be generated. No other record types shall be generated for that target.
– All: All AMF record types shall be generated.
6.2.2.2.2 Registration
The IRI-POI in the AMF shall generate an xIRI containing an AMFRegistration record when the IRI-POI present in the AMF detects that a UE matching one of the target identifiers provided via LI_X1 has successfully registered to the 5GS via 3GPP NG-RAN or non-3GPP access. Accordingly, the IRI-POI in the AMF generates the xIRI when the following event is detected:
– AMF sends a N1: REGISTRATION ACCEPT message to the target UE and the UE 5G Mobility Management (5GMM) state for the access type (3GPP NG-RAN or non-3GPP access) within the AMF is changed to 5GMM-REGISTERED.
Table 6.2.2-1: Payload for AMFRegistration record
Field name |
Description |
M/C/O |
registrationType |
Specifies the type of registration, see TS 24.501 [13] clause 9.11.3.7. This is derived from the information received from the UE in the REGISTRATION REQUEST message. |
M |
registrationResult |
Specifies the result of registration, see TS 24.501 [13] clause 9.11.3.6. |
M |
slice |
Provide, if available, one or more of the following: – allowed NSSAI (see TS 24.501 [13] clause 9.11.3.37). – configured NSSAI (see TS 24.501 [13] clause 9.11.3.37). – rejected NSSAI (see TS 24.501 [13] clause 9.11.3.46). This is derived from the information sent to the UE in the REGISTRATION ACCEPT message. |
C |
sUPI |
SUPI associated with the registration (see clause 6.2.2.4). |
M |
sUCI |
SUCI used in the registration, if available. |
C |
pEI |
PEI provided by the UE during the registration, if available. |
C |
gPSI |
GPSI obtained in the registration, if available as part of the subscription profile. |
C |
gUTI |
5G-GUTI provided as outcome of initial registration or used in other cases, see TS 24.501 [13] clause 5.5.1.2.2. |
M |
location |
Location information determined by the network during the registration, if available. Encoded as a userLocation parameter (location>locationInfo>userLocation) and, when Dual Connectivity is activated, as an additionalCellIDs parameter (location>locationInfo>additionalCellIDs), see Annex A. |
C |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
fiveGSTAIList |
List of tracking areas associated with the registration area within which the UE is current registered, see TS 24.501 [13] clause 9.11.3.9 (see NOTE) |
C |
sMSoverNASIndicator |
Indicates whether SMS over NAS is supported. Provide, if included in registrationResult, see TS 24.501 [13] clause 9.11.3.6. |
C |
oldGUTI |
GUTI or 5G-GUTI, if provided in the REGISTRATION REQUEST message, see TS 24.501 [13] clause 5.5.1.2.2. |
C |
eMM5GRegStatus |
UE Status, if provided in the REGISTRATION REQUEST message, see TS 24.501 [13] clause 9.11.3.56. |
C |
nonIMEISVPEI |
MACAddress or EUI-64 used as UE equipment identity if IMEI or IMEISV based PEI is not available. Provide if known, see TS 24.501 [13] clause 8.2.26.4. |
C |
mACRestIndicator |
Indicates whether the non-IMEISV PEI MACAddress can be used as an equipment identifier. Required if non-IMEISVPEI is used, see TS 24.501 [13] clause 9.11.3.4. |
C |
pagingRestrictionIndicator |
Indicates if paging is restricted or the type of paging allowed. Include if sent in the REGISTRATION REQUEST message. Encoded per TS 24.501 [13] clause 9.11.3.77.2, omitting the first two octets. |
C |
NOTE: List shall be included each time there is a change to the registration area. |
6.2.2.2.3 Deregistration
The IRI-POI in the AMF shall generate an xIRI containing an AMFDeregistration record when the IRI-POI present in the AMF detects that a UE matching one of the target identifiers provided via LI_X1 has deregistered from the 5GS over at least one access type. Accordingly, the IRI-POI in AMF generates the xIRI when any of the following events is detected:
– For network initiated de-registration, when the AMF receives the N1: DEREGISTRATION ACCEPT message from the target UE or when implicit deregistration timer expires; and in both cases the UE 5GMN state for the access type (3GPP NG-RAN or non-3GPP access) within the AMF is changed to 5GMM-DEREGISTERED.
– For UE initiated de-registration, when the AMF sends the N1: DEREGISTRATION ACCEPT message to the target UE or when the AMF receives the N1: DEREGISTRATION REQUEST message from the target UE with deregistration type value of “switch off”; and in both cases the UE 5GMN state for the access type (3GPP NG-RAN or non-3GPP access) within the AMF is changed to 5GMM-DEREGISTERED.
– For network initiated AMF UE relocation, the AMFDeregistration xIRI shall not be sent unless the 5GMM COMMON PROCEDURE INITIATED (see TS 24.501 [13] clause 5.1.3.2.3.3) results in deregistration.
Table 6.2.2-2: Payload for AMFDeregistration record
Field name |
Description |
M/C/O |
deregistrationDirection |
Indicates whether the deregistration was initiated by the network or by the UE. |
M |
accessType |
Indicates the access for which the deregistration is handled, see TS 24.501 [13] clause 9.11.3.20. |
M |
sUPI |
SUPI associated with the deregistration (see clause 6.2.2.4), if available. |
C |
sUCI |
SUCI used in the deregistration, if available (see NOTE). |
C |
pEI |
PEI used in the deregistration, if available (see NOTE). |
C |
gPSI |
GPSI associated to the deregistration, if available as part of the subscription profile. |
C |
gUTI |
5G-GUTI used in the deregistration, if available, see TS 24.501 [13] clause 5.5.2.2.1 (see NOTE). |
C |
cause |
Indicates the 5GMM cause value for network-initiated deregistration, see TS 24.501 [13] clause 9.11.3.2. |
C |
location |
Location information determined by the network during the deregistration, if available. Encoded as a userLocation parameter (location>locationInfo>userLocation), see Annex A. |
C |
switchOffIndicator |
Indicates whether the deregistration type is normal or switch off, if available, see TS 24.501 [13] clause 9.1.3.20.1. |
C |
reRegRequiredIndicator |
Indicates whether UE re-registration is required in the DEREGISTRATION REQUEST message, if available, see TS 24.501 [13] clause 9.1.3.20.1. |
C |
NOTE: At least one among SUCI, PEI and GUTI shall be provided. |
6.2.2.2.4 Location update
The IRI-POI in the AMF shall generate an xIRI containing an AMFLocationUpdate record each time the IRI-POI present in an AMF detects that the target’s UE location is updated due to target UE mobility or as a part of an AMF service procedure and the reporting of location information is not restricted by service scoping. The generation of such separate xIRI is not required if the updated UE location information is obtained as a part of a procedure producing some other xIRIs (e.g. mobility registration). In that case the location information is included into the respective xIRI.
The UE mobility events resulting in generation of an AMFLocationUpdate xIRI include the N2 Path Switch Request (Xn based inter NG-RAN handover procedure described in TS 23.502 [4] clause 4.9.1.2) and the N2 Handover Notify (Inter NG-RAN node N2 based handover procedure described in TS 23.502 [4] clause 4.9.1.3).
The AMFLocationUpdate xIRI is also generated when the AMF receives an NG-RAN NGAP PDU Session Resource Modify Indication message as a result of Dual Connectivity activation/release for the target UE, as described in TS 37.340 [37] clause 10.
Optionally, based on operator policy, other NG-RAN NGAP messages that do not generate separate xIRI but carry location information (e.g. RRC INACTIVE TRANSITION REPORT) may trigger the generation of an xIRI AMFLocationUpdate record.
Additionally, based on regulatory requirements and operator policy, the location information obtained by AMF from NG-RAN or LMF in the course of some service operation (e.g. emergency services, LCS) may generate xIRI AMFLocationUpdate record. The AMF services providing the location information in these cases include the AMF Location Service (ProvideLocInfo, ProvidePosInfo, NotifiedPosInfo and EventNotify service operations) and the AMF Exposure Service (AmfEventReport with LOCATION_REPORT) (see TS 29.518 [22]). Additionally, the AMF Communication Service (Namf_Communication_N1MessageNotify service operation) may be monitored to capture the location information in the scenarios described in TS 23.273 [42] clause 6.3.1. Also, in the case of Mobile Originated LCS service invoked by the target, the location information may be derived from a Nlmf_Location_DetermineLocation Response to AMF (see TS 23.273 [42] clause 6.2).
The AMFLocationUpdate record is also used by LARF to deliver Location Acquisition responses to MDF2, as described in clause 7.3.5.6. The IRI-POI in the AMF shall not generate the AMFLocationUpdate xIRI when the location is acquired as the result of a LARF request, as described in TS 33.127 [5], clause 7.3.5.2.
Table 6.2.2-3: Payload for AMFLocationUpdate record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the location update (see clause 6.2.2.4). |
M |
sUCI |
SUCI associated with the location update, if available, see TS 24.501 [13]. |
C |
pEI |
PEI associated with the location update, if available. |
C |
gPSI |
GPSI associated with the location update, if available as part of the subscription profile. |
C |
gUTI |
5G-GUTI associated with the location update, if available, see TS 24.501 [13]. |
C |
location |
Updated location information determined by the network. Depending on the service or message type from which the location information is extracted, it may be encoded in several forms (Annex A): 1) as a userLocation parameter (location>locationInfo>userLocation) in the case the information is obtained from an NGAP message, except the LOCATION REPORT message (see TS 38.413 [23]); 2) as a locationInfo parameter (location>locationInfo) in the case the information is obtained from a ProvideLocInfo (TS 29.518 [22] clause 6.4.6.2.6); 3) as a locationPresenceReport parameter (location>locationPresenceReport) in the case the information is obtained from an AmfEventReport (TS 29.518 [22] clause 6.2.6.2.5) with event type Location-Report or Presence-In-AOI-Report; 4) as a positionInfo parameter (location>positioningInfo>positionInfo) in the case the information is obtained from a ProvidePosInfo (TS 29.518 [22] clause 6.4.6.2.3) or a NotifiedPosInfo (TS 29.518 [22] clause 6.4.6.2.4). |
M |
sMSoverNASIndicator |
No longer used in present version of this specification. |
C |
oldGUTI |
No longer used in present version of this specification. |
C |
6.2.2.2.5 Start of interception with registered UE
The IRI-POI in the AMF shall generate an xIRI containing an AMFStartOfInterceptionWithRegisteredUE record when the IRI-POI present in the AMF detects that interception is activated on a UE that has already been registered in the 5GS (see clause 6.2.2.4 on identity privacy). A UE is considered already registered to the 5GS when the 5GMM state for the access type (3GPP NG-RAN or non-3GPP access) for that UE is 5GMM-REGISTERED. Therefore, the IRI-POI present in the AMF shall generate the xIRI AMFStartOfInterceptionWithRegisteredUE record when it detects that a new interception for a UE is activated (i.e. provisioned by the LIPF) and the 5G mobility management state for the access type (3GPP NG-RAN or non-3GPP access) within the AMF for that UE is 5GMM-REGISTERED. If the UE is registered over both 3GPP NG-RAN and non-3GPP access, the IRI-POI present in the AMF shall generate an xIRI containing an AMFStartOfInterceptionWithRegisteredUE record for each access type.
Table 6.2.2-4: Payload for AMFStartOfInterceptionWithRegisteredUE record
Field name |
Description |
M/C/O |
registrationResult |
Specifies the result of registration, see TS 24.501 [13] clause 9.11.3.6. |
M |
registrationType |
Specifies the type of registration, see TS 24.501 [13] clause 9.11.3.7, if available. |
C |
slice |
Provide, if available, one or more of the following: – allowed NSSAI (see TS 24.501 [13] clause 9.11.3.37). – configured NSSAI (see TS 24.501 [13] clause 9.11.3.37). |
C |
sUPI |
SUPI associated with the target UE. |
M |
sUCI |
SUCI used in the registration, if available. |
C |
pEI |
PEI associated with the target UE, if available. |
C |
gPSI |
GPSI associated with the target UE, if available. |
C |
gUTI |
Latest 5G-GUTI assigned to the target UE by the AMF. |
M |
location |
Location information associated with the access type for the target UE, if available. Encoded as a userLocation parameter (location>locationInfo>userLocation) and, when Dual Connectivity is activated, as an additionalCellIDs parameter (location>locationInfo>additionalCellIDs), see Annex A. |
C |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
timeOfRegistration |
Time at which the last registration occurred, if available. This is the time stamp when the REGISTRATION ACCEPT message was sent to the UE or (when applicable) when the REGISTRATION COMPLETE was received from the UE. Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time). |
C |
fiveGSTAIList |
List of tracking areas associated with the target UE for the access type. |
C |
sMSoverNASIndicator |
Indicates whether SMS over NAS is supported. Provide, if included in the UE Context. |
C |
oldGUTI |
Latest GUTI or 5G-GUTI received from the target UE if different than the latest GUTI assigned by the AMF and the target UE has not acknowledged the latest GUTI assignment. |
C |
eMM5GRegStatus |
UE Status, if this parameter can be derived from information available in the UE Context at the AMF. |
C |
NOTE: The values of the parameters in the table above are derived from the UE Context at the AMF, see TS 23.502 clause 5.2.2.2.2. |
The IRI-POI present in the AMF generating an xIRI containing an AMFStartOfInterceptionWithRegisteredUE record shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
6.2.2.2.6 AMF unsuccessful procedure
The IRI-POI in the AMF shall generate an xIRI containing an AMFUnsuccessfulProcedure record when the IRI-POI present in the AMF detects an unsuccessful procedure for a UE matching one of the target identifiers provided via LI_X1.
Accordingly, the IRI-POI in the AMF generates the xIRI when any of the following events is detected:
– AMF sends a N1: REGISTRATION REJECT message to the target UE and the UE 5G Mobility Management (5GMM) state for the access type (3GPP NG-RAN or non-3GPP access) within the AMF is changed to 5GMM-DEREGISTERED.
– AMF aborts a registration procedure before the UE 5G Mobility Management (5GMM) state for the access type (3GPP NG-RAN or non-3GPP access) within the AMF is changed to 5GMM-REGISTERED.
– AMF sends a SERVICE REJECT message to the target UE including a PDU session establishment reject message type.
– AMF aborts a UE-initiated NAS transport procedure with payload container type IE set to "SMS".
Unsuccessful registration shall be reported only if the target UE has been successfully authenticated.
Table 6.2.2-5: Payload for AMFUnsuccessfulProcedure record
Field name |
Description |
M/C/O |
|
failedprocedureType |
Specifies the procedure which failed at the AMF. |
M |
|
failureCause |
Provides the value of the 5GSM or 5GMM cause, see TS 24.501 [13] clauses 9.11.3.2 and 9.11.4.2. |
M |
|
requestedSlice |
Slice requested for the procedure, if available, given as a NSSAI (a list of S-NSSAI values as described in TS 24.501 [13] clause 9.11.3.37). |
C |
|
sUPI |
SUPI associated with the procedure, if available (see NOTE). |
C |
|
sUCI |
SUCI used in the procedure, if applicable and if available (see NOTE). |
C |
|
pEI |
PEI used in the procedure, if available (see NOTE). |
C |
|
gPSI |
GPSI used in the procedure, if available (see NOTE). |
C |
|
gUTI |
5G-GUTI used in the procedure, if available, see TS 24.501 [13] clause 9.11.3.4 (see NOTE). |
C |
|
location |
Location information determined during the procedure, if available. Encoded as a userLocation parameter (location>locationInfo>userLocation), see Annex A. |
C |
|
NOTE: At least one identity shall be provided, the others shall be provided if available. |
6.2.2.2.7 AMF identifier association
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).
Table 6.2.2-6: Payload for AMFIdentifierAssociation record
Field name |
Description |
M/C/O |
|
sUPI |
SUPI associated with the procedure (see NOTE 1). |
M |
|
sUCI |
SUCI used in the procedure, if applicable and if available. |
C |
|
pEI |
PEI used in the procedure, if available (see NOTE 1). |
C |
|
gPSI |
GPSI used in the procedure, if available (see NOTE 1). |
C |
|
gUTI |
5G-GUTI used in the procedure, see TS 24.501 [13] clause 9.11.3.4. |
M |
|
location |
Location information available when identifier association occurs. Encoded as a userLocation parameter (location>locationInfo>userLocation) and, when Dual Connectivity is activated, as an additionalCellIDs parameter (location>locationInfo>additionalCellIDs), see Annex A. |
M |
|
fiveGSTAIList |
List of tracking areas associated with the registration area within which the UE is current registered, see TS 24.501 [13], clause 9.11.3.9. (see NOTE 2) |
C |
|
NOTE 1: SUPI shall always be provided, in addition to the warrant target identifier if different to SUPI. Other identifiers shall be provided if available. NOTE 2: List shall be included each time there is a change to the registration area. |
The IRI-POI present in the AMF generating an xIRI containing an AMFIdentifierAssociation record shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
6.2.2.2.8 Positioning info transfer
The IRI-POI present in the AMF shall generate an xIRI containing an AMFPositioningInfoTransfer when the IRI-POI present in the AMF detects one of the following events :
– an NRPPa (see TS 38.455 [86]) message related to a target UE has been exchanged between the LMF and NG-RAN via the AMF.
– a LPP (see TS 37.355 [85]) message related to a target UE has been exchanged between the LMF and the target UE via the AMF.
Accordingly, the IRI-POI in AMF generates the xIRI when any of the following events is detected:
– AMF receives an Namf_Communication_N1N2MessageTransfer (see TS 29.518 [22]) from LMF to request the transfer of a NRPPa request to the serving NG-RAN node for a target UE as part of a UE associated NRPPa positioning activity. The NRPPa request may be E-CID MEASUREMENT INITIATION REQUEST or OTDOA INFORMATION REQUEST.
– AMF sends a Namf_Communication_N2InfoNotify [22] to the LMF to forward the NRPPa response or report received from the NG-RAN for a target UE. The NRPPa response or report may be E-CID MEASUREMENT INITIATION RESPONSE, E-CID MEASUREMENT REPORT or OTDOA INFORMATION RESPONSE.
– AMF receives an Namf_Communication_N1N2MessageTransfer ([22]) from LMF to request the transfer of a LPP message to a target UE as part of a LPP positioning activity.
– AMF sends an Namf_Communication_N1MessageNotify ([22]) to LMF to forward a LPP message received from the target UE.
Table 6.2.2-6A: Payload for AMFPositioningInfoTransfer record
Field name |
Description |
M/C/O |
|
sUPI |
SUPI associated with the procedure (see NOTE 1 in table 6.2.2-6). |
M |
|
sUCI |
SUCI used in the procedure, if applicable and if available. |
C |
|
pEI |
PEI used in the procedure, if available (see NOTE 1 in table 6.2.2-6). |
C |
|
gPSI |
GPSI used in the procedure, if available (see NOTE 1 in table 6.2.2-6). |
C |
|
gUTI |
5G-GUTI used in the procedure, see TS 24.501 [13] clause 9.11.3.4. |
C |
|
nRPPaMessage |
Any UE associated NRPPa message exchanged between the LMF and NG-RAN via AMF. |
C |
|
lPPMessage |
Any LPP message exchanged between the LMF and the target UE via AMF. |
C |
|
lcsCorrelationId |
LCS correlation ID (see TS 29.572 [24] clause 6.1.6.3.2) related to a location session, found in the Namf_CommunicationN1N2MessageTransfer and corresponding Namf_Communication_N2InfoNotify or Namf_CommunicationN1MessageNotify. All the AMFPositioningInfoTransfer records related to the same location session have the same lcsCorrelationId. |
M |
6.2.2.2.9 Handovers
6.2.2.2.9.1 General
The present clause provides the LI requirements for NG interface-based handovers which occur for a target UE. Such handovers may be intra 5GS (inter-gNB), 5GS to EPS (inter-system), EPS to 5GS (inter-system), or 5GS to UTRA (inter-system).
The following xIRI records are used to report handover related events between the AMF and RAN nodes for the target UE when the delivery of location information is not restricted by service scoping:
– AMFRANHandoverCommand.
– AMFRANHandoverRequest.
The above xIRIs are used to report handover events and information that are not carried in the AMFLocationUpdate (clause 6.2.2.2.4) record and shall include the information transferred between the AMF and RAN nodes, as a part of handover preparation, resource allocation, and handover notification.
6.2.2.2.9.2 Handover command
The IRI-POI in the AMF shall generate an xIRI containing an AMFRANHandoverCommand record when the IRI-POI present in the AMF detects that the AMF has sent a HANDOVER COMMAND message to the source RAN node (old RAN node) in response to a HANDOVER REQUIRED message for the target UE and location information is not restricted by service scoping.
Table 6.2.2.2.9.2-1: Payload for AMFRANHandoverCommand record
Field name |
Description |
M/C/O |
userIdentifiers |
List of identifiers, including the target identifier, associated with the target UE registration stored in the AMF context. See TS 29.518 [22] clause 6.1.2.2.5. |
M |
aMFUENGAPID |
Identity that the AMF uses to uniquely identify the target UE over the NG Interface. See TS 38.413 [23] clause 9.3.1.1. This is correlated to the SUPI known in the UE AMF context. |
M |
rANUENGAPID |
Identity that the AMF receives from the NG-RAN node uniquely identifying the target UE with the NG-RAN Node. See TS 38.413 [23] clause 9.3.3.2. |
M |
handoverType |
Identifies the type of handover indicated by the source RAN node to the AMF. See TS 38.413 [23] clause 9.3.1.22. |
M |
targetToSourceContainer |
Provides radio related information about the gaining NG-RAN node. See TS 38.413 [23] clause 9.3.1.21. |
M |
6.2.2.2.9.3 Handover request
The IRI-POI in the AMF shall generate an xIRI containing an AMFRANHandoverRequest record when the IRI-POI in the AMF detects that the AMF received a HANDOVER REQUEST ACKNOWLEDGE message from the target RAN node (new RAN node) for the target UE and location information is not restricted by service scoping.
NOTE: The gaining RAN node sends the HANDOVER REQUEST ACKNOWLEDGE in response to a HANDOVER REQUEST from the AMF.
Table 6.2.2.2.9.3-1: Payload for AMFRANHandoverRequest record
Field name |
Description |
M/C/O |
userIdentifiers |
List of user identifiers associated with the target UE registration stored in the AMF context. See TS 29.518 [22] clause 6.1.2.2.5. |
M |
aMFUENGAPID |
Identity that the AMF uses to uniquely identify the target UE over the NG Interface, See TS 38.413 [23] clause 9.3.1.1. This is correlated to the SUPI known in the UE AMF context. |
M |
rANUENGAPID |
Identity that the AMF receives from the NG-RAN node uniquely identifying the target UE within the NG-RAN Node. See TS 38.413 [23] clause 9.3.3.2. |
M |
handoverType |
Identifies the type of handover indicated by the AMF to gaining RAN Node as seen in the HANDOVER REQUEST message. See TS 38.413 [23] clause 9.3.1.22. |
M |
handoverCause |
Indicates the cause of handover as seen in the HANDOVER REQUEST message from AMF to gaining RAN node. See TS 38.413 [23] clause 9.3.1.2. |
M |
pDUSessionResourceInformation |
Indicates the PDU Session to be transferred and Handover Command Transfer information as seen in the HANDOVER REQUEST and confirmed in the HANDOVER REQUEST ACKNOWLEDGE message. See TS 38.413 [23] clauses 9.3.1.50 and 9.3.4.10. |
M |
mobilityRestrictionList |
Provides roaming or access restrictions related to mobility from AMF to gaining RAN Node. Include if sent in HANDOVER REQUEST. See TS 38.413 [23] clause 9.3.1.85. |
C |
locationReportingRequestType |
Indicates the type of location reporting requested in the HANDOVER REQUEST. Include if in HANDOVER REQUEST message. See TS 38.413 [23] clause 9.3.1.65. |
C |
targetToSourceContainer |
Provides radio related information from gaining to losing NG-RAN node that the AMF receives from the gaining RAN Node in the HANDOVER REQUEST ACKNOWLEDGE message. See TS 38.413 [23] clause 9.3.1.21. |
M |
nPNAccessInformation |
Globally identifies the secondary NG-RAN node CAG Cells. Include if sent in the HANDOVER REQUEST ACKNOWLEDGE message from gaining RAN node to AMF. See TS 38.413 [23] clause 9.3.3.46. |
C |
rANSourceToTargetContainer |
Provides radio related information via the AMF in the HANDOVER REQUEST from source to gaining NG-RAN node. See TS 38.413 [23] clause 9.3.1.21. |
M |
6.2.2.2.10 UE Configuration Update
The IRI-POI in the AMF shall generate an xIRI containing a AMFUEConfigurationUpdate record when the IRI-POI present in the AMF detects that a UE matching one of the target identifiers provided via LI_X1 has been commanded to update its configuration. Accordingly, the IRI-POI in the AMF generates the xIRI when the following event is detected:
– AMF sends a CONFIGURATION UPDATE COMMAND message to the target UE.
Table 6.2.2.2.10-1: Payload for AMFUEConfigurationUpdate record
Field name |
Description |
M/C/O |
userIdentifiers |
List of identifiers, including the target identifier, associated with the target UE registration stored in the AMF context. See TS 29.518 [22] clause 6.1.6.2.25. |
M |
gUTI |
Current 5G-GUTI associated with the UE context. If the AMF includes a new 5G-GUTI as a part of the configuration update, this parameter shall be set to the new GUTI and the oldGUTI parameter shall be populated, see TS 24.501 [13] clause 8.2.19.3. |
M |
oldGUTI |
Old 5G-GUTI associated with the UE context. If the AMF includes a new 5G-GUTI as a part of the configuration update, this parameter shall be set to the old GUTI. |
C |
fiveGSTAIList |
List of tracking areas associated with the registration area within which the UE is current registered, see TS 24.501 [13] clause 9.11.3.9. Shall be included each time there is a change to the registration area and omitted if the registration area does not change. |
C |
slice |
Provide, if available, one or more of the following: – allowed NSSAI (see TS 24.501 [13] clause 9.11.3.37). – configured NSSAI (see TS 24.501 [13] clause 9.11.3.37). – rejected NSSAI (see TS 24.501 [13] clause 9.11.3.46). This is derived from the information sent to the UE in the CONFIGURATION UPDATE COMMAND message. |
C |
serviceAreaList |
Includes a list of allowed service areas or non-allowed service areas, encoded per TS 24.501 [13] clause 9.11.3.49, omitting the first two octets. Shall be included if present in the CONFIGURATION UPDATE COMMAND message, see TS 24.501 [13] clause 8.2.19. |
C |
registrationResult |
Specifies the result of registration, see TS 24.501 [13] clause 9.11.3.6. Shall be included if present in the CONFIGURATION UPDATE COMMAND message, see TS 24.501 [13] clause 8.2.19. |
C |
sMSoverNASIndicator |
Indicates whether SMS over NAS is supported. Shall be present if the SMS indication is present in the CONFIGURATION UPDATE COMMAND message, see TS 24.501 [13] clause 8.2.19. |
C |
6.2.2.3 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in AMF, the MDF2 shall generate the corresponding IRI message and deliver over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received in the xIRI over LI_X2. This record may be enriched with any additional information available at the MDF (e.g. additional location information).
The timestamp field of the PSHeader structure shall be set to the time at which the AMF event was observed (i.e. the timestamp field of the X2 PDU).
The IRI type parameter (see ETSI TS 102 232-1 [9] clause 5.2.10) shall be included and coded according to table 6.2.2-7.
Table 6.2.2-7: IRI type for IRI messages
IRI message |
IRI type |
AMFRegistration |
REPORT |
AMFDeregistration |
REPORT |
AMFLocationUpdate |
REPORT |
AMFStartOfInterceptionWithRegisteredUE |
REPORT |
AMFUnsuccessfulProcedure |
REPORT |
AMFIdentifierAssociation |
REPORT |
AMFPositioningInfoTransfer |
REPORT |
AMFRANHandoverCommand |
REPORT |
AMFRANHandoverRequest |
REPORT |
AMFUEConfigurationUpdate |
REPORT |
These IRI messages shall omit the CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).
The threeGPP33128DefinedIRI field in ETSI TS 102 232-7 [10] clause 15 shall be populated with the BER-encoded IRIPayload.
When an additional warrant is activated on a target UE and the LIPF uses the same XID for the additional warrant, the MDF2 shall be able to generate and deliver the IRI message containing the AMFStartOfInterceptionWithRegisteredUE record to the LEMF associated with the additional warrant without receiving a corresponding xIRI. The payload of the AMFStartOfInterceptionWithRegisteredUE record is specified in table 6.2.2-4.
If the MDF2 did not receive from the IRI-POI the value of timeOfRegistration parameter in a previous corresponding AMFStartOfInterceptionWithRegisteredUE for the same registration, the MDF2 shall include in that parameter the time provided in the timestamp previously received in the header of the related AMFRegistration xIRI.
6.2.2.4 Identity privacy
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 [11]. 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.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 [13] 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.
Table 6.2.2A-1: 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 [13] 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 [13] 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 [23] clause 9.3.3.5) and NCI (encoded as per TS 38.413 [23] clause 9.3.1.7). |
M |
nCGITime |
ueLocationTimestamp(s) of nCGIs if available in AMF as per TS 29 .571 [17] 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 [13] 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 [13], clause 9.11.3.9. (see NOTE 2) |
C |
gPSI |
GPSI, (see NOTE 1). |
C |
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.
Table 6.2.2A-2: 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 [23] clause 9.3.3.5) and NCI (encoded as per TS 38.413 [23] clause 9.3.1.7). |
M |
nCGITime |
ueLocationTimestamp(s) of nCGIs if available in AMF as per TS 29 .571 [17] 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 [7] 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 present document.
6.2.3 LI for SMF/UPF
6.2.3.1 Provisioning over LI_X1
6.2.3.1.1 General
If the warrant is for IRI and CC, then the IRI-POI and the CC-TF in the SMF shall be provisioned in accordance with clause 6.2.3.1.2, the MDF2 shall be provisioned in accordance with clause 6.2.3.1.3, and the MDF3 shall be provisioned in accordance with clause 6.2.3.1.4.
If the warrant is for IRI only, the IRI-POI in the SMF shall be provisioned in accordance with clause 6.2.3.1.2 and the MDF2 shall be provisioned in accordance with clause 6.2.3.1.3.
If approach 1 described in clause 6.2.3.9 is used for packet header information reporting, the IRI-TF in the SMF shall be provisioned in accordance with clause 6.2.3.1.2 and the MDF2 shall be provisioned in accordance with clause 6.2.3.1.3. If approach 2 described in clause 6.2.3.9 is used for packet header information reporting, the CC-TF in the SMF shall be provisioned in accordance with clause 6.2.3.1.2, the MDF2 shall be provisioned in accordance with clause 6.2.3.1.3, and the MDF3 shall be provisioned in accordance with clause 6.2.3.1.4.
If the SMF is part of a combined SMF+PGW-C, the requirements in clause 6.3.3 shall apply.
6.2.3.1.2 Provisioning of the IRI-POI, IRI-TF and CC-TF in the SMF
The IRI-POI, IRI-TF and CC-TF present in the SMF are provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The POI/TF in the SMF shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– SUPIIMSI.
– SUPINAI.
– PEIIMEI.
– PEIIMEISV.
– GPSIMSISDN.
– GPSINAI.
Table 6.2.3-0A shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI, in the SMF.
Table 6.2.3-0A: ActivateTask message for SMF IRI-POI, CC-TF and IRI-TF
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
XID assigned by LIPF. If the CC-TF or IRI-TF is also being tasked for the same interception, the same XID shall be used. |
M |
TargetIdentifiers |
One or more of the target identifiers listed in the paragraph above. |
M |
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. (NOTE: "X2Only" for IRI-POI, IRI-TF and "X3Only" for CC-TF can also be used). |
M |
TaskDetailsExtensions/ HeaderReporting |
Header reporting-specific tag to be carried in the TaskDetailsExtensions field of ETSI TS 103 221-1 [7]. See table 6.2.3.9.2-1. Unless there is a CSP/LEA agreement to not report packet header information, this field shall be present to enable packet header information reporting. |
C |
ListOfDIDs |
Delivery endpoints of LI_X2 or LI_X3. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
ListOfServiceTypes |
Shall be included when the task should only intercept specific CSP service types as described in clause 5.2.4. This parameter is defined in ETSI TS 103 221-1 [7], clause 6.2.1.2, table 4. |
C |
To enable packet header information reporting, parameters specified in table 6.2.3.9.2-1: PDHRReportingExtensions parameters shall be provided as the TaskDetailsExtensions/HeaderReporting field of the LI_X1 provisioning message.
6.2.3.1.3 Provisioning of the MDF2
The MDF2 listed as the delivery endpoint for xIRI generated by the IRI-POI in the SMF or the IRI-POI in the UPF shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 6.2.3-0B shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
The MDF2 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– SUPIIMSI.
– SUPINAI.
– PEIIMEI.
– PEIIMEISV.
– GPSIMSISDN.
– GPSINAI.
Table 6.2.3-0B: ActivateTask message for MDF2
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
XID assigned by LIPF. |
M |
TargetIdentifiers |
One or more of the target identifiers listed in the paragraph above. |
M |
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. (Ignored by the MDF2). |
M |
TaskDetailsExtensions/ HeaderReporting |
Header reporting-specific tag to be carried in the TaskDetailsExtensions field of ETSI TS 103 221-1 [7]. See table 6.2.3.9.2-1. Unless there is a CSP/LEA agreement to not report packet header information, this field shall be present to enable packet header information reporting. |
C |
ListOfDIDs |
Delivery endpoints of LI_HI2. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
ListOfMediationDetails |
Sequence of Mediation Details, See table 6.2.3-0C. |
M |
Table 6.2.3-0C: Mediation Details for MDF2
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
LIID |
Lawful Intercept ID associated with the task. |
M |
DeliveryType |
Set to "HI2Only". |
M |
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
ServiceScoping |
Shall be included to Identify the service(s) and associated service-related delivery settings for this LIID. May include more than one instance of this parameter to allow for different combinations of subparameters associated with a single LIID. This parameter is defined in ETSI TS 103 221-1 [7] Annex C table C.2. |
C |
MediationDetailsExtensions/ HeaderReporting |
Header reporting-specific tag to be carried in the MediationDetailsExtensions field of ETSI TS 103 221-1 [7]. See table 6.2.3.9.2-1. This field shall be included if deviation from the taskDetails HeaderReporting TaskDetailsExtensions is required. If included, the details shall be used instead of the HeaderReporting instructions specified in the HeaderReporting field in the TaskDetails structure. |
C |
6.2.3.1.4 Provisioning of the MDF3
The MDF3 listed as the delivery endpoint for the xCC generated by the CC-POI in the UPF shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 6.2.3-0D shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF3. If packet header information reporting is authorised and approach 2 described in clause 6.2.3.9.1 is used, the endpoint for the MDF3 shall be the MDF2 over LI_MDF.
The MDF3 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– SUPIIMSI.
– SUPINAI.
– PEIIMEI.
– PEIIMEISV.
– GPSIMSISDN.
– GPSINAI.
Table 6.2.3-0D: ActivateTask message for MDF3
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
XID assigned by LIPF. |
M |
TargetIdentifiers |
One or more of the target identifiers listed in the paragraph above. |
M |
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. |
M |
TaskDetailsExtensions/ HeaderReporting |
Header reporting-specific tag to be carried in the TaskDetailsExtensions field of ETSI TS 103 221-1 [7]. See table 6.2.3.9.2-1. Unless there is a CSP/LEA agreement to not report packet header information, this field shall be present to enable packet header information reporting is. |
C |
ListOfDIDs |
Delivery endpoints of LI_HI3 or LI_MDF. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
ListOfMediationDetails |
Sequence of Mediation Details, see table 6.2.3-0E. |
M |
Table 6.2.3-0E: Mediation Details for MDF3
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
LIID |
Lawful Intercept ID associated with the task. |
M |
DeliveryType |
Set to "HI3Only". |
M |
ListOfDIDs |
Details of where to send the CC for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
ServiceScoping |
Shall be included to Identify the service(s) and associated service-related delivery settings for this LIID. May include more than one instance of this parameter to allow for different combinations of subparameters associated with a single LIID. This parameter is defined in ETSI TS 103 221-1 [7] Annex C table C.2. |
C |
MediationDetailsExtensions/ HeaderReporting |
Header reporting-specific tag to be carried in the MediationDetailsExtensions field of ETSI TS 103 221-1 [7]. See table 6.2.3.9.2-1. This field shall be included if deviation from the taskDetails HeaderReporting TaskDetailsExtensions is required. If included, the details shall be used instead of the HeaderReporting instructions specified in the HeaderReporting field in the TaskDetails structure. |
C |
6.2.3.2 Generation of xIRI at IRI-POI in SMF over LI_X2
6.2.3.2.1 General
The IRI-POI present in the SMF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 6.2.3.3, the details of which are described in the following clauses. In the case where the SMF is part of a combined SMF+PGW-C, the details of the events are specified in clause 6.3.3.2. The IRI-POI present in the SMF shall also send a SeparatedLocationReporting xIRI (as described in clause 7.3.4.1) when the IRI-POI provisioned in the H-SMF detects that the V-SMF has sent location data via the HsmfUpdateData service operation to the H-SMF that does not otherwise trigger an existing SMF record type.
As specified in TS 23.501 [2] clause 5.6.1, a PDU session may support either a single-access PDU Connectivity Service (referred to as a single-access PDU Session) or a multi-access PDU Connectivity Service (referred to as a Multi-Access PDU (MA PDU) session).
The details of the messages for single-access PDU sessions are provided below in clauses 6.2.3.2.2, 6.2.3.2.3, 6.2.3.2.4, 6.2.3.2.5 and 6.2.3.2.6.
The details of the messages for multi-access PDU sessions are provided below in clauses 6.2.3.2.7 and 6.2.3.2.8.
6.2.3.2.2 PDU session establishment
The IRI-POI in the SMF shall generate an xIRI containing an SMFPDUSessionEstablishment record when the IRI-POI present in the SMF detects that a single-access PDU session has been established for the target UE. The IRI-POI present in the SMF shall generate the xIRI for the following events:
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), sends the N1 NAS message (via AMF) PDU SESSION ESTABLISHMENT ACCEPT to the UE and the 5G Session Management (5GSM) state within the SMF is changed to PDU SESSION ACTIVE (see TS 24.501 [13]). If SMF receives a Npcf_SMPolicyControl_Create response from the PCF for the target UE in response to Npcf_SMPolicyControl_Create request sent by SMF to PCF including PCC rules which traffic control policy data contains either a routeToLocs IE or trafficSteeringPolIdDl IE and/or trafficSteeringPolIdUl IE, SMF includes them in the xIRI. These PCC rules correspond to policies that influence the target UE’s traffic flows (see TS 29.513 [88] clause 5.5.3).
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) sends the N16: Nsmf_PDU_Session_Create response message with n1SmInfoToUe IE containing the PDU SESSION ESTABLISHMENT ACCEPT (see TS 29.502 [16]).
Table 6.2.3-1: Payload for SMFPDUSessionEstablishment record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions (see NOTE). |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI has not been authenticated, or “false” if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available (see NOTE). |
C |
gPSI |
GPSI associated with the PDU session if available (see NOTE). |
C |
pDUSessionID |
PDU Session ID See TS 24.501 [13] clause 9.4. |
M |
gTPTunnelID |
Contains the F-TEID identifying the UPF endpoint of the GTP tunnel used to encapsulate the traffic derived from the UL NG-U UP TNL Information (see TS 38.413 clause 9.3.4.1), as defined in TS 29.244 [15] clause 8.2.3. Non-GTP encapsulation is for further study. |
M |
pDUSessionType |
Identifies selected PDU session type, see TS 24.501 [13] clause 9.11.4.11. |
M |
sNSSAI |
Slice identifiers associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
uEEndpoint |
UE endpoint address(es) assigned to the PDU Session if available (see TS 29.244 [15] clause 5.21). |
C |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
dNN |
Data Network Name requested by the target UE, as defined in TS 23.003[19] clause 9A and described in TS 23.502 [4] clause 4.3.2.2. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
M |
aMFID |
Identifier of the AMF associated with the target UE, as defined in TS 23.003 [19] clause 2.10.1 if available. |
C |
hSMFURI |
URI of the Nsmf_PDUSession service of the selected H-SMF, if available. See TS 29.502 [16] clause 6.1.6.2.2. |
C |
requestType |
Type of request as described in TS 24.501 [13] clause 9.11.3.47 provided within the Nsmf_PDU_Session_CreateSMContext Request (TS 29.502 [16]) message shall be reported. In the case where the network does not support Multi Access (MA) PDU sessions, but receives a MA PDU session request, a request type of “Initial request” shall be reported. In the case where the network does not provide a request type value for a non-MA PDU session, a request type of “initial request”, according to TS 24.501 [13] clause 6.4.1.2 shall be reported. |
M |
accessType |
Access type associated with the session (i.e. 3GPP or non-3GPP access) if provided by the AMF (see TS 24.501 [13] clause 9.11.2.1A). |
C |
rATType |
RAT Type associated with the access if provided by the AMF as part of session establishment (see TS 23.502 [4] clause 4.3.2). Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
sMPDUDNRequest |
Contents of the SM PDU DN Request container, if available, as described in TS 24.501 [13] clause 9.11.4.15. |
C |
uEEPSPDNConnection |
This IE shall be present, if available, during an EPS to 5GS Idle mode mobility or handover using the N26 interface. If present, it shall contain the EPS bearer context(s) information present in the uEEPSPDNConnection parameter of the intercepted SmContextCreateData message. (see TS 29.502 [16] clause 6.1.6.2.2). |
C |
ePS5GSComboInfo |
Provides detailed information about PDN associated with PDU Sessions when the SMFPDUSessionEstablishment xIRI message is used to report PDU Session Establishment (see clause 6.3.3.2.2). Shall be included if the AMF has selected a SMF+PGW-C to serve the PDU session. This parameter shall include the additional IEs in Table 6.2.3-1A, if present. |
C |
selectedDNN |
Shall be present if a DNN other than the UE requested DNN is selected for the PDU Session. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
servingNetwork |
PLMN ID of the serving core network operator, and, for a Non-Public Network (NPN), the NID that together with the PLMN ID identifies the NPN. Shall be present if this IE is in the SMContextCreateData or PDUSessionCreateData message sent to the SMF or the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). |
C |
oldPDUSessionID |
Shall be present if this IE is in the SMContextCreateData or PDUSessionCreateData message sent to the SMF or the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). |
C |
handoverState |
Indicates whether the PDU Session Establishment being reported was due to a handover. Shall be present if this IE is in the SMContextCreatedData sent by the SMF (see TS 29.502 [16] clause 6.1.6.2.3). |
C |
gTPTunnelInfo |
Contains the information for the User Plane GTP Tunnels for the PDU Session (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). See Table 6.2.3-1B. |
M |
pCCRules |
Set of PCC rules related to traffic influence. Each PCC rule influences the routing of a given traffic flow. If several flows are concerned, then several PCC rules shall be handled by the SMF. Traffic influence policies are orginated by an AF. PCF translates these rules into PCC rules for traffic influence. The payload of a PCC rule for traffic influence is defined in Table 6.2.3-1E. |
C |
ePSPDNConnectionEstablishment |
Provides details about PDN Connections when the SMFPDUSessionEstablishment xIRI message is used to report PDN Connection establishment. See Table 6.3.3-1 and clause 6.3.3.2.2. |
C |
NOTE: At least one of the SUPI, PEI or GPSI fields shall be present. |
Table 6.2.3-1A: Payload for ePS5GSComboInfo
ePSInterworkingIndication |
Indicates whether and how the PDU Session may be moved to EPS. Shall be derived from the EpsInterworkingIndication associated with the PDU Session at the SMF+PGW-C(see TS 29.502 [16] clause 6.1.6.3.11). |
M |
ePSSubscriberIDs |
Includes the Subscriber Identities associated with the EPS PDN Connection in the UE Context sent from the MME to the AMF or known in the context at the SMF+PGW-C.See TS 29.274 [87] clause 7.2.1 and TS 23.502 [4] clause 4.11.1. |
M |
ePSPdnCnxInfo |
Shall be present if there are any EPS PDN connections associated to the PDU Session in the SM Context or PDU Session Context at the SMF+PGW-C. Contains information about the EPS PDN connection associated with the PDU Session. See TS 29.502 [16] clause 6.1.6.2.31. |
C |
ePSBearerInfo |
Shall be present if there are any EPS Bearers associated to the PDU Session in the SM Context or PDU Session Context at the SMF+PGW-C. Contains information about the EPS Bearer context(s) associated with the PDU Session. See TS 29.502 [16] clause 6.1.6.2.4. |
C |
Table 6.2.3-1B: gTPTunnelInfo field
Field name |
Description |
M/C/O |
fiveGSGTPTunnels |
Shall include the 5GS GTP Tunnels (See Table 6.2.3-1C)when the xIRI message is used to report PDU Session related events. |
C |
ePSGTPTunnels |
Shall include the information for the User Plane GTP Tunnels for the bearer context if present in the Request or Response (see TS 29.274 [87] clauses 7.2.2, 7.2.4 and 8.15) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4) when the xIRI message is used to report PDN Connection related events. See Table 6.3.3-6. |
C |
Table 6.2.3-1C: fiveGSGTPTunnels field
Field name |
Description |
M/C/O |
uLNGUUPTunnelInformation |
Shall include the F-TEID for the UPF endpoint of the NG-U transport bearer (See TS 38.413 [23] clause 9.3.4.1). |
C |
additionalULNGUUPTunnelInformation |
Shall include the F-TEID for the UPF endpoint of any additional NG-U transport bearers (See TS 38.413 [23] clause 9.3.4.1). |
C |
dLRANTunnelInformation |
Shall include the RAN tunnel and QOS Flow information for the PDU Session (See TS 29.502 [16] clause 6.1.6.2.39 and TS 38.413 [23] clause 9.3.4.1). See Table 6.2.3-1D. |
C |
Table 6.2.3-1D: dLRANTunnelInformation field
Field name |
Description |
M/C/O |
dLQOSFlowTunnelInformation |
Shall include the F-TEID NG-RAN endpoint of the NG-U transport bearer together with associated QoS flows (See TS 38.413 [23] clause 9.3.4.2 and TS 29.502 [16] clause 6.1.6.2.39). |
C |
additionalDLQOSFlowTunnelInformation |
Shall include the F-TEID NG-RAN endpoint of any additional NG-U transport bearers together with associated QoS flows (See TS 38.413 [23] clause 9.3.4.2 and TS 29.502 [16] clause 6.1.6.2.39). |
C |
redundantDLQOSFlowTunnelInformation |
Shall include the F-TEID NG-RAN endpoint of redundant NG-U transport bearers together with associated QoS flows (See TS 38.413 [23] clause 9.3.4.2 and TS 29.502 [16] clause 6.1.6.2.39). |
C |
additionalredundantDLQOSFlowTunnelInformation |
Shall include the F-TEID NG-RAN endpoint of any additional redundant NG-U transport bearers together with associated QoS flows (See TS 38.413 [23] clause 9.3.4.2 and TS 29.502 [16] clause 6.1.6.2.39). |
C |
Each PCC rule for traffic influence has the payload defined in Table 6.2.3-1E.
Table 6.2.3-1E: Payload of PCCrule for traffic influence
Field name |
Description |
M/C/O |
pCCRuleID |
Policy rule identifier. This IE is defined in TS 29.512 [89], table 5.6.2.6-1. |
M |
appId |
Identifies an application (NOTE 1), if available. This IE is defined in TS 29.512 [89], table 5.6.2.6-1 (NOTE 1). |
C |
pFD |
Packet flow description (PFD) associated with the appId, if available. It is defined in TS 29.551 [96] table 5.6.2.5-1 (NOTE 1). |
C |
flowInfos |
A set of flow information, if available. A flow information is an Ethernet or IP flow packet filter information (NOTE 1). This IE is defined in TS 29.512 [89], table 5.6.2.6-1 (NOTE 1). FlowInfos may be IP flow or Ethernet flow. IP flow is specified in TS 29.214, section 5.3.8 [92]. Ethernet Flow is specified in TS 29.514 [91] Table 5.6.2.17-1. |
C |
appReloc |
Indicates that the application cannot be relocated once a location of the application is selected by the 5GC when it is included and set to "true". The default value is "false". |
C |
simConnInd |
Indication of simultaneous connectivity temporarily maintained for the source and target PSA (PDU Session Anchor). If it is included and set to "true", temporary simultaneous connectivity should be kept. The default value "false" applies, if the IE is not present. This IE is defined in TS 29.512 [89], table 5.6.2.9-1. |
C |
simConnTerm |
Indication of the minimum time interval to be considered for inactivity of the traffic routed via the source PSA during the edge re-location procedure. It may be included when the "simConnInd" attribute is set to true. This IE is defined in TS 29.512 [89], table 5.6.2.9-1. |
C |
maxAllowedUpLat |
Indicates the target user plane latency in units of milliseconds used by SMF to decide whether edge relocation is needed to ensure that the user plane latency does not exceed the value. This IE is defined in TS 29.512 [89], table 5.6.2.9-1, if available. |
C |
routeToLocs |
A set of traffic routes, if available. A traffic route provides information to route to/from a DNAI. This IE is defined in TS 29.512 [89], table 5.6.2.9-1 (NOTE 2). |
C |
trafficSteeringPolIdDl |
Traffic steering policy for downlink traffic at the SMF, if available. This IE is defined in TS 29.512 [89], table 5.6.2.9-1 (NOTE 2). |
C |
trafficSteeringPolIdUl |
Traffic steering policy for uplink traffic at the SMF, if available. This IE is defined in TS 29.512 [89], table 5.6.2.9-1 (NOTE 2). |
C |
sourceDNAI |
No longer used in present version of this specification |
O |
targetDNAI |
No longer used in present version of this specification |
O |
dNAIChangeType |
No longer used in present version of this specification |
O |
sourceUEIPAddress |
No longer used in present version of this specification |
O |
targetUEIPAddress |
No longer used in present version of this specification |
O |
eASIPReplaceInfos |
Contains EAS IP replacement information for a Source and a Target EAS, if available. This IE is defined in TS 29.571 [17], table 5.4.4.79. |
C |
NOTE 1: Either appId/pFD or flowInfos shall be supplied. NOTE 2: TrafficSteeringPolIdDl attribute and/or trafficSteeringPolIdUl attribute and routeToLocs attribute are mutually exclusive. |
6.2.3.2.3 PDU session modification
The IRI-POI in the SMF shall generate an xIRI containing an SMFPDUSessionModification record when the IRI-POI present in the SMF detects that a single-access PDU session has been modified for the target UE. The IRI-POI present in the SMF shall generate the xIRI for the following events:
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION MODIFICATION COMMAND COMPLETE from the UE and the 5GSM state within the SMF is returned to PDU SESSION ACTIVE (see TS 24.501 [13]). This applies to the following two cases:
– UE initiated PDU session modification.
– Network (VPLMN) initiated PDU session modification.
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), sends the N1 NAS message (via AMF) PDU SESSION ESTABLISHMENT ACCEPT to the UE and the 5GSM state within the SMF remains in the PDU SESSION ACTIVE (see TS 24.501 [13]). This applies to the following case:
– Handover from one access type to another access type happens (e.g. 3GPP to non-3GPP).
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION MODIFICATION COMMAND COMPLETE (see TS 29.502 [16]). This applies to the following three cases:
– UE initiated PDU session modification.
– Network (VPLMN) initiated PDU session modification.
– Network (HPLMN) initiated PDU session modification.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) sends the N16: Nsmf_PDU_Session_Create response message with n1SmInfoToUe IE containing the PDU SESSION ESTABLISHMENT ACCEPT (see TS 29.502 [16]) while it had received a N16 Nsmf_PDU_Session_Create request message with an existing PDU Session Id with access type being changed. This applies to the following case:
– Handover from one access type to another access type happens (e.g. 3GPP to non-3GPP).
– For a non-roaming scenario, SMF sends a Npcf_SMPolicyControlUpdateNotify response to the PCF for the target UE in response to an Npcf_SMPolicyControlUpdateNotify request sent by PCF to SMF including PCC rules which traffic control policy data contains either a routeToLocs IE or trafficSteeringPolIdDl IE and/or trafficSteeringPolIdUl IE. These PCC rules correspond to policies that influence the target UE’s traffic flows (see TS 29.513 [88] clause 5.5.3).
– For a non-roaming scenario, SMF sends a Nsmf_EventExposure_Notify request to the NEF or AF for the target UE for the event "UP Path Change" related to a corresponding subscription from AF (see TS 29.508 [90] clause 4.2.2).
– For a non-roaming scenario, SMF sends a Nsmf_EventExposure_AppRelocationInfo response to the NEF or AF for the target UE in response to Nsmf_EventExposure_AppRelocationInfo request sent by NEF or AF to SMF (see TS 29.508 [90] clause 4.2.5).
– For a non-roaming scenario, SMF receives a Nnef_PFDManagement_Fetch response from the NEF for the target UE in response to Nnef_PFDManagement_Fetch request sent by SMF to NEF (see TS 29.551 [96] clause 4.2.2).
Table 6.2.3-2: Payload for SMFPDUSessionModification record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions. |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI was not authenticated, or “false” if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
sNSSAI |
Slice identifier associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
requestType |
Type of request as described in TS 24.501 [13] clause 9.11.3.47 if available. |
C |
accessType |
Access type associated with the session (i.e. 3GPP or non-3GPP access) if provided by the AMF (see TS 24.501 [13] clause 9.11.2.1A). |
C |
rATType |
RAT type associated with the access, if available. Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
pDUSessionID |
PDU Session ID See TS 24.501 [13] clause 9.4. This parameter is conditional only for backwards compatibility. |
C |
ePS5GSComboInfo |
Provides detailed information about PDN Connections associated with PDU Sessions when the SMFPDUSessionEstablishment xIRI message is used to report PDU Session Establishment (see clause 6.3.3.2.2). Shall be included when the AMF has selected a SMF+PGW-C to serve the PDU session. This parameter may include the additional IEs in Table 6.2.3-1A, when available. |
C |
uEEndpoint |
UE IP address(es) assigned to the PDU Session if available (See TS 29.244 [15] clause 5.21). |
C |
servingNetwork |
Shall be present if this IE is in the SMContextUpdateData, HsmfUpdateData or message sent to the SMF or the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clauses 6.1.6.2.3, 6.1.6.2.11 and 6.1.6.2.39). |
C |
handoverState |
Indicates whether the PDU Session Modification being reported was due to a handover. Shall be present if this IE is in the SMContextUpdatedData or sent by the SMF (see TS 29.502 [16] clause 6.1.6.2.3). |
C |
gTPTunnelInfo |
Contains the information for the User Plane GTP Tunnels for the PDU Session (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). See Table 6.2.3-1B. |
M |
pCCRules |
Set of PCC rules related to traffic influence. Each PCC rule influences the routing of a given traffic flow. If several flows are concerned, then several PCC rules shall be handled by the SMF. Traffic influence policies are orginated by an AF. PCF translates these rules into PCC rules for traffic influence, if available. The payload of a PCC rule for traffic influence is defined in Table 6.2.3-1E. |
C |
ePSPDNConnectionModification |
Provides details about PDN Connections when the SMFPDUSessionModification xIRI message is used to report PDN Connection Modification. See Table 6.3.3-8 and clause 6.3.3.2.3. |
C |
uPPathChange |
Notification of the UPPathChange event. This IE is defined in TS 29.508 [90], if available, Table 5.6.2.5-1. |
C |
pFDDataForApp |
Represents the packet flow descriptions (PFDs) for an application identifier (AppId), if available. This IE is defined in TS 29.551 [96], Table 5.6.2.2-1. |
C |
Table 6.2.3-2A: Payload of UPPathChange
Field name |
Description |
M/C/O |
sourceDNAI |
Source DNAI, if the DNAI has changed. DNAI represents the location of applications towards which the traffic routing should apply, if available. |
C |
targetDNAI |
Target DNAI if the DNAI has changed. |
C |
dNAIChangeType |
Type of a DNAI change. Possible values are “early”, “late” and “earlyAndLate” notification of UP path reconfiguration, if available. |
C |
sourceUEIPAddress |
The IPv4 Address of the served UE for the source DNAI, if available. |
C |
targetUEIPAddress |
The IPv4 Address of the served UE for the target DNAI, if available. |
C |
sourceTrafficRouting |
N6 traffic routing information for the source DNAI, if available. |
C |
targetTrafficRouting |
N6 traffic routing information for the target DNAI, if available. |
C |
mACAddress |
The MAC address of the served UE, if available. |
C |
Table 6.2.3-2B: Payload of PFDDataForApp
Field name |
Description |
M/C/O |
appId |
Identifier of an application. |
M |
pFDs |
PFDs for an application identifier, if available. PFD is defined in TS 29.551 [96], Table 5.6.2.5-1. |
C |
Table 6.2.3-2C: Payload of PFD
Field name |
Description |
M/C/O |
pFDId |
PFD identifier. |
M |
pFDflowDescription |
Represents a set of 3-tuple with protocol, server IP address and server port for UL/DL application traffic, if available. |
C |
uRLs |
Represents a set of URL, if available. |
C |
domainNames |
Represents a set of FQDN, if available. |
C |
dnProtocol |
Indicates the additional protocol and protocol field for domain names to be matched, if available. This IE is defined in 29.122 [63], Table 5.14.2.2.4-1. |
C |
6.2.3.2.4 PDU session release
The IRI-POI in the SMF shall generate an xIRI containing an SMFPDUSessionRelease record when the IRI-POI present in the SMF detects that a single-access PDU session has been released. The IRI-POI present in the SMF shall generate the xIRI for the following events:
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION RELEASE COMMAND COMPLETE from the UE and the 5GSM state within the SMF is changed to PDU SESSION INACTIVE (see TS 24.501 [13]). This applies to the following two cases:
– UE initiated PDU session release.
– Network initiated PDU session release.
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION MODIFICATION COMMAND REJECT from the UE with the cause value #43 indicating an invalid PDU Session ID and the 5GSM state within the SMF is changed to PDU SESSION INACTIVE (see TS 24.501 [13]). This applies to the case where the UE rejects a PDU SESSION MODIFICATION COMMAND as it finds that the indicated PDU session ID is invalid. The 5GSM state is changed to PDU SESSION INACTIVE within the SMF.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION RELEASE COMMAND COMPLETE (see TS 29.502 [16]) from the V-SMF. This applies to the following three cases:
– UE initiated PDU session release.
– Network (VPLMN) initiated PDU session release.
– Network (HPLMN) initiated PDU session release.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION MODIFICATION COMMAND REJECT (see TS 29.502 [16]) from the V-SMF with the cause value #43 indicating an Invalid PDU Session ID.
Table 6.2.3-3: Payload for SMFPDUSessionRelease record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session. |
M |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
pDUSessionID |
PDU Session ID as assigned by the AMF. |
M |
timeOfFirstPacket |
Time of first packet for the PDU session. |
C |
timeOfLastPacket |
Time of last packet for the PDU session. |
C |
uplinkVolume |
Number of uplink octets for the PDU session. |
C |
downlinkVolume |
Number of downlink octets for the PDU session. |
C |
location |
Location information, if available. |
C |
cause |
Indicates the NF Service Consumer cause for the requested PDU session release (see TS 29.502 [16] clause 6.1.6.3.8 for enumerated cause information). Include if known. |
C |
ePS5GSComboInfo |
Provides detailed information about PDN Connections associated with PDU Sessions when the SMFPDUSessionEstablishment xIRI message is used to report PDU Session Establishment (see clause 6.3.3.2.2). This parameter may include the additional IEs in Table 6.2.3-1A, when available. |
C |
nGAPCause |
Indicates the NGAP cause for the requested SM context release (see TS 29.502 [16] clause 6.1.6.2.6). Shall be derived as described in TS 29.571 [17] clause 5.4.4.12. |
C |
fiveGMMCause |
Indicates the 5GMM cause for a PDU Session released due to any 5GMM failure (see 29.502 [16] clause 6.1.6.2.6). Shall be sent as an integer derived as described in TS 29.571 [17] clause 5.4.2. |
C |
pCCRuleIDs |
PCC rule IDs of the PCC rules related to traffic influence that are associated to the PDU session and active at the time the PDU session is released. |
C |
ePSPDNConnectionRelease |
Provides details about PDN Connections when the SMFPDUSessionRelease xIRI message is used to report PDN Connection Release. See Table 6.3.3-13 and clause 6.3.3.2.4. |
C |
6.2.3.2.5 Start of interception with an established PDU session
The IRI-POI in the SMF shall generate an xIRI containing an SMFStartOfInterceptionWithEstablishedPDUSession record when the IRI-POI present in the SMF detects that a single-access PDU session has already been established for the target UE when interception starts.
In a non-roaming scenario, the IRI-POI in the SMF (or in a roaming scenario, the IRI-POI in the V-SMF in the VPLMN) shall generate the xIRI containing the SMFStartOfInterceptionWithEstablishedPDUSession record when it detects that a new interception for a UE is activated (i.e. provisioned by the LIPF) for the following case:
– The 5GSM state within the SMF for that UE is 5GSM: PDU SESSION ACTIVE or PDU SESSION MODIFICATION PENDING.
NOTE: The above trigger happens when the SMF (V-SMF in VPLMN) had not sent an N1 NAS message PDU SESSION RELEASE COMMAND to the UE for a PDU session and the SMF (V-SMF in the VPLMN) had previously sent an N1 NAS message PDU SESSION ESTABLISHMENT ACCEPT to that UE for the same PDU session.
In a home-routed roaming scenario, the IRI-POI in the H-SMF shall generate the xIRI containing the SMFStartOfInterceptionWithEstablishedPDUSession record when it detects that a new interception for a UE is activated (i.e. provisioned by the LIPF) for the following case:
– The H-SMF had not sent a Nsmf_PDU_Session_Update Request (n1SmInfoToUe: PDU SESSION RELEASE COMMAND) to the V-SMF for a PDU session and H-SMF had previously sent a Nsmf_PDU_Session_Create response (n1SmInfoToUE: PDU SESSION ESTABLISHMENT ACCEPT) to the V-SMF for that PDU session.
The IRI-POI in the SMF shall generate the xIRI containing the SMFStartOfInterceptionWithEstablishedPDUSession record for each of the PDU sessions (that meets the above criteria) associated with the newly identified target UEs.
Table 6.2.3-4: Payload for SMFStartOfInterceptionWithEstablishedPDUSession record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions. |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI has not been authenticated, or “false” if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
pDUSessionID |
PDU Session ID as assigned by the AMF, as defined in TS 24.007 [14] clause 11.2.3.1b. |
M |
gTPTunnelID |
Contains the F-TEID identifying the UPF endpoint of the GTP tunnel used to encapsulate the traffic derived from the UL NG-U UP TNL Information (see TS 38.413 clause 9.3.4.1), as defined in TS 29.244 [15] clause 8.2.3. Non-GTP encapsulation is for further study. |
M |
pDUSessionType |
Identifies selected PDU session type, see TS 24.501 [13] clause 9.11.4.11. |
M |
sNSSAI |
Slice identifier associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
uEEndpoint |
UE endpoint address(es) if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). MAC addresses are given as 6 octets with the most significant octet first (see TS 29.244 [15] clause 5.21). |
C |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
location |
Location information provided by the AMF at session establishment or present in the context at the SMF, if available. |
C |
dNN |
Data Network Name associated with the target traffic, as defined in TS 23.003 [19] clause 9A and described in TS 23.502 [4] clause 4.3.2.2. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
M |
aMFID |
Identifier of the AMF associated with the target UE, as defined in TS 23.003 [19] clause 2.10.1, if available. |
C |
hSMFURI |
URI of the Nsmf_PDUSession service of the selected H-SMF, if available. See TS 29.502 [16] clause 6.1.6.2.2. |
C |
requestType |
Type of request as initially set within the PDU SESSION ESTABLISHMENT as described in TS 24.501 [13] clause 9.11.3.47. |
M |
accessType |
Access type associated with the session (i.e. 3GPP or non-3GPP access) if provided by the AMF (see TS 24.501 [13] clause 9.11.2.1A). |
C |
rATType |
RAT type associated with the access if provided by the AMF as part of session establishment (see TS 23.502 [4] clause 4.3.2). Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
sMPDUDNRequest |
Contents of the SM PDU DN request container, if available, as described in TS 24.501 [13] clause 9.11.4.15. |
C |
timeOfSessionEstablishment |
Time at which the session establishment occurred, if available. Shall be given qualified with time zone information (i.e. as UTC or offset from UTC, not as local time). |
C |
ePS5GSComboInfo |
Provides detailed information about PDN Connections associated with PDU Sessions when the SMFPDUSessionEstablishment xIRI message is used to report PDU Session Establishment (see clause 6.3.3.2.2). Shall be included when the AMF has selected a SMF+PGW-C to serve the PDU session. This parameter may include the additional IEs in table 6.2.3-1A, if available. |
C |
uEEPSPDNConnection |
This IE shall be present, if available, during an EPS to 5GS Idle mode mobility or handover using the N26 interface. If present, it shall contain the EPS bearer context(s) information present in the uEEPSPDNConnection parameter of the intercepted SmContextCreateData message. (see TS 29.502 [16] clause 6.1.6.2.2). |
C |
servingNetwork |
Indicates the serving core network operator PLMN, and for an SNPN, the NID. Shall be present if present in the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clause 6.1.6.2.39). |
C |
gTPTunnelInfo |
Contains the information for the User Plane GTP Tunnels for the PDU Session (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). See Table 6.2.3-1B. |
M |
pCCRules |
Set of PCC rules related to traffic influence. Each PCC rule influences the routing of a given traffic flow. If several flows are concerned, then several PCC rules shall be handled by the SMF. Traffic influence policies are orginated by an AF. PCF translates these rules into PCC rules for traffic influence. The payload of a PCC rule for traffic influence is defined in Table 6.2.3-1E. |
C |
ePSStartOfInterceptionWithEstablishedPDNConnection |
Provides details about PDN Connections when the SMFStartOfInterceptionWithEstablishedPDUSession xIRI message is used to report the start of interception on a target who already has existing PDN Connections. See Table 6.3.3-14 and clause 6.3.3.2.5. |
C |
pFDDataForApps |
Represents a set of associations between application identifier and packet flow descriptions (PFDs), if available. |
C |
The IRI-POI present in the SMF generating an xIRI containing a SMFStartOfInterceptionWithEstablishedPDUSession record shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
6.2.3.2.6 SMF unsuccessful procedure
The IRI-POI in the SMF shall generate an xIRI containing an SMFUnsuccessfulProcedure record when the IRI-POI present in the SMF detects an unsuccessful procedure or error condition for a UE matching one of the target identifiers provided via LI_X1.
Accordingly, the IRI-POI in the SMF generates the xIRI when one of the following events are detected:
– SMF sends a PDU SESSION ESTABLISHMENT REJECT message to the target UE.
– SMF sends a PDU SESSION MODIFICATION REJECT message to the target UE.
– SMF sends a PDU SESSION RELEASE REJECT message to the target UE.
– SMF receives a PDU SESSION MODIFICATION COMMAND REJECT message from the target UE.
– An ongoing SM procedure is aborted at the SMF, due to e.g. a 5GSM STATUS message sent from or received by the SMF.
Table 6.2.3-5: Payload for SMFUnsuccessfulProcedure record
Field name |
Description |
M/C/O |
|
failedProcedureType |
Specifies the procedure which failed or is aborted at the SMF. |
M |
|
failureCause |
Provides the value of the 5GSM cause, see TS 24.501 [13] clause 9.11.4.2. In case the procedure is aborted due to a 5GSM STATUS message, the 5GSM cause is the one included in the 5GSM status message. |
M |
|
requestedSlice |
Slice requested for the procedure, if available, given as a NSSAI (a list of S-NSSAI values as described in TS 24.501 [13] clause 9.11.3.37). |
C |
|
initiator |
Specifies whether the network (SMF) or the UE is initiating the rejection or indicating the failure. |
M |
|
sUPI |
SUPI associated with the procedure, if available (see NOTE). |
C |
|
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI has not been authenticated, or “false” if it has been authenticated. |
C |
|
pEI |
PEI used in the procedure, if available (see NOTE). |
C |
|
gPSI |
GPSI used in the procedure, if available (see NOTE). |
C |
|
pDUSessionID |
PDU Session ID See clause 9.4 of TS 24.501 [13], if available. |
C |
|
uEEndpoint |
UE endpoint address(es) if available. |
C |
|
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. |
C |
|
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
|
dNN |
Data Network Name associated with the target traffic, as defined in TS 23.003 [19] clause 9A and described in TS 23.501 [2] clause 4.3.2.2, if available. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
|
aMFID |
Identifier of the AMF associated with the target UE, as defined in TS 23.003 [19] clause 2.10.1 when available. |
C |
|
hSMFURI |
URI of the Nsmf_PDUSession service of the selected H-SMF, if available. See TS 29.502 [16] clause 6.1.6.2.2. |
C |
|
requestType |
Type of request as described in TS 24.501 [13] clause 9.11.3.47, if available. Otherwise depending on the REJECT event the following request type shall be reported: |
C |
|
accessType |
Access type associated with the session (i.e. 3GPP or non-3GPP access) if provided by the AMF (see TS 24.501 [13] clause 9.11.2.1A). |
C |
|
rATType |
RAT Type associated with the access if provided by the AMF as part of session establishment (see TS 23.502 [4] clause 4.3.2). Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
|
sMPDUDNRequest |
Contents of the SM PDU DN Request container, if available, as described in TS 24.501 [13] clause 9.11.4.15. |
C |
|
NOTE: At least one identity shall be provided, the others shall be provided if available. |
6.2.3.2.7 MA PDU sessions
6.2.3.2.7.1 General
In the present document, an MA PDU session will include two general types of PDU sessions as defined below:
– MA-Confirmed: This is an MA PDU session where the UE signals Upgrade Allowed to MA and the network immediately upgrades the session to an MA PDU session or the UE explicitly requests an MA PDU session (using a Request Type of MA PDU).
– MA-Upgrade-Allowed: This is a PDU session where the UE indicated that upgrade to an MA PDU session is allowed, but the network does not immediately confirm the upgrade. The network may at some later point upgrade the session to an MA PDU session.
NOTE: The above terms are not defined or used in other 3GPP Stage 2 or Stage 3 specifications, but have been introduced here to clarify and distinguish LI event reporting for the respective situations.
An MA-Confirmed MA PDU session may be established over a single access or over multiple accesses. The establishment over multiple accesses may occur concurrently or may occur at different points in time.
An MA-Upgrade-Allowed MA PDU session is established over a single access and nearly all aspects appears to be an ordinary non-MA PDU session with the key difference that the network may upgrade the session to an MA-confirmed MA PDU session.
6.2.3.2.7.2 MA PDU session establishment
The IRI-POI in the SMF shall generate an xIRI containing an SMFMAPDUSessionEstablishment record when the IRI-POI present in the SMF detects that a PDU session has been established for the target UE that is an MA PDU session (Request Type set to MA PDU session or upgraded at establishment), or where the upgrade allowed parameter is set to upgrade allowed and session is established as an ordinary PDU session (not upgraded at establishment, but may occur later on). The IRI-POI present in the SMF shall generate the xIRI for the following events:
– For a non-roaming scenario , the SMF sends the N1 NAS message (via AMF) PDU Session Establishment Accept to the UE for a new PDU session and the 5G Session Management (5GSM) state within the SMF is changed to PDU SESSION ACTIVE (see TS 24.501 [13]) in response to a PDU Session Establishment request received along with:
– PDU Session ID which does not identify an existing PDU session, and
– Request Type = MA PDU request, or
– Request Type = initial request and MA PDU session information set to "MA PDU session network upgrade is allowed", with either upgrade occuring at establishment or upgrade does not occur at establishment but may occur later.
– If SMF receives a Npcf_SMPolicyControl_Create response from the PCF for the target UE in response to Npcf_SMPolicyControl_Create request sent by SMF to PCF including PCC rules which traffic control policy data contains either a routeToLocs IE or trafficSteeringPolIdDl IE and/or trafficSteeringPolIdUl IE, SMF includes them in the xIRI. These PCC rules correspond to policies that influence the target UE’s traffic flows (see TS 29.513 [88] clause 5.5.3).
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) sends the N16: Nsmf_PDU_Session_Create response message with n1SmInfoToUe IE containing the PDU SESSION ESTABLISHMENT ACCEPT (see TS 29.502 [16]) for a new PDU session in response to a PDU Session Establishment request received along with:
– PDU Session ID which does not identify an existing PDU session, and
– Request Type = MA PDU request, or
– Request Type = initial request and MA PDU session information set to "MA PDU session network upgrade is allowed", with either upgrade occuring at establishment or upgrade does not occur at establishment but may occur later.
Table 6.2.3-5A: Payload for SMFMAPDUSessionEstablishment record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions (see NOTE). |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI has not been authenticated, or “false” if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available (see NOTE). |
C |
gPSI |
GPSI associated with the PDU session if available (see NOTE). |
C |
pDUSessionID |
PDU Session ID See clause 9.4 of TS 24.501 [13]. Identifies a new PDU session. |
M |
pDUSessionType |
Identifies selected PDU session type, see TS 24.501 [13] clause 9.11.4.11. |
M |
accessInfo |
Identifies the access(es) associated with the PDU session including the information for each specific access (see table 6.2.3-5B) |
M |
sNSSAI |
Slice identifiers associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
uEEndpoint |
UE endpoint address(es) assigned to the PDU Session if available (see TS 29.244 [15] clause 5.21). |
C |
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
dNN |
Data Network Name requested by the target UE, as defined in TS 23.003 [19] clause 9A and described in TS 23.502 [4] clause 4.3.2.2. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
M |
aMFID |
Identifier of the AMF associated with the target UE, as defined in TS 23.003 [19] clause 2.10.1 when available. |
C |
hSMFURI |
URI of the Nsmf_PDUSession service of the selected H-SMF, if available. See TS 29.502 [16] clause 6.1.6.2.2. |
C |
requestType |
Type of request as described in TS 24.501 [13] clause 9.11.3.47 provided within the Nsmf_PDU_Session_CreateSMContext Request (TS 29.502 [16]) message shall be reported. In the case where the network does not provide a request type value for a MA PDU session and the network does support MA PDU sessions, the request type shall be set to “MA PDU request” according to TS 24.501 [13] clause 6.4.1.2. |
M |
sMPDUDNRequest |
Contents of the SM PDU DN Request container, if available, as described in TS 24.501 [13] clause 9.11.4.15. |
C |
servingNetwork |
PLMN ID of the serving core network operator, and, for a Non-Public Network (NPN), the NID that together with the PLMN ID identifies the NPN. |
M |
oldPDUSessionID |
The old PDU Session ID received from the UE. See TS 23.502 [4] clauses 4.3.2.2.1 and 4.3.5.2 and TS 24.501 [13] clause 6.4.1.2. Shall be present if this IE is in the SMContextCreateData or PDUSessionCreateData message sent to the SMF or the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). |
C |
mAUpgradeIndication |
Indicates whether the PDU session is allowed to be upgraded to MA-Confirmed MA PDU session (see TS 23.502 [4] clause 4.22.3). Include if known. |
C |
ePSPDNCnxInfo |
Indicates if the PDU session may be moved to EPS during its lifetime (see TS 29.502 [16] clause 6.1.6.2.31). Include if known. |
C |
mAAcceptedIndication |
Indicates that a request to establish an MA PDU session was accepted or if a single access PDU session request was upgraded into a MA PDU session (see TS 23.502 [4] clauses 4.22.2 and 4.22.3). It shall be set as follows: – true: MA-Confirmed MA PDU session was established – false: single access MA-Upgrade-Allowed MA PDU session was established that may be upgraded to an MA-Confirmed MA PDU session. |
M |
aTSSSContainer |
Identifies the steering, switching, and splitting features for the MA-Confirmed MA PDU session. Also indicates whether MPTCP or ATSSS-LL is to be used for ATSSS. See TS 24.501[13] clause 9.11.4.22. |
C |
uEEPSPDNConnection |
This IE shall be present, if available, during an EPS to 5GS Idle mode mobility or handover using the N26 interface. If present, it shall contain the EPS bearer context(s) information present in the uEEPSPDNConnection parameter of the intercepted SmContextCreateData message. (see TS 29.502 [16] clause 6.1.6.2.2). |
C |
ePS5GSComboInfo |
Provides detailed information about PDN Connections and PDU Sessions during EPS to 5GS idle mode mobility or handover using the N26 interface. Shall be included if the AMF has selected a SMF+PGW-C to serve the PDU session. This parameter shall include the additional IEs in Table 6.2.3-1A, if present. |
C |
selectedDNN |
Shall be present if a DNN other than the UE requested DNN is selected for the PDU Session. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
handoverState |
Indicates whether the PDU Session Establishment being reported was due to a handover. Shall be present if this IE is in the SMContextCreatedData sent by the SMF (see TS 29.502 [16] clause 6.1.6.2.3). |
C |
pCCRules |
Set of PCC rules related to traffic influence. Each PCC rule influences the routing of a given traffic flow. If several flows are concerned, then several PCC rules shall be handled by the SMF. Traffic influence policies are orginated by an AF. PCF translates these rules into PCC rules for traffic influence. The payload of a PCC rule for traffic influence is defined in Table 6.2.3-1E. |
C |
ePSPDNConnectionEstablishment |
Provides details about PDN Connections when the SMFMAPDUSessionEstablishment xIRI message is used to report PDN Connection establishment. See table 6.3.3-1 and clause 6.3.3.2.2. |
C |
NOTE: At least one of the SUPI, PEI or GPSI fields shall be present. |
Table 6.2.3-5B: Contents of Access Info parameter
Field name |
Description |
M/C/O |
accessType |
Access type associated with the session (i.e. 3GPP or non-3GPP access) as provided by the AMF (see TS 24.501 [13] clause 9.11.2.1A). |
M |
rATType |
RAT Type associated with the access as provided by the AMF as part of session establishment (see TS 23.502 [4] clause 4.3.2). Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
gTPTunnelID |
Contains the F-TEID identifying the GTP tunnel used to encapsulate the traffic, as defined in TS 29.244 [15] clause 8.2.3. Non-GTP encapsulation is for further study. |
M |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
establishmentStatus |
Indicates whether the access type is established or released. |
M |
aNTypeToReactivate |
Indicates the Access Network Type for which the UP connection is requested to be re-activated, for an MA PDU session. Applicable to session modification reporting. |
C |
gTPTunnelInfo |
Contains the information for the User Plane GTP Tunnels for the PDU Session (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). See Table 6.2.3-1B. |
M |
6.2.3.2.7.3 MA PDU session modification
The IRI-POI in the SMF shall generate an xIRI containing an SMFMAPDUSessionModification record when the IRI-POI present in the SMF detects that an MA PDU session has been modified for the target UE. The IRI-POI present in the SMF shall generate the xIRI for the following events:
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION MODIFICATION COMMAND COMPLETE from the UE and the 5GSM state within the SMF is returned to PDU SESSION ACTIVE (see TS 24.501 [13]). This applies to the following cases for an MA-Upgrade-Allowed PDU session:
– UE initiated PDU session modification.
– Network (VPLMN) initiated PDU session modification.
– Upgrade to an MA PDU session.
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION RELEASE COMPLETE from the UE in response to a PDU SESSION RELEASE COMMAND message containing an Access type IE identifying a single access to be released of an MA PDU session which was established over both accesses and the 5GSM state within the SMF remains in the PDU SESSION ACTIVE (see TS 24.501 [13]). This applies to the following case:
– A single access type is released from an MA PDU session, but the MA PDU session continues.
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), sends the N1 NAS message (via AMF) PDU SESSION ESTABLISHMENT ACCEPT to the UE and the 5GSM state within the SMF remains in the PDU SESSION ACTIVE (see TS 24.501 [13]). This applies to the following cases:
– Handover from one access type to another access type happens (e.g. 3GPP to non-3GPP) for an MA-Upgrade-Allowed MA PDU session.
– MA PDU Session establishment over second access type.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION MODIFICATION COMMAND COMPLETE (see TS 29.502 [16]). This applies to the following cases for an MA-Upgrade-Allowed PDU session:
– UE initiated PDU session modification.
– Network (VPLMN) initiated PDU session modification.
– Network (HPLMN) initiated PDU session modification.
– Upgrade to an MA PDU session.
– For a non-roaming scenario, SMF sends a Npcf_SMPolicyControlUpdateNotify response to the PCF for the target UE in response to an Npcf_SMPolicyControlUpdateNotify request sent by PCF to SMF including PCC rules which traffic control policy data contains either a routeToLocs IE or trafficSteeringPolIdDl IE and/or trafficSteeringPolIdUl IE. These PCC rules correspond to policies that influence the target UE’s traffic flows (see TS 29.513 [88] clause 5.5.3).
– For a non-roaming scenario, SMF sends a Nsmf_EventExposure_Notify request to the NEF or AF for the target UE for the event "UP Path Change" related to a corresponding subscription from AF (see TS 29.508 [90] clause 4.2.2).
– For a non-roaming scenario, SMF sends a Nsmf_EventExposure_AppRelocationInfo response to the NEF or AF for the target UE in response to Nsmf_EventExposure_AppRelocationInfo request sent by NEF or AF to SMF (see TS 29.508 [90] clause 4.2.5).
– For a non-roaming scenario, SMF receives a Nnef_PFDManagement_Fetch response from the NEF for the target UE in response to Nnef_PFDManagement_Fetch request sent by SMF to NEF (see TS 29.551 [96] clause 4.2.2).
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION RELEASE COMPLETE message, a response to a PDU SESSION RELEASE COMMAND message containing an Access type IE identifying a single access to be released of an MA PDU session which was established over both accesses and the 5GSM state within the SMF remains in the PDU SESSION ACTIVE (see TS 29.502 [16]). This applies to the following cases:
– A single access type is released from an MA PDU session, but the MA PDU session continues.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) sends the N16: Nsmf_PDU_Session_Create response message with n1SmInfoToUe IE containing the PDU SESSION ESTABLISHMENT ACCEPT (see TS 29.502 [16]) while it had received an N16 Nsmf_PDU_Session_Create request message with an existing PDU Session Id with access type being changed. This applies to the following cases:
– Handover from one access type to another access type happens (e.g. 3GPP to non-3GPP) for an MA-Upgrade-Allowed PDU session.
– MA PDU Session establishment over second access type.
Table 6.2.3-5C: Payload for SMFMAPDUSessionModification record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions. |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message, and set to “true” if the SUPI was not authenticated, or “false” if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
pDUSessionID |
PDU Session ID, see TS 24.501 [13] clause 9.4. |
M |
accessInfo |
Identifies the access(es) associated with the PDU session including the information for each specific access (see table 6.2.3-5B) being modified. |
C |
sNSSAI |
Slice identifier associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
requestType |
For both a UE- as well as a network-requested PDU session, the POI (SMF) shall set the request type parameter to "modification request". |
C |
servingNetwork |
PLMN ID of the serving core network operator, and, for a Non-Public Network (NPN), the NID that together with the PLMN ID identifies the NPN. |
M |
oldPDUSessionID |
The old PDU Session ID received from the UE. See TS 23.502 [4] clauses 4.3.2.2.1 and 4.3.5.2 and TS 24.501 [13] clause 6.4.1.2. Shall be present if this IE is in the SMContextCreateData or PDUSessionCreateData message sent to the SMF or the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). |
C |
mAUpgradeIndication |
Indicates whether the PDU session is allowed to be upgraded to MA PDU session (see TS 23.502 [4] clause 4.22.3). Include if known. |
C |
ePSPDNCnxInfo |
Indicates if the PDU session may be moved to EPS during its lifetime (see TS 29.502 [16] clause 6.1.6.2.31). Include if known. |
C |
mAAcceptedIndication |
Indicates that a request to establish an MA PDU session was accepted or if a single access PDU session request was upgraded into a MA PDU session (see clauses 4.22.2 and 4.22.3 of TS 23.502 [4]). It shall be set as follows: – true: MA-Confirmed MA PDU session was established – false: single access MA-Upgrade-Allowed MA PDU session was established that may be upgraded to an MA-Confirmed MA PDU session. |
M |
aTSSSContainer |
Identifies the steering, switching, and splitting features for the MA-Confirmed MA PDU session. Also indicates whether MPTCP or ATSSS-LL is to be used for ATSSS. See clause 9.11.4.22 of TS 24.501 [13]. |
C |
uEEPSPDNConnection |
This IE shall be present, if available, during an EPS to 5GS Idle mode mobility or handover using the N26 interface. If present, it shall contain the EPS bearer context(s) information present in the uEEPSPDNConnection parameter of the intercepted SmContextCreateData message (see TS 29.502 [16] clause 6.1.6.2.2). |
C |
ePS5GSComboInfo |
Provides detailed information about PDN Connections and PDU Sessions during EPS to 5GS idle mode mobility or handover using the N26 interface. Shall be included if the AMF has selected a SMF+PGW-C to serve the PDU session. This parameter shall include the additional IEs in Table 6.2.3-1A, if present. |
C |
handoverState |
Indicates whether the PDU Session Establishment being reported was due to a handover. Shall be present if this IE is in the SMContextCreatedData sent by the SMF (see TS 29.502 [16] clause 6.1.6.2.3). |
C |
pCCRules |
Set of PCC rules related to traffic influence. Each PCC rule influences the routing of a given traffic flow. If several flows are concerned, then several PCC rules shall be handled by the SMF. Traffic influence policies are orginated by an AF. PCF translates these rules into PCC rules for traffic influence. The payload of a PCC rule for traffic influence is defined in Table 6.2.3-1E. |
C |
uPPathChange |
Notification of the UPPathChange event, if available. This IE is defined in TS 29.508 [90], Table 5.6.2.5-1. |
C |
pFDDataForApp |
Represents the packet flow descriptions (PFDs) for an application identifier (AppId), if available. This IE is defined in TS 29.551 [96], Table 5.6.2.2-1. |
C |
ePSPDNConnectionModification |
Provides details about PDN Connections when the SMFMAPDUSessionModification xIRI message is used to report PDN Connection Establishment or Modification. See table 6.3.3-8 and clause 6.3.3.2.3. |
C |
6.2.3.2.7.4 MA PDU session release
The IRI-POI in the SMF shall generate an xIRI containing an SMFMAPDUSessionRelease record when the IRI-POI present in the SMF detects that an MA PDU session has been released. The IRI-POI present in the SMF shall generate the xIRI for the following events:
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION RELEASE COMPLETE from the UE and the 5GSM state within the SMF is changed to PDU SESSION INACTIVE (see TS 24.501 [13]). This applies to the following two cases for an MA PDU session that is either MA-Confirmed or MA-Upgrade-Allowed:
– UE initiated PDU session release.
– Network initiated PDU session release.
– For a roaming scenario, V-SMF in the VPLMN, the V-SMF receives the N1 NAS message (via AMF) PDU SESSION RELEASE COMPLETE from the UE and the 5GSM state within the V-SMF is changed to PDU SESSION INACTIVE (see TS 24.501 [13]). This applies to the following two cases for an MA PDU session that is either MA-confirmed or MA-Upgrade-Allowed:
– UE initiated PDU session release of a single access for an MA PDU session; (VPLMN considers MA PDU session fully released while HPLMN considers MA PDU session active).
– Network initiated PDU session release of a single access for an MA PDU session; (VPLMN considers MA PDU session fully released while HPLMN considers MA PDU session active).
– For a non-roaming scenario, the SMF (or for a roaming scenario, V-SMF in the VPLMN), receives the N1 NAS message (via AMF) PDU SESSION MODIFICATION COMMAND REJECT from the UE with the cause value #43 indicating an invalid PDU Session ID and the 5GSM state within the SMF is changed to PDU SESSION INACTIVE (see TS 24.501 [13]). This applies to the case for a PDU session that is either MA-Confirmed or MA-Upgrade-Allowed and where the UE rejects a PDU SESSION MODIFICATION COMMAND as it finds that the indicated PDU session ID is invalid. The 5GSM state is changed to PDU SESSION INACTIVE within the SMF.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION RELEASE COMMAND COMPLETE (see TS 29.502 [16]) from the V-SMF. This applies to the following three cases for an MA PDU session that is either MA-Confirmed or MA-Upgrade-Allowed:
– UE initiated PDU session release.
– Network (VPLMN) initiated PDU session release.
– Network (HPLMN) initiated PDU session release.
– For a home-routed roaming scenario, the SMF in the HPLMN (i.e. H-SMF) receives the N16: Nsmf_PDU_Session_Update response message with n1SmInfoFromUe IE containing the PDU SESSION MODIFICATION COMMAND REJECT (see TS 29.502 [16]) from the V-SMF with the cause value #43 indicating an Invalid PDU Session ID for an MA PDU session that is either MA-Confirmed or MA-Upgrade-Allowed.
Table 6.2.3-5D: Payload for SMFMAPDUSessionRelease record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session. |
M |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
pDUSessionID |
PDU Session ID as assigned by the AMF. |
M |
timeOfFirstPacket |
Time of first packet for the PDU session. |
C |
timeOfLastPacket |
Time of last packet for the PDU session. |
C |
uplinkVolume |
Number of uplink octets for the PDU session. |
C |
downlinkVolume |
Number of downlink octets for the PDU session. |
C |
location |
Location information, if available. |
C |
cause |
Indicates the NF Service Consumer cause for the requested PDU session release (see TS 29.502 [16] clause 6.1.6.3.8 for enumerated cause information). Include if known. |
C |
nGAPCause |
Indicates the NGAP cause for the requested SM context release (see TS 29.502 [16] clause 6.1.6.2.6). Shall be derived as described in TS 29.571 [17] clause 5.4.4.12. |
C |
fiveGMMCause |
Indicates the 5GMM cause for a PDU Session released due to any 5GMM failure (see 29.502 [16] clause 6.1.6.2.6). Shall be sent as an integer derived as described in TS 29.571 [17] clause 5.4.2. |
C |
pCCRulesIDs |
PCC rule IDs of the PCC rules related to traffic influence that are associated to the PDU session and active at the time the PDU session is released. |
C |
ePSPDNConnectionRelease |
Provides details about PDN Connections when the SMFMAPDUSessionRelease xIRI message is used to report PDN Connection Release. See table 6.3.3-13 and clause 6.3.3.2.4. |
C |
6.2.3.2.7.5 Start of interception with an established MA PDU session
The IRI-POI in the SMF shall generate an xIRI containing an SMFStartOfInterceptionWithEstablishedMAPDUSession record when the IRI-POI present in the SMF detects that a MA PDU session has already been established for the target UE when interception starts.
In a non-roaming scenario, the IRI-POI in the SMF (or in a roaming scenario, the IRI-POI in the V-SMF in the VPLMN) shall generate the xIRI containing the SMFStartOfInterceptionWithEstablishedMAPDUSession record when it detects that a new interception for a UE is activated (i.e. provisioned by the LIPF) for the following case for an MA PDU session that is either MA-Confirmed or MA-Upgrade-Allowed:
– The 5GSM state within the SMF for that UE is 5GSM: PDU SESSION ACTIVE or PDU SESSION MODIFICATION PENDING.
NOTE: The above trigger happens when the SMF (V-SMF in VPLMN) had not sent an N1 NAS message PDU SESSION RELEASE COMMAND to the UE to release the entire MA PDU session and the SMF (V-SMF in the VPLMN) had previously sent an N1 NAS message PDU SESSION ESTABLISHMENT ACCEPT to that UE for the same MA PDU session.
In a home-routed roaming scenario, the IRI-POI in the H-SMF shall generate the xIRI containing the SMFStartOfInterceptionWithEstablishedMAPDUSession record when it detects that a new interception for a UE is activated (i.e. provisioned by the LIPF) for the following case for an MA PDU session that is either MA-Confirmed or MA-Upgrade-Allowed:
– The H-SMF had not sent an Nsmf_PDU_Session_Update Request (n1SmInfoToUe: PDU SESSION RELEASE COMMAND to release the entire MA PDU session) to the V-SMF for a PDU session and H-SMF had previously sent an Nsmf_PDU_Session_Create response (n1SmInfoToUE: PDU SESSION ESTABLISHMENT ACCEPT) to the V-SMF for that PDU session.
The IRI-POI in the SMF shall generate the xIRI containing the SMFStartOfInterceptionWithEstablishedMAPDUSession record for each of the MA PDU sessions (that meets the above criteria) associated with the newly identified target UEs.
The IRI-POI present in the SMF generating an xIRI containing a SMFStartOfInterceptionWithEstablishedMAPDUSession record shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
Table 6.2.3-5E: Payload for SMFStartOfInterceptionWithEstablishedMAPDUSession record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions. |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI has not been authenticated, or “false” if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
pDUSessionID |
PDU Session ID as assigned by the AMF, as defined in TS 24.007 [14] clause 11.2.3.1b. |
M |
pDUSessionType |
Identifies selected PDU session type, see TS 24.501 [13] clause 9.11.4.11. |
M |
accessInfo |
Identifies the access(es) associated with the PDU session including the information for each specific access (see table 6.2.3-5B). |
M |
sNSSAI |
Slice identifier associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
uEEndpoint |
UE endpoint address(es) if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). MAC addresses are given as 6 octets with the most significant octet first (see TS 29.244 [15] clause 5.21). |
C |
location |
Location information provided by the AMF at session establishment or present in the context at the SMF, if available. |
C |
dNN |
Data Network Name associated with the target traffic, as defined in TS 23.003 [19] clause 9A and described in TS 23.502 [4] clause 4.3.2.2. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
M |
aMFID |
Identifier of the AMF associated with the target UE, as defined in TS 23.003 [19] clause 2.10.1, if available. |
C |
hSMFURI |
URI of the Nsmf_PDUSession service of the selected H-SMF, if available. See TS 29.502 [16] clause 6.1.6.2.2. |
C |
requestType |
Type of request as initially set within PDU SESSION ESTABLISHMENT as described in TS 24.501 [13] clause 9.11.3.47. If the initial value is no longer available the request type shall be set to “existing PDU session”. |
C |
sMPDUDNRequest |
Contents of the SM PDU DN request container, if available, as described in TS 24.501 [13] clause 9.11.4.15. |
C |
servingNetwork |
PLMN ID of the serving core network operator, and, for a Non-Public Network (NPN), the NID that together with the PLMN ID identifies the NPN. |
M |
oldPDUSessionID |
The old PDU Session ID received from the UE. See TS 23.502 [4] clauses 4.3.2.2.1 and 4.3.5.2 and TS 24.501 [13] clause 6.4.1.2. Include if known. |
C |
mAUpgradeIndication |
Indicates whether the PDU session is allowed to be upgraded to MA PDU session (see TS 23.502 [4] clause 4.22.3). Include if known. |
C |
ePSPDNCnxInfo |
Indicates if the PDU session may be moved to EPS during its lifetime (see TS 29.502 [16] clause 6.1.6.2.31). Include if known. |
C |
mAAcceptedIndication |
Indicates that a request to establish an MA PDU session was accepted or if a single access PDU session request was upgraded into an MA PDU session (see TS 23.502 [4] clauses 4.22.2 and 4.22.3). It shall be set as follows: – true: MA-Confirmed MA PDU session was established. – false: single access MA-Upgrade-Allowed MA PDU session was established that may be upgraded to an MA-Confirmed MA PDU session. |
M |
aTSSSContainer |
Identifies the steering, switching, and splitting features for the MA-Confirmed MA PDU session. Also indicates whether MPTCP or ATSSS-LL is to be used for ATSSS. See TS 24.501 [13] clause 9.11.4.22. |
C |
ePS5GSComboInfo |
Provides detailed information about PDN Connections and PDU Sessions during EPS to 5GS idle mode mobility or handover using the N26 interface. Shall be included when the AMF has selected a SMF+PGW-C to serve the PDU session. This parameter may include the additional IEs in table 6.2.3-1A, if available. |
C |
uEEPSPDNConnection |
This IE shall be present, if available, during an EPS to 5GS Idle mode mobility or handover using the N26 interface. If present, it shall contain the EPS bearer context(s) information present in the uEEPSPDNConnection parameter of the intercepted SmContextCreateData message. (see TS 29.502 [16] clause 6.1.6.2.2). |
C |
pCCRules |
Set of PCC rules related to traffic influence. Each PCC rule influences the routing of a given traffic flow. If several flows are concerned, then several PCC rules shall be handled by the SMF. Traffic influence policies are orginated by an AF. PCF translates these rules into PCC rules for traffic influence. The payload of a PCC rule for traffic influence is defined in Table 6.2.3-1E. |
C |
pFDDataForApps |
Represents a set of associations between application identifier and packet flow descriptions (PFDs), if available. |
C |
ePSStartOfInterceptionWithEstablishedPDNConnection |
Provides details about PDN Connections when the SMFStartOfInterceptionWithEstablishedMAPDUSession xIRI message is used to report the start of interception on a target who already has existing PDN Connections. See table 6.3.3-14 and clause 6.3.3.2.5. |
C |
6.2.3.2.7.6 SMF MA unsuccessful procedure
The IRI-POI in the SMF shall generate an xIRI containing an SMFMAUnsuccessfulProcedure record when the IRI-POI present in the SMF detects an unsuccessful procedure or error condition for a UE matching one of the target identifiers provided via LI_X1.
Accordingly, the IRI-POI in the SMF generates the xIRI when one of the following events are detected:
– SMF sends a PDU SESSION ESTABLISHMENT REJECT message to the target UE for MA-Confirmed and MA-Upgrade-Allowed MA PDU sessions.
– SMF sends a PDU SESSION MODIFICATION REJECT message to the target UE for MA-Confirmed and MA-Upgrade-Allowed MA PDU sessions.
– SMF sends a PDU SESSION RELEASE REJECT message to the target UE for MA-Confirmed and MA-Upgrade-Allowed MA PDU sessions.
– SMF receives a PDU SESSION MODIFICATION COMMAND REJECT message from the target UE for MA-Confirmed and MA-Upgrade-Allowed MA PDU sessions.
– An ongoing SM procedure is aborted at the SMF, due to e.g. a 5GSM STATUS message sent from or received by the SMF for MA-Confirmed and MA-Upgrade-Allowed MA PDU sessions.
Table 6.2.3-5F: Payload for SMFMAUnsuccessfulProcedure record
Field name |
Description |
M/C/O |
|
failedProcedureType |
Specifies the procedure which failed or is aborted at the SMF. |
M |
|
failureCause |
Provides the value of the 5GSM cause, see TS 24.501 [13], clause 9.11.4.2. In case the procedure is aborted due to a 5GSM STATUS message, the 5GSM cause is the one included in the 5GSM status message. |
M |
|
requestedSlice |
Slice requested for the procedure, if available, given as a NSSAI (a list of S-NSSAI values as described in TS 24.501 [13] clause 9.11.3.37). |
C |
|
initiator |
Specifies whether the network (SMF) or the UE is initiating the rejection or indicating the failure. |
M |
|
sUPI |
SUPI associated with the procedure, if available (see NOTE). |
C |
|
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to “true” if the SUPI has not been authenticated, or “false” if it has been authenticated. |
C |
|
pEI |
PEI used in the procedure, if available (see NOTE). |
C |
|
gPSI |
GPSI used in the procedure, if available (see NOTE). |
C |
|
pDUSessionID |
PDU Session ID, see TS 24.501 [13] clause 9.4, if available. |
C |
|
accessInfo |
Identifies the access(es) associated with the PDU session including the information for each specific access (see table 6.2.3-5B). |
M |
|
uEEndpoint |
UE endpoint address(es) if available. |
C |
|
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
|
dNN |
Data Network Name associated with the target traffic, as defined in TS 23.003 [19] clause 9A and described in TS 23.501 [2] clause 4.3.2.2, if available. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
|
aMFID |
Identifier of the AMF associated with the target UE, as defined in TS 23.003 [19] clause 2.10.1 when available. |
C |
|
hSMFURI |
URI of the Nsmf_PDUSession service of the selected H-SMF, if available. See TS 29.502 [16] clause 6.1.6.2.2. |
C |
|
requestType |
Type of request as described in TS 24.501 [13] clause 9.11.3.47, if available. Otherwise depending on the REJECT event the following request type shall be reported: PDU SESSION ESTABLISHMENT REJECT: The request type shall be set to the one reported within the PDU SESSION ESTABLISHMENT or if there hasn’t been one reported it should be set to "MA PDU request". PDU SESSION MODIFICATION REJECT: "modification request”. PDU SESSION RELEASE REJECT: no request type shall be set. PDU SESSION MODIFICATION COMMAND REJECT: "modification request”. |
C |
|
sMPDUDNRequest |
Contents of the SM PDU DN Request container, if available, as described in TS 24.501 [13] clause 9.11.4.15. |
C |
|
NOTE: At least one identity shall be provided, the others shall be provided if available. |
6.2.3.2.8 PDU to MA PDU session modification
The IRI-POI in the SMF shall generate an xIRI containing an SMFPDUtoMAPDUSessionModification record when the IRI-POI present in the SMF detects that an existing PDU session for the target UE has been successfully modified to an MA PDU session using the PDU session modification procedures as described in TS 24.501 [13]. A PDU session is considered to be successfully modified to a MA PDU session, when all of the following are true:
1. The UE is registered to both 3GPP access and non-3GPP access:
– In the same PLMN (non-roaming UE).
– In the different PLMNs (roaming UE).
2. SMF receives the PDU SESSION MODIFICATION REQUEST from the UE (TS 24.501 [13] clause 8.2.10) that includes one of the following:
– modification request and includes MA PDU session information IE set to MA PDU session network upgrade allowed.
– MA PDU request.
3. SMF sends a PDU SESSION MODIFICATION COMMAND to the UE that includes the ATSSS IE (TS 24.501 [13] clause 6.4.2.3).
4. SMF receives the PDU SESSION MODIFICATION COMPLETE from the UE (TS 24.501 [13] clause 8.3.10.1).
5. The 5GSM state within the SMF is PDU Session Active.
Once the SMFPDUtoMAPDUSessionModification record has been generated by the IRI-POI in the SMF, the IRI-POI shall follow clause 6.2.3.2.7 of the present document for further reporting for this MA PDU session.
Table 6.2.3-5G: Payload for SMFPDUtoMAPDUSessionModification record
Field name |
Description |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the AMF in the associated Nsmf_PDU_Session_CreateSMContext service operation). Shall be present except for PEI-only unauthenticated emergency sessions. |
C |
sUPIUnauthenticated |
Shall be present if a SUPI is present in the message and set to true if the SUPI was not authenticated, or false if it has been authenticated. |
C |
pEI |
PEI associated with the PDU session if available. |
C |
gPSI |
GPSI associated with the PDU session if available. |
C |
sNSSAI |
Slice identifier associated with the PDU session, if available. See TS 23.003 [19] clause 28.4.2 and TS 23.501 [2] clause 5.15.2. |
C |
non3GPPAccessEndpoint |
UE’s local IP address used to reach the N3IWF, TNGF or TWIF, if available. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
location |
Location information provided by the AMF or present in the context at the SMF, if available. |
C |
requestType |
In accordance with the request type as described in TS 24.501 [13] clause 6.4.2.2 and clause 9.11.3.47 a request type of “modification request” shall be reported. |
M |
accessType |
Access type associated with the session (i.e. 3GPP or non-3GPP access) if provided by the AMF (see TS 24.501 [13] clause 9.11.2.1A). |
C |
rATType |
RAT type associated with the access, if available. Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
pDUSessionID |
PDU Session ID, see TS 24.501 [13] clause 9.4. |
M |
requestIndication |
Indicates the request type for PDU session modification as indicated by the requestIndication sent in the PDU SESSION MODIFICATION REQUEST (see TS 29.502 [16] clause 6.1.6.3.6). |
M |
aTSSSContainer |
Identifies the steering, switching, and splitting features for the MA-Confirmed MA PDU session. Also indicates whether MPTCP or ATSSS-LL is to be used for ATSSS. See TS 24.501 [13] clause 9.11.4.22. |
M |
uEEndpoint |
UE IP address(es) assigned to the PDU Session if available (See TS 29.244 [15] clause 5.21). |
C |
servingNetwork |
Shall be present if this IE is in the SMContextUpdateData, HsmfUpdateData or message sent to the SMF or the PDU Session Context or SM Context at the SMF (see TS 29.502 [16] clauses 6.1.6.2.3, 6.1.6.2.11 and 6.1.6.2.39). |
C |
handoverState |
Indicates whether the PDU Session Modification being reported was due to a handover. Shall be present if this IE is in the SMContextUpdatedData or sent by the SMF (see TS 29.502 [16] clause 6.1.6.2.3). |
C |
gTPTunnelInfo |
Contains the information for the User Plane GTP Tunnels for the PDU Session (see TS 29.502 [16] clauses 6.1.6.2.2, 6.1.6.2.9 and 6.1.6.2.39). See table 6.2.3-1B. |
M |
ePSPDNConnectionModification |
Provides details about PDN Connections when the SMFPDUtoMAPDUSessionModification xIRI message is used to report PDN Connection Modification. See table 6.3.3-8 and clause 6.3.3.2.3. |
C |
6.2.3.3 Triggering of the CC-POI from CC-TF over LI_T3
6.2.3.3.1 LI_T3 interface specifics
When interception of communication contents is authorised or the delivery of packet header information is authorised and approach 2 described in clause 6.2.3.5 is used, the CC-TF present in the SMF sends a trigger to the CC-POI present in the UPF over the LI_T3 interface.
When the CC-TF in the SMF detects that a PDU session is being established for a target UE (i.e. when the SMF sends the N4: Session Establishment Request), it shall send an activation message to the CC-POI in the UPF over the LI_T3 interface. The activation message shall contain the correlation identifiers that the CC-POI in the UPF shall use with the xCC. This can be achieved by sending an ActivateTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.1 with the following details.
Table 6.2.3-6: ActivateTask message for triggering the CC-POI in the UPF
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
Allocated by the CC-TF as per ETSI TS 103 221-1 [7]. |
M |
TargetIdentifiers |
Packet detection criteria as determined by the CC-TF in the SMF, which enables the UPF to isolate target traffic. The CC-POI in the UPF shall support at least the identifier types given in table 6.2.3-7. NOTE: This value is the target identifier for the CC-POI in the UPF and may be different from the target identifier specified in the warrant. |
M |
DeliveryType |
Set to “X3Only”. |
M |
ListOfDIDs |
Delivery endpoints for LI_X3. These delivery endpoints shall be configured by the CC-TF in the SMF using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
CorrelationID |
Correlation ID to assign to X3 PDUs generated by the CC-POI in the UPF. This field is populated with the same CorrelationID the IRI-POI in the SMF uses for the associated xIRI. |
M |
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the CC-TF. This value shall be used by the CC-POI in the UPF to fill the XID of X3 PDUs. |
M |
The CC-TF in the SMF shall not send the ListOfServiceTypes parameter of the ActivateTask message to the CC-POI in the UPF.
Table 6.2.3-7: Target Identifier Types for LI_T3
Identifier type |
Owner |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
GTP Tunnel ID |
3GPP |
gtpuTunnelId |
F-TEID (see XSD schema) |
UE IP Address |
ETSI |
IPv4Address or IPv6Address |
See ETSI TS 103 221-1 [7] |
UE TCP/UDP Port |
ETSI |
TCPPort or UDPPort |
See ETSI TS 103 221-1 [7] |
PFCP Session ID |
3GPP |
TargetIdentifierExtension / FSEID |
F-SEID (see XSD schema) |
PDR ID |
3GPP |
TargetIdentifierExtension / PDRID |
32 bit unsigned integer (see XSD schema) |
QER ID |
3GPP |
TargetIdentifierExtension / QERID |
32 bit unsigned integer (see XSD schema) |
Network Instance |
3GPP |
TargetIdentifierExtension / NetworkInstance |
Octet string (see XSD schema) |
GTP Tunnel Direction |
3GPP |
TargetIdentifierExtension / GTPTunnelDirection |
Enumeration (see XSD schema) |
When the CC-TF in the SMF detects that a targeted PDU session is changing (i.e. when the SMF sends the N4 Session Modification Request to the UPF) in a way that requires changes to the interception already activated by the CC-POI in the UPF, the CC-TF shall modify the interception at the CC-POI in the UPF over the LI_T3 interface. This is achieved by sending a ModifyTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.2. The ModifyTask message contains the same details as the ActivateTask message with the following fields updated as appropriate.
Table 6.2.3-8: Parameters that may be changed in a ModifyTask message when updating interception at the CC-POI in the UPF
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
TargetIdentifiers |
Updated packet detection criteria as determined by the CC-TF in the SMF. NOTE: See notes on TargetIdentifiers in table 6.2.3-6. |
M |
When the CC-TF in the SMF detects that a targeted PDU session is changing (i.e. when the SMF sends the N4 Session Modification Request to the UPF) for which the interception had not been previously activated in the CC-POI in the UPF (e.g. in case of previous unsuccessful LI activation at the CC-POI in the UPF by the CC-TF in the SMF), the CC-TF shall send an activation message to the CC-POI in the UPF over the LI_T3 interface. The activation message shall contain the correlation identifiers that the CC-POI in the UPF shall use with the xCC. This can be achieved by sending an ActivateTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.1 with the details provided by Table 6.2.3-6.
When the CC-TF in the SMF detects that the PDU session has been released (i.e. when the SMF sends the N4: Session Release Request to the UPF) for a target UE, it shall send a deactivation message to the CC-POI in the UPF over the LI_T3 interface. When using ETSI TS 103 221-1 [7] this is achieved by sending a DeactivateTask message with the XID field set to the XID associated with the interception, as described in ETSI TS 103 221-1 [7] clause 6.2.3.
By default, interception shall occur at the anchor UPF as described in clause 6.2.3.3.3.
When a warrant that includes the service scoping of CC is activated for a target UE with an established PDU session and when the IRI-POI present in the SMF generates the xIRI containing an SMFStartOfInterceptionWithEstablishedPDUSession record (see clause 6.2.3.2.5), the CC-TF present in the SMF shall send an activation message to the CC-POI present in the UPF to generate the xCC.
6.2.3.3.2 CC interception with multi-homed PDU session
When a target UE accesses multiple Data Networks (DNs) via a multi-homed PDU session (see TS 23.501 [2] clause 5.6.4.3), multiple UPFs are involved in providing the PDU Session Anchors, with one UPF providing the Branching Point functionality. The Branching Point UPF may, or may not, be a PDU Session Anchor UPF (see TS 33.127 [5] Annex A3.2). The CC-TF present in the SMF shall send the CC intercept trigger to the CC-POI present in an UPF if and only if that UPF is selected to provide the CC-POI functions.
When the target UE is involved in multi-homed PDU session, the CC-TF present in the SMF (i.e. in the SMF that establishes the PDU session) shall determine which UPF(s) is(are) more suitable to provide the CC-POI functions adhering to the following requirements specified in TS 33.127 [5]:
– All applicable user plane packets are captured and delivered.
– Duplicate delivery of CC is suppressed to the extent possible.
This clause assumes that a PDU session contains only one Branching Point UPF (with N3 reference point toward the target UE) and one PDU Session Anchor UPF for each DN connection.
Since the present document requires the interception of all DN connections, the SMF may choose either all the PDU Session Anchor UPFs or the Branching Point UPF to provide the CC-POI functions.
The Branching Point UPF may be chosen when all user plane packets pass through the Branching Point UPF, and the CC-TF present in the SMF may choose the Branching Point UPF to provide the CC-POI function and accordingly, send the CC interception trigger to the CC-POI present in the Branching Point UPF. The CC intercept trigger shall include the packet detection rules. An example of these rules is:
– Generate the xCC from all the incoming and outgoing user plane packets to the target UE.
In this case, the CC-TF present in the SMF shall not select any of the PDU Session Anchor UPFs to provide the CC-POI functions.
When a Branching Point UPF is chosen to provide the CC-POI functions, and if the Branching Point UPF is removed from the user plane path during a PDU session, then the CC POI functions will have to be moved to the PDU Session Anchor UPFs.
The xCC delivered to the MDF3 shall be correlated to the PDU session related xIRI. The use of Correlation Id shall be on a user-plane path basis, which means that the xCC generated at different UPFs that belong to different PDU sessions may need to have separate Correlation IDs, each correlating to their own PDU session related xIRI.
6.2.3.3.3 CC Interception only at PDU Session Anchor UPFs
An option is to intercept a copy of the packets sent and received on the N6 interface [2] side of the PDU Anchor UPF (for each UL classifier in case of selective routing or Service and Session Continuity mode 3) for all DNs the subject is connected to. In the in-bound roaming case for home-routed roaming, the CSP shall deliver a copy of the packets sent and received on the N9 side of the PDU Anchor UPF towards the serving network.
6.2.3.4 IRI-POI in UPF triggering over LI_T2
When interception of packet header information is authorised, if approach 1 described in clause 6.2.3.9.1 is used for packet header information reporting, the IRI-TF in the SMF shall send a trigger to the IRI-POI in the UPF over the LI_T2 interface when the IRI-TF in the SMF detects that a PDU session has been established for a target UE. The activation message shall contain the correlation ID that the IRI-POI in the UPF shall use when generating xIRI. This shall be achieved by sending an ActivateTask message as defined in TS 103 221-1 [7] clause 6.2.1 with the following details.
Table 6.2.3-9: ActivateTask message for triggering the UPF IRI-POI
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
Allocated by the IRI-TF as per ETSI TS 103 221-1 [7]. |
M |
TargetIdentifiers |
Packet detection criteria as determined by the IRI-TF in the SMF, which enable the UPF IRI-POI to isolate target traffic. The IRI-POI in the UPF shall support at least the identifier types given in table 6.2.3-7. NOTE: This value is the target identifier for the IRI-POI in the UPF and may be different from the target identifier specified in the warrant. |
M |
DeliveryType |
Set to “X2Only”. |
M |
TaskDetailsExtensions/ HeaderReporting |
Header reporting-specific tag to be carried in the TaskDetailsExtensions field of ETSI TS 103 221-1 [7]. See table 6.2.3.9.2-1. |
M |
ListOfDIDs |
Delivery endpoints of LI_X2. These delivery endpoints shall be configured by the IRI-TF in the SMF using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
CorrelationID |
Correlation ID to assign for xIRI generated by the IRI-POI in the UPF. This field is populated with the same CorrelationID the IRI-POI in the SMF uses for the associated xIRI. |
M |
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the IRI-TF. This value shall be used by the IRI-POI in the UPF to fill the XID of X2 PDUs. |
M |
The IRI-TF in the SMF shall not send the ListOfServiceTypes parameter of the ActivateTask message to the IRI-POI in the SMF.
Table 6.2.3-10: Void
When the IRI-TF in the SMF detects that a targeted PDU session has changed in a way which requires changes to the interception by the IRI-POI in the UPF, the IRI-TF in the SMF shall modify the interception at the IRI-POI in the UPF over the LI_T2 interface. This is achieved by sending a ModifyTask message as defined in ETSI TS 103 221-1 [7] clause 6.2.2. The ModifyTask message contains the same details as the ActivateTask message with the following fields updated as appropriate.
Table 6.2.3-11: Parameters that may be changed in a ModifyTask message when updating interception at the IRI-POI in the UPF
Field name |
Description |
M/C/O |
TargetIdentifiers |
Updated packet detection criteria as determined by the IRI-TF in the SMF. NOTE: See notes on TargetIdentifiers in table 6.2.3-6. |
M |
When the IRI-TF in the SMF detects that the PDU session has been released for a target UE, it shall send a deactivation message to the IRI-POI in the UPF over the LI_T2 interface. When using ETSI TS 103 221-1 [7] this is achieved by sending a DeactivateTask message with the XID field set to the XID associated with the interception, as described in ETSI TS 103 221-1 [7] clause 6.2.3.
When a PDU session involves multiple UPFs, the selection of UPF to provide the IRI-POI functions shall be done in the same way an UPF is selected to provide the CC-POI functions as described in clauses 6.2.3.3.2 and 6.2.3.3.3.
When interception of packet header information is authorised for a target UE, if approach 1 described in clause 6.2.3.9.1 is used for packet header information reporting, the IRI-TF present in the SMF shall send an activation message to the IRI-POI present in the UPF when the IRI-POI present in the SMF generates the xIRI containing an SMFStartOfInterceptionWithEstablishedPDUSession record to generate the packet header information reporting related xIRIs from the user plane packets of that PDU session.
6.2.3.5 Generation of xIRI at UPF over LI_X2
6.2.3.5.1 Packet data header reporting
When packet header information reporting is authorised, packet header information reports are generated either by the IRI-POI in the UPF (if approach 1 from clause 7.12.2.3 of TS 33.127 [5] is used) or by the MDF2 (if approach 2 from clause 7.12.2.3 of TS 33.127 [5] is used). Depending on the requirements of the warrant, the packet header information reports can be in per-packet form, as Packet Data Header Reports (PDHRs), or in summary form, as Packet Data Header Summary Reports (PDSRs).
6.2.3.5.2 Fragmentation
If the IRI-POI in the UPF is placed on a link which fragmented the original IP packet (see IETF RFC 791[34] for basic fragmentation rules, and IETF RFC 815 [26] for more complex re-assembly rules), a situation may occur in which only the first fragment can be sensibly reported in a PDHR, while the subsequent fragments may be missing essential fields that are mandatory, which may cause simplistic implementations to mis-report them, or omit them altogether.
In this case, the IRI-POI in the UPF shall report the first fragment of a fragmented IP packet, including the port numbers when they are included within this first fragment, using the length of the fragment to determine if the port numbers are indeed encoded within this first fragment. The subsequent fragments are reported without port information. This technique relieves the IRI-POI in the UPF from having to reassemble the original IP packet (at line speed) at the cost of accuracy of the reported fields.
6.2.3.5.3 Packet Data Header Report (PDHR)
If the per-packet form of packet header information reporting, i.e. PDHR, is authorised, the PDHeaderReport xIRI shall be generated as described in clause 6.2.3.9.3.
6.2.3.5.4 Packet Data Summary Report (PDSR)
If the summary form of the packet header information reporting, i.e. PDSR, is authorised, the PDSummaryReport xIRI shall be generated as described in clause 6.2.3.9.4.
6.2.3.6 Generation of xCC at CC-POI in the UPF over LI_X3
The CC-POI present in the UPF shall send xCC over LI_X3 for each IP packet matching the criteria specified in the Triggering message (i.e. ActivateTask message) received over LI_T3 from the CC-TF in the SMF.
NOTE: Implementers are reminded of the completeness and non-duplication requirements (see TS 33.127 [5]).
Each X3 PDU shall contain the contents of the user plane packet given using the GTP-U, IP or Ethernet payload format.
The CC-POI present in the UPF shall set the payload format to indicate the appropriate payload type (5 for IPv4 Packet, 6 for IPv6 Packet, 7 for Ethernet frame or 12 for GTP-U Packet as described in ETSI TS 103 221-2 [8] clauses 5.4 and 5.4.13.
If handover of the entire GTP-U packet is required over LI_HI3 (see clause 6.2.3.8), then consideration shall be made of the correct choice of LI_X3 payload type to ensure that the MDF3 has the necessary CC information. Support for delivery of LI_X3 as payload type 12 (GTP-U packet) is mandatory.
The CC-POI present in the UPF may use the Additional XID Related Information attributes to facilitate efficient delivery of xCC, as specified in ETSI TS 103 221-2 [8] clause 5.3.22.
6.2.3.7 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the SMF or the IRI-POI in the UPF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the SMF event was observed (i.e. the timestamp field of the xIRI).
The IRI type parameter (see ETSI TS 102 232-1 [9] clause 5.2.10) shall be included and coded according to table 6.2.3-14.
Table 6.2.3-14: IRI type for IRI messages
Record type |
IRI Type |
SMFPDUSessionEstablishment |
BEGIN |
SMFPDUSessionRelease |
END |
SMFPDUSessionModification |
CONTINUE |
SMFStartOfInterceptionWithEstablishedPDUSession |
BEGIN |
SMFUnsuccessfulProcedure |
REPORT |
SMFMAPDUSessionEstablishment |
BEGIN |
SMFMAPDUSessionRelease |
END |
SMFMAPDUSessionModification |
CONTINUE |
SMFStartOfInterceptionWithEstablishedMAPDUSession |
BEGIN |
SMFMAUnsuccessfulProcedure |
REPORT |
SMFPDUtoMAPDUSessionModification |
CONTINUE |
PDHeaderReport |
REPORT |
PDSummaryReport |
REPORT |
IRI messages associated with the same PDU Session shall be assigned the same CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).
The threeGPP33128DefinedIRI field (see ETSI TS 102 232-7 [10] clause 15) shall be populated with the BER-encoded IRIPayload.
When an additional warrant is activated on a target UE and the LIPF uses the same XID for the additional warrant, the MDF2 shall be able to generate and deliver the IRI message containing the SMFStartOfInterceptionWithEstablishedPDUSession record and the SMFStartOfInterceptionWithEstablishedMAPDUSession record to the LEMF associated with the additional warrant without receiving a corresponding xIRI. The payload of the SMFStartOfInterceptionWithEstablishedPDUSession record is specified in table 6.2.3-4, while the payload of the SMFStartOfInterceptionWithEstablishedMAPDUSession record is specified in table 6.2.3-9. The MDF2 shall generate and deliver the IRI message containing the SMFStartOfInterceptionWithEstablishedPDUSession record for each of the established PDU sessions to the LEMF associated with the new warrant. The MDF2 shall generate and deliver the IRI message containing the SMFStartOfInterceptionWithEstablishedMAPDUSession record for each of the established MA PDU sessions to the LEMF associated with the new warrant.
If the MDF2 did not receive from the IRI-POI the value of timeOfSessionEstablishment parameter in a previous corresponding SMFStartOfInterceptionWithEstablishedPDUSession or SMFStartOfInterceptionWithEstablishedMAPDUSession xIRI for the same session, the MDF2, when generating the SMFStartOfInterceptionWithEstablishedPDUSession or the SMFStartOfInterceptionWithEstablishedMAPDUSession IRI shall include in that parameter the time provided in the timestamp previously received in the header of the related SMFPDUSessionEstablishment or SMFMAPDUSessionEstablishment xIRI.
When the delivery of packet header information is authorised and approach 2 described in clause 6.2.3.9.1 is used, the MDF2 shall generate the IRI message and send it over LI_HI2 without undue delay when xCC is received over LI_MDF from the MDF3. The MDF2 shall generate packet header information reporting as described in clause 6.2.3.5.
6.2.3.8 Generation of CC over LI_HI3
When the xCC is received over LI_X3, the MDF3 shall emit the CC over LI_HI3 without undue delay.
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time that the UPF observed the data (i.e. the timestamp field of the xCC). The LIID and CID fields shall correctly reflect the target identity and communication session to which the CC belongs.
The MDF3 shall populate the threeGPP33128DefinedCC field (see clause 5.5.3 of the present document) with a BER-encoded CCPayload structure containing either:
1. The uPFCCPDU field containing the GTP-U packet received over LI_X3. It shall only be used if the content of the GTP-U packet is an IPv4 or IPv6 packet.
2. The extendedUPFCCPDU field as described in table 6.2.3-15.
The MDF3 shall support delivery using either option.
Table 6.2.3-15: ExtendedUPFCCPDU structure
Field name |
Description |
M/C/O |
payload |
Payload of the GTP-U packet without GTP-U encapsulation. Content shall be supplied according to table 6.2.3-16. |
M |
qFI |
Shall be populated with the QoS Flow Identifier value from the GTP-U header extension (see TS 38.415 [41] clause 5.5.3.3) if present over LI_X3. |
C |
Table 6.2.3-16: UPFCCPDUPayload structure
Field name |
Description |
uPFIPCC |
Contains an IPv4 or IPv6 packet |
uPFEthernetCC |
Contains an Ethernet frame |
uPFUnstructuredCC |
Contains an unstructured packet |
6.2.3.9 Packet header information reporting
6.2.3.9.1 General
As described in TS 33.127 [5] clause 7.12.2, warrants that do not require the interception of communication contents but do require packet header information reporting will require access to the user plane packets. Packet header information reporting includes the following two IRI messages:
– Packet Data Header Reporting (PDHR) in the form of PDHeaderReport records.
– Packet Data Summary Reporting (PDSR) in the form of PDSummaryReport records.
TS 33.127 [5] clause 7.12.2 provides two approaches for the generation of such IRI messages.
In approach 1, the IRI-POI present in the UP Entityconstructs and delivers the packet header information reporting related xIRIs to the MDF2 as described in clause 6.2.3.4.
In approach 2, the CC-POI present in the UP Entity intercepts, constructs and delivers the xCC to the MDF3 as described in clause 6.2.3.6. The MDF3 forwards the xCC to the MDF2 over the LI_MDF interface and the MDF2 generates the IRI messages containing the packet header information reporting related records from the xCC.
In both approaches, the payload of the PDHeaderReport and PDSummaryReport records are as described in clauses 6.2.3.9.3, 6.2.3.9.4, tables 6.2.3.9.3-1 and 6.2.3.9.4-1. Note that in approach 2, the MDF2 generates these IRI messages containing PDHeaderReport and PDSummaryReport records without receiving the equivalent xIRI from an IRI-POI. The actions of the MDF2, the MDF3, the CC-TF in the CP Entity in 5GS and CUPS EPS, and the CC-POI in non-CUPS EPS are managed as part of the intercept data provisioned to them over the LI_X1 interface.
6.2.3.9.2 Provisioning details
Table 6.2.3.9.2-1 shows the details of the HeaderReporting TaskDetailsExtension used in the LI_X1 ActivateTask message used for provisioning LI functions when packet header information reporting is authorised.
Table 6.2.3.9.2-1: PDHRReportingExtensions parameters
Field name |
Description |
M/C/O |
pDHType |
This field shall be set to either: – "PDHR," for packet-by-packet reporting. – "PDSR," for summarized reporting. |
M |
pDSRParameters |
If pDHType is PDSR, this field shall be set. See table 6.2.3.9.2-2. |
C |
Table 6.2.3.9.2-2: PDSRParameters
Field name |
Description |
M/C/O |
pDSRTriggerType |
This field shall be set to at least one of the following triggers: a) timer expiry (along with a timer value and unit). b) packet count (along with a value for the number of packets detected before a summary is to be triggered). c) byte count (along with a value for the cumulative byte size reached across all packets belonging to the summary before said summary is to be triggered). Summary reports shall not be cumulative, i.e. each summary report shall describe only the packets contained in its respective range, and each new summary shall start its count (of whichever attribute from the numbered list above applies) from zero, i.e. the information in the (n+1)’th summary report starts immediately after the end of the n’th summary report. |
M |
useSessionTriggers |
If useSessionTriggers is present and set to true, the trigger described in the pDSRTriggerType parameter shall be applied at the session level instead of per-flow. |
C |
6.2.3.9.3 PDHeaderReport record
If the per-packet form of packet header information reporting, i.e. PDHR, is used, the LI function responsible for generating the xIRI extracts the information shown in table 6.2.3.9.3-1 from each packet.
Table 6.2.3.9.3-1: PDHeaderReport record
Field name |
Description |
M/C/O |
pDUSessionID |
The PDU Session ID value 255 shall be used by the sender; the receiver shall ignore the parameter (see NOTE). |
M |
sourceIPAddress |
Shall contain the source address of the packet from the 32-bit “Source Address” field in IPv4, as defined in IETF RFC 791 [34], or from the 128-bit “Source Address” field in IPv6, as defined in IETF RFC 2460 [27]. |
M |
sourcePort |
Shall contain the “Source Port” number that indicates an application or service running on top of the transport, if the “Protocol” IP field (see the nextLayerProtocol field below in this table) is one of: a) Transmission Control Protocol (TCP), IP “Protocol” field decimal “6”; see IETF RFC 793 [28]. b) User Datagram Protocol (UDP), IP “Protocol” field decimal “17”; see IETF RFC 768 [29]. c) Datagram Congestion Control Protocol (DCCP), IP “Protocol” field decimal “33”; see IETF RFC 4340 [30]. d) Stream Control Transmission Protocol (SCTP), IP “Protocol” field decimal “132”; see IETF RFC 4960 [31]. For further details on Layer four protocols, see IANA [32]. |
C |
destinationIPAddress |
Shall contain the destination address of the packet from the 32-bit “Destination Address” field in IPv4, as defined in IETF RFC 791 [34], or from the 128-bit “Destination Address” field, as defined in IETF RFC 2460 [27]. |
M |
destinationPort |
Shall contain the “Destination Port” number that indicates an application or service running on top of the transport, if the “Protocol” IP field (see the nextLayerProtocol field below in this table) is one of: e) Transmission Control Protocol (TCP), IP “Protocol” field decimal “6”; see IETF RFC 793 [28]. f) User Datagram Protocol (UDP), IP “Protocol” field decimal “17”; see IETF RFC 768 [29]. g) Datagram Congestion Control Protocol (DCCP), IP “Protocol” field decimal “33”; see IETF RFC 4340 [30]. h) Stream Control Transmission Protocol (SCTP), IP “Protocol” field decimal “132”; see IETF RFC 4960 [31]. For further details on Layer four protocols, see IANA [32]. |
C |
nextLayerProtocol |
Shall contain the contents of the IP “Protocol” field as defined in IETF RFC 791 [34] (bits 72…79 in the IP header), and is one of the assigned Internet protocol numbers defined in IANA [32]. |
M |
iPv6flowLabel |
If the IP addresses in the report are IPv6, this field shall contain the 20-bit IPv6 “Flow Label” as defined in: – IPv6 IETF RFC 2460 [27], and – IPV6 Flow Label Specification IETF RFC 6437 [33]. |
C |
direction |
Shall contain the direction of the intercepted packet, and it indicates either “from target” or “to target.” |
M |
packetSize |
Shall contain the value of the “Total Length” IP header field if IPv4 is used, as defined in IETF RFC 791 [34], or the value of the “Payload Length” field if IPv6 is used, as defined in IETF RFC 2460 [27]. |
M |
NOTE: This is a placeholder value used to fill the pDUSessionID field, given that the UPF does not receive the PDU Session ID used for the session by the SMF, so this information is not available at the UPF. The PDU Session ID can be retrieved by the LEMF from the IRIs generated by the IRI-POI at the SMF and delivered by the MDF2. |
6.2.3.9.4 PDSummaryReport record
If the summary form of the packet header reporting, i.e. PDSR, is used, the LI function responsible for generating the xIRI extracts the information shown in table 6.2.3.9.4-1 from each packet and aggregates it in summaries according to the pDSRType field defined in the PDHRReportingExtensions parameters of the ActivateTask message used to provision the LI function. In addition, the current summary is sent when the LI function responsible for generating the xIRI receives a DeactivateTask message for the Task that generated the PDSR regardless of whether the trigger in the pDSRType field of the ActivateTask message was met. In this case, the pDSRSummaryTrigger field of the PDSR record shall be set to endOfFlow.
A PDSR shall be generated each time a flow (Source IP, Source Port, Destination IP, Destination Port, Next Level Protocol, Direction) starts or ends.
If the useSessionTriggers flag (see table 6.2.3.9.2-2) is absent or set to false and the provisioned pDSRTriggerType is:
– Packet count, a PDSR shall be generated whenever the number of packets detected as a part of the flow reaches the provisioned trigger value.
– Byte count, a PDSR shall be generated whenever the value for the cumulative byte size across all packets belonging to the flow reaches the provisioned trigger value.
– Timer expiry, a separate timer should be used for each flow. A PDSR shall be generated for a flow whenever the timer for that flow expires.
If the useSessionTriggers flag (see table 6.2.3.9.2-2) is set to true and the provisioned pDSRTriggerType is:
– Packet count, a PDSR shall be generated for each open flow whenever the number of packets sent and received in the PDU Session/PDN Connection is reaches the provisioned trigger value.
– Byte count, a PDSR shall be generated for each open flow whenever the value for the cumulative byte size across all packets belonging to the PDU Session/PDN Connection is reaches the provisioned trigger value.
– Timer expiry, a single timer should be used for each PDU Session/PDN Connection. A PDSR shall be generated for each open flow whenever the timer expires.
Table 6.2.3.9.4-1: PDSummaryReport record
Field name |
Description |
M/C/O |
pDUSessionID |
The PDU Session ID value 255 shall be used; the receiver shall ignore the parameter (see NOTE). |
M |
sourceIPAddress |
Shall contain the source address of the packet from the 32-bit “Source Address” field in IPv4, as defined in IETF RFC 791 [34], or from the 128-bit “Source Address” field in IPv6, as defined in IETF RFC 2460 [27]. |
M |
sourcePort |
Shall contain the “Source Port” number that indicates an application or service running on top of the transport, if the “Protocol” IP field (see the nextLayerProtocol field below in this table) is one of: a) Transmission Control Protocol (TCP), IP “Protocol” field decimal “6”; see IETF RFC 793 [28]. b) User Datagram Protocol (UDP), IP “Protocol” field decimal “17”; see IETF RFC 768 [29]. c) Datagram Congestion Control Protocol (DCCP), IP “Protocol” field decimal “33”; see IETF RFC 4340 [30]. d) Stream Control Transmission Protocol (SCTP), IP “Protocol” field decimal “132”; Stream Control Transmission Protocol [31]. For further details on Layer four protocols, see IANA [32]. |
C |
destinationIPAddress |
Shall contain the destination address of the packet from the 32-bit “Destination Address” field in IPv4, as defined in IETF RFC 791 [34], or from the 128-bit “Destination Address” field, as defined in IETF RFC 2460 [27]. |
M |
destinationPort |
Shall contain the “Destination Port” number that indicates an application or service running on top of the transport, if the “Protocol” IP field (see the nextLayerProtocol field below in this table) is one of: a) Transmission Control Protocol (TCP), IP “Protocol” field decimal “6”; see IETF RFC 793 [28]. b) User Datagram Protocol (UDP), IP “Protocol” field decimal “17”; see IETF RFC 768 [29]. c) Datagram Congestion Control Protocol (DCCP), IP “Protocol” field decimal “33”; see IETF RFC 4340 [30]. d) Stream Control Transmission Protocol (SCTP), IP “Protocol” field decimal “132”; Stream Control Transmission Protocol [31]. For further details on Layer four protocols, see IANA [32]. |
C |
nextLayerProtocol |
Shall contain the contents of the IP “Protocol” field as defined in IETF RFC 791 [34] (bits 72..79 in the IP header), and is one of the assigned Internet protocol numbers defined in IANA [32]. |
M |
iPv6flowLabel |
If the IP addresses in the report are IPv6, this field shall contain the 20-bit IPv6 “Flow Label” as defined in IPv6 IETF RFC 2460 [27] and the IPV6 Flow Label Specification IETF RFC 6437 [33]. |
C |
direction |
Shall contain the direction of the intercepted packet, and it indicates either “from target” or “to target.” |
M |
pDSRSummaryTrigger |
Shall contain the trigger that caused the summary report to be generated, which is one of the following: a) timer expiry. b) packet count. c) byte count. d) start of a flow. e) end of a flow. |
M |
firstPacketTimestamp |
Shall contain the timestamp that represents the time that the IRI-POI in the UPF detected the first packet in the set represented by this summary. |
M |
lastPacketTimestamp |
Shall contain the timestamp that represents the time that the IRI-POI in the UPF detected the last packet in the set represented by this summary. |
M |
packetCount |
Shall contain the number of packets detected during the creation of this summary. |
M |
byteCount |
Shall contain the number of bytes summed across all packets that belong to this summary. For IPv4 it is the sum of the “Total Length” fields across all packets in the summary as defined in Internet Protocol IETF RFC 791 [34], while for IPv6 it is the sum of the “Payload Length” fields across all packets in the summary as defined in Internet Protocol, Version 6 (IPv6) Specification, IETF RFC 2460 [27]. |
M |
perSessionTrigger |
Shall be present and set to true if the trigger that caused the summary report to be generated was applied to the Session. If the trigger that caused the summary report to be generated was applied per flow, this parameter may be omitted but shall be set to false if present. |
C |
NOTE: This is a placeholder value used to fill the pDUSessionID field, given that the UPF does not receive the PDU Session ID used for the session by the SMF, so this information is not available at the UPF. The PDU Session ID can be retrieved by the LEMF from the IRIs generated by the IRI-POI at the SMF and delivered by the MDF2. |
6.2.3.10 Sharing LI state information over LI_ST
6.2.3.10.1 Overview
TFs in SMFs in SMF sets need to share LI state information to avoid losing track of the XIDs and CorrelationIDs used in the tasks activated in the POI in the UPF when the triggered task control is transferred from one TF to another.
POIs in SMFs in SMF sets need to share LI state information to avoid losing track of the CorrelationIDs and sequence numbers used in the generation of xIRI and xCC when the interception is moved to another POI in the same SMF set.
The LIPF may request, store or remove any LI state records at any moment. The LIPF may revoke the credentials of any LI function to use the LI_ST function via LI_X0.
6.2.3.10.2 Storing LI state
The TF in the SMF shall store the LI state (related to a task active in the UPF POI) in the LISSF whenever the parent SMF stores session state for the relevant PDU session in the UDSF and whenever the parent SMF sends session state for the relevant PDU session to another SMF.
The POI in the SMF shall store the LI state (related to a task active in the SMF POI) in the LISSF whenever the parent SMF stores session state for the relevant PDU session in the UDSF and whenever the parent SMF sends session state for the relevant PDU session to another SMF.
When storing state, the LI function in the SMF shall use the state storage procedure specified in clause 5.10.2. During this procedure, the LI function shall add the metadata shown in table 6.2.3.10.2-1 to the RecordMeta for the record.
Table 6.2.3.10.2-1: Additional metadata for the RecordMeta
Field Name |
Description |
M/C/O |
PDUSessionID |
Identifier for the PDU session related to task. |
M |
UDSFRecordID |
The recordID used by the parent SMF to store the associated SMF session information in the UDSF. |
M |
LIStateRecordType |
Identifier for the record type which can be "TFLIState" or "POILIState". |
M |
The TF shall store the following information as the first record block (see TS 29.598 [64] clause 6.1.3.3.3.2), encoded as XML following the XSD schema given in Annex H.
Table 6.2.3.10.2-2: TFLIState structure for storing TF state information in the LISSF
Field Name |
Description |
M/C/O |
PDUSessionID |
Identifier for the PDU session related to task. |
M |
XID |
XID of the task object associated with the interception at the TF in SMF. |
M |
CorrelationID |
Correlation ID to assign to interception product generated by the POI in the UPF. |
M |
TriggeredTasks |
Collection of information about tasks that the TF in SMF has activated in triggered POIs in UPF due to interception for this PDU session. As a list of TriggeredTask, see table 6.2.3.10.2-3 below. |
M |
Table 6.2.3.10.2-3: TriggeredTask
Field Name |
Description |
M/C/O |
XID |
XID of the task object associated with the interception at the triggered. |
M |
NEID |
NEID used in LI_T2/LI_T3 communication by the triggered POI in UPF. |
M |
The TF shall specify the XID in order to avoid removing the LI state related to the same ProductID but a different task in the UPF POI, for example if there is more than one PDU session.
The SMF POI shall store the information shown in table 6.2.3.10.2-4 as the first record block (see TS 29.598 [64] clause 6.1.3.3.3.2), encoded as XML following the XSD schema given in Annex H.
Table 6.2.3.10.2-4: POILIState structure for storing POI state information in the LISSF
Field Name |
Description |
M/C/O |
PDUSessionID |
Identifier for the PDU session related to task. |
M |
XID |
XID of the task object associated with the interception at the POI in SMF. |
M |
SequenceNumber |
Last sequence number used in the generation of xIRI/xCC. |
M |
CorrelationID |
Correlation ID to assign to interception product generated by the POI in the SMF. |
M |
6.2.3.10.3 Retrieving LI state
When the TF in an SMF in an SMF set is provisioned by the LIPF with a specific XID and access to an LISSF function, the TF shall use the LISSF to retrieve LI state information.
If the implementation of the SMF set does not ensure that active SM contexts are always present in some SMF of the SMF set, when a task previously provisioned by the LIPF in the TF is deactivated, the TF shall request the records associated to the XID (received from the LIPF) from the LISSF, by performing a search as described in clause 5.10.3, using the XID as a search criteria. If no records are found, the TF may assume that no previous interception has occurred and proceed accordingly.
When a TF detects that its parent SMF is retrieving state for a targetted PDU session from the UDSF, the TF shall request records associated with that PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the UDSFRecordID used by the SMF as a search criteria. When a TF detects that its parent SMF is receiving state for a targetted PDU session from another SMF, the TF shall request records associated with that PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the XID of the task related to the target of that PDU session. If no records are found, the TF may assume that no previous interception has occurred and proceed accordingly. Implementers should be aware that multiple records may be returned.
When an SMF POI detects that its parent SMF is retrieving state for a targetted PDU session from the UDSF, the POI shall request records associated with that PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the UDSFRecordID used by the SMF as a search criteria. When an SMF POI detects that its parent SMF is receiving state for a targetted PDU session from another SMF, the SMF POI shall request records associated with that target PDU session from the LISSF by performing a search as described in clause 5.10.3 and using the XID of the task related to the target of that PDU session. If no records are found, the SMF POI may assume that no previous interception has occurred and proceed accordingly.
6.2.3.10.4 Removing LI state
When a task is deactivated successfully in the UPF POI, the TF shall remove the LI state record from the LISSF as described in clause 5.10.4.
When a task is deactivated in the SMF POI, the POI shall remove the LI state record from the LISSF as described in clause 5.10.4.
6.2.4 LI at UDM for 5G
6.2.4.1 General description
In 5G packet core network, the UDM provides the unified data management for UE. The UDM shall have LI capabilities to generate the target UE’s service area registration related xIRI. See clause 7.2.2 for the details.
6.2.5 LI at SMSF
6.2.5.1 Provisioning over LI_X1
The IRI-POI present in the SMSF is provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The IRI-POI in the SMSF shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages:
– SUPIIMSI.
– SUPINAI.
– PEIIMEI.
– PEIIMEISV.
– GPSIMSISDN.
– GPSINAI.
If service scoping is to be performed at the IRI-POI in the SMSF, the IRI-POI in the SMSF shall support the following CSP service types (see clauses 4.4.2 and 5.2.4):
– Messaging.
If the IRI-POI in the SMSF receives an ActivateTask message and the ListOfServiceTypes parameter contains a ServiceType that is not supported, the IRI-POI in the SMSF shall reject the task with an appropriate error as described in ETSI TS 103 221-1 [7] clause 6.2.1.2.
Table 6.2.5-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI in the SMSF.
Table 6.2.5-1: ActivateTask message for the IRI-POI in the SMSF
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
XID assigned by LIPF. |
M |
TargetIdentifiers |
One of the target identifiers listed in the paragraph above. |
M |
DeliveryType |
Set to “X2Only”. |
M |
ListOfDIDs |
Delivery endpoints for LI_X2 for the IRI-POI in the SMSF. These delivery endpoints are configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
TaskDetailsExtensions/ SMSFExtensions |
This field shall be included if the delivery of the full TPDU is not authorised. See table 6.2.5-2. |
C |
ListOfServiceTypes |
Shall be included when the task should only intercept specific CSP service types as described in clause 5.2.4. This parameter is defined in ETSI TS 103 221-1 [7], clause 6.2.1.2, table 4. |
C |
Table 6.2.5-2: TruncateTPUserData Parameters
Field Name |
Description |
M/C/O |
TruncateTPUserData |
If included, the truncatedSMSTPDU field of the sMSTPDUData (as described in table 6.2.5-7) structure shall be used when applicable (see text below table). If absent, the sMSTPDU field of the sMSTPDUData structure shall be used. |
C |
If the TruncateTPUserData field of the LI_X1 ActivateTask message is included, the IRI-POI in the SMSF shall use the truncatedSMSTPDU field in xIRI generated at the IRI-POI in the SMSF for SMS-SUBMIT and SMS-DELIVER TPDUs, otherwise, the sMSTPDU field shall be used.
The MDF2 listed as the delivery endpoint for the LI_X2 generated by the IRI-POI in the SMSF shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. If SMS Content delivery is not authorized, the MDF2 shall be provisioned with the TruncateTPUserData included, otherwise it shall be be left absent.
Table 6.2.5-3 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
Table 6.2.5-3: ActivateTask message for MDF2
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
XID |
XID assigned by LIPF. |
M |
TargetIdentifiers |
One of the target identifiers listed in clause 6.2.5.1. |
M |
DeliveryType |
Set to “X2Only”. (Ignored by the MDF2). |
M |
ListOfDIDs |
Delivery endpoints for LI_HI2. These delivery endpoints are configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
ListOfMediationDetails |
Sequence of Mediation Details, see table 6.2.5-4. |
M |
TaskDetailsExtensions/ SMSFExtensions |
This field shall be included if the delivery of the full TPDU is not authorised. See table 6.2.5-2. |
C |
Table 6.2.5-4: Mediation Details for MDF2
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
LIID |
Lawful Interception ID associated with the task. |
M |
DeliveryType |
Set to "HI2Only". |
M |
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations specified in the ListOfDIDs field in the ActivateTask Message. |
C |
ServiceScoping |
Shall be included to Identify the service(s) and associated service-related delivery settings for this LIID. May include more than one instance of this parameter to allow for different combinations of sub-parameters associated with a single LIID. This parameter is defined in ETSI TS 103 221-1 [7] Annex C table C.2. |
C |
6.2.5.2 Generation of xIRI over LI_X2
The IRI-POI present in the SMSF shall send xIRI over LI_X2 for the event listed in TS 33.127 [5] clause 6.2.5.3, the details of which are described in the following clause.
6.2.5.3 SMS Message
The IRI-POI in the SMSF shall generate an xIRI containing an SMSMessage record for the following cases:
SMS-MO case:
– When a target UE originates an SMS message or when any UE originates an SMS message destined to a target non-local ID.
SMS-MT case:
– When an SMS message delivery to a target UE is attempted or when an SMS message delivery originated from a target non-local ID is attempted to any UE.
– When an SMS message is successfully delivered to a target UE or when an SMS message originated from a target non-local ID is successfully delivered to any UE.
The SMS-MT case can also apply to the scenario when a receipt of SMS delivery from the far end is delivered successfully to the target UE or when a receipt of SMS delivery from a target non-Local ID is successfully delivered to the originating UE.
The IRI-POI present in the SMSF shall generate the xIRI containing the SMSMessage record when it detects following events:
– The SMSF receives an SMCP message CP-DATA_RP-DATA [SMS-SUBMIT, SMS-COMMAND] (via AMF in Nsmsf_SMService_UplinkSMS message) from a target UE.
– The SMSF receives an SMCP message CP-DATA_RP-DATA [SMS-SUBMIT] (via AMF in Nsmsf_SMService_UplinkSMS message) from any UE with TP-DA field within the SMS-SUBMIT containing a target non-Local ID and SMSF returns the SMCP: CP-ACK to that originating UE.
– The SMSF receives an SMCP message CP-DATA_RP-DATA [SMS-COMMAND] (via AMF in Nsmsf_SMService_UplinkSMS message) from any UE with TP-DA field within the SMS-COMMAND containing a target non-Local ID and SMSF returns the SMCP: CP-ACK to that originating UE.
– The SMSF receives a TCAP message MAP MT-FORWARD-SHORT-MESSAGE Request [SMS-DELIVER, SMS-STATUS-REPORT] destined to a target UE.
– The SMSF receives a TCAP message MAP MT-FORWARD-SHORT-MESSAGE Request [SMS-DELIVER] destined to any UE with the TP-OA field within the SMS-DELIVER containing a target non-Local ID.
– The SMSF receives a TCAP message MAP MT-FORWARD-SHORT-MESSAGE Request [SMS-STATUS-REPORT] destined to any UE with the TP-RA field within the SMS-STATUS-REPORT containing a target non-Local ID.
The IRI-POI present in the SMSF shall generate the xIRI containing the SMSReport record when it detects following events:
– The SMSF sends a SMCP message CP-DATA_RP-ACK [SMS-SUBMIT-REPORT] (via AMF in Namf_ Communication_N1N2MessageTransfer message) in response to a previously intercepted CP-DATA_RP-DATA.
– The SMSF sends a SMCP message CP-DATA_RP-ERROR [SMS-SUBMIT-REPORT] (via AMF in Namf_ Communication_N1N2MessageTransfer message) in response to a previously intercepted CP-DATA_RP-DATA.
– The SMSF sends a TCAP message MAP MT-FORWARD-SHORT-MESSAGE Response [SMS-DELIVER-REPORT] in response to a previously intercepted MAP MT-FORWARD-SHORT-MESSAGE Request.
NOTE 1: In the above-mentioned descriptions, the requirements of target Non-Local ID do not apply when both originating and terminating users of an SMS message are served by the same CSP. The method used to identify a target non-Local ID is different from the method used to identify a local target ID.
If the IRI-POI is provisioned with the TruncateTPUserData parameter included and the IRI-POI is generating xIRI for the SMS-SUBMIT type (TS 23.040 [18] clause 9.2.2.2) or SMS-DELIVER type (TS 23.040 [18] clause 9.2.2.1) TPDUs, the IRI-POI shall use the truncatedSMSTPDU (as described in table 6.2.5-7), otherwise, the IRI-POI shall use the sMSTPDU.
Table 6.2.5-5: Payload for SMSMessage record
Field name |
Description |
M/C/O |
originatingSMSParty |
Identity of the originating SMS party. See NOTE 2. |
M |
terminatingSMSParty |
Identity of the terminating SMS party. See NOTE 3. |
M |
direction |
Direction of the SMS with respect to the target. See NOTE 4. |
M |
linkTransferStatus |
Indicates whether the SMSF sent the TPDU to the next network element. See NOTE 5. |
M |
otherMessage |
In the event of a server-initiated transfer, indicates whether the server will send another SMS. May be omitted if the transfer is target-initiated. See NOTE 6. |
C |
location |
Location information associated with the target sending or receiving the SMS, if available and authorised. See NOTE 7. Encoded as a userLocation parameter (location>locationInfo>userLocation), see Annex A. |
C |
peerNFAddress |
Address of the other network function (SMS-GMSC/IWMSC/SMS-Router) involved in the communication of the SMS, if available. |
C |
peerNFType |
Type of the other network function (SMS-GMSC/IWMSC/SMS-Router) involved in the communication of the SMS, if available. |
C |
sMSTPDUData |
See table 6.2.5-7. This is conditional only for backwards compatibility. |
C |
messageType |
See table 6.2.5-8. This is conditional only for backwards compatibility. |
C |
rPMessageReference |
The SM-RL Message Reference of the message per TS 24.011 [46] clause 7.3. This is conditional only for backwards compatibility. |
C |
The sMSTPDU field shall always be used for the sMSTPDUData field of the SMSReport record.
Table 6.2.5-6: Payload for SMSReport record
Field name |
Description |
M/C/O |
location |
Location information associated with the target sending or receiving the SMS, if available and authorised. See NOTE 7. |
C |
sMSTPDUData |
SMS TPDU, encoded as per TS 23.040 [18] clause 9. |
M |
messageType |
See table 6.2.5-8. |
M |
rPMessageReference |
The SM-RL Message Reference of the message per TS 24.011 [46] clause 7.3. |
M |
Table 6.2.5-7: SMSTPDUData field
Field name |
Description |
sMSTPDU |
SM-TL PDU encoded per the PDUs defined in TS 23.040 [18] clause 9.2.2. Shall be chosen if the TruncateTPUserData Parameter is absent. |
truncatedSMSTPDU |
SM-TL PDU encoded per the PDUs defined in TS 23.040 [18] clause 9.2.2 but truncated to remove TP-User-Data (TS 23.040 [18] clause 9.2.3.24). Shall be chosen if the TruncateTPUserData Parameter is set. |
Table 6.2.5-8: SMSMessageType values
messageType value |
RP MTI Value |
RP Message Type |
TP-MTI Value |
SMS TPDU Message Type |
deliver |
001 |
RP-DATA (network🡪UE) |
00 |
SMS-DELIVER |
deliverReportAck |
010 |
RP-ACK (UE🡪network) |
00 |
SMS-DELIVER-REPORT |
deliverReportError |
100 |
RP-ERROR (UE🡪network) |
00 |
SMS-DELIVER-REPORT |
statusReport |
001 |
RP-DATA (network🡪UE) |
10 |
SMS-STATUS-REPORT |
command |
000 |
RP-DATA (UE🡪network) |
10 |
SMS-COMMAND |
submit |
000 |
RP-DATA (UE🡪network) |
01 |
SMS-SUBMIT |
submitReportAck |
011 |
RP-ACK (network🡪UE) |
01 |
SMS-SUBMIT-REPORT |
submitReportError |
101 |
RP-ERROR (network🡪UE) |
01 |
SMS-SUBMIT-REPORT |
reserved |
Reserved |
11 |
Reserved |
The IRI-POI in the SMSF shall populate the messageType field with the values listed in table 6.2.5-8 based on the SMS TPDU message type (see TS 23.040 [18] clause 9.2.2) and the RP Message Type (see TS 24.011 [46] clause 8.2.2) that triggered the generation of the xIRI. The SMS TPDU Message Type is indicated by the value of the TP-Message Type Indicator (TP-MTI) (see TS 23.040 [18] clause 9.2.3.1) as described in TS 23.040 [18] clause 9.2.3.1. The RP Message Type is indicated by the value of the RP MTI (See TS 24.011 [46] clause 8.2.2).
NOTE 2: For the SMS-MO case, the originating party is the address of the UE from which the SMSF receives the CP-DATA_RP-DATA [SMS-SUBMIT, SMS-COMMAND] message (via AMF in the Nsmsf_SMService_UplinkSMS). The GPSI is one of the data fields used in the Nsmsf related messages (see TS 29.540 [21]). Alternatively, the SMSF may find the originating party address in the same way it finds the address when generating charging records. For SMS-MT case, this is derived from TP-OA field (TS 23.040 [18]) for SMS-DELIVER TPDUs or the TP-RA field (TS 23.040 [18]) for SMS-STATUS-REPORT TPDUs. In cases where the originatingSMSParty is not a GPSI, PEI, or SUPI, the sMSAddress parameter is populated with the octets received in the field used to derive the address (as per TS 23.040 [18] clause 9.1.2.5).
NOTE 3: For SMS-MT case, the terminating party is the address of the UE to which the SMSF sends the CP-DATA_RP-DATA [SMS-DELIVER, SMS-STATUS-REPORT] message (via AMF in Namf_Communications_N1N2MessageTransfer). The GPSI is one of the data fields used in the Namf related messages (TS 29.518 [22]). Alternatively, the SMSF may find the terminating party address in the same way it finds the address when generating charging records. For SMS-MO case, this is derived from the TP-DA field (TS 23.040 [18]). In cases where the terminatingSMSParty is not a GPSI, PEI, or SUPI, the sMSAddress parameter is populated with the octets received in the field used to derive the address (as per TS 23.040 [18] clause 9.1.2.5).
NOTE 4: For the SMS-MO case, for SMS originated from the target UE, the value fromTarget is used and for SMS destined to target Non-local ID, the toTarget is used. For SMS-MT case, for SMS terminated to the target UE, the value toTarget is used and for SMS originated from a target Non-local ID, the fromTarget is used.
NOTE 5: This field is set to transferSucceeded or transferFailed as follows:
– SMS-MO case:
– To transferSucceeded: when the IRI-POI in the SMSF detects that SMSF sends the MO-FORWARD-SHORT-MESSAGE-Request [SMS-SUBMIT] message to the SMS-IWMSC.
– To transferFailed: when the IRI-POI in SMSF detects the scenarios where SMSF cannot send the MO-FORWARD-SHORT-MESSAGE-Request [SMS-SUBMIT] to the SMS-IWMSC, but still generates an xIRI containing the SMSMessage record.
– SMS-MT case:
– To transferSucceeded: when the IRI-POI in the SMSF detects that SMSF sends the MT-FORWARD-SHORT-MESSAGE-Response [SMS-DELIVER-REPORT] message to the SMS-GMSC.
– To transferFailed: when the IRI-POI in SMSF detects the scenarios where SMSF cannot send the MT-FORWARD-SHORT-MESSAGE-Response [SMS-DELIVER-REPORT] to the SMS-GMSC, but an xIRI containing the SMSMessage record is still generated.
NOTE 6: This is only applicable to the SMS-MT case and can be derived from the TP-MMS (More Message to Send) field present in the SMS-DELIVER sent to the UE (via AMF in the Namf_Communications_N1N2MessageTransfer).
NOTE 7: This is derived from the ueLocation field of SmsRecord IE received from the AMF in the Nsmsf_SMService_UplinkSMS message (TS 29.540 [21]). For the SMSMessage record, the SMCP message is CP-DATA_RP-DATA [SMS-SUBMIT, SMS-COMMAND] and for the SMSReport record, the SMCP message is CP-DATA-RP-ACK [SMS-DELIVER-REPORT]. This value is encoded as a userLocation parameter (location>locationInfo>userLocation), see Annex A.
6.2.5.4 Generation of IRI over LI_HI2
When an xIRI containing the SMSMessage record is received over LI_X2 from the IRI-POI in SMSF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the SMSMessage record received over LI_X2. The SMSMessage record may be enriched by other information available at the MDF (e.g. additional location information).
If the MDF2 is provisioned with the TruncateTPUserData parameter included, the truncatedSMSTPDU field shall be used in SMSMessage IRI message, otherwise, the sMSTPDU field shall be used.
The threeGPP33128DefinedIRI field (see ETSI TS 102 232-7 [10] clause 15) shall be populated with the BER-encoded IRIPayload.
The timestamp field of the PSHeader structure shall be set to the time that the SMSF event was observed (i.e. the timestamp field of the xIRI).
Each SMSMessage record shall be delivered as an IRI REPORT (see ETSI TS 102 232-1 [9] clause 5.2.10) with a new CIN assigned (see ETSI TS 102 232-1 [9] clause 5.2.4).
Each SMSReport record shall be delivered as a separate IRI REPORT (see ETSI TS 102 232-1 [9] clause 5.2.10) with the same CIN as the IRI REPORT of the associated SMSMessage record.
6.2.6 LI support at NRF
The SIRF present within the NRF provides SBA-related information to the LIPF over the LI_SI interface. Details for this interface are not considered in the present document and are for further study.