6.3 4G
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
6.3.1 General
The present document allows three options for EPC LI stage 3 interfaces for 4G / LTE:
– Option A: Use LI_X1, LI_X2 and LI_X3 interfaces specified below in clauses 6.3.2 and 6.3.3 for the events listed in TS 33.127 [5] clauses 6.3.2.3 and 6.3.3.3, and the events related to SMS over NAS as specified in TS 33.107 [36] clause 18.2.4.
– Option B: Use LI_X1, LI_X2 and LI_X3 interfaces as specified in clause 6.3.2 and 6.3.3 for the events listed in TS 33.107 [36] clause 12.2.1.2 and for the events related to the MMEIdentifierAssociation record described in clause 6.3.2.2.2.
– Option C: Use TS 33.107 [36] clause 12 natively as defined in that document.
For implementations that include EPS/5GS interworking, Option A shall be used.
In all cases, the present document specifies the stage 3 for the LI_HI1, LI_HI2 and LI_HI3 interfaces.
6.3.2 LI at MME
6.3.2.1 Provisioning over LI_X1
The IRI-POI present in the MME is provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The POI in the MME shall support the following target identifier formats:
– IMSI (using the IMSI target identifier format from ETSI TS 103 221-1 [7]).
– MSISDN (using the E164Number target identifier format from ETSI TS 103 221-1 [7]).
– ME Identity (using the IMEI target identifier format from ETSI TS 103 221-1 [7]).
Table 6.3.2-0A shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI in the MME.
Table 6.3.2-0A: ActivateTask message for the IRI-POI in the MME
|
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 MME. 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 MMEIdentifierAssociation records (see clause 6.3.2.2.1). If the field is absent, MMEIdentifierAssociation records shall not be generated. |
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.3.2-0B: IdentifierAssociationExtensions Parameters
|
Field Name |
Description |
M/C/O |
|
EventsGenerated |
One of the following values: – IdentifierAssociation – All See clause 6.3.2.2.1 for the interpretation of this field. |
M |
6.3.2.2 Generation of xIRI over LI_X2
6.3.2.2.1 General
If the MME receives one or more cell IDs in an S1 message (as specified in TS 36.413 [38]), the POI associated with the MME shall report all of them.
The IRI-POI in the MME shall only generate xIRI containing the MMEIdentifierAssociation record in the following scenarios:
– IdentifierAssociation: MMEIdentifierAssociation and Tracking Area/EPS Location Update (see TS 33.107 [36] clause 12.2.1.2) records shall be generated. No other record types shall be generated for that target.
– All: All MME record types shall be generated.
When Option A specified in clause 6.3.1 is used:
– The IRI-POI present in the MME shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 6.3.2.3, the details of which are described in the following clauses.
– In addition to the xIRI events listed in TS 33.127 [5] clause 6.3.2.3, the MME shall support xIRI generation in case of SMS over NAS as specified in TS 33.107 [36] clause 18.2.4. For records related to SMS over NAS in EPS:
– The IRI-POI present in the MME shall set the payload format to EpsHI2Operations.EpsIRIContent (value 14), see clause 5.3 and ETSI TS 103 221-2 [8] clause 5.4. The payload field shall contain an EpsHI2Operations.EpsIRIContent structure encoded according to TS 33.108 [12] clauses 10.5, 15.2 and B.9.
– As the LIID may be not available at the MME but is mandatory in EpsHI2Operations.EpsIRIContent according to TS 33.108 [12] Annex B.9, its value in the lawfulInterceptionIdentifier field of the encoded PDU shall be set to the fixed string "LIIDNotPresent".
When Option B specified in clause 6.3.1 is used:
– The IRI-POI present in the MME shall send the xIRIs over LI_X2 for each of the events listed in TS 33.107 [36] clause 12.2.1.1, the details of which are specified in clause 12.2.3 of the same TS, and in case of SMS over NAS as specified in TS 33.107 [36] clause 18.2.4.
– For all records except MMEIdentifierAssociation (see clause 6.3.2.2.2), the IRI-POI present in the MME shall set the payload format to EpsHI2Operations.EpsIRIContent (value 14), see clause 5.3 and ETSI TS 103 221-2 [8] clause 5.4. The payload field shall contain an EpsHI2Operations.EpsIRIContent structure encoded according to TS 33.108 [12] clauses 10.5, 15.2 and B.9.
– As the LIID may be not available at the MME but is mandatory in EpsHI2Operations.EpsIRIContent according to TS 33.108 [12] Annex B.9, its value in the lawfulInterceptionIdentifier field of the encoded PDU shall be set to the fixed string "LIIDNotPresent".
– In addition to the xIRI events listed in TS 33.107 [36], the MME shall support xIRI containing the MMEIdentiferAssociation record in clause 6.3.2.2.2.
6.3.2.2.2 MME identifier association
The IRI-POI present in the MME shall generate an xIRI containing an MMEIdentifierAssociation record when the IRI-POI present in the MME 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.3.2.2.1).
Table 6.3.2-1: Payload for MMEIdentifierAssociation record
|
Field name |
Description |
M/C/O |
|
|
iMSI |
IMSI associated with the procedure. (see NOTE 1). |
M |
|
|
iMEI |
IMEI used in the procedure, if available (see NOTE 1). |
C |
|
|
mSISDN |
MSISDN used in the procedure, if available (see NOTE 1). |
C |
|
|
gUTI |
LTE GUTI used in the procedure. |
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 |
|
|
tAIList |
List of tracking areas associated with the registration area within which the UE is current registered. (see NOTE 2). |
C |
|
|
NOTE 1: IMSI shall always be provided, in addition to the warrant target identifier if different to IMSI. 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 MME generating an xIRI containing an MMEIdentifierAssociation 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).
When transmitting the xIRI, the IRI-POI present in the MME shall set the payload format to 2, and provide the payload as a BER-encoded TS33128Payloads.XIRIPayloads structure.
6.3.2.2.3 Attach
The IRI-POI in the MME shall generate an xIRI containing an MMEAttach record when the IRI-POI present in the MME detects that a UE matching one of the target identifiers provided via LI_X1 has successfully attached to EPS. Accordingly, the IRI-POI in the MME generates the xIRI when the following event is detected:
– MME sends an S1: ATTACH ACCEPT message to the target UE and the UE EPS Mobility Management (EMM) state within the MME is changed to EMM-REGISTERED.
Table 6.3.2-2: Payload for MMEAttach record
|
Field name |
Description |
M/C/O |
|
attachType |
Specifies the type of EPS Attach, see TS 24.301 [51] clause 9.9.3.11. This is derived from the information received from the UE in the Attach Request message. |
M |
|
attachResult |
Specifies the result of the attach procedure, see TS 24.301 [51] clause 9.9.3.10. |
M |
|
iMSI |
IMSI associated with the registration. |
M |
|
iMEI |
IMEI associated with the registration, if available. |
C |
|
mSISDN |
mSISDN associated with the registration, if available. |
C |
|
gUTI |
GUTI provided as outcome of initial attach or used in other cases, see TS 24.301 [51] clause 5.5.1.2.4. |
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 |
|
ePSTAIList |
List of tracking areas associated with the registration area within which the UE is currently registered, see TS 24.301 [51] clause 9.9.3.33. (see NOTE) |
C |
|
sMSServiceStatus |
Indicates the availability of SMS Services. Shall be provided if present in the ATTACH ACCEPT. |
C |
|
oldGUTI |
Old GUTI used in the registration, if available. |
C |
|
eMM5GRegStatus |
UE Status, if provided in the REGISTRATION REQUEST message, see TS 24.501 [13] clause 9.11.3.56. |
C |
|
NOTE: List shall be included each time there is a change to the registration area. |
||
6.3.2.2.4 Detach
The IRI-POI in the MME shall generate an xIRI containing an MMEDetach record when the IRI-POI present in the MME detects that a UE matching one of the target identifiers provided via LI_X1 has deregistered from the EPS. Accordingly, the IRI-POI in the MME generates the xIRI when any of the following events is detected:
– For network initiated de-registration, when the MME receives the S1: DETACH ACCEPT message from the target UE, when the MME receives an S3: DETACH NOTIFICATION about the target UE from the SGSN or when implicit deregistration timer expires; and in all cases the UE EMM state within the MME is changed to EMM-DEREGISTERED.
– For UE initiated de-registration, when the MME sends the S1: DETACH ACCEPT message to the target UE or when the MME receives the S1: DETACH REQUEST message from the target UE with deregistration type value of “switch off”; and in both cases the UE EMM state within the MME is changed to EMM-DEREGISTERED.
Table 6.3.2-3: Payload for MMEDetach record
|
Field name |
Description |
M/C/O |
|
deregistrationDirection |
Indicates whether the deregistration was initiated by the network or by the UE. |
M |
|
detachType |
Indicates the type of detach as determined by the direction of the detach request and the value of the DetachType information element, see table 6.3.2-4. |
M |
|
iMSI |
IMSI associated with the detach. |
M |
|
iMEI |
IMEI associated with the detach, if available. |
C |
|
mSISDN |
mSISDN associated with the detach, if available. |
C |
|
gUTI |
GUTI associated with the detach, if available. |
C |
|
cause |
Indicates the EMM cause value for network-initiated detach, see TS 24.301 [51] clause 9.9.3.9. |
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 |
If Bit 4 of the Detach type information element sent in the Detach Request is set to 0, this parameter shall be set to “normalDetach”. If Bit 4 of the Detach type information element sent in the Detach Request is set to 1, this parameter shall be set to “switchOff”. See TS 24.301 [51] clause 9.9.3.7. This parameter is conditional only for backwards compatibility. |
C |
Table 6.3.2-4: detachType values
|
Type of detach value |
Direction |
detachType value |
|
001 |
UE🡪network |
ePSDetach |
|
010 |
UE🡪network |
iMSIDetach |
|
011 |
UE🡪network |
combinedEPSIMSIDetach |
|
110 |
UE🡪network |
reserved |
|
111 |
UE🡪network |
reserved |
|
Any Other |
UE🡪network |
combinedEPSIMSIDetach |
|
001 |
network🡪UE |
reAttachRequired |
|
010 |
network🡪UE |
reAttachNotRequired |
|
011 |
network🡪UE |
iMSIDetach |
|
110 |
network🡪UE |
reserved |
|
111 |
network🡪UE |
reserved |
|
Any Other |
network🡪UE |
reAttachNotRequired |
The IRI-POI in the MME shall populate the ePSDetachType field with the values listed in table 6.3.2-4 based on the Detach Type sent in the Detach Request message (see TS 24.301 [51] clause 9.9.3.7) and the direction of the Detach Request associated to the event that triggered the generation of the xIRI.
If the Detach Request message associated to the event that triggered the generation of the xIRI has the EMM Cause field populated, the IRI-POI in the MME shall set the value of the cause field of the MMEDetach record to the integer value of the EMM Cause, see TS 24.301 [51] clause 9.9.3.9.
6.3.2.2.5 Tracking Area/EPS Location update
When the reporting of location information is authorised, the IRI-POI in the MME shall generate an xIRI containing an MMELocationUpdate record each time the IRI-POI present in an MME detects that the target UE location is updated due to target UE mobility or as a part of an MME service procedure. 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.
In addition to the Tracking Area Update described in TS 23.401 [50], clause 5.3.3, the UE mobility events resulting in generation of an MMELocationUpdate xIRI include the S1 Path Switch Request (intra E-UTRAN handover X2 based handover procedure described in TS 23.401 [50] clause 5.5.1.1) and the S1 Handover Notify (Intra E-UTRAN S1 based handover procedure described in TS 23.401 [50] clause 5.5.1.2).
The MMELocationUpdate xIRI is also generated when the MME receives an E-UTRAN S1AP ERAB Modification Indication message as a result of Dual Connectivity activation/release for the target UE, as described in TS 37.340 [37] clause 10.
Based on regulatory requirements and operator policy, the location information obtained by the MME from E-UTRAN or the E-SMLC in the course of some service operations may result in the generation of the MMELocationUpdate xIRI record. Additionally, the IRI-POI in the MME shall capture the location information in the scenarios described in TS 23.271 [52] clause 4.4.2. Also, in the case of Mobile Originated LCS service invoked by the target, the location information may be derived from the Location Service Response sent to the target UE via the MME (see TS 23.271 [52] clause 9.2.6).
Optionally, based on regulatory and operator policy, other MME messages that do not generate separate xIRI but carry location information such as emergency services or LCS may trigger the generation of an MMELocationUpdate xIRI record.
Table 6.3.2-5: Payload for MMELocationUpdate record
|
Field name |
Description |
M/C/O |
|
iMSI |
iMSI associated with the location update. |
M |
|
iMEI |
iMEI associated with the location update, if available. |
C |
|
mSISDN |
mSISDN associated with the location update, if available as part of the subscription profile. |
C |
|
gUTI |
GUTI assigned during the location update, if available, see TS 24.301 [50]. |
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). |
M |
|
oldGUTI |
GUTI used to initiate the location update, if available, see TS 24.301 [50]. |
C |
|
sMSServiceStatus |
Indicates the availability of SMS Services. Shall be provided if present in the TRACKING AREA UPDATE ACCEPT. |
C |
6.3.2.2.6 Start of interception with EPS attached UE
The IRI-POI in the MME shall generate an xIRI containing an MMEStartOfInterceptionWithEPSAttachedUE record when the IRI-POI present in the MME detects that interception is activated on a UE that has already attached to the EPS. A UE is considered already attached to the EPS when the EMM state for that UE is EMM-REGISTERED. Therefore, the IRI-POI present in the MME shall generate the xIRI MMEStartOfInterceptionWithEPSAttachedUE record when it detects that a new interception for a UE is activated (i.e. provisioned by the LIPF) and the EPS mobility management state within the MME for that UE is EMM-REGISTERED.
Table 6.3.2-6: Payload for MMEStartOfInterceptionWithEPSAttachedUE record
|
Field name |
Description |
M/C/O |
|
attachType |
Specifies the type of EPS Attach, see TS 24.301 [51] clause 9.9.3.11. This is derived from the information stored in the UE Context at the MME, see TS 23.401 [50] clause 5.7.2. |
M |
|
attachResult |
Specifies the result of the attach procedure, see TS 24.301 [51] clause 9.9.3.10. This is derived from the information stored in the UE Context at the MME, see TS 23.401 [50] clause 5.7.2. |
M |
|
iMSI |
IMSI associated with the target UE Context at the MME, see TS 23.401 [50] clause 5.7.2. |
M |
|
iMEI |
IMEI associated with the target UE Context at the MME, if available, see TS 23.401 [50] clause 5.7.2. |
C |
|
mSISDN |
mSISDN associated with the target UE Context at the MME, if available. |
C |
|
gUTI |
Current GUTI associated with the target UE context at the MME, if available, see TS 23.401 [50] clause 5.7.2. |
C |
|
location |
Location information stored in the UE Context at the MME, if available, see TS 23.401 [50] clause 5.7.2. 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 |
|
ePSTAIList |
List of tracking areas associated with the registration area within which the UE is currently registered, see TS 24.301 [51], clause 9.9.3.33 and TS 23.401 [50] clause 5.7.2. |
C |
|
sMSServiceStatus |
Indicates the availability of SMS Services. Shall be provided if present in the UE Context at the MME, see TS 23.401 [50] clause 5.7.2. |
C |
|
eMM5GRegStatus |
UE Status, if present in the UE Context at the MME, see TS 24.501 [13] clause 9.11.3.56. |
C |
The IRI-POI present in the MME generating an xIRI containing an MMEStartOfInterceptionWithEPSAttachedUE record shall set the Payload Direction field in the PDU header to not applicable (see ETSI TS 103 221-2 [8] clause 5.2.6).
6.3.2.2.7 MME unsuccessful procedure
The IRI-POI in the MME shall generate an xIRI containing an MMEUnsuccessfulProcedure record when the IRI-POI present in the MME detects an unsuccessful procedure for a UE matching one of the target identifiers provided via LI_X1.
Accordingly, the IRI-POI in the MME generates the xIRI when any of the following events is detected:
– MME sends a reject to any EMM request message to the target UE and the UE EPS Mobility Management (EMM) within the MME is changed to EMM-DEREGISTERED.
– MME aborts a registration procedure before the UE EPS Mobility Management (EMM) state within the MME is changed to EMM-REGISTERED.
– MME sends a reject to any ESM request message to the target UE.
Unsuccessful attach attempts shall be reported only if the target UE has been successfully authenticated.
Table 6.3.2-7: Payload for MMEUnsuccessfulProcedure record
|
Field name |
Description |
M/C/O |
|
|
failedprocedureType |
Specifies the procedure which failed at the MME. |
M |
|
|
failureCause |
Provides the value of the ESM or EMM cause, see TS 24.301 [51] clauses 9.9.3.9 and 9.9.4.4. |
M |
|
|
iMSI |
IMSI associated with the procedure, if available (see NOTE). |
C |
|
|
iMEI |
IMEI associated with the procedure, if available. |
C |
|
|
mSISDN |
mSISDN associated with the procedure, if available. |
C |
|
|
gUTI |
GUTI provided used in the procedure, if available. |
C |
|
|
location |
Location information determined by the network 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.3.2.2.8 Positioning info transfer
The IRI-POI present in the MME shall generate an xIRI containing an MMEPositioningInfoTransfer when the IRI-POI present in the MME detects one of the following events:
– a LPPa (see TS 36.455 [84]) message related to a target UE has been exchanged between the E-SMLC and the eNB via the MME.
– a LPP (see TS 37.355 [85]) message related to a target UE has been exchanged between the E-SMLC and the target UE via the MME.
Accordingly, the IRI-POI in MME generates the xIRI when any of the following events is detected:
– MME receives an SLs CONNECTION ORIENTED INFORMATION message (see TS 29.171 [54]) from E-SMLC to request the transfer of a LPPa request to the serving eNB for a target UE as part of a UE associated LPPa positioning activity. The LPPa request may be E-CID MEASUREMENT INITIATION REQUEST or OTDOA INFORMATION REQUEST.
– MME sends an SLs CONNECTION ORIENTED INFORMATION message to the E-SMLC to forward the LPPa response or report received from the eNB for a target UE. The LPPa response or report may be E-CID MEASUREMENT INITIATION RESPONSE, E-CID MEASUREMENT REPORT or OTDOA INFORMATION RESPONSE.
– MME receives an SLs CONNECTION ORIENTED INFORMATION message from E-SMLC to request the transfer of a LPP request to the target UE.
– MME sends an SLs CONNECTION ORIENTED INFORMATION message to E-SMLC to forward a LPP message received from the target UE.
Table 6.3.2-7A: Payload for MMEPositioningInfoTransfer record
|
Field name |
Description |
M/C/O |
|
iMSI |
IMSI associated with the location update. |
M |
|
iMEI |
IMEI associated with the location update, if available. |
C |
|
mSISDN |
MSISDN associated with the location update, if available as part of the subscription profile. |
C |
|
gUTI |
GUTI assigned during the location update, if available, see TS 24.301 [50]. |
C |
|
lPPaMessage |
Any UE associated LPPa message exchanged between the LMF and eNB via MME. |
C |
|
lPPMessage |
Any LPP message exchanged between the E-SMLC and the target UE via MME. |
C |
|
mMELCSCorrelationId |
MMELCSCorrelationId is made of Correlation Id, described in clause 7.4.28 of TS 29.171 [54], related to a location session, found in the SLs CONNECTION ORIENTED INFORMATION sent by E-SMLC to MME and corresponding SLs CONNECTION ORIENTED INFORMATION sent by MME to E-SMLC. All the MMEPositioningInfoTransfer records related to the same location session have the same CorrelationId. |
M |
6.3.2.3 Generation of IRI over LI_HI2
6.3.2.3.1 General
When Option A or Option B specified in clause 6.3.1 are used and an xIRI is received over LI_X2 from the IRI-POI in the MME, the MDF2 shall generate the corresponding IRI message and deliver it over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received in the xIRI over LI_X2.
When Option C specified in clause 6.3.1 is used the MDF2 shall generate IRI messages based on the proprietary information received from the MME and provide it over LI_HI2 without undue delay.
The IRI record may be enriched with any additional information available at the MDF (e.g. additional location information).
The IRI messages shall be delivered over LI_HI2 according to ETSI TS 102 232-7 [10] clause 10.When Option A specified in clause 6.3.1 is used, LI_HI2 shall be realised as described in clause 6.3.2.3.2.
When Option B or Option C specified in clause 6.3.1 is used, LI_HI2 shall be realised as described in clause 6.3.2.3.3.
6.3.2.3.2 Option A
The IRI message the MDF2 generates shall contain a copy of the relevant record received in the xIRI over LI_X2 and provide it over LI_HI2 without undue delay.
The timestamp field of the PSHeader structure shall be set to the time at which the MME 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.3.2-8.
Table 6.3.2-8: IRI type for IRI messages
|
IRI message |
IRI type |
|
MMEAttach |
REPORT |
|
MMEDetach |
REPORT |
|
MMELocationUpdate |
REPORT |
|
MMEStartOfInterceptionWithEPSAttachedUE |
REPORT |
|
MMEUnsuccessfulProcedure |
REPORT |
|
MMEIdentifierAssociation |
REPORT |
|
MMEPositioningInfoTransfer |
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 MMEStartOfInterceptionWithEPSAttachedUE record to the LEMF associated with the additional warrant without receiving a corresponding xIRI. The payload of the MMEStartOfInterceptionWithEPSAttachedUE record is specified in table 6.3.2-6.
For records related to SMS over NAS in EPS, the process detailed in clause 6.3.2.3.3 shall be used.
6.3.2.3.3 Option B and Option C
For all messages except MMEIdentifierAssociation, the IRI messages shall include an IRI payload encoded according to TS 33.108 [12] Annex B.9.
The MDF2 shall encode the correct value of LIID in the IRI message, replacing the value "LIIDNotPresent" given in the xIRI (see clause 6.3.2.2).
For MMEIdentifierAssociation messages, the IRI message shall be encoded as an IRIEvent structure according to Annex B and used to populate the threeGPP33128DefinedIRI field in ETSI TS 102 232-7 [10] clause 15.
6.3.3 LI at SGW/PGW and ePDG
6.3.3.0 General
Unless otherwise specified, the following clauses apply to both CUPS and non-CUPS EPS architectures. When CUPS architecture is used, unless otherwise specified, the term SGW/PGW refers to both the SGW-U/PGW-U and the SGW-C/PGW-C.
Unless otherwise specified, the following clauses apply in the case of EPC-5GC interworking via combined SMF+PGW-C and UPF+PGW-U.
6.3.3.1 Provisioning over LI_X1
6.3.3.1.1 General
If the warrant is for IRI and CC, then the LI functions in the SGW/PGW shall be provisioned in accordance with clause 6.3.3.1.2 for non-CUPS architecture and clause 6.3.3.1.3 for CUPS architecture, the MDF2 shall be provisioned in accordance with clause 6.3.3.1.4, and the MDF3 shall be provisioned in accordance with clause 6.3.3.1.5.
If the warrant is for IRI only, the IRI-POI in the SGW/PGW shall be provisioned in accordance with clause 6.3.3.1.2 for non-CUPS architecture and clause 6.3.3.1.3 for CUPS architecture and the MDF2 shall be provisioned in accordance with clause 6.3.3.1.4.If approach 1 described in clause 6.2.3.9 is used for packet header information reporting:
– For non-CUPS architecture, the IRI-POI in the SGW/PGW shall be provisioned in accordance with clause 6.3.3.1.2 and the MDF2 shall be provisioned in accordance with clause 6.3.3.1.4.
– For CUPS architecture, the IRI-TF in the SGW-C/PGW-c shall be provisioned in accordance with clause 6.3.3.1.3 and the MDF2 shall be provisioned in accordance with clause 6.3.3.1.4.
If approach 2 described in clause 6.2.3.9 is used for packet header information reporting:
– For non-CUPS architecture, the CC-POI in the SGW/PGW shall be provisioned in accordance with clause 6.3.3.1.2, the MDF2 shall be provisioned in accordance with clause 6.3.3.1.4, and the MDF3 shall be provisioned in accordance with clause 6.3.3.1.5.
– For CUPS architecture, the CC-TF in the SGW-C/PGW-C shall be provisioned in accordance with clause 6.3.3.1.3, the MDF2 shall be provisioned in accordance with clause 6.3.3.1.4, and the MDF3 shall be provisioned in accordance with clause 6.3.3.1.5.
The LI functions in the SGW/PGW and ePDG, the MDF2 and 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):
– IMSI.
– MSISDN (using the E164Number target identifier format from ETSI TS 103 221-1 [7]).
– IMEI.
In the case of EPC-5GC interworking via combined SMF+PGW-C and UPF+PGW-U, the LI functions in the SMF+PGW-C, MDF2 and MDF3 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivatlent if ETSI TS 103 221-1 [7] is not used):
– SUPINAI.
– SUPIIMSI.
– IMSI.
– GPSINAI.
– GPSIMSISDN.
– MSISDN (using the E164Number target identifier format from ETSI TS 103 221-1 [7]).
– PEIIMEISV.
– PEIIMEI.
– IMEI.
When the target identifier is an IMSI, the LI functions in the SMF+PGW-C shall also trigger when events associated to a SUPI in the form of an IMSI with a value matching the provisioned IMSI target identifier value are detected. Likewise, when the target identifier is a SUPIIMSI, the LI functions in the SMF+PGW-C shall also trigger when events associated to an IMSI with a value matching the provisioned SUPIIMSI target identifier value are detected.
When the target identifier is an MSISDN, the LI functions in the SMF+PGW-C shall also trigger when events associated to a GPSI in the form of an MSISDN with a value matching the provisioned MSISDN target identifier value are detected. Likewise, then the target identifier is a GPSIMSISDN, the LI functions in the SMF+PGW-C shall also trigger when events associated to an MSISDN with a value matching the provisioned GPSIMSISDN target identifier value are detected.
When the target identifier is an IMEI, the LI functions in the SMF+PGW-C shall also trigger when events associated to a PEI in the form of an IMEI with a value matching the provisioned IMEI target identifier value are detected. Likewise, then the target identifier is a PEIIMEI, the LI functions in the SMF+PGW-C shall also trigger when events associated to an IMEI with a value matching the provisioned PEIIMEI target identifier value are detected.
NOTE: When both a 4G identifier and its equivalent 5G identifier are provisioned by means of separate tasks in the LI functions present in the SMF+PGW-C, interception will be triggered independently for each of the two identifiers.
6.3.3.1.2 Non-CUPS Architecture
When the EPS is implemented using non-CUPS architecture, the IRI-POI and CC-POI present in the SGW/PGW and ePDG are provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. A single task may be used.
Table 6.3.3.1-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI and the CC-POI in the SGW/PGW.
Table 6.3.3.1-1: ActivateTask message for the IRI-POI and CC-POI in the SGW/PGW and ePDG in non-CUPS architecture
|
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 clause above. |
M |
|
DeliveryType |
Set to “X2Only”, “X3Only” or “X2andX3” as needed to meet the requirements of the warrant. |
M |
|
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 |
|
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 |
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.3.3.1.3 CUPS Architecture
When the EPS is implemented using CUPS architecture, the IRI-POI, IRI-TF and CC-TF present in the SGW-C/PGW-C and the IRI-POI and CC-POI present in the ePDG are provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
Table 6.3.3.1-2 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI, CC-TF and IRI-TF in the SGW-C/PGW-C. If the ePDG is used, the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI and the CC-POI in the ePDG are detailed in Table 6.3.3.1-1.
Table 6.3.3.1-2: ActivateTask message for the IRI-POI, CC-TF and IRI-TF in the SGW-C/PGW-C in CUPS architecture
|
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 clause 6.3.3.1.1. |
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 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 |
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.3.3.1.4 Provisioning of the MDF2
The MDF2 listed as the delivery endpoint for xIRI generated by the IRI-POI in the CP entity of the SGW/PGW or ePDG shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 6.3.3.1-3 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
Table 6.3.3.1-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 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.3.3.1-4. |
M |
Table 6.3.3.1-4: 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.3.3.1.5 Provisioning of the MDF3
The MDF3 listed as the delivery endpoint for the xCC generated by the CC-POI in the UP entity of the SGW/PGW or ePDG shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 6.3.3.1-5 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF3. If packet header reporting is authorised and approach 2 described in clause 6.2.3.9 is used, the endpoint for the MDF3 shall be the MDF2 over LI_MDF.
Table 6.3.3.1-5: 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. |
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.3.3.1-6. |
M |
Table 6.3.3.1-6: 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.3.3.2 Generation of xIRI over LI_X2
6.3.3.2.1 General
When Option A specified in clause 6.3.1 is used:
– For architectures with EPC/5GC interworking:
– For home routed roaming interception in the visited network, in this version of the specification, the IRI-POI present in the SGW shall be implemented in accordance with Option B or Option C specified in clause 6.3.1.
– For all other cases, the IRI-POI present in the SMF+PGW-C shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 6.3.3.3.1.2, as described in clause 6.3.1.
– As described in TS 23.501 [2] clause 5.32.7.1, a PDN Connection in EPS can be one leg of an MA PDU session. The details of the messages for single-access PDU sessions are provided in clauses 6.3.3.2.2, 6.3.3.2.3, 6.3.3.2.4 and 6.3.3.2.5. The details for the messages for MA PDU sessions are provided in clauses 6.3.3.2.6, 6.3.3.2.7, 6.3.3.2.8 and 6.3.3.2.9.
NOTE: The details of the events triggers used to generate the xIRIs are specified at high-level in support of possible hitherto implementation variations for EPS LI.
When Option B specified in clause 6.3.1 is used:
– The IRI-POI present in the SGW/PGW and ePDG shall send the xIRIs over LI_X2 for each of the events listed in TS 33.107 [36] clause 12.2.1.2, the details of which are specified in clause 12.2.3 of the same TS.
– The IRI-POI present in the SGW/PGW and ePDG shall set the payload format to EpsHI2Operations.EpsIRIContent (value 14), see clause 5.3 and ETSI TS 103 221-2 [8] clause 5.4. The payload field shall contain an EpsHI2Operations.EpsIRIContent structure encoded according to TS 33.108 [12] clauses 10.5 and B.9.
– As the LIID may not be available at the SGW/PGW and ePDG but is mandatory in EpsHI2Operations.EpsIRIContent according to TS 33.108 [12] Annex B.9, its value in the lawfulInterceptionIdentifier field of the encoded PDU shall be set to the fixed string "LIIDNotPresent".
6.3.3.2.2 PDU Session Establishment message reporting PDU session establishment or PDN Connection establishment
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFPDUSessionEstablishment record (see clause 6.2.3.2.2) when the IRI-POI present in the SMF+PGW-C detects that a single-access PDU Session or PDN Connection has been established for the target UE. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C creates a new PDN Connection in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C creates a new PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.2 and clause 5.2.2.7).
When the SMFPDUSessionEstablishment record (see clause 6.2.3.2.2) is used to report the creation of a new PDN Connection:
– The ePSPDNConnectionEstablishment field shall be populated with the information in Table 6.3.3-1.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFPDUSessionEstablishment record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID present in the PCO of the request or response messages or associated to the context for the PDN connection, the pDUSessionID field of the SMFPDUSessionEstablishment record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFPDUSessionEstablishment record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
Table 6.3.3-1: Payload for ePSPDNConnectionEstablishment Field
|
Field name |
Description |
M/C/O |
|
ePSSubscriberIDs |
EPS Subscriber Identities associated with the PDN connection (e.g. as provided by the MME or SGW in the associated Create Session Request or as associated with the PDN connection in the context known at the NF). The IMSI shall be present except for unauthenticated emergency . |
M |
|
iMSIUnauthenticated |
Shall be present if an IMSI is present in the ePSSubscriberIDs and set to “true” if the IMSI has not been authenticated, or “false” if it has been authenticated. |
C |
|
defaultBearerID |
Shall contain the EPS Bearer Identity of the default bearer associated with the PDN connection. |
M |
|
gTPTunnelInfo |
Contains the information for the Control Plane GTP Tunnels present in the Create Session Request or known in the context at the SGW or PGW. See Table 6.2.3-1B. |
C |
|
pDNConnectionType |
Identifies selected PDN session type, see TS 29.274 [87] clause 8.34. |
M |
|
uEEndpoints |
UE endpoint address(es) if available. Derived from the PDN Address portion of the PDN Address Allocation parameter (see TS 29.274 [87] clause 8.14) present in the Create Session Request or the IP Address associated to the PDN Connection in the context known at the NF (see TS 23.401 [50] clauses 5.7.3 and 5.7.4). |
C |
|
non3GPPAccessEndpoint |
UE’s local IP address used to reach the ePDG, if present in the Create Session Request (see TS 29.274 [87], clause 7.2.1) or known at the context at the SGW or PGW. |
C |
|
location |
Location information present in the Create Session Request (see TS 29.274 [87], clause 7.2.1) or known in the context at the SGW or PGW. |
C |
|
additionalLocation |
Additional location information present in the Create Session Request, known in the context at the SGW or PGW, or known at the MDF. |
C |
|
aPN |
Access Point Name associated with the PDN connection present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.6) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4), as defined in TS 23.003[19] clause 9.1. |
M |
|
requestType |
Type of request as derived from the Request Type described in TS 24.301 [50] clause 9.9.4.14 and TS 24.008 [95] clause 10.5.6.17, if available. |
C |
|
accessType |
Access type associated with the PDN connection (i.e. 3GPP or non-3GPP access). Shall be set to nonThreeGPPAccess by the ePDG or by the PGW when the Create Session Request for the PDN connection is received from an ePDG. Shall be set to threeGPPAccess by the SGW or by the PGW when the Create Session Request for the PDN connection is received from an SGW. |
C |
|
rATType |
RAT Type associated with the PDN connection. Shall be present if included in the Create Session Request (see TS 29.274 [87] clause 7.2.1) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4). |
C |
|
protocolConfigurationOptions |
Shall be present if the Create Session Request or the Create Session Response (see TS 29.274 [87] clause 7.2.2 and clause 7.2.3) contains the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 6.3.3-4. |
C |
|
servingNetwork |
Shall be present if this IE is in the Create Session Request or the context for the PDN connection at the SGW/PGW. |
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 |
|
bearerContextsCreated |
Shall include a list of the Bearer Contexts created sent in the Create Session Response message (see TS 29.274 [87] clause 7.2.2). See Table 6.3.3-2. |
M |
|
bearerContextsMarkedForRemoval |
Shall include a list of the Bearer Contexts to be removed sent in the Create Session Response message (see TS 29.274 [87] clause 7.2.2). See Table 6.3.3-3. |
C |
|
indicationFlags |
Shall be included if the Indication Flags field is present in the Create Session Request (see TS 29.274 [87] clause 7.2.1). The value of this parameter shall be set to the value of the Indication IE (see TS 29.274 [87] clause 8.12) starting with octet 5. |
C |
|
handoverIndication |
Shall be present if the Handover Indication is set to 1 in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
nBIFOMSupport |
Shall be present if the NBIFOM Support Indication is set to 1 in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
fiveGSInterworkingInfo |
Shall be present if the 5GS Interworking Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). See Table 6.3.3-5. |
C |
|
cSRMFI |
Shall be present if the Create Session Request Message Forwarded Indication (CSRMFI) is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). Indicates the Create Session Request message has been forwarded by a PGW. |
C |
|
restorationOfPDNConnectionsSupport |
Shall be present if the Restoration of PDN connection after an PGW-C/SMF Change Support Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
pGWChangeIndication |
Shall be present if the PGW Change Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
pGWRNSI |
Shall be present if the PGW Redirection due to mismatch with Network Slice subscribed by the UE Support Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
Table 6.3.3-2: Payload for bearerContextsCreated Field
|
Field name |
Description |
M/C/O |
|
ePSBearerID |
Shall include the EPS bearer ID for the EPS Bearer (See TS 29.274 [87] clauses 7.2.2 and 7.2.4). |
M |
|
cause |
Shall indicate whether the bearer handling was successful and if not, it gives information on the reason (see TS 29.274 [87] clause 7.2.2 and 7.2.4). Sent as an integer cause value (see TS 29.274 [87] Table 8.4-1) |
M |
|
gTPTunnelInfo |
Contains 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). See Table 6.2.3-1B. |
C |
|
bearerQOS |
Shall include the QOS information for the bearer if present in the Request or Response (see TS 29.274 [87] clauses 7.2.2, 7.2.15 and 8.15) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4). See Table 6.3.3-7. |
C |
|
protocolConfigurationOptions |
Shall be present if the Bearer Context reported (see TS 29.274 [87] clauses 7.2.2, 7.2.3, and 7.2.4) contains the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 7.6.3.3-4. |
C |
Table 6.3.3-3: Payload for bearerContextsMarkedForRemoval Field
|
Field name |
Description |
M/C/O |
|
ePSBearerID |
Shall include the EPS bearer ID for the EPS Bearer (See TS 29.274 [87] clause 7.2.2, 7.2.8 and 7.2.10). |
M |
|
cause |
Shall indicate whether the bearer handling was successful and if not, it gives information on the reason (see TS 29.274 [87] clause 7.2.2, 7.2.8 and 7.2.10). |
M |
Table 6.3.3-4: Payload for protocolConfigurationOptions Field
|
Field name |
Description |
M/C/O |
|
requestPCO |
Shall be present if the Protocol Configuration Options IE is present in the request message. The value of this parameter shall contain a copy of the value field of the PCO IE of the request message (see 29.274 [87] clause 8.13 starting with octet 5). |
C |
|
requestAPCO |
Shall be present if the Additional Protocol Configuration Options IE is present in the request message. The value of this parameter shall contain a copy of the value field of the PCO IE of the request message (see 29.274 [87] clause 8.94 starting with octet 5). |
C |
|
requestEPCO |
Shall be present if the Extended Protocol Configuration Options IE is present in the request message. The value of this parameter shall contain a copy of the value field of the PCO IE of the request message (see 29.274 [87] clause 8.128 starting with octet 5). |
C |
|
responsePCO |
Shall be present if the Protocol Configuration Options IE is present in the response message. The value of this parameter shall contain a copy of the value field of the PCO IE of the response message (see 29.274 [87] clause 8.13 starting with octet 5). |
C |
|
responseAPCO |
Shall be present if the Additional Protocol Configuration Options IE is present in the response message. The value of this parameter shall contain a copy of the value field of the PCO IE of the response message (see 29.274 [87] clause 8.94 starting with octet 5). |
C |
|
responseEPCO |
Shall be present if the Extended Protocol Configuration Options IE is present in the response message. The value of this parameter shall contain a copy of the value field of the PCO IE of the response message (see 29.274 [87] clause 8.128 starting with octet 5). |
C |
Table 6.3.3-5: Payload for fiveGSInterworkingInfo Field
|
Field name |
Description |
M/C/O |
|
fiveGSInterworkingIndicator |
Shall be set toTRUE if the 5GSIWKI flag in the Indication IE of the request or response is set to 1. Indicates that the UE supports N1 mode and the PDN connection is not restricted from interworking by the 5GS user subscription. See TS 29.274 [87] clauses 7.2.1 and 8.12. |
M |
|
fiveGSInterworkingWithoutN26 |
Shall be set to TRUE if the 5GS Interworking without N26 Indication flag in the Indication IE of the request or response is set to 1. If the 5GS Interworking without N26 Indication flag in the Indication IE of the request or response is set to 0 or not present, this parameter shall be set to FALSE. See TS 29.274 [87] clauses 7.2.1 and 8.12. |
M |
|
fiveGCNotRestrictedSupport |
Shall be set to True if the 5GCNRS (5GC Not Restricted Support) flag in the Indication IE of the request or response is set to 1. If the 5GCNRS flag in the Indication IE of the request or response is set to 0 or not present, this parameter shall be set to FALSE. See TS 29.274 [87] clauses 7.2.1 and 8.12. |
M |
Table 6.3.3-6: Payload for ePSGTPTunnels Field
|
Field name |
Description |
M/C/O |
|
controlPlaneSenderFTEID |
Shall include the Sender F-TEID for the control plane if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the SGW or PGW. |
C |
|
controlPlanePGWS5S8FTEID |
Shall include the PGW F-TEID for the control plane if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the SGW or PGW. |
C |
|
s1UeNodeBFTEID |
Shall include the F-TEID for the eNodeB S1-U interface for the bearer if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the SGW or PGW. |
C |
|
s5S8SGWFTEID |
Shall include the F-TEID for the SGW S5 or S8 interface for the bearer if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the SGW or PGW. |
C |
|
s5S8PGWFTEID |
Shall include the F-TEID for the PGW S5 or S8 interface for the bearer if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the SGW or PGW. |
C |
|
s2bUePDGFTEID |
Shall include the F-TEID for the ePDG on the S2b-U interface for the bearer if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the PGW or ePDG. |
C |
|
s2aUePDGFTEID |
Shall include the F-TEID for the ePDG on the S2a-U interface for the bearer if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.15, 7.2.16) or known in the context at the PGW or ePDG. |
C |
Table 6.3.3-7: Payload for bearerQOS Field
|
Field name |
Description |
M/C/O |
|
qCI |
Shall include the QCI for the bearer if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3 and 7.2.15), or known in the context at the SGW or PGW. |
C |
|
maximumUplinkBitRate |
Shall include the maximum uplink bitrate encoded as kilobits per second in binary value (see TS 29.274 [87] clause 8.15) if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3 and 7.2.15), or known in the context at the SGW or PGW. |
C |
|
maximumDownlinkBitRate |
Shall include the maximum downlink bitrate encoded as kilobits per second in binary value (see TS 29.274 [87] clause 8.15) if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3 and 7.2.15), or known in the context at the SGW or PGW. |
C |
|
guaranteedUplinkBitRate |
Shall include the guaranteed uplink bitrate encoded as kilobits per second in binary value (see TS 29.274 [87] clause 8.15) if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3 and 7.2.15), or known in the context at the SGW or PGW. |
C |
|
guaranteedDownlinkBitRate |
Shall include the guaranteed downlink bitrate encoded as kilobits per second in binary value (see TS 29.274 [87] clause 8.15) if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3 and 7.2.15), or known in the context at the SGW or PGW. |
C |
|
priorityLevel |
Shall include the priority level assigned to the bearer as an integer value (see TS 29.274 [87] clause 8.15) if present in the Request or response (See TS 29.274 [87] clause 7.2.1, 7.2.2, 7.2.3 and 7.2.15), or known in the context at the SGW or PGW. |
C |
6.3.3.2.3 PDU Session Modification message reporting PDU session modification, PDN Connection modification or inter-system handover
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFPDUSessionModification record (see clause 6.2.3.2.3) when the IRI-POI present in the SMF+PGW-C detects that a single-access PDU Session or PDN Connection has been modified for the target UE. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C modifies an existing PDN Connection in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C modifies an existing PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.3 and clause 5.2.2.8).
– The SMF+PGW-C transfers an existing PDU Session to EPS (see TS 23.502 [4] clauses 4.11.1.2.1 and 4.11.2.2).
– The SMF+PGW-C transfers an existing PDN Connection to 5GS (see TS 23.502 [4] clauses 4.11.1.2.2 and 4.11.2.3).
When the SMFPDUSessionModification record (see clause 6.2.3.2.3) is used to report the modification of a PDN Connection:
– The ePSPDNConnectionModification field shall be populated with the information in Table 6.3.3-8.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFPDUSessionModification record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID present in the PCO of the request or response messages or associated to the context for the PDN connection, the pDUSessionID field of the SMFPDUSessionModification record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFPDUSessionModification record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
Table 6.3.3-8: Payload for ePSPDNConnectionModification Field
|
Field name |
Description |
M/C/O |
|
ePSSubscriberIDs |
EPS Subscriber Identities associated with the PDN connection (e.g. as provided by the MME or SGW in the associated network message or as associated with the PDN connection in the context known at the NF). The IMSI shall be present except for unauthenticated emergency . |
M |
|
iMSIUnauthenticated |
Shall be present if an IMSI is present in the ePSSubscriberIDs and set to “true” if the IMSI has not been authenticated, or “false” if it has been authenticated. |
C |
|
defaultBearerID |
Shall contain the EPS Bearer Identity of the default bearer associated with the PDN connection. |
M |
|
gTPTunnelInfo |
Contains the information for the Control Plane GTP Tunnels present in the network message or known in the context at the SGW or PGW. See Table 6.2.3-1B. If the gTPTunnelInfo received in the network message is different than the gTPTunnelInfo in the context for the PDN Connection, this message shall be populated with the new information. |
C |
|
pDNConnectionType |
Identifies selected PDN session type, see TS 29.274 [13] clause 8.34. |
M |
|
uEEndpoints |
UE endpoint address(es) if available. Derived from the PDN Address portion of the PDN Address Allocation parameter (see TS 29.274 [87] clause 8.14) present in the network message or the IP Address associated to the PDN Connection in the context known at the NF (see TS 23.401 [50] clauses 5.7.3 and 5.7.4). |
C |
|
non3GPPAccessEndpoint |
UE’s local IP address used to reach the ePDG, if present in the network message (see TS 29.274 [87], clauses 7.2.4, 7.2.7 and 7.2.16) or known at the context at the SGW or PGW. |
C |
|
location |
Location information present in the network message (see TS 29.274 [87], clause 8.21) or known in the context at the SGW or PGW. |
C |
|
additionalLocation |
Additional location information present in the network message, known in the context at the SGW or PGW, or known at the MDF. |
C |
|
aPN |
Access Point Name associated with the PDN connection present in the network message (see TS 29.274 [87] clause 8.6) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4), as defined in TS 23.003[19] clause 9.1. |
M |
|
requestType |
Type of request as derived from the Request Type described in TS 24.301 [50] clause 9.9.4.14 and TS 24.008 [95] clause 10.5.6.17, if available. |
C |
|
accessType |
Access type associated with the PDN connection (i.e. 3GPP or non-3GPP access). |
C |
|
rATType |
RAT Type associated with the PDN connection. Shall be present if included in the network message (see TS 29.274 [87] clauses 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.2.15 and 7.2.16) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4). |
C |
|
protocolConfigurationOptions |
Shall be present if the network message (see TS 29.274 [87]) contains the Protocol Configuration Options, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 6.3.3-4. |
C |
|
servingNetwork |
Shall be present if this IE is in the network message or the context for the PDN connection at the SGW/PGW. |
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 |
|
bearerContextsCreated |
Shall include a list of the Bearer Contexts created if the event that resulted in the generation of the message was the activation of a dedicated Bearer. Shall contain the contents of the Bearer Context field of the Create Bearer Response message (see TS 29.274 [87] clause 7.2.4). See Table 6.3.3-2. |
C |
|
bearerContextsModified |
Shall include a list of the Bearer Contexts modified if the event that resulted in the generation of the message was the modification of an existing bearer. Shall contain the contents of the Bearer Contexts Modified field of the Modify Bearer Response message (see TS 29.274 [87] clause 7.2.8) or the Bearer Contexts within the Update Bearer Response message (see TS 29.274 [87] clause 7.2.16). See Table 6.3.3-9. |
M |
|
bearerContextsMarkedForRemoval |
Shall include a list of the Bearer Contexts to be removed if the event that resulted in the generation of the message included the removal of an existing bearer. (see TS 29.274 [87] clause 7.2.8 and 7.2.10). See Table 6.3.3-3. |
C |
|
bearersDeleted |
Shall include a list of the Bearers to be deleted if the event that resulted in the generation of the message included a Delete Bearer Request or Response. (see TS 29.274 [87] clauses 7.2.9 and 7.2.10). See Table 6.3.3-10 |
C |
|
indicationFlags |
Shall be included if the Indication Flags field is present in the network message (see TS 29.274 [87] clauses 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.2.15 and 7.2.16). The value of this parameter shall be set to the value of the Indication IE (see TS 29.274 [87] clause 8.12) starting with octet 5. |
C |
|
handoverIndication |
Shall be present if the Handover Indication is set to 1 in the Modify Bearer Request (see TS 29.274 [87] clauses 7.2.7 and 8.12). |
C |
|
nBIFOMSupport |
Shall be present if the NBIFOM Support Indication is set to 1 in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
fiveGSInterworkingInfo |
Shall be present if the 5GS Interworking Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). See Table 6.3.3-5. |
C |
|
cSRMFI |
Shall be present if the Create Session Request Message Forwarded Indication (CSRMFI) is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). Indicates the Create Session Request message has been forwarded by a PGW. |
C |
|
restorationOfPDNConnectionsSupport |
Shall be present if the Restoration of PDN connection after an PGW-C/SMF Change Support Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
pGWChangeIndication |
Shall be present if the PGW Change Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
|
pGWRNSI |
Shall be present if the PGW Redirection due to mismatch with Network Slice subscribed by the UE Support Indication is present in the Create Session Request (see TS 29.274 [87] clauses 7.2.1 and 8.12). |
C |
Table 6.3.3-9: Payload for bearerContextsModified Field
|
Field name |
Description |
M/C/O |
|
ePSBearerID |
Shall include the EPS bearer ID for the EPS Bearer (See TS 29.274 [87] clauses 7.2.7, 7.2.8, 7.2.15 and 7.2.16). |
M |
|
cause |
Shall indicate whether the bearer handling was successful and if not, it gives information on the reason (See TS 29.274 [87] clauses 7.2.7, 7.2.8, 7.2.15 and 7.2.16). Sent as an integer cause value (see TS 29.274 [87] Table 8.4-1) |
M |
|
gTPTunnelInfo |
Contains 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.7, 7.2.8, 7.2.15, 7.2.16 and 8.15) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4). See Table 6.2.3-1B. |
C |
|
bearerQOS |
Shall include the QOS information for the bearer if present in the Request or Response (see TS 29.274 [87] clauses 7.2.7, 7.2.8, 7.2.15, 7.2.16 and 8.15) or known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4). See Table 6.3.3-7. |
C |
|
protocolConfigurationOptions |
Shall be present if the Bearer Context reported (see TS 29.274 [87] clauses 7.2.7, 7.2.8, 7.2.15, 7.2.16 and 8.15) contains the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 6.3.3-4. |
C |
Table 6.3.3-10: Payload for bearersDeleted Field
|
Field name |
Description |
M/C/O |
|
linkedEPSBearerID |
Shall include the EBI for the default bearer associated with the PDN being disconnected if all bearers belonging to a PDN connection are being released (See TS 29.274 [87] clause 7.2.9). |
C |
|
ePSBearerIDs |
Shall include a list of the EPS Bearer IDs to be deleted if only some of the EPS Bearers belonging to a PDN Connection are being released(See TS 29.274 [87] clause 7.2.9). |
C |
|
protocolConfigurationOptions |
Shall be present if the Delete Bearer Request or Response reported (see TS 29.274 [87] clauses 7.2.9) contains the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 6.3.3-4. |
C |
|
cause |
Shall indicate the reason the EPS Bearers are being deleted (See TS 29.274 [87] clause 7.2.9). Sent as an integer cause value (see TS 29.274 [87] Table 8.4-1) |
C |
|
deleteBearerResponse |
Shall contain information from the Delete Bearer Response (See TS 29.274[87] clause 7.2.10). See Table 6.3.3-11. |
M |
Table 6.3.3-11: Payload for deleteBearerResponse Field
|
Field name |
Description |
M/C/O |
|
cause |
Indicates whether the bearers requested for deletion were successfully deleted (See TS 29.274 [87] clause 7.2.10). |
M |
|
linkedEPSBearerID |
Shall include the EBI for the default bearer associated with the PDN being disconnected if all bearers belonging to a PDN connection are being released (See TS 29.274 [87] clause 7.2.10). |
C |
|
bearerContexts |
Shall include a list of the EPS Bearer Contexts requested for deletion along with details on whether they were successfully deleted. Shall be included if only some of the EPS Bearers belonging to a PDN Connection are being released(See TS 29.274 [87] clause 7.2.10). See Table 6.3.3-12. |
C |
|
protocolConfigurationOptions |
Shall be present if the Delete Bearer Request or Response reported (see TS 29.274 [87] clauses 7.2.9) contains the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 6.3.3-4. |
C |
Table 6.3.3-12: Payload for bearerContexts Field in deleteBearerResponse
|
Field name |
Description |
M/C/O |
|
cause |
Indicates whether the bearers requested for deletion were successfully deleted (See TS 29.274 [87] clause 7.2.10). |
M |
|
ePSBearerID |
Shall include the EBI for the bearer (See TS 29.274 [87] clause 7.2.10). |
M |
|
protocolConfigurationOptions |
Shall be present if the Delete Bearer Request or Response reported (see TS 29.274 [87] clauses 7.2.9) contains the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options IE. See Table 6.3.3-4. |
C |
|
rANNASCause |
Shall be present if the RAN/NAS Release Cause is present in the delete session response bearer context (see TS 29.274 [87] clause 7.2.10). Shall be sent as an Octet String encoded as specified in TS 29.274 [87] clause 8.103. |
C |
6.3.3.2.4 PDU Session Release message reporting PDU session release, PDN Connection release
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFPDUSessionRelease record (see clause 6.2.3.2.4) when the IRI-POI present in the SMF+PGW-C detects that a single-access PDU Session or PDN Connection has been released for the target UE. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C releases an existing PDN Connection in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C releases an existing PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.4 and clause 5.2.2.9).
When the SMFPDUSessionRelease record (see clause 6.2.3.2.4) is used to report the release of a PDN Connection:
– The ePSPDNConnectionRelease field shall be populated with the information in Table 6.3.3-13.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFPDUSessionRelease record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID present in the PCO of the request or response messages or associated to the context for the PDN connection, the pDUSessionID field of the SMFPDUSessionRelease record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFPDUSessionRelease record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
Table 6.3.3-13: Payload for ePSPDNConnectionRelease field
|
Field name |
Description |
M/C/O |
|
ePSSubscriberIDs |
EPS Subscriber Identities associated with the PDN connection (e.g. as provided by the MME or SGW in the associated network message or as associated with the PDN connection in the context known at the NF). The IMSI shall be present except for unauthenticated emergency . |
M |
|
iMSIUnauthenticated |
Shall be present if an IMSI is present in the ePSSubscriberIDs and set to “true” if the IMSI has not been authenticated, or “false” if it has been authenticated. |
C |
|
defaultBearerID |
Shall contain the EPS Bearer Identity of the default bearer associated with the PDN connection. |
M |
|
location |
Location information present in the network message (see TS 29.274 [87], clause 8.21) or known in the context at the SGW or PGW. |
C |
|
gTPTunnelInfo |
Contains the information for the Control Plane GTP Tunnels present in the network message or known in the context at the SGW or PGW. See Table 6.2.3-1B. If the gTPTunnelInfo received in the network message is different than the gTPTunnelInfo in the context for the PDN Connection, this message shall be populated with the new information. |
C |
|
rANNASCause |
Shall be present if the RAN/NAS Release Cause is present in the delete session request (see TS 29.274 [87] clause 7.2.9). |
C |
|
pDNConnectionType |
Identifies selected PDN session type, see TS 29.274 [13] clause 8.34. |
M |
|
indicationFlags |
Shall be included if the Indication Flags field is present in the network message (see TS 29.274 [87] clauses 7.2.3, 7.2.4, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.2.15 and 7.2.16). The value of this parameter shall be set to the value of the Indication IE (see TS 29.274 [87] clause 8.12) starting with octet 5. |
C |
|
scopeIndication |
This flag shall be present and set to True, if the request corresponds to TAU/RAU/Handover with SGW change/SRNS Relocation Cancel Using S4 with SGW change, Inter RAT handover Cancel procedure with SGW change, S1 Based handover Cancel procedure with SGW change. If this parameter is absent, it shall be interpreted as False. |
C |
|
bearersDeleted |
Shall include a list of the Bearers to be deleted if the event that resulted in the generation of the message included a Delete Bearer Request or Response. (see TS 29.274 [87] clauses 7.2.9 and 7.2.10). See Table 6.3.3-10 |
C |
6.3.3.2.5 SMF Start of Interception with Already Established PDU Session message reporting Start of Interception with Already Established PDU Session or Start of Interception with Already Established PDN Connection
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFStartOfInterceptionWithEstablishedPDUSession record (see clause 6.2.3.2.5) when the IRI-POI present in the SMF+PGW-C detects that a single-access PDU Session or PDN Connection has already been established for the target UE when interception starts. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C has an existing PDN Connection in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C has an existing PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.2 and clause 5.2.2.7).
When the SMFStartOfInterceptionWithEstablishedPDUSession record (see clause 6.2.3.2.5) is used to report an existing PDN Connection:
– The ePSStartOfInterceptionWithEstablishedPDNConnection field shall be populated with the information in Table 6.3.3-14.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFStartOfInterceptionWithEstablishedPDUSession record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID associated to the context for the PDN connection, the pDUSessionID field of the SMFStartOfInterceptionWithEstablishedPDUSession record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFStartOfInterceptionWithEstablishedPDNConnection record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
Table 6.3.3-14: Payload for ePSStartOfInterceptionWithEstablishedPDNConnection field
|
Field name |
Description |
M/C/O |
|
ePSSubscriberIDs |
EPS Subscriber Identities associated with the PDN connection (as associated with the PDN connection in the context known at the NF). The IMSI shall be present except for unauthenticated emergency sessions. |
M |
|
iMSIUnauthenticated |
Shall be present if an IMSI is present in the ePSSubscriberIDs and set to “true” if the IMSI has not been authenticated, or “false” if it has been authenticated. |
C |
|
defaultBearerID |
Shall contain the EPS Bearer Identity of the default bearer associated with the PDN connection. |
M |
|
gTPTunnelInfo |
Contains the information for the Control Plane GTP Tunnels known in the context at the SGW or PGW. See Table 6.2.3-1B. |
C |
|
pDNConnectionType |
Identifies selected PDN session type, see TS 29.274 [87] clause 8.34. |
M |
|
uEEndpoints |
UE endpoint address(es) if available. Derived from the PDN Address portion of the PDN Address Allocation parameter (see TS 29.274 [87] clause 8.14) associated to the PDN Connection in the context known at the NF (see TS 23.401 [50] clauses 5.7.3 and 5.7.4). |
C |
|
non3GPPAccessEndpoint |
UE’s local IP address used to reach the ePDG, if known at the context at the SGW or PGW. |
C |
|
location |
Location information known in the context at the SGW or PGW. |
C |
|
additionalLocation |
Additional location information known in the context at the SGW or PGW, or known at the MDF. |
C |
|
aPN |
Access Point Name associated with the PDN known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4), as defined in TS 23.003[19] clause 9.1. |
M |
|
requestType |
Type of request as derived from the Request Type described in TS 24.301 [50] clause 9.9.4.14 and TS 24.008 [95] clause 10.5.6.17, if available. |
C |
|
accessType |
Access type associated with the PDN connection (i.e. 3GPP or non-3GPP access). |
C |
|
rATType |
RAT Type associated with the PDN connection. Shall be present if known at the context at the SGW or PGW (see TS 23.401 [50] clause 5.6.4). |
C |
|
protocolConfigurationOptions |
Shall be present the Protocol Configuration, Additional Protocol Configuration Options or extended Protocol Configuration Options are known in the context at the SGW or PGW. See Table 6.3.3-4. |
C |
|
servingNetwork |
Shall be present if this IE is in the context for the PDN connection at the SGW/PGW. |
C |
|
bearerContexts |
Shall include a list of the Bearer Contexts present in the UE Context (see TS 23.401 [50] clauses 5.7.3 and 5.7.4). See Table 6.3.3-2. |
M |
6.3.3.2.6 MA PDU Session Establishment message reporting MA PDU session establishment or PDN Connection establishment as part of an MA PDU Session
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFMAPDUSessionEstablishment record (see clause 6.2.3.2.7) when the IRI-POI present in the SMF+PGW-C detects that a PDN Connection has been established for the target UE and associated to a multi-access PDU Session. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C creates a new PDN Connection in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4) and it is associated to an MA PDU session as described in TS 23.502 [4] clause 4.22.2.3.
– The SMF+PGW-C creates a new multi-access PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.2 and clause 5.2.2.7).
When the SMFMAPDUSessionEstablishment record (see clause 6.2.3.2.7) is used to report the creation of a new PDN Connection:
– The ePSPDNConnectionEstablishment field shall be populated with the information in table 6.3.3-1.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFMAPDUSessionEstablishment record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID present in the PCO of the request or response messages or associated to the context for the PDN connection, the pDUSessionID field of the SMFMAPDUSessionEstablishment record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFMAPDUSessionEstablishment record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
6.3.3.2.7 MA PDU Session Modification message reporting MA PDU session modification, modification of a PDN Connection associated to MA PDU session or inter-system handover
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFMAPDUSessionModification record (see clause 6.2.3.2.7) when the IRI-POI present in the SMF+PGW-C detects that an MA PDU Session or PDN Connection associated to an MA PDU Session has been modified for the target UE. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C modifies an existing PDN Connection associated to an MA PDU Session in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C modifies an existing MA PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.3 and clause 5.2.2.8).
– The SMF+PGW-C transfers the 3GPP Access Leg of an existing MA PDU Session to EPS (see TS 23.502 [4] clause 4.22.6).
– The SMF+PGW-C transfers an existing PDN Connection associated to an MA PDU Session to 5GS (see TS 23.502 [4] clause 4.22.6).
When the SMFMAPDUSessionModification record (see clause 6.2.3.2.7) is used to report the modification of a PDN Connection:
– The ePSPDNConnectionModification field shall be populated with the information in table 6.3.3-8.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFMAPDUSessionModification record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID present in the PCO of the request or response messages or associated to the context for the PDN connection, the pDUSessionID field of the SMFMAPDUSessionModification record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFMAPDUSessionModification record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
6.3.3.2.8 MA PDU Session Release message reporting MA PDU session release or the release of a PDN Connection associated to an MA PDU session
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFMAPDUSessionRelease record (see clause 6.2.3.2.7) when the IRI-POI present in the SMF+PGW-C detects that an MA PDU Session or PDN Connection associated to an MA PDU Session has been released for the target UE. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C releases an existing PDN Connection associated to an MA PDU Session in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C releases an existing MA PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.4 and clause 5.2.2.9).
When the SMFMAPDUSessionRelease record (see clause 6.2.3.2.7) is used to report the release of a PDN Connection:
– The ePSPDNConnectionRelease field shall be populated with the information in table 6.3.3-13.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFMAPDUSessionRelease record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID present in the PCO of the request or response messages or associated to the context for the PDN connection, the pDUSessionID field of the SMFMAPDUSessionRelease record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFMAPDUSessionRelease record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
6.3.3.2.9 SMF Start of Interception with Already Established MA PDU Session message reporting Start of Interception with Already Established MA PDU Session or Start of Interception with Already Established PDN Connection associated to an MA PDU Session
The IRI-POI in the SMF+PGW-C shall generate an xIRI containing an SMFStartOfInterceptionWithEstablishedMAPDUSession record (see clause 6.2.3.2.7) when the IRI-POI present in the SMF+PGW-C detects that an MA PDU Session or PDN Connection associated to an MA PDU Session has already been established for the target UE when interception starts. The IRI-POI present in the SMF+PGW-C shall generate the xIRI for the following events:
– The SMF+PGW-C has an existing PDN Connection associated to an MA PDU Session in the target UE context of the SMF+PGW-C (see TS 23.401 [50] clause 5.7.4).
– The SMF+PGW-C has an existing MA PDU Session context or SM Context for the target UE (see TS 29.502 [16] clause 5.2.2.2 and clause 5.2.2.7).
When the SMFStartOfInterceptionWithEstablishedMAPDUSession record (see clause 6.2.3.2.7) is used to report an existing PDN Connection:
– The ePSStartOfInterceptionWithEstablishedPDNConnection field shall be populated with the information in Table 6.3.3-14.
– If there is no SUPI associated to the SM context for the target UE, the SUPI field of the SMFStartOfInterceptionWithEstablishedMAPDUSession record shall be populated with the value of the IMSI from the target UE context.
– If there is no PDU Session ID associated to the context for the PDN connection, the pDUSessionID field of the SMFStartOfInterceptionWithEstablishedMAPDUSession record shall be populated with the EBI of the default bearer for the PDN Connection.
– If there is no 5G UP tunnel present in the context associated to the PDN Connection, the gTPTunnelID field of the SMFStartOfInterceptionWithEstablishedMAPDUSession record shall be populated with the F-TEID for the PGW S5 or S8 interface for the default bearer of the PDN Connection.
6.3.3.2A Triggering of the CC-POI from CC-TF over LI_T3
When CUPS architecture is used and the interception of user plane packets is required, the CC-TF present in the SGW-C/PGW-C sends a trigger to the CC-POI present in the SGW-U/PGW-U over the LI_T3 interface.
6.3.3.3 Generation of xCC at CC-POI in the SGW/PGW and ePDG over LI_X3
6.3.3.3.1 Non-CUPS architecture
The CC-POI present in the SGW/PGW and ePDG shall send xCC over LI_X3 for each IP packet belonging to the target’s communication.
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 SGW/PGW and ePDG 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 per ETSI TS 103 221-2 [8] clause 5.4).
If it is required to send the ICE-type for the xCC, the CC-POI shall set the NFID attribute (see ETSI TS 103 221-2 [8] clause 5.3.7) to the appropriate value from the ICE-type enumeration in TS 33.108 [12] Annex B.10 as a single octet. As an example, an ICE-type of "sgw" is indicated by setting the attribute to value 3.
6.3.3.3.2 CUPS architecture
When CUPS architecture is used, the CC-POI in the SGW-U/PGW-U is provisioned by the CC-TF in the SGW-C/PGW-C using a Triggering message (i.e. ActivateTask message) as described in clause 6.3.3.0.
The CC-POI present in the SGW-U/PGW-U 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 SGW-C/PGW-C.
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 SGW-U/PGW-U 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.
6.3.3.4 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the SGW/PGW or ePDG, the MDF2 shall generate the corresponding IRI message and deliver it over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received in the xIRI over LI_X2.
When option 2 specified in clause 6.3.1 is used, the MDF2 shall generate IRI messages based on the proprietary information received from the SGW/PGW or ePDG and provide it over LI_HI2 without undue delay.
The IRI messages shall include an IRI payload encoded according to clause 10.5 and TS 33.108 [12] Annex B.9. The MDF2 shall encode the correct value of LIID in the IRI message, replacing the value "LIIDNotPresent" given in the xIRI (see clause 6.3.2.2).
The IRI messages shall be delivered over LI_HI2 according to ETSI TS 102 232-7 [10] clause 10.
6.3.3.5 Generation of CC over LI_HI3
When xCC is received over LI_X3 from the CC-POI in the SGW/PGW or ePDG, the MDF3 shall generate the corresponding CC and deliver it over LI_HI3 without undue delay. The CC message shall contain a copy of the relevant xCC received over LI_X3.
When option 2 specified in clause 6.3.1 is used, the MDF3 shall generate CC based on the proprietary information received from the SGW/PGW or ePDG and provide it over LI_HI3 without undue delay.
The CC shall include a CC payload encoded according to TS 33.108 [12] Annex B.10.
The CC shall be delivered over LI_HI3 according to ETSI TS 102 232-7 [10] clause 10.