5 ATSSS control procedures

24.1933GPP5G SystemAccess Traffic Steering, Switching and Splitting (ATSSS)Release 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

The ATSSS control procedures include:

a) multi-access PDU connectivity service procedures (see clause 5.2);

b) multi-access PDU connectivity over E-UTRAN and non-3GPP access network (see clause 5.3); and

c) performance measurement function protocol procedures (see clause 5.4).

In clause 5.2, multi-access PDU connectivity service procedures include following management procedures:

a) activation of multi-access PDU connectivity service;

b) re-activation of user-plane resources;

c) release of user-plane resources;

d) updating ATSSS parameters;

e) converting PDU session transferred from EPS to MA PDU session; and

f) PDU session establishment with network modification to MA PDU session.

In clause 5.3, the multi-access PDU connectivity procedures over E-UTRAN and non-3GPP access network are specified.

In clause 5.4, performance measurement function protocol procedures are performed by exchanges of PMF protocol messages between the PMF in a UE and the PMF in the UPF over the user plane. For MA PDU sessions of IPv4, IPv6, or IPv4v6 PDU session type, the PMF protocol messages are transported using UDP. For MA PDU sessions of Ethernet PDU session type, the PMF protocol messages are transported using Ethernet frames. The protocol stacks of the PMF protocol are specified in clause 5.32.5.4 of 3GPP TS 23.501 [2].

5.2 Multi-access PDU connectivity service

5.2.1 Activation of multi-access PDU connectivity service

Activating multi-access PDU connectivity service refers to the establishment of user-plane resources on both 3GPP access and non-3GPP access:

a) if the UE is registered over both 3GPP access and non-3GPP access in the same PLMN, the UE shall initiate the UE-requested PDU session establishment procedure as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over a selected access, either 3GPP access or non-3GPP access. Over which access to initiate this UE-requested PDU session establishment procedure is UE implementation specific. When the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6], the UE shall consider that the MA PDU session has been established and the user plane resources are successfully established on the selected access. When the user plane resources are established on the access other than the selected access (e.g. received lower layer indication in 3GPP access or established user plane IPsec SA in untrusted non-3GPP access), the UE shall consider the user plane resources are established on both;

NOTE: If the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE and fails to receive user plane resources established on the access other than the selected access, upon an implementation specific timer expiry the UE re-initiates the UE-requested PDU session establishment procedure over the access other than the selected access, in order to establish user plane resources on the access other than the selected access.

b) if the UE is registered over both 3GPP access and non-3GPP access in different PLMNs, the UE shall initiate the UE-requested PDU session establishment procedure as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over 3GPP access and non-3GPP access sequentially. Over which access to first initiate the UE-requested PDU session establishment procedure is UE implementation specific. When the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the selected access, the UE shall consider that the MA PDU session has been established and the user plane resources of the MA PDU session on this access are successfully established. The UE shall then initiate the UE-requested PDU session establishment procedure with the same PDU session ID, as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over the other access, in order to establish user plane resources on the other access for the MA PDU session. If the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the other access, the UE shall consider that the user plane resources of the MA PDU session have been established on both 3GPP access and non-3GPP access; or

c) if the UE is registered to a PLMN over only one access, either 3GPP access or non-3GPP access, the UE shall initiate the UE-requested PDU session establishment procedure as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over this access. When the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the access, the UE shall consider that the MA PDU session has been established and the user plane resources of the MA PDU session on this access are successfully established. When the UE at a later point in time registers over the other access, either in the same PLMN or in a different PLMN, the UE shall initiate the UE-requested PDU session establishment procedure with the same PDU session ID as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over the other access in order to establish user plane resources on the other access for the MA PDU session. If the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the other access, the UE shall consider that the user plane resources of the MA PDU session have been established over both 3GPP access and non-3GPP access.

If the UE is in the non-allowed area, the UE shall not initiate a PDU session establishment procedure for an MA PDU session over the 3GPP access. It may still initiate a PDU session establishment procedure for an MA PDU session over the non-3GPP access other than wireline access network, however the network shall not establish user plane resources for the 3GPP access if the UE is in the non-allowed area. The handling of non-allowed area when using wireline access is described in 3GPP TS 23.316 [4].

5.2.2 Re-activation of user-plane resources

In order to re-establish the user-plane resources of an MA PDU session:

a) if the UE requests re-establishment of the user-plane resources of the MA PDU session over 3GPP access which were released, the UE shall include the Uplink data status IE indicating the related MA PDU session,

1) in the REGISTRATION REQUEST message when the registration procedure for mobility and periodic registration update is initiated by the UE over 3GPP access as specified in clause 5.5.1.3.2 of 3GPP TS 24.501 [6]; or

2) in the SERVICE REQUEST message when the service request procedure initiated by the UE over 3GPP access as specified in clause 5.6.1.2 of 3GPP TS 24.501 [6];

b) if the UE requests re-establishment of the user-plane resources of the MA PDU session over non-3GPP access which were released and the UE is in 5GMM-CONNECTED mode over non-3GPP access, the UE shall include the Uplink data status IE indicating the related MA PDU session,

1) in the REGISTRATION REQUEST message when the registration procedure for mobility registration update is initiated by the UE over non-3GPP access as specified in clause 5.5.1.3.2 of 3GPP TS 24.501 [6]; or

2) in the SERVICE REQUEST message when the service request procedure initiated by the UE over non-3GPP access as specified in clause 5.6.1.2 of 3GPP TS 24.501 [6];

c) if the UE requests re-establishment of the user-plane resources of the MA PDU session over non-3GPP access which were released and the UE is in 5GMM-IDLE mode over non-3GPP access,

1) for untrusted non-3GPP access, the UE shall perform the procedure as specified in clause 7.3 of 3GPP TS 24.502 [7] and include the Uplink data status IE indicating the related MA PDU session in the SERVICE REQUEST message when the service request procedure initiated by the UE over non-3GPP access as specified in clause 5.6.1.2 of 3GPP TS 24.501 [6]; or

2) for trusted non-3GPP access, the UE shall perform the procedures as specified in clause 7.3A of 3GPP TS 24.502 [7] and include the Uplink data status IE indicating the related MA PDU session in the SERVICE REQUEST message when the service request procedure initiated by the UE over non-3GPP access as specified in clause 5.6.1.2 of 3GPP TS 24.501 [6]; and

d) if the network requests re-establishment of the user-plane resources of the MA PDU session, the UE shall initiate the service request procedure by sending a SERVICE REQUEST message to the AMF upon receipt of the paging request as specified in clause 5.6.1.2 of 3GPP TS 24.501 [6] or shall follow the procedure specified in clause 5.6.3 of 3GPP TS 24.501 [6] upon receipt of a NOTIFICATION message.

If the UE is in the non-allowed area, the UE shall not request re-establishment of the user plane resources of the MA PDU session for the 3GPP access. It may still request re-establishment of the user plane resources of the MA PDU session for the non-3GPP access.

5.2.3 Release of user-plane resources

In order to release the MA PDU session:

a) the SMF shall initiate the network-requested PDU session release procedure as specified in clause 6.3.3.2 of 3GPP TS 24.501 [6] over 3GPP access or non-3GPP access, by sending the PDU SESSION RELEASE COMMAND message to the UE. Over which access to initiate this network-requested PDU session release procedure is SMF implementation specific; or

b) the UE shall initiate the UE-requested PDU session release procedure as specified in clause 6.4.3.2 of 3GPP TS 24.501 [6] over 3GPP access or non-3GPP access by sending the PDU SESSION RELEASE REQUEST message to the network. Over which access to initiate this UE-requested PDU session release procedure is UE implementation specific.

When the UE receives the PDU SESSION RELEASE COMMAND message, the UE shall behave as specified in 3GPP TS 24.501 [6] clause 6.3.3.3.

In order to release the MA PDU session’s user-plane resources on either 3GPP access or non-3GPP access, the SMF shall initiate the network-requested PDU session release procedure as specified in clause 6.3.3.2 of 3GPP TS 24.501 [6] over 3GPP access or non-3GPP access, by sending the PDU SESSION RELEASE COMMAND message with the Access type IE indicating of which access the user-plane resources are released to the UE, e.g. when the AMF indicates to the SMF that the UE is deregistered over an access or when S-NSSAI of the MA PDU session is not in the Allowed NSSAI over an access. Over which access to initiate this network-requested PDU session release procedure is SMF implementation specific. When the UE receives the PDU SESSION RELEASE COMMAND message, the UE shall behave as specified in 3GPP TS 24.501 [6] clause 6.3.3.3, and consider that the user plane resources of the MA PDU session have been released on the access indicated in the Access type IE.

5.2.4 Updating ATSSS parameters

An SMF may update ATSSS parameters, i.e. the ATSSS rules, and the MAI, according to the procedure for the network-requested PDU session modification as specified in clause 6.3.2 of 3GPP TS 24.501 [6] over 3GPP access network or non-3GPP access network. The ATSSS rules may be individually added, deleted or updated using the ATSSS rule ID and ATSSS rule operation. The SMF may change the access network over which the traffic of the GBR QoS flow is transmitted by updating the UE’s ATSSS rules. The SMF may change the QoS flows over which access performance measurements may be performed by updating the MAI.

5.2.5 Converting PDU session transferred from EPS to MA PDU session

When an ATSSS capable UE has transferred a PDN connection from S1 mode to N1 mode in the network supporting N26 interface and the related URSP or UE local configuration does not mandate the PDU session shall be established over a single access:

