7.2 Central Subscriber Management

33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS

7.2.1 General description

This clause describes interception at central subscriber management functions or databases (e.g. UDM and HSS).

7.2.2 LI at UDM

7.2.2.1 General description

In 3GPP 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 and subscription management related xIRI.

7.2.2.2 Provisioning over LI_X1

The IRI-POI present in the UDM is provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.

The POI in the UDM shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages:

– SUPIIMSI.

– SUPINAI.

– PEIIMEI.

– PEIIMEISV.

– GPSIMSISDN.

– GPSINAI.

7.2.2.3 Generation of xIRI over LI_X2

7.2.2.3.1 General description

The IRI-POI present in the UDM shall send xIRI over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.2.2.4, the details of which are described in the following clauses.

7.2.2.3.2 Serving system

The IRI-POI in the UDM shall generate an xIRI containing the UDMServingSystemMessage record when it detects the following events:

– When the UDM receives the amf3GPPAccessRegistration from the AMF as part of the Nudm_UEContextManagement_Registration service operation (see TS 29.503 [25] clause 5.3.2.2.2).

– When the UDM receives the amfNon3GPPAccessRegistration from the AMF as part of the Nudm_UEContextManagement_Registration service operation (see TS 29.503 [25] clause 5.3.2.2.3).

When a target UE registers to both 3GPP and non-3GPP access, two separate xIRIs each containing the UDMServingSystemMessage record may be generated by the IRI-POI in the UDM.

Table 7.2.2.3-1: Payload for UDMServingSystemMessage record

Field name

Description

M/C/O

sUPI

SUPI associated with the target UE, see TS 29.571 [17].

M

pEI

PEI associated with the target UE, when known, see TS 29.571 17].

C

gPSI

GPSI associated with the target UE, when known, see TS 29.571 [17].

C

gUAMI

Serving AMF’s GUAMI, when known., see NOTE 1.

C

gUMMEI

Serving MME’s GUMMEI, see NOTE 2.

C

pLMNID

Serving PLMN Id. See TS 29.571 [17]. See NOTE 3.

C

servingSystemMethod

Identifies method used to access the serving system, see NOTE 4.

M

serviceID

Identifies the target UE’s 5G service identifiers (e.g. SNSSAI, CAGID) when the AMF Registration is executed, when known, see TS 29.571 [17].

C

roamingIndicator

Boolean which indicates if the serving PLMN is different from the HPLMN. See TS 29.503 [25] clause 6.4.6.2.8.

M

NOTE 1: GUAMI is the global unique identifier of an AMF [2] and its format is defined in TS 29.571 [17]. As defined in TS 23.501 [2] clause 5.9.4, GUAMI consists of <MCC> <MNC> <AMF Region ID> <AMF Set ID> <AMF Pointer>. The GUAMI is reported if the UDM receives the same from the AMF.

NOTE 2: GUMMEI is the global unique identifier of an MME and its format is defined in TS 23.003 [19]. As defined in TS 23.003 [19] clause 2.8.1, GUMMEI consists of <MCC> <MNC> <MME Identifier>. The GUMMEI is reported if the UDM has this information (e.g. in a combined UDM/HSS).

NOTE 3: PLMN Id provides the VPLMN Id when the target UE is roaming.

NOTE 4: This identifies whether the xIRI containing the UDMServingSystemMessage record is generated due to the reception of an amf3GPPAccessRegistration, or an amfNon3GPPAccessRegistration. See TS 29.503 [25].

TS 29.571 [17] requires that the encoding of 3GPP defined identifiers (e.g. IMSI, NAI) shall be prefixed with its corresponding prefix (e.g. with reference to SUPI it requires ‘imsi-‘,’nai-‘). However, identifiers and parameters shall be coded over the LI_X2 and LI_HI2 according to Annex A of the present document, so without the prefix specified in TS 29.571 [17].

