7.7 LI at NEF
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
7.7.1 Provisioning over LI_X1
7.7.1.1 General
For NIDD using NEF:
– If delivery type for the warrant is "IRI and CC", then the IRI-POI and the CC-POI in the NEF, the MDF2 and MDF3 shall be provisioned.
– If delivery type for the warrant is "IRI", then the IRI-POI in the NEF and the MDF2 shall be provisioned.
– Delivery type "CC" is not applicable to the warrant.
For device triggering, MSISDN-less MO SMS and Parameter Provisioning:
– the delivery type for the warrant is "IRI"; the IRI-POI in the NEF and the MDF2 shall be provisioned.
7.7.1.2 Provisioning of the IRI-POI and CC-POI in NEF
The IRI-POI and CC-POI present in the NEF are provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The POI in the NEF shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– SUPIIMSI.
– SUPINAI.
– GPSIMSISDN.
– GPSINAI.
NOTE: For Parameter Provisioning, only GPSIMSISDN and GPSINAI are applicable.
7.7.2 LI for NIDD using NEF
7.7.2.1 Generation of xIRI at IRI-POI in NEF over LI_X2
7.7.2.1.1 General
The IRI-POI present in the NEF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.9.2.3, the details of which are described in the following clauses. Each event will be based on PDU session between NEF and target UE, except for Unsuccessful Procedure event. The IRI-POI in the NEF shall also send a SeparatedLocationReporting xIRI (as described in clause 7.3.4.1) when the IRI-POI provisioned in the NEF receives updated UE location information via the Nnef_Location_LocationUpdateNotify service operation destined for an external AF.
7.7.2.1.2 PDU session establishment
The IRI-POI in the NEF shall generate an xIRI containing an NEFPDUSessionEstablishment record when the IRI-POI present in the NEF detects that an unstructured PDU session using NEF has been established for the target UE. The IRI-POI present in the NEF shall generate the xIRI for the following event:
– NEF returns Nnef_SMContext_Create Response towards the SMF confirming the establishment of the unstructured PDU session to the NEF for the target UE (as defined in TS 29.541 [57] clause 5.2.2.2) and connection to the AF is established.
Table 7.7.2-1: NEFPDUSessionEstablishment record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the SMF in the associated Nnef_SMContext_Create Request). |
M |
gPSI |
GPSI associated with the PDU session. |
M |
pDUSessionID |
PDU Session ID. |
M |
sNSSAI |
Slice identifier associated with the PDU session. |
C |
nEFID |
NEF identity handling the PDU session. |
M |
dNN |
Data Network Name associated with the target traffic. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
M |
rDSSupport |
True if Reliable Data Service is supported in the PDU session, otherwise False. |
M |
sMFID |
Identifier of the SMF associated with the target UE for that that PDU Session. |
M |
aFID |
Identifier of the AF. |
M |
7.7.2.1.3 PDU session modification
The IRI-POI in the NEF shall generate an xIRI containing an NEFPDUSessionModification record when the IRI-POI present in the NEF detects that an unstructured PDU session using NEF has been modified for the target UE. The IRI-POI present in the NEF shall generate the xIRI for the following events:
– NEF returns Nnef_SMContext_Update Response to SMF to confirm the modification of the connection between SMF and NEF (see TS 29.541 [57] clause 5.2.2.5).
– NEF returns a RDS MANAGE PORT Response to a UE with a "Status" field set to "Success" in response to a RDS MANAGE PORT command sent by UE with an "Action" field set to "Reserve port" to confirm the reservation of a combination of source and destination port numbers for use for a traffic to be sent by the UE to a specific application on an AF (see TS 24.250 [61] clause 5.4.2.6.2).
– NEF receives a RDS MANAGE PORT Response from a UE with a "Status" field set to "Success" in response to a RDS MANAGE PORT command sent by the NEF with an "Action" field set to "Reserve port” to confirm the reservation of a combination of source and destination port numbers for use for a traffic to be sent by an AF to a specific application on the UE (see TS 24.250 [61] clause 5.4.2.6.2).
– NEF returns a RDS MANAGE PORT Response to a UE with a "Status" field set to "Success" in response to a RDS MANAGE PORT command sent by UE with an "Action" field set to "Release port" to confirm the release of a combination of source and destination port numbers for an application on an AF (see TS 24.250 [61] clause 5.4.2.6.3).
– NEF receives a RDS MANAGE PORT Response from a UE with a "Status" field set to "Success" in response to a RDS MANAGE PORT command sent by the NEF with an "Action" field set to "Release port" to confirm the release of a combination of source and destination port numbers for an application on the UE (see TS 24.250 [61] clause 5.4.2.6.3).
Table 7.7.2-2: NEFPDUSessionModification record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the PDU session |
M |
gPSI |
GPSI associated with the PDU session |
M |
sNSSAI |
Slice identifier associated with the PDU session |
M |
Initiator |
Initiator of the modification of the PDU session, UE, SMF or NEF |
M |
rDSSourcePortNumber |
RDS source port number |
C |
rDSDestinationPortNumber |
RDS destination port number |
C |
applicationID |
Application identifier on the UE or on the AF if RDS is used |
C |
aFID |
Identifier of the AF if RDS is used |
C |
rDSAction |
Action if RDS is used. Possible values: "ReservePort", "ReleasePort" |
C |
serializationFormat |
Data format exchanged between UE and AF if RDS is used |
C |
7.7.2.1.4 PDU session release
The IRI-POI in the NEF shall generate an xIRI containing an NEFPDUSessionRelease record when the IRI-POI present in the NEF detects that an unstructured PDU session using NEF related to the target UE needs to be released. The IRI-POI present in the NEF shall generate the xIRI for the following events:
– NEF notifies the SMF that the SMF-NEF Connection for NIDD via NEF is no longer valid using Nnef_SMContext_DeleteNotify service operation when NEF receives a notification from the UDM that the NIDD authorization has ended. NEF releases the SM Context for NIDD on NEF as described in TS 29.541 [57] clause 5.2.2.4. This corresponds to NEF Initiated SMF-NEF Connection Release procedure.
– NEF returns Nnef_SMContext_Delete Response towards SMF confirming release of the SMF-NEF session for the target UE. In this scenario, SMF releases the SM Context for NIDD on NEF as specified in TS 29.541 [57] clause 5.2.2.3).
Table 7.7.2-3: NEFPDUSessionRelease record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the PDU session |
M |
gPSI |
GPSI associated with the PDU session |
M |
pDUSessionID |
PDU Session ID as assigned by the AMF |
M |
timeOfFirstPacket |
Time of first packet for the PDU session |
C |
timeOfLastPacket |
Time of last packet for the PDU session |
C |
uplinkVolume |
Number of uplink octets for the PDU session |
C |
downlinkVolume |
Number of downlink octets for the PDU session |
C |
releaseCause |
Cause of PDU Session Release |
M |
7.7.2.1.5 Unsuccessful procedure
The IRI-POI in the NEF shall generate an xIRI containing an NEFUnsuccessfulProcedure record when the IRI-POI present in the NEF detects an unsuccessful procedure or error condition for a UE matching one of the target identifiers provided via LI_X1.
Accordingly, the IRI-POI in the NEF generates the xIRI when one of the following events are detected as described in TS 29.541 [57] clause 6.1.7.3 and TS 24.250 [61] clause 5.4.2.6:
– NEF sends a Nnef_SMContext_Create Reject message to the SMF with a reject cause set to "USER_UNKNOWN" or "NIDD_CONFIGURATION_NOT_AVAILABLE".
– NEF sends a Nnef_SMContext_Update Reject message to the SMF with a reject cause set to "CONTEXT_NOT_FOUND".
– NEF sends a Nnef_SMContext_Delete Reject message to the SMF with a reject cause set to "CONTEXT_NOT_FOUND".
– NEF returns a RDS MANAGE PORT Response to a UE with a "Status" field set to "Port not free" in response to a RDS MANAGE PORT command sent by UE with an "Action" field set to "Reserve port".
– NEF receives a RDS MANAGE PORT Response from a UE with a "Status" field set to "Port not free" in response to a RDS MANAGE PORT command sent by NEF with an "Action" field set to "Reserve port".
– NEF returns a RDS MANAGE PORT Response to a UE with a "Status" field set to "Port not associated with specified application" in response to a RDS MANAGE PORT command sent by UE with an "Action" field set to "Release port".
– NEF receives a RDS MANAGE PORT Response from a UE with a "Status" field set to "Port not associated with specified application" in response to a RDS MANAGE PORT command sent by NEF with an "Action" field set to "Release port".
Table 7.7.2-4: NEFUnsuccessfulProcedure record
Field name |
Value |
M/C/O |
failureCause |
Provides the value of the failure cause. |
M |
sUPI |
SUPI associated with the procedure. |
M |
gPSI |
GPSI used in the procedure, if available. |
C |
pDUSessionID |
PDU Session ID. |
C |
dNN |
Data Network Name associated with the target traffic, if available. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
C |
sNSSAI |
Slice requested for the procedure, if available. |
C |
rDSDestionationPortNumber |
RDS destination port number. |
C |
applicationID |
Application associated with the RDS destination port number. |
C |
aFID |
Application Function identifier. |
C |
7.7.2.1.6 Start of interception with established PDU session
The IRI-POI in the NEF shall generate an xIRI containing an NEFStartOfInterceptionWithEstablishedPDUSession record when the IRI-POI present in the NEF detects that an unstructured PDU session using NEF has already been established, at the time the POI on NEF is provisioned with a new target ID.
The IRI-POI in the NEF shall generate the xIRI containing the NEFStartOfInterceptionWithEstablishedPDUSession record for each of the PDU sessions for NIDD using NEF associated with the target UE with a different value of correlation information.
Table 7.7.2-5: NEFStartOfInterceptionWithEstablishedPDUSession record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the PDU session (e.g. as provided by the SMF in the associated Nnef_SMContext_Create Request). |
M |
gPSI |
GPSI associated with the PDU session. |
M |
pDUSessionID |
PDU Session ID. |
M |
sNSSAI |
Slice identifier associated with the PDU session. |
M |
dNN |
Data Network Name associated with the target traffic. Shall be given in dotted-label presentation format as described in TS 23.003 [19] clause 9.1. |
M |
nEFID |
NEF identity handling the PDU session. |
M |
rDSSupport |
True if Reliable Data Service is supported in the PDU session, otherwise False. |
M |
sMFID |
Identifier of the SMF associated with the target UE for that that PDU Session. |
M |
aFID |
String Identifying the AF the traffic will be delivered to. |
M |
The IRI-POI present in the SMF generating an xIRI containing a NEFStartOfInterceptionWithEstablishedPDUSession 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).
7.7.2.2 Generation of xCC at CC-POI in NEF over LI_X3
The CC-POI present in the NEF shall send xCC over LI_X3 for each NIDD packet.
Each X3 PDU shall contain the contents of the user plane packet (i.e. NIDD) using an unstructured payload format.
The CC-POI present in the NEF shall set the payload format to indicate the appropriate payload type (i.e. unstructured payload) as described in ETSI TS 103 221-2 [8] clause 5.4.
7.7.2.3 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the NEF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the NEF 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.7.2-6.
Table 7.7.2-6: IRI type for IRI messages
Record type |
IRI Type |
NEFPDUSessionEstablishment |
BEGIN |
NEFPDUSessionRelease |
END |
NEFPDUSessionModification |
CONTINUE |
NEFStartOfInterceptionWithEstablishedPDUSession |
BEGIN |
NEFUnsuccessfulProcedure |
REPORT or CONTINUE |
IRI messages associated with the same PDU Session shall be assigned the same CIN (see ETSI TS 102 232-1 [9] clause 5.2.4).
The threeGPP33128DefinedIRI field (see ETSI TS 102 232-7 [10] clause 15) shall be populated with the BER-encoded IRIPayload.
7.7.2.4 Generation of CC over LI_HI3
When xCC is received over LI_X3 from the CC-POI in the NEF, the MDF3 shall populate the threeGPP33128DefinedCC field with a CCPayload structure containing NIDDCCPDU and send it over LI_HI3 interface to LEMF without undue delay.
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time that the NEF observed the data (i.e. the timestamp field of the xCC). The LIID and CID fields shall correctly reflect the target identity and communication session to which the CC belongs.
7.7.3 LI for device triggering
7.7.3.1 Generation of xIRI LI_X2 at IRI-POI in NEF over LI_X2
7.7.3.1.1 General
The IRI-POI present in the NEF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.9.3.4, the details of which are described in the following clauses.
7.7.3.1.2 Device trigger
The IRI-POI in the NEF shall generate an xIRI containing a NEFDeviceTrigger record when the IRI-POI present in the NEF detects that an AF has sent a Device trigger to a target UE matching one of the target identifiers.
Accordingly, the IRI-POI in the NEF generates the xIRI when any of the following events is detected:
– NEF sends a Nnef_Trigger_Delivery Response to the AF to acknowledge the reception of Nnef_Trigger_Delivery Request with GPSI matching the target identifier (see TS 23.502 [4] clause 4.13.2.1 and TS 29.522 [58] clause 4.4.3).
– NEF sends a T4 Device-Trigger-Request (DTR) to SMS-SC with Trigger-Action AVP set to TRIGGER and User-Identifier AVP matching the SUPI of the target UE as described in TS 29.337 [60] clause 5.2.1.
Table 7.7.3-1: NEFDeviceTrigger record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the UE. |
M |
gPSI |
GPSI used with the UE. |
M |
triggerId |
Identity of the Device trigger that should be provided in the deviceTriggeringDeliveryReportNotification IRI, Device trigger replacement IRI and Device trigger cancellation IRI. |
M |
aFID |
The AF sending the Device trigger. |
M |
triggerPayload |
The Device triggering payload. |
C |
validityPeriod |
The validity time in seconds for the specific action requested. |
C |
priorityDT |
The priority indication for a trigger payload. |
C |
sourcePortId |
Application identity on the AF which delivers the Device trigger. |
C |
destinationPortId |
Used to uniquely identify the triggering application addressed in the device. |
C |
7.7.3.1.3 Device trigger replace
The IRI-POI in the NEF shall generate an xIRI containing a NEFDeviceTriggerReplace record when the IRI-POI present in the NEF detects that an AF has sent a Device trigger replacement for a previously sent Device trigger to a UE matching one of the target identifiers provided via LI_X1 to the IRI POI in the NEF. It replaces a previously submitted Device trigger message which has not yet been delivered to the UE.
Accordingly, the IRI-POI in the NEF generates the xIRI when any of the following events is detected:
– NEF receives a Nnef_Trigger_Delivery Request (for a device trigger replacement) from an AF as described in TS 29.522 [58] clause 4.4.3 with GPSI matching the target identifier.
– NEF sends a T4 Device-Trigger-Request (DTR) to SMS-SC with Trigger-Action AVP set to REPLACE and User-Identifier AVP matching the SUPI of the target UE as specified in 29.337 [60] clause 5.2.1.
Table 7.7.3-2: NEFDeviceTriggerReplace record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the target UE. |
M |
gPSI |
GPSI used with the taget UE. |
M |
triggerId |
Identity of the corresponding Device trigger to be replaced. |
M |
aFID |
The AF replacing an existing Device trigger which has not been delivered yet to the device (e.g. because the device is unreachable) by a new Device trigger. |
M |
triggerPayload |
The device triggering payload. |
C |
validityPeriod |
The validity time in seconds for the specific action requested. |
C |
priorityDT |
Priority indication for a trigger payload. |
C |
sourcePortId |
Port on the AF which delivers the device trigger. |
C |
destinationPortId |
Port on the device which is the recipient of the device trigger. |
C |
7.7.3.1.4 Device trigger cancellation
The IRI-POI in the NEF shall generate an xIRI containing a NEFDeviceTriggerCancellation record when the IRI-POI present in the NEF detects that an AF has sent a Device trigger cancellation for a previously sent Device trigger to a UE matching one of the target identifiers provided via LI_X1 to the IRI-POI in the NEF. It cancels previously submitted Device trigger message which has not yet been delivered to the target UE.
Accordingly, the IRI-POI in the NEF generates the xIRI when any of the following events is detected:
– NEF receives a Nnef_Trigger_Delivery Request (for a device trigger cancellation) with GPSI matching the target identifier as described in TS 29.522 [58] clause 4.4.3.
– NEF sends a T4 Device-Trigger-Request (DTR) to SMS-SC with Trigger-Action AVP set to RECALL and User-Identifier AVP matching the SUPI of the target UE as specified in TS 29.337 [60] clause 5.2.1.
Table 7.7.3-3: NEFDeviceTriggerCancellation record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the target UE. |
M |
gPSI |
GPSI used with the target UE. |
M |
triggerId |
Identity of the corresponding device trigger to be cancelled. |
M |
7.7.3.1.5 Device trigger report notification
The IRI-POI in the NEF shall generate an xIRI containing a NEFDeviceTriggerReportNotify record when the IRI-POI present in the NEF detects that the NEF has returned a Device trigger report to the AF with a cause value indicating the trigger delivery outcome (e.g. succeeded, unknown or failed).
Accordingly, the IRI-POI in the NEF generates the xIRI when any of the following events is detected:
– NEF sends a Nnef_Trigger_DeliveryNotify service operation with the GPSI of the target UE to inform the AF on the delivery outcome of the device trigger as described in TS 29.522 [58] clause 4.4.3.
– SMS-SC sends a T4 Delivery-Report-Request (DRR) to the NEF with User-Identifier matching the SUPI of the target UE as specified in 29.337 [60] clause 5.2.2.
Table 7.7.3-4: NEFDeviceTriggerReportNotify record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the target UE. |
M |
gPSI |
GPSI used with the target UE. |
M |
triggerId |
Identity of the corresponding Device trigger. |
M |
deviceTriggerDeliveryResult |
Delivery result represents the result of the delivery of a device triggering request: – SUCCESS: The value indicates that the device action request was successfully completed. – UNKNOWN: The value indicates any unspecified errors. – FAILURE: The value indicates that this trigger encountered a delivery error and is deemed permanently undeliverable. – TRIGGERED: The value indicates that Device triggering request is accepted by the NEF. – EXPIRED: The value indicates that the validity period expired before the trigger could be delivered. – UNCONFIRMED: The value indicates that the delivery of the device action request is not confirmed. – REPLACED: The value indicates that the device triggering replacement request is accepted by the NEF. – TERMINATE: The NEF includes this value in the response for a successful device triggering cancellation request. The value indicates that the delivery of the device action request is terminated by the AF. |
M |
7.7.3.2 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the NEF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the NEF 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.7.3-5.
Table 7.7.3-5: IRI type for IRI messages
Record type |
IRI Type |
NEFDeviceTrigger |
REPORT |
NEFDeviceTriggerReplace |
REPORT |
NEFDeviceTriggerCancellation |
REPORT |
NEFDeviceTriggerReportNotify |
REPORT |
7.7.4 LI for MSISDN-less MO SMS
7.7.4.1 Generation of xIRI LI_X2 at IRI-POI in NEF over LI_X2
7.7.4.1.1 General
The IRI-POI present in the NEF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.9.4.4, the details of which are described in the following clauses.
7.7.4.1.2 MSISDN-less MO SMS
The IRI-POI in the NEF shall generate an xIRI containing a NEFMSISDNLessMOSMS record when the IRI-POI present in the NEF detects that a target UE has sent a MSISDN-less MO SMS to an AF.
Accordingly, the IRI-POI in the NEF generates the xIRI when any of the following events is detected:
– NEF receives a SGd MO-Forward-Short-Message-Request (OFR) from an SMS-SC with SUPI matching the target identifier (see TS 29.338 [59] clause 6.2.1).
– NEF sends a Nnef_MSISDN-less_MO_SMSNotify service operation to the AF with the GPSI of the target UE sending the MSISDN-less SMS as described in TS 29.522 [58] clause 4.4.10.
Table 7.7.4-1: NEFMSISDNLessMOSMS record
Field name |
Value |
M/C/O |
sUPI |
SUPI associated with the target UE. |
M |
gPSI |
GPSI in the form of an external identifier as username@realm and corresponding to the identity of the originating SMS party. |
M |
terminatingSMSParty |
Identity of the AF receiving the SMS. |
M |
sMS |
SMS TPDU. |
C |
sourcePort |
port identifying the application of the target UE sending the MSISN-less MO SMS. |
C |
destinationPort |
port identifying the application of the AF which is the recipient of the MSISN-less MO SMS. |
C |
7.7.4.2 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the NEF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the NEF 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.7.4-2.
Table 7.7.4-2: IRI type for IRI messages
Record type |
IRI Type |
NEFMSISDNLessMOSMS |
REPORT |
7.7.5 LI for parameter provisioning
7.7.5.1 Generation of xIRI LI_X2 at IRI-POI in NEF over LI_X2
7.7.5.1.1 General
The IRI-POI present in the NEF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.9.5.4, the details of which are described in the following clauses.
7.7.5.1.2 Expected UE behavior update
The IRI-POI in the NEF shall generate an xIRI containing an NEFExpectedUEBehaviorUpdate record when the IRI-POI present in the NEF detects that an AF has updated the UE Expected behavior data.
Accordingly, the IRI-POI in the NEF generates the xIRI when any of the following events is detected (see TS 29.503 [25] clauses 5.6.2.1 and 6.1.6.2.49):
– NEF receives a NEF_ParameterProvision_Create Request or NEF_ParameterProvision_Update Request from an AF, related to the target UE.
– NEF receives a NEF_ParameterProvision_Delete Request from an AF to delete the existing UE Expected Behaviour parameters related to the target UE.
– NEF returns a NEF_ParameterProvision_Get Response containing the UE Expected Behavior of the target UE to the querying AF.
Table 7.7-5-1: NEFExpectedUEBehaviorUpdate record
Field name |
Value |
M/C/O |
gPSI |
GPSI of the target UE to which the expected UE behavior applies. |
M |
expectedUEMovingTrajectory |
Identifies the UE’s expected geographical movement. |
O |
stationaryIndication |
Identifies whether the UE is stationary or mobile. |
O |
communicationDurationTime |
Indicates for how long the UE will normally stay in CM-Connected for data transmission expressed in seconds. |
O |
periodicTime |
Interval Time of periodic communication in seconds. |
O |
scheduledCommunicationTime |
Time and day of the week when the UE is available for communication, as defined in TS 29.571 [17]. |
O |
batteryIndication |
Identifies power consumption criticality for the UE: if the UE is battery powered but the battery is not rechargeable/not replaceable, battery powered with rechargeable/replaceable battery, or not battery powered. |
O |
trafficProfile |
Identifies the type of data transmission: single packet transmission (UL or DL), dual packet transmission (UL with subsequent DL or DL with subsequent UL), multiple packets transmission. |
O |
scheduledCommunicationType |
Indicates that the Scheduled Communication Type is Downlink only or Uplink only or Bi-directional. |
O |
expectedTimeAndDayOfWeekInTrajectory |
Identifies the time and day of week when the UE is expected to be at each location included in the Expected UE Moving Trajectory. |
O |
aFID |
AF identity requesting expected UE behavior update. |
M |
validityTime |
Identifies when the expected UE behavior parameter set expires and shall be deleted. If absent, it indicates that there is no expiration time for this parameter set. |
O |
7.7.5.2 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the NEF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the NEF 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.7.4-2.
Table 7.7.5-2: IRI type for IRI messages
Record type |
IRI Type |
NEFExpectedUEBehaviorUpdate |
REPORT |