a) if the UE is registered over both 3GPP access and non-3GPP access in the same PLMN, and the S-NSSAI associated with the PDU session over 3GPP access is included in the allowed NSSAI of non-3GPP access, the UE may initiate the UE-requested PDU session modification procedure by sending the PDU SESSION MODIFICATION REQUEST message including 5GSM capability IE over 3GPP access as specified in clause 6.4.2.2 of 3GPP TS 24.501 [6]. The UE may set the Request type IE to either:

1) "modification request" and include the MA PDU session information IE set to "MA PDU session network upgrade is allowed" as defined in clause 9.11.3.31A of 3GPP TS 24.501 [6]; or

2) "MA PDU request"

in the UL NAS TRANSPORT message as specified in clause 8.2.10 of 3GPP TS 24.501 [6]. When the UE receives the PDU SESSION MODIFICATION COMMAND message including the ATSSS container IE as specified in clause 6.4.2.3 of 3GPP TS 24.501 [6], the UE shall consider that the requested PDU session was converted by the network to an MA PDU session and the user plane resources are successfully established on 3GPP access. When the user plane resources are established on the non-3GPP access (e.g., received established user plane IPsec SA in untrusted non-3GPP access), the UE shall consider the user plane resources are established on both accesses;

NOTE: If the UE receives the PDU SESSION MODIFICATION COMMAND message including the ATSSS container IE and fails to receive user plane resources established on the non-3GPP access, upon an implementation specific timer expiry the UE initiates the UE-requested PDU session establishment procedure over the non-3GPP access, in order to establish user plane resources on the non-3GPP access.

b) if the UE is registered over both 3GPP access and non-3GPP access in different PLMNs, the UE may initiate the UE-requested PDU session modification procedure by sending the PDU SESSION MODIFICATION REQUEST message including 5GSM capability IE over 3GPP access as specified in clause 6.4.2.2 of 3GPP TS 24.501 [6]. The UE may set the Request type IE to either:

1) "modification request" and include the MA PDU session information IE set to "MA PDU session network upgrade is allowed" as defined in clause 9.11.3.31A of 3GPP TS 24.501 [6]; or

2) "MA PDU request"

in the UL NAS TRANSPORT message as specified in clause 8.2.10 of 3GPP TS 24.501 [6]. When the UE receives the PDU SESSION MODIFICATION COMMAND message including the ATSSS container IE as specified in clause 6.4.2.3 of 3GPP TS 24.501 [6], the UE shall consider that the requested PDU session was converted by the network to an MA PDU session and the user plane resources are successfully established on 3GPP access. The UE shall then initiate the UE-requested PDU session establishment procedure with the same PDU session ID, as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over non-3GPP access, in order to establish user plane resources on the other access for the MA PDU session; or

c) if the UE is registered over 3GPP access only, the UE may initiate the UE-requested PDU session modification procedure by sending the PDU SESSION MODIFICATION REQUEST message including 5GSM capability IE over 3GPP access as specified in clause 6.4.2.2 of 3GPP TS 24.501 [6], The UE may set the Request type IE to either:

1) "modification request" and include the MA PDU session information IE set to "MA PDU session network upgrade is allowed" as defined in clause 9.11.3.31A of 3GPP TS 24.501 [6]; or

2) "MA PDU request"

in the UL NAS TRANSPORT message as specified in clause 8.2.10 of 3GPP TS 24.501 [6]. When the UE receives the PDU SESSION MODIFICATION COMMAND message including the ATSSS container IE as specified in clause 6.4.2.3 of 3GPP TS 24.501 [6], the UE shall consider that the requested PDU session was converted by the network to an MA PDU session and the user plane resources are successfully established on 3GPP access. When the UE at a later point in time registers over the non-3GPP access, either in the same PLMN or in a different PLMN, the UE shall initiate the UE-requested PDU session establishment procedure with the same PDU session ID as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over non-3GPP access in order to establish user plane resources on non-3GPP access for the MA PDU session.

5.2.6 PDU session establishment with network modification to MA PDU session

When an ATSSS capable UE establishes a new PDU session and the related URSP or UE local configuration does not mandate the PDU session shall be established over a single access:

a) if the UE is registered over both 3GPP access and non-3GPP access in the same PLMN and the UE initiates the UE-requested PDU session establishment procedure over a selected access, either 3GPP access or non-3GPP access, the UE may include the MA PDU session information IE in the UL NAS TRANSPORT message and set the IE to "MA PDU session network upgrade is allowed" as defined in clause 9.11.3.31A of 3GPP TS 24.501 [6]. When the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6], the UE shall consider that the requested PDU session is established as an MA PDU session and the user plane resources are successfully established on the selected access. When the user plane resources are established on the access other than the selected access (e.g. received lower layer indication in 3GPP access or established user plane IPsec SA in untrusted non-3GPP access), the UE shall consider the user plane resources are successfully established on both accesses;

b) if the UE is registered over both 3GPP access and non-3GPP access in different PLMNs and the UE initiates the UE-requested PDU session establishment procedure over 3GPP access or non-3GPP access, the UE may include the MA PDU session information IE in the UL NAS TRANSPORT message and shall set the IE to "MA PDU session network upgrade is allowed" as defined in clause 9.11.3.31A of 3GPP TS 24.501 [6]. When the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the access, the UE shall consider that the requested PDU session is established as an MA PDU session and the user plane resources are established on this access. The UE shall then initiate the UE-requested PDU session establishment procedure with the same PDU session ID, as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over the other access, in order to establish user plane resources on the other access for the MA PDU session. If the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the other access, the UE shall consider that the user plane resources of the MA PDU session have been established on both 3GPP access and non-3GPP access; or

c) if the UE is registered to a PLMN over only one access, either 3GPP access or non-3GPP access, and the UE requests to establish a PDU session over this access, the UE may include the MA PDU session information IE in the UL NAS TRANSPORT message and shall set the IE to "MA PDU session network upgrade is allowed" as defined in clause 9.11.3.31A of 3GPP TS 24.501 [6]. When the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the access, the UE shall consider that the requested PDU session is established as an MA PDU session and the user plane resources are established on this access. When the UE at a later point in time registers over the other access, either in the same PLMN or in a different PLMN, the UE shall initiate the UE-requested PDU session establishment procedure with the same PDU session ID as specified in clause 6.4.1.2 of 3GPP TS 24.501 [6] over the other access in order to establish user plane resources on the other access for the MA PDU session. If the UE receives the PDU SESSION ESTABLISHMENT ACCEPT message including the ATSSS container IE as specified in clause 6.4.1.3 of 3GPP TS 24.501 [6] over the other access, the UE shall consider that the user plane resources of the MA PDU session have been established on both 3GPP access and non-3GPP access.

5.3 Multi-access PDU connectivity over E-UTRAN and non-3GPP access network

5.3.0 General

If the UE supports MA PDU session and procedures for PDN connection establishment as specified in 3GPP TS 24.301 [10], then the UE shall also support handling as described in clauses 5.3.1 and 5.3.2.

NOTE: The PDN connection established as a user plane resource of an MA PDU session is not applicable for CIoT EPS optimizations in this release of specification.

5.3.1 UE establishing a PDN connection as a user-plane resource of an MA PDU session to be established

In order to establish a PDN connection as a user-plane resource of an MA PDU session to be established, the UE shall initiate the UE requested PDN connectivity procedure according to 3GPP TS 24.301 [10].

In the PDN CONNECTIVITY REQUEST message or, when applicable, in the ESM INFORMATION RESPONSE message, of the UE requested PDN connectivity procedure:

a) the UE shall set the request type to "initial request" as specified in 3GPP TS 24.301 [10];

NOTE: According to 3GPP TS 24.301 [10], a newly generated PDU session ID is included in the protocol configuration options IE or the extended protocol configuration options IE of the PDN CONNECTIVITY REQUEST message with the request type "initial request".

b) the UE shall set the PDN Type IE to "IPv4", "IPv6", "IPv4v6" or "Ethernet"; and

c) in the protocol configuration options or extended protocol configuration options IE of the PDN CONNECTIVITY REQUEST message, the UE shall include the ATSSS request PCO parameter. In the ATSSS request PCO parameter:

1) if the UE supports ATSSS Low-Layer functionality with any steering mode as specified in clause 5.32.6 of 3GPP TS 23.501 [2], the UE shall set the ATSSS-ST field to "ATSSS Low-Layer functionality with any steering mode supported";

2) if the UE supports MPTCP functionality with any steering mode and ATSSS-LL functionality with only active-standby steering mode as specified in clause 5.32.6 of 3GPP TS 23.501 [2], the UE shall set the ATSSS-ST field to "MPTCP functionality with any steering mode and ATSSS-LL functionality with only active-standby steering mode supported"; or

3) if the UE supports MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode as specified in clause 5.32.6 of 3GPP TS 23.501 [2], the UE shall set the ATSSS-ST field to "MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode supported".

Upon receipt of an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message of a default EPS bearer context activation procedure as a response to the PDN CONNECTIVITY REQUEST message as specified in 3GPP TS 24.301 [10], the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message containing the extended protocol configuration options IE with the ATSSS response with the length of two octets PCO parameter:

a) the UE shall consider that the MA PDU session is established based on parameters from the default EPS bearer context of the PDN connection, as follows:

1) the PDN type of the default EPS bearer context shall be mapped to the PDU session type of the MA PDU session as follows:

i) if the PDN type is "IPv4", the PDU session type is set to "IPv4";

ii) if the PDN type is "IPv6", the PDU session type is set to "IPv6";

iii) if the PDN type is "IPv4v6", the PDU session type is set to "IPv4v6"; or