The IRI-POI present in the UDM generating an xIRI containing an UDMServingSystemMessage 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).

7.2.2.3.3 Subscriber record change

The IRI-POI in the UDM shall generate an xIRI containing the UDMSubscriberRecordChangeMessage record when it detects the following events:

– When the UDM receives the Amf3GppAccessRegistration from the AMF as part of the Nudm_UEContextManagement Registration service operation (see TS 29.503 [25] clause 5.3.2.2.2) and detects a change in the SUPI/GPSI/PEI association for a target.

– When the UDM receives the AmfNon3GppAccessRegistration from the AMF as part of the Nudm_UEContextManagement Registration service operation (see TS 29.503 [25] clause 5.3.2.2.3) and detects a change in the SUPI/GPSI/PEI association for a target.

– When the UDM receives the Amf3GppAccessRegistrationModification from the AMF as part of Nudm_UEContextManagement Update service operation (see TS 29.503 [25] clause 5.3.2.6.2) and detects a change in the SUPI/GPSI/PEI association for a target.

– When the UDM receives the AmfNon3GppAccessRegistrationModification from the AMF as part of Nudm_UEContextManagement Update service operation (see TS 29.503 [25] clause 5.3.2.6.3) and detects a change in the SUPI/GPSI/PEI association for a target.

– When the UDM receives the PeiUpdateInfo from the HSS as part of the Nudm_UEContextManagement PEI Update service operation (see TS 29.503 [25] clause 5.3.2.10.2) and detects a change in the SUPI/GPSI/PEI association for a target.

– Upon detection of modification between SUPI and GPSI association (if UDR is deployed, when UDM receives the DataChangeNotify from the UDR including the modified GPSI as part of the Nudr_DataRepository Notification service operation (see TS 29.504 [48] clause 5.2.2.8.3 and TS 29.505 [49] clause 5.4.2.6); if UDR is not deployed, when the modification is detected as result of UDM provisioning).

– Upon UE de-provisioning (if UDR is deployed, when UDM receives the DataChangeNotify from the UDR including the deleted SUPI as part of the Nudr_DataRepository Notification service operation (see TS 29.504 [48] clause 5.2.2.8.3 and TS 29.505 [49] clause 5.4.2.6); if UDR is not deployed, when the modification is detected as result of UDM deprovisioning).

– When a new SUPI is provisioned (if UDR is deployed, when UDM receives the DataChangeNotify from the UDR including the new and the old SUPI as part of the Nudr_DataRepository Notification service operation (see TS 29.504 [48] clause 5.2.2.8.3 and TS 29.505 [49] clause 5.4.2.6); if UDR is not deployed, when the modification is detected as result of UDM provisioning).

– When the UDM receives the Amf3GppAccessRegistrationModification from the AMF as part of Nudm_UEContextManagement Update service operation (see TS 29.503 [25] clause 5.3.2.2.2) and detects a change in the ServiceID association for a target.

