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.