iv) if the PDN type is "Ethernet", the PDU session type is set to "Ethernet";

2) the PDN address of the default EPS bearer context shall be mapped to PDU address of the MA PDU session;

3) the APN of the default EPS bearer context shall be mapped to the DNN of the MA PDU session;

4) the PDU session identity of the MA PDU session shall be set to the PDU session identity included by the UE in the Protocol configuration options IE or Extended protocol configuration options IE in the PDN CONNECTIVITY REQUEST message;

5) the S-NSSAI of the MA PDU session shall be set to the S-NSSAI included by the network in the Protocol configuration options IE or Extended protocol configuration options IE in the ACTIVATE DEFAULT EPS BEARER REQUEST message, if the PDN connection is a non-emergency PDN connection;

6) the SSC mode of the MA PDU session shall be set to "SSC mode 1";

7) state of the PDU session shall be set to PDU SESSION ACTIVE; and

8) the ESM cause of the default EPS bearer context, if any, shall be mapped to the 5GSM cause of the MA PDU session as follows:

i) if the ESM cause is #50 "PDN type IPv4 only allowed", the 5GSM cause of the MA PDU session is set to #50 "PDU session type IPv4 only allowed"; or

ii) if the ESM cause is #51 "PDN type IPv6 only allowed", the 5GSM cause of the MA PDU session is set to #51 "PDU session type IPv6 only allowed";

and that the PDN connection is established as a user-plane resource of the MA PDU session;

b) if the network steering functionalities information is included in the ATSSS response with the length of two octets PCO parameter, the UE shall use the network steering functionalities information; and

c) if the measurement assistance information is included in the ATSSS response with the length of two octets PCO parameter, the UE shall use the measurement assistance information.

Upon receipt of:

a) a PDN CONNECTIVITY REJECT message as a response to the PDN CONNECTIVITY REQUEST message as specified in 3GPP TS 24.301 [10]; or

b) an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message of a default EPS bearer context activation procedure as a response to the PDN CONNECTIVITY REQUEST message as specified in 3GPP TS 24.301 [10] without the extended protocol configuration options IE containing the ATSSS response with the length of two octets PCO parameter;

the UE shall consider that the MA PDU session is not established and the PDN connection is not established as a user-plane resource of the MA PDU session.

5.3.2 UE establishing a PDN connection as a user-plane resource of an already established MA PDU session

In order to establish a PDN connection as a user-plane resource of an already established MA PDU session, the UE shall initiate the UE requested PDN connectivity procedure according to 3GPP TS 24.301 [10].

In the PDN CONNECTIVITY REQUEST message or, when applicable, in the ESM INFORMATION RESPONSE message, of the UE requested PDN connectivity procedure:

a) the UE shall set the request type to "handover" as specified in 3GPP TS 24.301 [10];

NOTE 1: According to 3GPP TS 24.301 [10], the PDU session ID of the already established MA PDU session is included in the protocol configuration options IE or the extended protocol configuration options IE of the PDN CONNECTIVITY REQUEST message with the request type "handover".

b) the UE shall set the PDN Type IE to "IPv4", "IPv6", "IPv4v6", "Ethernet" or "non-IP"; and

NOTE 2: If the UE does not support Ethernet PDN type or the Ethernet PDN type is not supported in EPC, the UE sets "non-IP" PDN type when the established MA PDU session is Ethernet PDU session type.

c) in the protocol configuration options or extended protocol configuration options IE, the UE shall include the ATSSS request PCO parameter.

Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message of a default EPS bearer context activation procedure as a response to the PDN CONNECTIVITY REQUEST message as specified in 3GPP TS 24.301 [10], the UE shall consider that the PDN connection is established as a user-plane resource of the MA PDU session.

Upon receipt of a PDN CONNECTIVITY REJECT message as specified in 3GPP TS 24.301 [10], the UE shall consider that the PDN connection is not established as a user-plane resource of the MA PDU session.

5.3.3 Re-activation of user-plane resources

For an MA PDU session with a PDN connection established as a user-plane resource:

a) if the UE in EMM-IDLE mode has pending user data to be sent over the PDN connection, the UE shall:

1) set the "active" flag in the EPS update type IE in the TRACKING AREA UPDATE REQUEST message when the normal and periodic tracking area updating procedure is initiated by the UE as specified in clause 5.5.3.2.2 of 3GPP TS 24.301 [10]; or

2) initiate service request procedure as specified in clause 5.6.1.2.1 of 3GPP TS 24.301 [10];

b) if the UE requests re-establishment of the user-plane resources of the MA PDU session over non-3GPP access which were established but released, the UE shall initiate registration procedure for mobility registration update or service request procedure as specified in clause 5.2.2 bullets b) and c); or

c) if the UE is in EMM-IDLE mode and the network has pending user data to be sent over the PDN connection, the UE shall initiate the service request procedure by sending a SERVICE REQUEST message to the MME upon receipt of the paging request as specified in clause 5.6.1.2.1 of 3GPP TS 24.301 [10].

5.3.4 Release of user-plane resource(s)

In order to release an MA PDU session which has a PDN connection established as a user-plane resource:

a) to release the PDN connection established as a user-plane resource of the MA PDU session:

1) the network shall:

i) initiate the network initiated detach procedure as specified in clause 5.5.2.3 of 3GPP TS 24.301 [10] by sending the DETACH REQUEST message to the UE if EMM-REGISTERED without PDN connection is not supported by the UE and the MME and the PDN connection is the last PDN connection; or

ii) initiate the EPS bearer context deactivation procedure as specified in clause 6.4.4 of 3GPP TS 24.301 [10] by sending the DEACTIVATE EPS BEARER CONTEXT REQUEST message to the UE if EMM-REGISTERED without PDN connection is supported by the UE and the MME or the PDN connection is not the last PDN connection; or

2) the UE shall:

i) initiate the UE initiated detach procedure as specified in clause 5.5.2.2 of 3GPP TS 24.301 [10] by sending the DETACH REQUEST message to the network if EMM-REGISTERED without PDN connection is not supported by the UE and the MME and the PDN connection is the last PDN connection; or

ii) initiate the UE requested PDN disconnect procedure as specified in clause 6.5.2 of 3GPP TS 24.301 [10] by sending the PDN DISCONNECT REQUEST message to the network if EMM-REGISTERED without PDN connection is supported by the UE and the MME or the PDN connection is not the last PDN connection; and

b) to release the user-plane resources, if any, established on non-3GPP access of the MA PDU session:

1) the network shall initiate the network-requested PDU session release procedure as specified in clause 6.3.3.2 of 3GPP TS 24.501 [6] by sending the PDU SESSION RELEASE COMMAND message with the Access type IE indicating "Non-3GPP access" or without including the Access type IE to the UE; or

2) the UE shall initiate the UE-requested PDU session release procedure as specified in clause 6.4.3.2 of 3GPP TS 24.501 [6] by sending the PDU SESSION RELEASE REQUEST message to the network.

5.3.5 Updating ATSSS parameters

A PGW-C+SMF may update ATSSS parameters as specified in clause 5.2.4 and include the updated MAI in the extended protocol configuration options IE with the ATSSS response with the length of two octets PCO parameter. The updated MAI in the extended protocol configuration options IE with the ATSSS response with the length of two octets PCO parameter is sent to the UE during the EPS bearer context modification according to clause 6.4.3 of 3GPP TS 24.301 [10].

5.3.6 A/Gb mode or Iu mode Interworking

Upon inter-system change from S1 mode to A/Gb mode or Iu mode, for a PDN connection which was established as a user-plane resource of an MA PDU session:

a) if the SM activates a PDP context using parameters from the default EPS bearer context of the PDN connection as specified clause 6.1.4 of 3GPP TS 24.301 [10]:

1) the SMF can initiate the network-requested PDU session release procedure over non-3GPP access as specified in clause 6.3.3.2 of 3GPP TS 24.501 [6] if the user plane resources are established on non-3GPP access for this MA PDU session, or perform a local release of the MA PDU session; and

2) the UE performs a local release of the MA PDU session.

NOTE 1: If the UE receives from the network a PDU SESSION RELEASE COMMAND message which indicates to release the MA PDU session over non-3GPP access and the UE has already performed or is performing a local release of the MA PDU session, the error handling as specified in clause 6.3.3.6 of 3GPP TS 24.501 [6] is applied.

NOTE 2: If the SM does not activate a PDP context using parameters from the default EPS bearer context of the PDN connection and the user plane resources are established on non-3GPP access for this MA PDU session, the SMF initiates the network-requested PDU session modification procedure as specified in clause 6.3.2.2 of 3GPP TS 24.501 [6] over non-3GPP access if the SMF decides to move the traffic of the MA PDU session to non-3GPP access, or the SMF initiates the network-requested PDU session release procedure as specified in clause 6.3.3.2 of 3GPP TS 24.501 [6] over non-3GPP access without including the Access type IE or with the Access type IE indicating "Non-3GPP access".

5.3.7 Abnormal cases in the UE

The following abnormal cases can be identified:

a) For an MA PDU session already established over non-3GPP access, upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, if any of the following conditions is not fulfilled:

1) the "PDN type value" of the PDN address IE is set to

i) "IPv4" and the stored PDU session type of the MA PDU session is set to "IPv4";

ii) "IPv6" and the stored PDU session type of the MA PDU session is set to "IPv6";

iii) "IPv4v6" and the stored PDU session type of the MA PDU session is set to "IPv4v6"; or

iv) "Ethernet" and the stored PDU session type of the MA PDU session is set to "Ethernet";

2) the PDN address in "PDN address information" of the PDN address IE is the same as the stored PDU address of the MA PDU session;