– Upon detection of modification in the Service ID association (if UDR is deployed, when UDM receives the DataChangeNotify from the UDR including the modified Service ID as part of the Nudr_DataRepository Notification service operation (see TS 29.504 [48] clause 5.2.2.8.3 and TS 29.505 [49] clause 5.4.2.6); if UDR is not deployed, when the modification is detected as a result of UDM provisioning.

When a target UE registers to both 3GPP and non-3GPP access, two separate xIRIs each containing the UDMSubscriberRecordChangeMessage report record may be generated by the IRI-POI in the UDM.

Table 7.2.2.3-2: Payload for UDMSubscriberRecordChangeMessage record

Field name

Description

M/C/O

sUPI

SUPI currently associated with the target UE, see TS 29.571 [17], see NOTE 1

C

pEI

PEI currently associated with the target UE, when known, see TS 29.571 [17].

C

gPSI

GPSI currently associated with the target UE, when known, see TS 29.571 [17].

C

oldSUPI

Old SUPI associated with the target UE, when known.

C

oldServiceID

Identifies the target UE’s old service identifiers (e.g. SNSSAI, CAGID), when known, see TS 29.571 [17].

C

oldPEI

Old PEI associated with the target UE, when known.

C

oldGPSI

Old GPSI associated with the target UE, when known.

C

subscriberRecordChangeMethod

Identifies the trigger of Subscriber Record Change operation, see NOTE 2.

M

serviceID

Identifies the target UE’s 5G service identifiers that have been modified (e.g. SNSSAI, CAGID), when known, see TS 29.571 [17].

C

NOTE 1: When an identity is changed, both the old one and the current one are reported; the target identity is always reported either as current identity or old identity depending on the change, together with the other current identities (e.g. ServiceIDs), if available. If the target identity is changed, the old identity represents the target otherwise the current identity represents the target (as examples, when SUPI is the target and PEI is changing, SUPI (target), PEI and old PEI, along with GPSI, if available, are reported; when SUPI is the target and SUPI is changed, SUPI and oldSUPI (target), along with PEI and GPSI, if available, are reported).

NOTE 2: This identifies whether the xIRI containing the UDMSubscriberRecordChangeMessage record is generated due to a PEI change, a GPSI, a SUPI modification or ServiceID change, or a UE de-provisioning.

The IRI-POI present in the UDM generating an xIRI containing an UDMSubscriberRecordChangeMessage 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).

TS 29.571 [17] requires that the encoding of 3GPP defined identifiers (e.g. IMSI, NAI) shall be prefixed with its corresponding prefix (e.g. with reference to SUPI it requires ‘imsi-‘,’nai-‘). However, identifiers and parameters shall be coded over the LI_X2 and LI_HI2 according to Annex A of the present document, so without the prefix specified in TS 29.571 [17].

7.2.2.3.4 Cancel location

The IRI-POI in the UDM shall generate an xIRI containing the UDMCancelLocation record when it detects the following events:

– When the UDM sends DeregistrationData to AMF as part of the Nudm_UEContextManagement DeregistrationNotification service operation (see TS 29.503 [25] clause 5.3.2.3.2) (e.g. to cancel location retrieval operations).

– When the UDM receives the Amf3GppAccessRegistrationModification with purgeFlag set to true from the AMF as part of Nudm_UEContextManagement Deregistration service operation (see TS 29.503 [25] clause 5.3.2.4.2).

– When UDM receives the AmfNon3GppAccessRegistrationModification with purgeFlag set to true from the AMF as part of Nudm_UEContextManagement Deregistration service operation (see TS 29.503 [25] clause 5.3.2.4.3).

When a target UE deregisters from both 3GPP and non-3GPP access, two separate xIRIs each containing the UDMCancelLocation report record may be generated by the IRI-POI in the UDM.

NOTE: Invocation of the Nudm_UEContextManagement Deregistration service operation in the case of UE deregistration is an implementation option (see TS 23.502 [4], clause 4.5.3). Consequently, the UDMCancel Location xIRI in such case is only generated if this option is supported by the serving network.

Table 7.2.2.3.4-1: Payload for UDMCancelLocationMessage record

Field name

Description

M/C/O

sUPI

SUPI associated with the target UE, see TS 29.571 [17].

M

pEI

PEI associated with the target UE, when known, see TS 29.571 [17].

C

gPSI

GPSI associated with the target UE, when known, see TS 29.571 [17].

C

gUAMI

Previous serving AMF’s GUAMI, when known. See NOTE 1.

C

pLMNID

Previous serving PLMN ID. See TS 29.571 [17]. See NOTE 2.

C

cancelLocationMethod

Identifies method used to access the serving system, see NOTE 3.

M

aMFDeregistrationInfo

Shall include the information sent in the AMF Registration Modification patch record to the UDM (with purgeFlag set to true), including cause information. See TS 29.503 [25] clause 6.2.6.2.7.

C

deregistrationData

