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