3) the stored selected SSC mode of the MA PDU session is set to "SSC mode 1";

4) the ESM cause IE is:

i) not included and there is no stored 5GSM cause of the MA PDU session;

ii) set to #50 "PDN type IPv4 only allowed" and the stored 5GSM cause of the MA PDU session is set to #50 "PDU session type IPv4 only allowed";

iii) set to #51 "PDN type IPv6 only allowed" and the stored 5GSM cause of the MA PDU session is set to #51 "PDU session type IPv6 only allowed"; or

iv) set to #52 "single address bearers only allowed" and there is no stored 5GSM cause of the MA PDU session;

5) the S-NSSAI is included by the network in the Protocol configuration options IE or Extended protocol configuration options IE and is the same as the stored S-NSSAI value of the MA PDU session; and

6) the APN maps to the same DNN as the stored DNN of the MA PDU session;

the UE shall send ACTIVATE DEFAULT EPS BEARER CONTEXT REJECT message to the network as specified in clause 6.4.1.4 of 3GPP TS 24.301 [10], may perform a local release of the MA PDU session and the registration procedure for mobility and periodic registration update with a REGISTRATION REQUEST message including the PDU session status IE over non-3GPP access.

5.4 Performance measurement function (PMF) protocol (PMFP) procedures

5.4.1 General

Performance measurement function protocol (PMFP) procedures are performed between a performance measurement function (PMF) in a UE and a PMF in the UPF.

The following UE-initiated PMFP procedures are specified:

a) UE-initiated RTT measurement procedure; and

b) access availability or unavailability report procedure;

c) UE-initiated PLR measurement procedure;

d) UE assistance data provisioning procedure; and

e) UE assistance data termination procedure.

The following UPF-initiated PMFP procedures are specified:

a) UPF-initiated RTT measurement procedure; and

b) UPF-initiated PLR measurement procedure.

The UE-initiated PMFP procedures and the UPF-initiated PMFP procedures can be performed:

a) on the user plane of an MA PDU session via either 3GPP access or non-3GPP access in 5GS if the MAI is provided to the UE during establishment of the MA PDU session; or

b) on the user plane of the PDN connection established as the user plane resource of an MA PDU session via 3GPP access in EPS or the user plane of the MA PDU session via non-3GPP access in 5GS as specified in clause 5.3.

PMFP messages are transported in an IP packet or an Ethernet frame according to clause 5.3.2.

If the UE supports performance measurement function protocol procedures for the QoS flow of a non-default QoS rule, the UE indicates its "access performance measurements per QoS flow" capability as defined in clause 9.11.4.1 of 3GPP TS 24.501 [6] to the SMF. If the SMF determines that PMFP using the QoS flow of the non-default QoS rule is applied to the MA PDU session for the UE, the SMF provides the UE with the MAI including a list of QoS flows over which access performance measurements may be performed. The UE performs the RTT measurement procedure or the PLR measurement procedure over the QoS flow(s) as indicated in the received MAI.

NOTE 1: In this release of the specification, for the PDN connection established as a user-plane resource of an MA PDU session, the PMFP procedures are only performed over the default EPS bearer of the PDN connection.

If the UPF receives the indication from the SMF that the performance measurement is for QoS flow(s) of the non-default QoS rule, the UPF performs the RTT measurement procedure or the PLR measurement procedure over the QoS flow(s) of non-default QoS rule as indicated by the SMF. Otherwise, the UPF performs the RTT measurement procedure or the PLR measurement procedure over the QoS flow of the default QoS rule

PMFP messages, transported between the UE and the UPF over one (or more) QoS flows of a non-default QoS rule, are specified in clause 5.4.2.1.3.

PMFP messages transported between the UE and the UPF (and vice versa) are protected using the security mechanisms protecting the user data packets transported over NG-RAN or non-3GPP access connected to the 5GCN and over the N3 and N9 reference points, are specified in 3GPP TS 33.501 [14]. A PMFP-specific security mechanism is not specified.

NOTE 2: Even though transport of PMFP messages between the UE and the UPF is protected, a compromised UE can send false or incorrect PMFP messages.

PMFP is a standard L3 protocol according to 3GPP TS 24.007 [13], PMFP messages are standard L3 messages according to 3GPP TS 24.007 [13] and error behaviour specified for L3 protocol in according to 3GPP TS 24.007 [13] applies for PMFP.

The access availability or unavailability report procedure is only performed over the QoS flow of the default QoS rule, or over the default EPS bearer of the PDN connection established as a user-plane resource.

5.4.2 Elementary procedures for PMFP

5.4.2.1 PMFP message transport

5.4.2.1.1 PMFP message transport in IPv4, IPv6 or IPv4v6 PDU session

In order to send a PMFP message over an access of an MA PDU session of IPv4, IPv6 or IPv4v6 PDU session type:

a) if the UE obtained IPv4 address for the PDU session and the received measurement assistance information contains an IPv4 address of the PMF in the UPF, the UE shall create a UDP/IPv4 packet. In the UDP/IPv4 packet, the UE:

1) shall set the data octets field to the PMFP message;

2) shall set the source port field to the UDP port of the PMF in the UE;

3) shall set the destination port field to the UDP port of the PMF in the UPF associated with the access of the MA PDU session indicated in the received measurement assistance information according to the target QoS flow which is used to transport the PMFP message:

A) if the target QoS flow is the QoS flow of the default QoS rule, the destination UDP port field is set to the value of:

– the "PMF 3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over 3GPP access; or

– the "PMF non-3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over non-3GPP access; and

B) if the target QoS flow is a QoS flow of the non-default QoS rule, the destination UDP port field is set to the value of:

– the "PMF 3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over 3GPP access; or

– the "PMF non-3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over non-3GPP access;

4) shall set the source address field to the IPv4 address of the UE; and

5) shall set the destination address field to the IPv4 address of the PMF in the UPF as specified in figure 6.1.5.2-1, included in the received measurement assistance information; or

b) if the UE obtained IPv6 prefix for the PDU session, generated an IPv6 address for the PMF in the UE and the received measurement assistance information contains an IPv6 address of the PMF in the UPF, the UE shall create a UDP/IPv6 packet. In the UDP/IPv6 packet, the UE:

1) shall set the data octets field to the PMFP message;

2) shall set the source port field to the UDP port of the PMF in the UE;

A) if the target QoS flow is the QoS flow of the default QoS rule, the destination UDP port field is set to the value of:

– the "PMF 3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over 3GPP access;

– the "PMF non-3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over non-3GPP access; and

B) if the target QoS flow is a QoS flow of the non-default QoS rule, the destination UDP port field is set to the value of:

– the "PMF 3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over 3GPP access; or

– the "PMF non-3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over non-3GPP access;

4) shall set the source address field to the IPv6 address of the PMF in the UE; and

5) shall set the destination address field to the IPv6 address of the PMF in the UPF as specified in figure 6.1.5.2-1, included in the received measurement assistance information.

The UE shall send the UDP/IPv4 packet or UDP/IPv6 packet over the access of the MA PDU session.

In order to send a PMFP message over an access of an MA PDU session of IPv4, IPv6 or IPv4v6 PDU session type:

a) if the UPF is aware of the UDP port of the PMF in the UE used with IPv4, the UPF shall create a UDP/IPv4 packet. In the UDP/IPv4 packet, the UPF:

1) shall set the data octets field to the PMFP message;

2) shall set the source port field to the UDP port of the PMF in the UPF associated with the access of the MA PDU session indicated in the measurement assistance information provided to the UE according to the target QoS flow which is used to transport the PMFP message:

A) if the target QoS flow is the QoS flow of the default QoS rule, the source UDP port field is set to the value of:

– the "PMF 3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over 3GPP access;

– the "PMF non-3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over non-3GPP access; and

B) if the target QoS flow is a QoS flow of the non-default QoS rule, the source UDP port field is set to the value of:

– the "PMF 3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over 3GPP access; or

– the "PMF non-3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over non-3GPP access;

3) shall set the destination port field to the UDP port of the PMF in the UE used with IPv4;

4) shall set the source address field to the IPv4 address of the PMF in the UPF as specified in figure 6.1.5.2-1, included in the measurement assistance information provided to the UE; and

5) shall set the destination address field to the IPv4 address of the UE; or

b) if the UPF is aware of the UDP port and the IPv6 address of the PMF in the UE, the UPF shall create a UDP/IPv6 packet. In the UDP/IPv6 packet, the UPF:

1) shall set the data octets field to the PMFP message;

A) if the target QoS flow is the QoS flow of the default QoS rule, the source UDP port field is set to the value of:

– the "PMF 3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over 3GPP access;

– the "PMF non-3GPP port" as specified in figure 6.1.5.2-1 for the PMFP message to be transported over non-3GPP access; and

B) if the target QoS flow is a QoS flow of the non-default QoS rule, the source UDP port field is set to the value of:

– the "PMF 3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over 3GPP access; or

– the "PMF non-3GPP port" of the corresponding QoS flow as specified in figure 6.1.5.2-4 for the PMFP message to be transported over non-3GPP access;

3) shall set the destination port field to the UDP port of the PMF in the UE;

4) shall set the source address field to the IPv6 address of the PMF in the UPF as specified in figure 6.1.5.2-1, included in the measurement assistance information provided to the UE; and

5) shall set the destination address field to the IPv6 address of the PMF in the UE.

The UPF shall send the UDP/IPv4 packet or UDP/IPv6 packet over the access of the MA PDU session.