Shall identify the reason for the deregistration included in the deregistration notification sent by the UDM. See TS 29.503 [25] clauses 6.2.6.2.5 and 6.2.6.3.3.

C

NOTE 1: GUAMI is the global unique identifier of an AMF [2] and its format is defined in TS 29.571 [17]. As defined in TS 23.501 [2] clause 5.9.4, GUAMI consists of <MCC> <MNC> <AMF Region ID> <AMF Set ID> <AMF Pointer>. The GUAMI is reported if the UDM receives the same from the AMF.

NOTE 2: PLMN ID provides the vPLMN ID when the target UE is roaming.

NOTE 3: This identifies whether the xIRI containing the UDMCancelLocationMessage record is generated due to the reception of a UDM deregistration, and AMF 3GPP Access deregistration, or an AMF Non 3GPP access deregistration.

The IRI-POI present in the UDM generating an xIRI containing an UDMCancelLocationMessage 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).

TS 29.571 [17] requires that the encoding of 3GPP defined identifiers (e.g. IMSI, NAI) shall be prefixed with its corresponding prefix (e.g. with reference to SUPI it requires ‘imsi-‘,’nai-‘). However, identifiers and parameters shall be coded over the LI_X2 and LI_HI2 according to Annex A of the present document, so without the prefix specified in TS 29.571 [17].

7.2.2.3.5 Location information request

Location information request is not supported in the present document.

7.2.2.3.6 Location information result

The IRI-POI in the UDM shall generate an xIRI containing the UDMLocationInformationResult record when it detects the following events:

– When UDM receives the LocationInfoRequest from an NF service consumer (i.e. HSS) as part of Nudm_MT_ProvideLocationInfo service operation (see TS 29.503 [25], clause 6.7.6.2.3) and the UDM sends the LocationInfoResult as part of Nudm_MT_ProvideLocationInfo service operation (see TS 29.503 [25], clause 6.7.6.2.4).

When a target UE is registered to both 3GPP and non-3GPP access, two separate xIRIs each containing the LocationInfoResult report record may be generated by the IRI-POI in the UDM.

Table 7.2.2.3.6-1: Payload for UDMLocationInformationResult record

Field name

Description

M/C/O

sUPI

SUPI currently associated with the target, see TS 29.571 [17].

M

pEI

PEI currently associated with the target UE, when known, see TS 29.571 [17].

C

gPSI

GPSI currently associated with the target UE, when known, see TS 29.571 [17].

C

locationInfoRequest

Indicates the information received from the HSS in the LocationInfoRequest. At least one of the parameters in Table 7.2.2.3.6-2 shall be included. See NOTE below table 7.2.2.3.6-2.

M

vPLMNId

PLMNID of the visited PLMN, if UE is currently registered to visited network.

C

currentLocationIndicator

Shall indicate if the UE location is current or last known. Include if provided in the LocationInfoResult.

C

aMFinstanceID

Provides the NF instance ID of the serving AMF for 3GPP access. Shall be included if provided in the LocationInfoResult.

C

sMSFinstanceID

Provides the NF instance ID of the serving SMSF. Shall be included if provided in the LocationInfoResult.

C

location

Location information available at the UDM at the time of the LocationInfoRequest, include if in LocationInfoResult.

C

rATType

Shall provide the current RAT type of the UE, if present in the LocationInfoResult.

C

problemDetails

Indicates the reason for LocationInfoResult failure. See TS 29.571 [17], clause 5.2.4.1. Shall be included if provided in the LocationInfoResult.

C

Table 7.2.2.3.6-2: Payload for LocationInfoRequest parameter

Field name

Description

req5GSLocation

Boolean that indicates If 5GS location is requested.

reqCurrentLocation

Boolean that indicates if current location is requested.

reqRatType

Boolean indicates if Rat Type is requested.

reqTimeZone

Boolean indicates if time zone is requested.

reqServingNode

Boolean indicates if serving node instance ID is requested.

NOTE: The absence of one or more of the parameters in table 7.2.2.3.6-2 assumes that it was not included in the LocationInfoRequest.

7.2.2.3.7 UE information response

The IRI-POI in the UDM shall generate an xIRI containing the UDMUEInfromationResponse record when it detects the following events:

– When the UDM receives the ProvideUeInfo GET request from the NF service consumer as part of Nudm_MT_ProvideUeInfo service operation (see TS 29.503 [25], clause 6.7.6.2.2) and the UDM returns a UeInfo response.

Table 7.2.2.3.7-1: Payload for UDMUEInformationResponse record

Field name

Description

M/C/O

sUPI

SUPI currently associated with the target UE, see TS 29.571 [17].

M

tADSInfo

Contains the UE Context Information as known at the UDM. See TS 29.518 [22], clause 6.3.6.2.4. Shall be included if UE Context is returned in the UeInfo response.

C

fiveGSUserStateInfo

Describes the 5GS user state of the UE as known at the UDM. See TS 29.518 [22], clause 6.2.6.3.11. Shall be included if 5GS user state is returned in the UeInfo response.

C

fiveGSRVCCInfo

Indicates whether the UE supports 5G SRVCC. See TS 29.503 [25], clause 6.7.6.2.5. Shall be included if returned in the UeInfo response.

C

problemDetails

Indicates the reason for UeInfo response failure. See TS 29.571 [17], clause 5.2.4.1. Shall be included if provided in the UeInfo response.

C

7.2.2.3.8 UE Authentication response

The IRI-POI in the UDM shall generate an xIRI containing the UDMUEAuthenticationResponse record when it detects the following events:

– When the UDM receives the AuthenticationInfoRequest from the AUSF as part of Nudm_UEAuthentication service operation (see TS 29.503 [25], clause 6.3.6.2.2) and the UDM sends the AuthenticationInfoResult to the AUSF as part of the Nudm_UEAuthentication service operation (see TS 29.503 [25], clause 6.3.6.2.3).

– When the UDM receives the HSSAuthenticationInfoRequest from the HSS as part of the Nudm_UEAuthentication service operation (see TS 29.503 [25], clause 6.3.6.2.10) and the UDM sends the HSSAuthenticationInfoResult to the AUSF as part of the Nudm_UEAuthentication service operation (see TS 29.503 [25], clause 6.3.6.2.11).

When a target UE registers from both 3GPP and non-3GPP access, two separate xIRIs each containing the UDMUEAuthentication report record may be generated by the IRI-POI in the UDM.

Table 7.2.2.3.8-1: Payload for UDMUEAuthenticationResponse record

Field name

Description

M/C/O

sUPI

SUPI currently associated with the target UE, see TS 29.571 [17].

M

authenticationInfoRequest

Indicateds information provided in the UEAuthenticationInfoRequest. See Table 7.2.2.3.8-2 for details of payload.

M

aKMAIndicator

Indicates whether AKMA keys are needed for the UE, Shall be included if AKMA keys are requested in the AuthenticationInfoRequest.

C

problemDetails

Shall Indicate reason for AuthenticationInfoResultfailure. Shall be included if failure occurs. See TS 29.571 [17], clause 5.2.4.1.

C

Table 7.2.2.3.8-2: Payload for AuthenticationInfoRequest parameter

Field name

Description

M/C/O

infoRequestType

Indicates whether the AuthenticationInfoRequest was sent by the HSS, AUSF or other.

M

rGAuthCtx

Contains the UE ID (i.e. SUPI, SUCI) provided in the authentication indication, at least one shall be present.

M

authType

Indicates the authentication method provided by the HSS or AUSF in the AuthenticationInfoRequest.

M

servingNetworkName

Serving network name. See TS 33.501 [11] clause 6.1.1.4.

M

aUSFInstanceID