The UE shall select the UDP port of the PMF in the UE upon establishment of an MA PDU session of IPv4, IPv6 or IPv4v6 PDU session type. The UE shall use the same UDP port of the PMF in the UE till release of the MA PDU session. The UE shall select the IPv6 address of the PMF in the UE upon establishment of an MA PDU session of IPv6 or IPv4v6 PDU session type. The UE shall use the same IPv6 address of the PMF in the UE till release of the MA PDU session.

NOTE: Regardless of whether the target QoS flow is associated with default QoS rule or not, the UE only allocates a single UDP port for PMFP messages.

The UPF shall discover the UDP port of the PMF in the UE used with IPv4 of an MA PDU session of IPv4 or IPv4v6 PDU session type, in the source port field of an UDP/IPv4 packet:

a) received via the MA PDU session;

b) with the destination port field set to the UDP port of the PMF in the UPF associated with an access, included in the measurement assistance information provided to the UE; and

c) with the destination address field set to the IPv4 address of the PMF in the UPF, included the measurement assistance information provided to the UE.

The UPF shall discover the UDP port and the IPv6 address of the PMF in the UE of an MA PDU session of IPv6 or IPv4v6 PDU session type, in the source port field and the source address field of an UDP/IPv6 packet:

a) received via the MA PDU session;

b) with the destination port field set to the UDP port of the PMF in the UPF associated with an access, included in the measurement assistance information provided to the UE; and

c) with the destination address field set to the IPv6 address of the PMF in the UPF, included the measurement assistance information provided to the UE.

In order to enable the UPF to discover:

a) the UDP port of the PMF in the UE in case of an MA PDU session of IPv4 or IPv4v6 PDU session type, or

b) the UDP port and the IPv6 address of the PMF in the UE in case of an MA PDU session of IPv6 or IPv4v6 PDU session type;

the UE shall perform a access availability or unavailability report procedure over an access immediately after the MA PDU session is established. If the MA PDU session is established over both 3GPP access and non-3GPP access, the UE may use either of the accesses for the access availability or unavailability report procedure. If the access availability or unavailability report procedure is aborted, the UE shall repeat the access availability or unavailability report procedure over the same access or, if the MA PDU session is established over both 3GPP access and non-3GPP access, over the other access.

5.4.2.1.2 PMFP message transport in Ethernet PDU session

In order to send a PMFP message over an access of an MA PDU session of Ethernet PDU session type, the UE shall create an Ethernet frame as specified in IEEE 802.3 [12]. In the Ethernet frame, the UE:

a) shall set the length/type field of the Ethernet frame to the ethertype value included in the received measurement assistance information;

b) shall set the destination address field of the Ethernet frame to the MAC address of the PMF in the UPF associated with the access of the MA PDU session indicated in the received measurement assistance information according to the target QoS flow which is used to transport the PMFP message:

1) if the target QoS flow is the QoS flow of the default QoS rule, the destination address field of the Ethernet frame is set to the value of:

A) the "PMF 3GPP MAC address" as specified in figure 6.1.5.2-2 for the PMFP message to be transported over 3GPP access; or

B) the "PMF non-3GPP MAC address" as specified in figure 6.1.5.2-2 for the PMFP message to be transported over non-3GPP access; and

2) if the target QoS flow is a QoS flow of the non-default QoS rule, the destination address field of the Ethernet frame is set to the value of:

A) the "PMF 3GPP MAC address" of the corresponding QoS flow as specified in figure 6.1.5.2-5 for the PMFP message to be transported over 3GPP access; or

B) the "PMF non-3GPP MAC address" of the corresponding QoS flow as specified in figure 6.1.5.2-5 for the PMFP message to be transported over non-3GPP access;

c) shall set the source address field of the Ethernet frame to the MAC address of the PMF in the UE;

d) shall set the MAC client data field of the Ethernet frame to the 3GPP IEEE MAC based protocol family envelope;

e) shall set the protocol subtype field of the 3GPP IEEE MAC based protocol family envelope to "Performance measurement function protocol (PMFP)"; and

f) shall set the PMFP message field of the protocol data field of the 3GPP IEEE MAC based protocol family envelope to the PMFP message.

The UE shall send the Ethernet frame over the access of the MA PDU session.

In order to send a PMFP message over an access of an MA PDU session, the UPF shall create an Ethernet frame as specified in IEEE 802.3 [12]. In the Ethernet frame, the UPF:

a) shall set the length/type field of the Ethernet frame to the ethertype value included in the measurement assistance information provided to the UE;

b) shall set the source address field of the Ethernet frame to the MAC address of the PMF in the UPF associated with the access of the MA PDU session indicated in the measurement assistance information provided to the UE according to the target QoS flow which is used to transport the PMFP message:

1) if the target QoS flow is the QoS flow of the default QoS rule, the source address field of the Ethernet frame is set to the value of:

A) the "PMF 3GPP MAC address" as specified in figure 6.1.5.2-2 for the PMFP message to be transported over 3GPP access; or

B) the "PMF non-3GPP MAC address" as specified in figure 6.1.5.2-2 for the PMFP message to be transported over non-3GPP access; and

2) if the target QoS flow is a QoS flow of the non-default QoS rule, the source address field of the Ethernet frame is set to the value of:

A) the "PMF 3GPP MAC address" of the corresponding QoS flow as specified in figure 6.1.5.2-5 for the PMFP message to be transported over 3GPP access; or

B) the "PMF non-3GPP MAC address" of the corresponding QoS flow as specified in figure 6.1.5.2-5 for the PMFP message to be transported over non-3GPP access;

c) shall set the destination address field of the Ethernet frame to the MAC address of the PMF in the UE;

d) shall set the MAC client data field of the Ethernet frame to the 3GPP IEEE MAC based protocol family envelope;

e) shall set the protocol subtype field of the 3GPP IEEE MAC based protocol family envelope to "Performance measurement function protocol (PMFP)"; and

f) shall set the PMFP message field of the protocol data field of the 3GPP IEEE MAC based protocol family envelope to the PMFP message.

The UPF shall send the Ethernet frame so that the UE receives it over the access of the MA PDU session.

The UE shall select the MAC address of the PMF in the UE upon establishment of an MA PDU session of Ethernet PDU session type. The UE shall use the same MAC address of the PMF in the UE till release of the MA PDU session.

NOTE: Regardless of whether the target QoS flow is associated with default QoS rule or not, the UE only allocates a single MAC address for PMFP messages.

The UPF shall discover the MAC address of the PMF in the UE of an MA PDU session of Ethernet PDU session type, in the source address field of an Ethernet frame:

a) received via the MA PDU session;

b) with the length/type field of the Ethernet frame set to the ethertype value included in the measurement assistance information provided to the UE; and

c) with the destination address field of the Ethernet frame set to the MAC address of the PMF in the UPF associated with an access, included in the measurement assistance information provided to the UE.

In order to enable the UPF to discover the MAC address of the PMF in the UE of an MA PDU session of Ethernet PDU session type, the UE shall perform an access availability or unavailability report procedure over an access immediately after the MA PDU session is established. If the MA PDU session is established over both 3GPP access and non-3GPP access, the UE may use either of the accesses for the access availability or unavailability report procedure. If the access availability or unavailability report procedure is aborted, the UE shall repeat the access availability or unavailability report procedure over the same access or, if the MA PDU session is established over both 3GPP access and non-3GPP access, over the other access.

5.4.2.1.3 PMFP message transport associated with QoS flow

In this release of specification, RTT measurement procedure and PLR measurement procedure can be performed per QoS flow.

In order to transport PMFP ECHO REQUEST message, PMFP ECHO RESPONSE message, PMFP PLR COUNT REQUEST message, PMFP PLR COUNT RESPONSE message, PMFP PLR REPORT REQUEST message and PMFP PLR REPORT RESPONSE message over the specific QoS flows, SMF shall provide the UE with the QoS rules including the packet filters containing the UDP port or the MAC address associated with the QoS flow in the MAI.

NOTE: The SMF providing the UPF with the UL PDR including the UDP port or the MAC address associated with a QoS flow is specified in 3GPP TS 29.244 [16].

5.4.2.2 Extended procedure transaction identity (EPTI)

The UE shall maintain the current available UE EPTI value. When the MA PDU session is established, the UE shall set the current available UE EPTI value to 0000H. When a UE-initiated PMFP procedure is initiated, the UE shall allocate the current available UE EPTI value to the UE-initiated PMFP procedure and:

– if the current available UE EPTI value is 7FFFH, shall set the current available UE EPTI value to 0000H; or

– otherwise, shall increase the current available UE EPTI value by one.

The UE shall release the EPTI value allocated to the UE-initiated PMFP procedure when the UE-initiated PMFP procedure completes or is aborted.

The UPF shall maintain the current available UPF EPTI value. When the MA PDU session is established, the UPF shall set the current available UPF EPTI value to 8000H. When a UPF-initiated PMFP procedure is initiated, the UPF shall allocate the current available UPF EPTI value to the UPF-initiated PMFP procedure and:

– if the current available UPF EPTI value is FFFFH, shall set the current available UPF EPTI value to 8000H; or

– otherwise, shall increase the current available UPF EPTI value by one.

The UPF shall release the EPTI value allocated to the UPF-initiated PMFP procedure when the UPF-initiated PMFP procedure completes or is aborted.

5.4.3 UE-initiated RTT measurement procedure

5.4.3.1 General

The purpose of the UE-initiated RTT measurement procedure is to enable the UE to measure the RTT of an exchange of user data packets between the UE and the UPF over an access of an MA PDU session.

The UE-initiated RTT measurement procedure can be performed over an access of an MA PDU session only when the UE has user-plane resources on the access of the MA PDU session.

5.4.3.2 UE-initiated RTT measurement procedure initiation

In order to initiate a UE-initiated RTT measurement procedure over an access of an MA PDU session, the UE shall allocate an EPTI value as specified in clause 5.4.2.2 and shall create one or more PMFP ECHO REQUEST messages. The number of created PMFP ECHO REQUEST messages is UE implementation specific. In each PMFP ECHO REQUEST message, the UE:

a) shall set the EPTI IE to the allocated EPTI value;

b) shall set the RI IE to a unique value identifying the particular PMFP ECHO REQUEST message within the transaction; and.

c) if the upper layers request a particular length of PMFP messages, shall include the Padding IE such that length of the PMFP message becomes equal to the requested length.

The UE shall start a timer T101 and shall send the one or more PMFP ECHO REQUEST messages over the access of the MA PDU session.

An example of the UE-initiated RTT measurement procedure is shown in figure 5.3.3.2-1.

Figure 5.4.3.2-1: UE-initiated RTT measurement procedure

5.4.3.3 UE-initiated RTT measurement procedure completion

Upon reception of the PMFP ECHO REQUEST message, the UPF shall create a PMFP ECHO RESPONSE message. In the PMFP ECHO RESPONSE message, the UPF shall set the EPTI IE to the EPTI value in the PMFP ECHO REQUEST message and shall set the RI IE to the RI value in the PMFP ECHO REQUEST message. If the PMFP ECHO REQUEST message contains the Padding IE, the UPF shall include the Padding IE such that length of the PMFP message becomes equal to length of the received PMFP message. The UPF shall send the PMFP ECHO RESPONSE message over the access of the MA PDU session via which the PMFP ECHO REQUEST message was received.

Upon reception of a PMFP ECHO RESPONSE message with the same EPTI as the allocated EPTI value and with the RI value of a sent PMFP ECHO REQUEST message, the UE shall determine the RTT value for the request identified by the RI value by subtracting the current value of the timer T101 from the value of the timer T101 valid when the PMFP ECHO REQUEST with the RI value was sent.

When a PMFP ECHO RESPONSE message with the same EPTI as the allocated EPTI value has been received for each sent PMFP ECHO REQUEST message, the UE shall calculate an average of the RTT values for the requests, shall stop the timer T101.

5.4.3.4 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiration of the timer T101

Upon expiration of the timer T101, the UE shall abort the procedure, shall calculate an average of the RTT values for the requests for which a response was received and shall count the number of requests for which no response was received.

5.4.4 Network-initiated RTT measurement procedure

5.4.4.1 General

The purpose of the UPF-initiated RTT measurement procedure is to enable the UPF to measure the RTT of an exchange of user data packets between the UPF and the UE over an access of an MA PDU session.

The UPF-initiated RTT measurement procedure can be performed over an access of an MA PDU session only when the UE has user-plane resources on the access of the MA PDU session.

5.4.4.2 UPF-initiated RTT measurement procedure initiation

In order to initiate a UPF-initiated RTT measurement procedure over an access of an MA PDU session, the UPF shall allocate a EPTI value as specified in clause 5.4.2.2 and shall create one or more PMFP ECHO REQUEST messages. The number of created PMFP ECHO REQUEST messages is UPF implementation specific. In each PMFP ECHO REQUEST message, the UPF:

a) shall set the EPTI IE to the allocated EPTI value;

b) shall set the RI IE to a unique value identifying the particular PMFP ECHO REQUEST message within the transaction; and

c) if the upper layers request a particular length of PMFP messages, shall include the Padding IE such that length of the PMFP message becomes equal to the requested length.

The UPF shall start a timer T201 and shall send the one or more PMFP ECHO REQUEST messages over the access of the MA PDU session.

An example of the UPF-initiated RTT measurement procedure is shown in figure 5.4.4.2-1.

Figure 5.4.4.2-1: UPF-initiated RTT measurement procedure

5.4.4.3 UPF-initiated RTT measurement procedure completion

Upon reception of the PMFP ECHO REQUEST message, the UE shall create a PMFP ECHO RESPONSE message. In the PMFP ECHO RESPONSE message, the UE shall set the EPTI IE to the EPTI value in the PMFP ECHO REQUEST message and shall set the RI IE to the RI value in the PMFP ECHO REQUEST message. If the PMFP ECHO REQUEST message contains the Padding IE, the UE shall include the Padding IE such that length of the PMFP message becomes equal to length of the received PMFP message. The UE shall send the PMFP ECHO RESPONSE message over the access of the MA PDU session via which the PMFP ECHO REQUEST message was received.

Upon reception of a PMFP ECHO RESPONSE message with the same EPTI as the allocated EPTI value and with the RI value of a sent PMFP ECHO REQUEST message, the UPF shall determine the RTT value for the request identified by the RI value by subtracting the current value of the timer T201 from the starting value of the timer T201 valid when the PMFP ECHO REQUEST with the RI value was sent.

When a PMFP ECHO RESPONSE message with the same EPTI as the allocated EPTI value has been received for each sent PMFP ECHO REQUEST message, the UPF shall calculate an average of the RTT values for the requests, shall stop the timer T201.

5.4.4.4 Abnormal cases in the network

The following abnormal cases can be identified:

a) Expiration of the timer T201

Upon expiration of the timer T201, the UPF shall abort the procedure, shall calculate an average of the RTT values for the requests for which a response was received and shall count the number of requests for which no response was received.

5.4.5 Access availability or unavailability report procedure

5.4.5.1 General

The purpose of the access availability or unavailability report procedure is to enable the UE to inform the UPF about availability or unavailability of an access of an MA PDU session.

5.4.5.2 Access availability or unavailability report procedure initiation

In order to initiate an access availability or unavailability report procedure over an access of an MA PDU session, the UE shall allocate a EPTI value as specified in clause 5.4.2.2 and shall create a PMFP ACCESS REPORT message. In the PMFP ACCESS REPORT message, the UE shall set the EPTI IE to the allocated EPTI value. The UE shall send the PMFP ACCESS REPORT message over the access of the MA PDU session and shall start a timer T102.

An example of the access availability or unavailability report procedure is shown in figure 5.4.5.2-1.

Figure 5.4.5.2-1: Access availability or unavailability report procedure

5.4.5.3 Access availability or unavailability report procedure completion

Upon reception of the PMFP ACCESS REPORT message, the UPF shall create a PMFP ACKNOWLEDGEMENT message. In the PMFP ACKNOWLEDGEMENT message, the UPF shall set the EPTI IE to the EPTI value in the PMFP ACCESS REPORT message. The UPF shall send the PMFP ACKNOWLEDGEMENT message over the access of the MA PDU session via which the PMFP ACCESS REPORT message was received.

Upon reception of a PMFP ACKNOWLEDGEMENT message with the same EPTI as the allocated EPTI value, the UE shall stop the timer T102.

5.4.5.4 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiry of the timer T102

The UE shall, on the first expiry of the timer T102, retransmit the PMFP ACCESS REPORT message and shall reset and start timer T102. This retransmission is repeated up to four times, i.e. on the fifth expiry of timer T102, the UE shall abort the procedure.

5.4.6 UE-initiated PLR measurement procedure

5.4.6.1 General

The purpose of the UE-initiated PLR measurement procedure is to enable the UE to measure the PLR of UL traffic to the UPF over an access of an MA PDU session.

The UE-initiated PLR measurement procedure can be performed over an access of an MA PDU session only when the UE has user-plane resources on the access of the MA PDU session. The UE-initiated PLR measurement procedure can be performed for the QoS flow of the default QoS rule or the QoS flow of the non-default QoS rule.

The UE-initiated PLR measurement procedure consists of following:

a) one UE-initiated PLR count procedure (see clause 5.4.6.2); and

b) one or more UE-initiated PLR report procedure (see clause 5.4.6.3).

If an indication to request restart of counting procedure is sent by the UE and accepted by the UPF, the UE-initiated PLR measurement procedure consists of more than one UE-initiated PLR report procedure. Otherwise, the UE-initiated PLR measurement procedure consists of one UE-initiated PLR report procedure.

The UE shall not initiate another PLR measurement procedure over the same QoS flow on the same access until current UE-initiated PLR measurement procedure is completed.

An example of UE-initiated PLR measurement procedure which consists of the two procedures is shown in figure 5.4.6.1-1.

Figure 5.4.6.1-1: UE-initiated PLR measurement procedure

1. The UE sends a PMFP PLR count request message to the UPF. If the UE-initiated PLR measurement is to meaure the PLR of the SDF over a QoS flow of the non-default QoS rule, the PMFP PLR count request message is transported over the QoS flow of the non-default QoS rule. Otherwise, the PMFP PLR count request message is transported over the QoS flow of the default QoS rule.

NOTE 1: In the UE-initiated PLR measurement procedure, all the PMFP messages are transported over the same QoS flow on the same access.

2. Upon sending the PMFP PLR count request message, the UE starts counting the transmitted UL packets over the QoS flow.

3-4. Upon receiving the PMFP PLR count request message, the UPF starts counting the received UL packets over the QoS flow which the PMFP PLR count request message is received from and sends the PMFP PLR count response message to the UE.

5-7. The UE sends a PMFP PLR report request message to request the UPF to report the number of the counted UL packets and stops counting the transmitted UL packets over the QoS flow. If the UE intends to request the UPF to restart counting the UL packets, the UE can include an indication in the PMFP PLR report request message and restart counting the transmitted UL packets over the QoS flow.