Identifies the AUSF instance which generated the AuthenticationInformatoinRequest. Shall be included if known.

C

cellCagInfo

Provides CAG cell information (e.g. CAGId) if UE is attempting registration from a CAG.

C

n5GCIndicator

Boolean value that indicates whether the device is a N5GC device. Include if provided in the AuthenticationInfoRequest.

C

7.2.2.3.9 Start of Interception with UE registered at the UDM

The IRI-POI in the UDM shall generate an xIRI containing the UDMStartOfInterceptionWithRegisteredTarget record when the IRI-POI present in the UDM detects that interception is activated for a UE that has already been registered in the UDM. A UE is considered registered in the UDM when the UDM has a current UE context management entry (see TS 29.503 [25], clauses 5.3.2.2 and 6.2), over at least one access type.

When a target UE is registered on both 3GPP and non-3GPP access, a single UDMStartofInterceptionWithRegisteredTarget record including context information from both accesses shall be generated by the IRI-POI in the UDM.

Table 7.2.2.3.9-1: Payload for UDMStartOfInterceptionWithRegisteredTarget record

Field name

Description

M/C/O

sUPI

SUPI associated with the target UE, see TS 29.571 [17].

M

gPSI

GPSI associated with the target UE, when known, see TS 29.571 [17].

C

uDMSubscriptionDataSets

Includes current subscription information for the target UE stored at the UDM. Encoded according to TS 29.503 [25] clause 6.1.6.2.15 (schema definition reference TS29503_Nudm_SDM.yaml).

M

7.2.2.4 Generation of IRI over LI_HI2

When an xIRI is received over LI_X2 from the IRI-POI in UDM, the MDF2 shall send an IRI message over LI_HI2 without undue delay.

The timestamp field of the PSHeader structure shall be set to the time that the UDM 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 7.2.2-4.

Table 7.2.2-4: IRI type for IRI messages

IRI message

IRI type

UDMServingSystemMessage

REPORT

UDMSubscriberRecordChangeMessage

REPORT

UDMCancelLocationMessage

REPORT

UDMLocationInformationResult

REPORT

UDMUEInformationResponse

REPORT

UDMUEAuthenticationResponse

REPORT

UDMStartOfInterceptionWithRegisteredTarget

REPORT

These IRI messages shall omit the CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).

7.2.3 LI at HSS

7.2.3.1 General

The HSS provides the support functions in the mobility management, session setup and user authentication and access authorization.

The present document allows two options for HSS LI stage 3 interfaces:

1. Use LI_X1 and LI_X2 interfaces specified below in the present document for stage 3.

2. Use TS 33.107 [36] natively as defined in that document in addition to the start of intercept with target already registered at the HSS xIRI defined in clause 7.2.3.3.3 of the present document.

In both cases, the present document specifies the stage 3 for the LI_HI1 and LI_HI2 interfaces.

When the HSS is capable of exchanging information related to the target with the UDM (e.g. via the 5G Nhss SBI), the xIRIs defined in clause 7.2.3.3 of the present document are applicable for stage 3 reporting of such events.

7.2.3.2 Provisioning over LI_X1

The IRI-POI present in the HSS is provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2 of the present document.

The IRI-POI in the HSS shall support the target identifiers specified in TS 33.107 [36]:

– 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]).

– IMEI (using the IMEI target identifier format from ETSI TS 103 221-1 [7]).

– IMPU (using the IMPU target identifier format from ETSI TS 103 221-1 [7]).

– IMPI (using the IMPI target identifier format from ETSI TS 103 221-1 [7]).

7.2.3.3 Generation of xIRI over LI_X2

7.2.3.3.1 General description

The IRI-POI present in the HSS shall send the xIRIs over LI_X2 for each of the events listed in TS 33.107 [36], the details of which are also specified in TS 33.107 [36].

The IRI-POI present in the HSS shall set the payload format to EpsHI2Operations.EpsIRIContent (value 14), see clause 5.3 of the present document 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] clause B.9.