8-10. Upon receiving the PMFP PLR report request message, the UPF stops counting the UL packets and sends PMFP PLR report response message which includes the number of the UL packets counted since the reception of the last PMFP PLR count request message. If an indication to request restart of counting procedure is received in the PMFP PLR report request message and accepted by the UPF, the UPF restarts counting the received UL packets.

11. The UE calculates the UL packet loss rate based on the local counting result of the number of transmitted UL packets and the reported number of received UL packets included in the PMFP PLR report response message. If the UE includes an indication to request restart of counting in the PMFP PLR report request message in step 5 and the UE receives PMFP PLR report response message with an indication of restart counting is not accepted or without an indication of restart counting, the UE shall abort the restart of PMFP PLR measurement procedure.

12. Same as step 5, if the UE restarts counting the transmitted UL packets as specified in step 7.

13. Same as step 6, if the UE restarts counting the transmitted UL packets as specified in step 7.

14. Same as step 7.

15. Same as step 8, if the UPF restarts counting the received UL packets as specified in step 9.

16. Same as step 9.

17 Same as step 10, if the UPF restarts counting the transmitted UL packets as specified in step 9.

18 Same as step 11, if the UE restarts counting the transmitted UL packets as specified in step 7.

NOTE 2: When the UE requests and the UPF accepts the restart of counting, there can be multiple occurrences of step 7, 9, and 12-18.

5.4.6.2 UE-initiated PLR count procedure

5.4.6.2.1 UE-initiated PLR count procedure initiation

In order to initiate a UE-initiated PLR count procedure over an access of an MA PDU session, the UE shall:

– allocate an EPTI value as specified in clause 5.4.2.2;

– create a PMFP PLR COUNT REQUEST message;

– set the EPTI IE of the PMFP PLR COUNT REQUEST message to the allocated EPTI value;

– send the PMFP PLR COUNT REQUEST message using the QoS flow indicated in the MAI over the access of the MA PDU session;

– start a timer T103 upon sending the PMFP PLR COUNT REQUEST message; and

– start counting the transmitted UL packets over the QoS flow.

An example of the UE-initiated PLR count procedure is shown in figure 5.4.6.2.1-1.

Figure 5.4.6.2.1-1: UE-initiated PLR count procedure

5.4.6.2.2 UE-initiated PLR count procedure completion

Upon receiving the PMFP PLR COUNT REQUEST message, the UPF shall:

– create a PMFP PLR COUNT RESPONSE message;

– set the EPTI IE of the PMFP PLR COUNT RESPONSE message to the EPTI value of the received PMFP PLR COUNT REQUEST message;

– send the PMFP PLR COUNT RESPONSE message over the access of the MA PDU session via which the PMFP PLR COUNT REQUEST message was received; and

– set the counted received UL packets, if any, to zero, and start counting the received UL packets over the QoS flow on the same access which the PMFP PLR COUNT REQUEST message is received.

Upon receiving PMFP PLR COUNT RESPONSE message with the same EPTI as the allocated EPTI value of the sent PMFP PLR COUNT REQUEST message, the UE shall stop the timer T103 and consider that the counting has started.

5.4.6.2.3 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiration of the timer T103

Upon expiration of the timer T103, the UE shall abort the procedure.

5.4.6.3 UE-initiated PLR report procedure

5.4.6.3.1 UE-initiated PLR report procedure initiation

In order to initiate a UE-initiated PLR report procedure over an access of an MA PDU session, the UE shall

– allocate an EPTI value as specified in clause 5.4.2.2;

– create a PMFP PLR REPORT REQUEST message;

– set the EPTI IE of the PMFP PLR REPORT REQUEST message to the allocated EPTI value; and

– include the Additional measurement indication IE with "RC" bit set if the UE intends to request the UPF to restart counting the UL packets.

Upon sending the PMFP PLR REPORT REQUEST message the UE shall:

– start a timer T104;

– stop counting the UL packets; and

– restart counting the transmitted UL packets if the Additional measurement indication IE with "RC" bit set is included in the PMFP PLR REPORT REQUEST message.

An example of the UE-initiated PLR report procedure is shown in figure 5.4.6.3.1-1.

Figure 5.4.6.3.1-1: UE-initiated PLR report procedure

5.4.6.3.2 UE-initiated PLR report procedure completion

Upon receiving the PMFP PLR REPORT REQUEST message, the UPF shall:

– create a PMFP PLR REPORT RESPONSE message;

– set the EPTI IE of the PMFP PLR REPORT RESPONSE message to the EPTI value of the received PMFP PLR REPORT REQUEST message;

– stop counting the received UL packets and set the Counting result IE to the number of counted received UL packets since the reception of the last PMFP PLR COUNT REQUEST message over the QoS flow; and

– include the Additional measurement indication IE with "RC" bit set if accepting the request from the UE to restart counting the UL packets.

The UPF shall send the PMFP PLR REPORT RESPONSE message over the QoS flow on the same access which the PMFP PLR REPORT REQUEST message was received. Upon sending the PMFP PLR REPORT RESPONSE message, the UPF restarts counting the received UL packets over the QoS flow on the same access which the PMFP PLR REPORT REQUEST message is received if accepting the request from the UE to restart counting the UL packets.

Upon receiving the PMFP PLR REPORT RESPONSE message with the same EPTI as the allocated EPTI value of the sent PMFP PLR REPORT REQUEST message, the UE shall:

– stop the timer T104; and

– calculate the UL PLR over the QoS flow based on the number of the UL packets counted locally and the number indicated in Counting result IE in the received PMFP PLR REPORT RESPONSE message.

5.4.6.3.3 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiration of the timer T104

Upon expiration of the timer T104, the UE shall abort the UE-initiated PLR measurement procedure.

5.4.7 Network-initiated PLR measurement procedure

5.4.7.1 General

The purpose of the network-initiated PLR measurement procedure is to enable the UPF to measure the PLR of DL traffic to the UE over an access of an MA PDU session.

The network-initiated PLR measurement procedure can be performed over an access of an MA PDU session only when there is user-plane resources on the access of the MA PDU session. The network-initiated PLR measurement procedure can be performed for the QoS flow of the default QoS rule or the QoS flow of the non-default QoS rule. In the latter case, the SMF shall provide the UE with the QoS rules including downlink only or bidirectional packet filter matching the SDF to be measured, unless reflective QoS is used for the SDF during the PDU session establishment procedure or PDU session modification procedure as specified in 3GPP TS 24.501 [6].

The network-initiated PLR measurement procedure consists of following:

a) one network-initiated PLR count procedure (see clause 5.4.7.2); and

b) one or more network-initiated PLR report procedure (see clause 5.4.7.3).

If an indication to request restart of counting procedure is sent by the UPF and accepted by the UE, the network-initiated PLR measurement procedure consists of more than one network-initiated PLR report procedure. Otherwise, the network-initiated PLR measurement procedure consists of one network-initiated PLR report procedure.

The network shall not initiate another PLR measurement procedure over the same QoS flow until current network-initiated PLR measurement procedure is completed.

An example of network-initiated PLR measurement procedure which consists of the two procedures is shown in figure 5.4.7.1-1.

Figure 5.4.7.1-1: Network-initiated PLR measurement procedure

1. The UPF sends a PMFP PLR count request message to the UE. If the network-initiated PLR measurement is to measure the PLR of the SDF over a QoS flow of the non-default QoS rule, the PMFP PLR count request message is transported over the QoS flow of the non-default QoS rule. Otherwise, the PMFP PLR count request message is transported over the QoS flow of the default QoS rule.

NOTE 1: In the network-initiated PLR measurement procedure, all the PMFP messages are transported over the same QoS flow on the same access of the MA PDU session.

2. Upon sending the PMFP PLR count request message, the UPF starts counting the transmitted DL packets over the QoS flow.

3-4. Upon receiving the PMFP PLR count request message, the UE starts counting the received DL packets over the QoS flow which the PMFP PLR count request message is received from and sends the PMFP PLR count response message to the UPF. In order to determine the QFI the counted DL packet is associated with, the UE:

– learns the QFI from the header of the received DL packet (e.g. in the SDAP header as specified in 3GPP TS 37.324 [15]); or

– maps the DL packet to the QFI by evaluating the QoS rules for downlink only or bidirectional packet filter(s) if no QFI is included in the header of the received DL packet.

5-7. The UPF sends a PMFP PLR report request message to request the UE to report the number of the counted DL packets. If the UPF intends to request the UE to restart counting the DL packets, the UPF can include an indication in the PMFP PLR report request message and restart counting the transmitted DL packets over the QoS flow.

8-10. Upon receiving the PMFP PLR report request message, the UE stops counting the DL packets and sends PMFP PLR report response message which includes the number of the DL packets counted since the reception of the last PMFP PLR count request message. If an indication to request restart of counting procedure is received in the PMFP PLR report request message and accepted by the UE, the UE restarts counting the received DL packets.

11. The UPF calculates the DL packet loss rate based on the local counting result of the number of transmitted DL packets and the reported number of received DL packets included in the PMFP PLR report response message. If the UPF includes an indication to request restart of counting in the PMFP PLR report request message in step 5 and the UPF receives PMFP PLR report response message with an indication of restart counting is not accepted or without an indication of restart counting, the UPF shall abort the restart of PMFP PLR measurement procedure.

12. Same as step 5, if the UPF restarts counting the transmitted DL packets as specified in step 7.

13. Same as step 6, if the UPF restarts counting the transmitted DL packets as specified in step 7.

14. Same as step 7.

15. Same as step 8, if the UE restarts counting the received DL packets as specified in step 9.

16. Same as step 9.