As the LIID may be not available at the HSS but is mandatory in EpsHI2Operations.EpsIRIContent according to TS 33.108 [12] clause B.9, its value in the lawfulInterceptionIdentifier field of the encoded PDU shall be set to the fixed string "LIIDNotPresent".

When the HSS interworks with the UDM via the Nhss service based interfaces, the IRI-POI present in the HSS shall send xIRI over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.2.2.3 the details of which are described in the following clauses.

7.2.3.3.2 Serving system

The IRI-POI in the HSS shall generate an xIRI containing the HSSServingSystemMessage record when it detects the following events:

– When the HSS receives the Roaming Status Update from the UDM as part of the Nhss_UEContextManagement_RoamingStatusUpdate service operation (see TS 29.563 [100] clause 5.4.2.4).

Table 7.2.3.3.2-1: Payload for HSSServingSystemMessage record

Field name

Description

M/C/O

iMSI

IMSI associated with the target UE, See TS 29.563 [100] clause 6.3.6.2.5.

M

oldPLMNID

Includes the old PLMN for which the UE was previously registered.

M

newPLMNID

Indicates the new PLMN to which the UE is now registered.

M

roamingIndicator

Indicates if the serving PLMNID is different than the HPLMN or EHPLMN.

M

responseCode

Includes the response code as sent from HSS to UDM in the POST response. See TS 29.563 [100] clause 6.3.4.4.2 for details of this structure.

M

7.2.3.3.3 Start of Interception with target registered at the HSS

The IRI-POI in the HSS shall generate an xIRI containing the HSSStartOfInterceptionWithRegisteredTarget record when the IRI-POI present in the HSS detects that interception is activated for a UE that has already been registered at the HSS.

The HSS may have stored target subscription data for both EPC and IMS. In such a case, a single HSS Start of Interception with Registered Target xIRI shall be generated containing the target context.

Table 7.2.3.3.3-1: Payload for HSSStartOfInterceptionWithRegisteredTarget record

Field name

Description

M/C/O

hSSIdentities

Indicates the identifiers for which the subscription data sets apply. Shall include one or more subscriber identifier. See TS 29.562 [101] clause 6.2.3.1.

M

subscriptionDataSets

Includes current subscription information for the target UE stored at the HSS. Encoded according to TS 29.562 [101] clause 6.2.6.2.4. The SBIReference for this parameter shall be populated with ‘TS29562_Nhss_imsSDM.yaml#/components/schemas/ImsProfileData’.

C

pSUserState

Indicates the user state in the PS domain as known at the HSS. Encoded according to TS 29.562 [101] clause 6.2.6.3.15. The SBIReference for this parameter shall be populated with ‘TS29562_Nhss_imsSDM.yaml #/components/schemas/PsUserState’.

C

7.2.3.4 Generation of IRI over LI_HI2

When an xIRI is received over LI_X2 from the IRI-POI in the HSS, 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 7.2.3.1 above is used, the MDF2 shall generate IRI messages based on the proprietary information received from the HSS, except for the HSSStartOfInterceptionWithRegisteredTarget, and provide it over LI_HI2 without undue delay.

The IRI messages shall include an IRI payload encoded according to TS 33.108 [12] clause 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 7.2.3.3 above).

The IRI messages shall omit the CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).

The IRI messages shall be delivered over LI_HI2 according to ETSI TS 102 232-7 [10] clause 10.

Table 7.2.3.4-1: IRI type for IRI messages

IRI message

IRI type

HSSServingSystemMessage

REPORT

HSSStartOfInterceptionWithRegisteredTarget

REPORT

When an additional warrant is activated on a target 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 HSSStartOfInterceptionWithRegisteredTarget record to the LEMF associated with the additional warrant without receiving a corresponding xIRI. The payload of the HSSStartOfInterceptionWithRegisteredTarget record is specified in table 7.2.3.3.3-1.