17. Same as step 10, if the UE restarts counting the received DL packets as specified in step 9.

18. Same as step 11, if the UPF restarts counting the transmitted DL packets as specified in step 7.

NOTE 2: When the UPF requests and the UE accepts the restart of counting, there can be multiple occurrences of step 7, 9, and 12-18.

5.4.7.2 Network-initiated PLR count procedure

5.4.7.2.1 Network-initiated PLR count procedure initiation

In order to initiate a network-initiated PLR count procedure over an access of an MA PDU session, the UPF shall:

– allocate an EPTI value as specified in clause 5.4.2.2;

– create a PMFP PLR COUNT REQUEST message;

– set the EPTI IE of the PMFP PLR COUNT REQUEST message to the allocated EPTI value;

– send the PMFP PLR COUNT REQUEST message using the QoS flow indicated in the MAI over the access of the MA PDU session;

– start a timer T203 upon sending the PMFP PLR COUNT REQUEST message; and

– start counting the transmitted DL packets over the QoS flow.

An example of the network-initiated PLR count procedure is shown in figure 5.4.7.2.1-1.

Figure 5.4.7.2.1-1: Network-initiated PLR count procedure

5.4.7.2.2 Network-initiated PLR count procedure completion

Upon receiving the PMFP PLR COUNT REQUEST message, the UE shall:

– create a PMFP PLR COUNT RESPONSE message;

– set the EPTI IE of the PMFP PLR COUNT RESPONSE message to the EPTI value of the received PMFP PLR COUNT REQUEST message;

– send the PMFP PLR COUNT RESPONSE message over the access of the MA PDU session via which the PMFP PLR COUNT REQUEST message was received; and

– set the counted received DL packets, if any, to zero, and start counting the received DL packets over the QoS flow on the same access which the PMFP PLR COUNT REQUEST message is received.

Upon receiving PMFP PLR COUNT RESPONSE message with the same EPTI as the allocated EPTI value of the sent PMFP PLR COUNT REQUEST message, the UPF shall stop the timer T203 and consider that the counting has started.

5.4.7.2.3 Abnormal cases in the UPF

The following abnormal cases can be identified:

a) Expiration of the timer T203

Upon expiration of the timer T203, the UPF shall abort the procedure.

5.4.7.3 Network-initiated PLR report procedure

5.4.7.3.1 Network-initiated PLR report procedure initiation

In order to initiate a network-initiated PLR report procedure over an access of an MA PDU session, the UPF shall

– allocate an EPTI value as specified in clause 5.4.2.2;

– create a PMFP PLR REPORT REQUEST message;

– set the EPTI IE of the PMFP PLR REPORT REQUEST message to the allocated EPTI value; and

– include the Additional measurement indication IE with "RC" bit set if the UPF intends to request the UE to restart counting the DL packets.

Upon sending the PMFP PLR REPORT REQUEST message the UPF shall:

– start a timer T204;

– stop counting the DL packets; and

– restart counting the transmitted DL packets if the Additional measurement indication IE with "RC" bit set is included in the PMFP PLR REPORT REQUEST message.

An example of the network-initiated PLR report procedure is shown in figure 5.4.7.3.1-1.

Figure 5.4.7.3.1-1: Network-initiated PLR report procedure

5.4.7.3.2 Network-initiated PLR report procedure completion

Upon receiving the PMFP PLR REPORT REQUEST message, the UE shall:

– create a PMFP PLR REPORT RESPONSE message;

– set the EPTI IE of the PMFP PLR REPORT RESPONSE message to the EPTI value of the received PMFP PLR REPORT REQUEST message;

– stop counting the received DL packets and set the Counting result IE to the number of counted received DL packets since the reception of the last PMFP PLR COUNT REQUEST message over the QoS flow; and

– include the Additional measurement indication IE with "RC" bit set if accepting the request from the UPF to restart counting the DL packets.

The UE shall send the PMFP PLR REPORT RESPONSE message over the QoS flow on the same access which the PMFP PLR REPORT REQUEST message was received. Upon sending the PMFP PLR REPORT RESPONSE message, the UE restarts counting the received DL packets over the QoS flow on the same access which the PMFP PLR REPORT REQUEST message is received if accepting the request from the UPF to restart counting the DL packets.

Upon receiving the PMFP PLR REPORT RESPONSE message with the same EPTI as the allocated EPTI value of the sent PMFP PLR REPORT REQUEST message, the UPF shall:

– stop the timer T204; and

– calculate the DL PLR over the QoS flow based on the number of the DL packets counted locally and the number indicated in Counting result IE in the received PMFP PLR REPORT RESPONSE message.

5.4.7.3.3 Abnormal cases in the UPF

The following abnormal cases can be identified:

a) Expiration of the timer T204

Upon expiration of the timer T204, the UE shall abort the network-initiated PLR measurement procedure.

5.4.8 UE assistance data provisioning procedure

5.4.8.1 General

The purpose of the UE assistance data provisioning procedure is to enable the UE to provide to the UPF a DL traffic distribution that can be applied by the UPF for all DL traffic that applies to the UE assistance operation.

If the UE has received the UE assistance indicator in an ATSSS rule and decides to apply for an SDF a UL traffic distribution different from the default UL traffic distribution indicated in the load balancing steering mode of the ATSSS rule, the UE sends a PMFP UAD provisioning message to the UPF.

NOTE 1: It is based on UE implementation that how the UE decides to apply a different UL traffic distribution for an SDF and how the corresponding DL traffic distribution is decided.

NOTE 2: Once the UE assistance data provisioning procedure is successfully completed, if the UE receives updated ATSSS rules in which the value of the load balancing percentages adjustment operation filed is changed from "UE assistance operation is allowed" to other values, the UE needs to turn to apply immediately the UL traffic distribution for the SDF indicated in the updated ATSSS rules.

5.4.8.2 UE assistance data provisioning procedure initiation

In order to initiate a UE assistance data provisioning procedure over an access of an MA PDU session, the UE shall:

a) allocate an EPTI value as specified in clause 5.4.2.2;

b) create a PMF UAD PROVISIONING message;

c) set the EPTI IE of the PMFP UAD PROVISIONING message to the allocated EPTI value; and

d) include the DL distribution information IE with a DL traffic distribution that can be applied by the UPF for all DL traffic that applies to the UE-assistance operation.

Upon sending the PMFP UAD PROVISIONING message the UE shall start a timer T106.

The UE in the PMFP UAD provisioning message includes DL distribution information.

Figure 5.4.8.2-1: UE assistance data provisioning procedure

5.4.8.3 UE assistance data received by the network

On receipt of a PMFP UAD PROVISIONING message, the UPF may use the information in the received PMFP UAD PROVISIONING message to align the DL traffic distribution for all DL traffic that applies to the UE-assistance operation. Furthermore, the UPF shall create a PMFP UAD PROVISIONING COMPLETE message. In the PMFP UAD PROVISIONING COMPLETE message, the UPF shall set the EPTI IE to the EPTI value in the PMFP UAD PROVISIONING message. The UPF shall send the PMFP UAD PROVISIONING COMPLETE message over the access of the MA PDU session via which the PMFP UAD PROVISIONING message was received.

5.4.8.4 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiry of the timer T106

The UE shall, on the first expiry of the timer T106, retransmit the PMFP UAD PROVISIONING message and shall reset and start timer T106. This retransmission is repeated up to four times, i.e. on the fifth expiry of timer T106, the UE shall abort the procedure.

5.4.9 UE assistance data termination procedure

5.4.9.1 General

The purpose of the UE assistance data termination procedure is to enable the UE to inform the UPF that the UE assistance data operation is terminated and the UE performs UL traffic distribution according to load balancing percentages of the ATSSS rule received from the network.

If the UE decides to terminate the UE assistance data operation and instead use the split percentages for respective SDF traffic transmitted over 3GPP access and non-3GPP access as indicated in the load balancing steering mode of the ATSSS rules, the UE sends a PMFP UAT command message to the UPF.

NOTE: It is based on UE implementation how the UE decides to terminate applying UL traffic distribution different from the percentages indicated in the load balancing steering mode of the ATSSS rules.

5.4.9.2 UE assistance data termination procedure initiation

In order to initiate a UE assistance data termination procedure over an access of an MA PDU session, the UE shall:

a) allocate an EPTI value as specified in clause 5.4.2.2;

b) create a PMF UAT COMMAND message; and

c) set the EPTI IE of the PMFP UAT COMMAND message to the allocated EPTI value.

Upon sending the PMFP UAT COMMAND message the UE shall start a timer T105.

Figure 5.4.9.1-1: UE assistance data termination procedure

5.4.9.3 UE assistance data termination received by the network

On receipt of a PMFP UAT command message, the UPF shall remove the DL steering information, if created for a previous UE assistance data operation, and shall perform DL traffic distribution according to the load balancing percentages without UE assistance operation. Furthermore, the UPF shall create a PMFP UAT COMPLETE message . In the PMFP UAT COMPLETE message, the UPF shall set the EPTI IE to the EPTI value in the PMFP UAT COMMAND message. The UPF shall send the PMFP UAT COMPLETE message over the access of the MA PDU session via which the PMFP UAT COMMAND message was received.

Upon reception of a PMFP UAT COMPLETE message with the same EPTI as the allocated EPTI value, the UE shall stop the timer T105.

5.4.9.4 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Expiry of the timer T105

The UE shall, on the first expiry of the timer T105, retransmit the PMFP UAT COMMAND message and shall reset and start timer T105. This retransmission is repeated up to four times, i.e. on the fifth expiry of timer T105, the UE shall abort the procedure.