6 PDUs and parameters specific to the present document

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

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

6.1 ATSSS parameters

6.1.1 General

The ATSSS parameters are the contents of the ATSSS container as defined in clause 9.11.4.22 of 3GPP TS 24.501 [6].

The purpose of the ATSSS parameters is to indicate the parameters associated with ATSSS (e.g. ATSSS rules).

6.1.2 Encoding of ATSSS parameters

The ATSSS container contents include one or more ATSSS parameters and they are coded as shown in figure 6.1.2-1, figure 6.1.2-2 and table 6.1.2-1.

8	7	6	5	4	3	2	1
ATSSS parameter 1								octet 1 octet a
ATSSS parameter 2								octet a+1* octet b*
…								octet b+1* … octet c*
ATSSS parameter N								octet c+1* octet d*

Figure 6.1.2-1: ATSSS container contents

8	7	6	5	4	3	2	1
ATSSS parameter identifier								octet 1
ATSSS parameter contents length								octet 2 octet 3
ATSSS parameter contents								octet 4 octet a

Figure 6.1.2-2: ATSSS parameter

Table 6.1.2-1: ATSSS parameter

The ATSSS parameter identifier is encoded as follows: Bits
8	7	6	5	4	3	2	1
0	0	0	0	0	0	0	1	ATSSS rules
0	0	0	0	0	0	1	0	Network steering functionalities information
0	0	0	0	0	0	1	1	Measurement assistance information
All other values are spare.

The ATSSS parameter contents for the ATSSS rules are specified according to clause 6.1.3.

The ATSSS parameter contents for the network steering functionalities information are specified according to clause 6.1.4.

The ATSSS parameter contents for the measurement assistance information are specified according to clause 6.1.5.

6.1.3 ATSSS rules

6.1.3.1 Definition of ATSSS rules

The ATSSS rules are defined in 3GPP TS 23.501 [2] and is set of one or more ATSSS rules, where a rule is composed of:

a) an ATSSS rule ID identifying the individual ATSSS rule;

b) an ATSSS rule operation identifying whether the ATSSS rule is added to or deleted from the set of ATSSS rules;

c) a precedence value of the ATSSS rule identifying the precedence of the ATSSS rule;

d) a traffic descriptor matching a service data flow (SDF); and

e) an access selection descriptor including:

1) a steering functionality set to:

A) MPTCP functionality, the UE steers the SDF by using the MPTCP functionality; or

B) ATSSS-LL functionality, the UE steers the SDF by using the ATSSS-LL functionality;

C) UE’s supported steering functionality;

NOTE 0: The steering functionality can only be set to "UE’s supported steering functionality" if the UE indicated that the UE supports only "ATSSS Low-Layer functionality with any steering mode".

NOTE 1: If the included steering functionality is not supported by the UE, the UE ignores this ATSSS rule, and proceeds with the evaluation of the ATSSS rule with the next smallest precedence, if available.

2) a steering mode:

A) active-standby, the UE steers the SDF by using the active access if the active access is available. If the active access is not available and the standby access is available, the UE steers the SDF by using the standby access;

B) smallest delay, the UE steers the SDF by using the access network with the smallest RTT. If there is only one access available, the UE steers the SDF by using the available access. This steering mode is only applicable to non-GBR SDF;

C) load balancing, the UE steers the SDF across both the 3GPP access and the non-3GPP access with a given precentage if both accesses are available. If there is only one access available, the UE steers the SDF by using the available access. This steering mode is only applicable to non-GBR SDF; or

D) priority based, the UE steers the SDF over the access with high priority unless the access with high priority is congested or unavailable, when the UE steers the SDF over both the access with high priority and the access with low priority. This steering mode is only applicable to non-GBR SDF;

3) optionally, a steering mode additional indicator:

A) load balancing percentages adjustment operation (LBPAO):

– autonomous load-balance operation, this operation is only applicable to load balancing steering mode. With this operation, the UE may ignore the information provided in the steering mode information (i.e. percentages of the SDF traffic transmitted over 3GPP access and non-3GPP access), and that the UE may autonomously determine its own percentages for traffic splitting, in a way that maximizes the aggregated bandwidth in the uplink direction. The UPF may apply a similar behaviour in the downlink direction; or

– UE assistance operation, this operation is only applicable to load balancing steering mode. With this operation, the UE may decide how to distribute the UL traffic of the matching SDF based on the UE’s internal state (e.g. when the UE is in the special internal state such as lower battery level) and inform the UPF how it decided to distribute the UL traffic of the matching SDF by performing UE assistance data provisioning procedure as specified in clause 5.4.8.

NOTE 2: The UE is expected to determine its own percentages for traffic splitting by performing measurements across both the 3GPP access and the non-3GPP access.

4) threshold values include one maximum RTT value or one maximum packet loss rate value or both. The threshold values are only used when the steering mode is indicated as load balancing or priority based.

NOTE 3: The threshold values and the LBPAO set with either "autonomous load-balancing operation is allowed" or "UE assistance operation is allowed" in the steering mode additional indicator cannot exist at the same time in an ATSSS rule.

The UE and the UPF use the provided threshold values on both 3GPP access and non-3GPP access as follows:

A) for the load balancing steering mode,

i) if the maximum RTT value or the maximum packet loss rate value of the MA PDU session in an access exceeds the indicated value, the UE and the UPF reduce the amount of traffic sent over that access and they send traffic over the other access; and

ii) if both the maximum RTT value and the maximum packet loss rate value of the MA PDU session for both accesses do not exceed the provided threshold values, the UE and the UPF steer the SDF traffic across both the 3GPP access and non-3GPP access as indicated by the steering information of the ATSSS rule; and

B) for the priority based steering mode, the UE and the UPF use the maximum RTT value or the maximum packet loss rate value or both to detect when an access of an MA PDU session is congested. If the maximum RTT value or the maximum packet loss rate value in an access of the MA PDU session exceeds the indicated value, the UE and the UPF may send some traffic over the other access, i.e. the UE splits the SDF traffic over both the access with high priority and the access with low priority.

6.1.3.2 Encoding of ATSSS rules

The ATSSS rules are encoded as shown in figure 6.1.3.2-1, figure 6.1.3.2-2 and figure 6.1.3.2-3 and table 6.1.3.2-1.

8	7	6	5	4	3	2	1
ATSSS rule 1								octet 4 octet s
ATSSS rule 2								octet s+1 octet t
…								octet t+1 octet u
ATSSS rule n								octet u+1 octet a

Figure 6.1.3.2-1: ATSSS parameter contents including one or more ATSSS rules

8	7	6	5	4	3	2	1
Length of ATSSS rule								octet 4 octet 5
ATSSS rule ID								octet 6
ATSSS rule operation								octet 7
Precedence value of ATSSS rule								octet 8
Length of traffic descriptor								octet 9 octet 10
Traffic descriptor								octet 11 octet f
Access selection descriptor								octet f+1 octet s*

Figure 6.1.3.2-2: ATSSS rule

Length of access selection descriptor	octet f+1
Steering functionality	octet f+2
Steering mode	octet f+3
Steering mode information	octet f+4*
Steering mode additional indicator	octet z* (NOTE)
Threshold values	octet z+1* octet s*

NOTE: If the steering mode is defined as smallest delay, then “Steering mode information” is not present and z=f+4; otherwise, z=f+5.

Figure 6.1.3.2-3: Access selection descriptor

Spare

LBPAO

octet z*

Figure 6.1.3.2-4: Steering mode additional indicator

Length of threshold values

octet z+1*

Maximum RTT value

octet z+2*

octet z+3*

Maximum packet loss rate

octet s*

Figure 6.1.3.2-5: Threshold values

Table 6.1.3.2-1: ATSSS parameter contents including an ATSSS rule

ATSSS rule ID (octet 6)
The ATSSS rule ID specifies the identity of the individual ATSSS rule on which the ATSSS rule operation in octet 7 is applied.

ATSSS rule operation (octet 7)
The ATSSS rule operation is encoded as follows:
Bits

8	7	6	5	4	3	2		1
0	0	0	0	0	0	0		1			Add or replace ATSSS rule
0	0	0	0	0	0	1		0			Delete ATSSS rule
All other values are spare.

If "Add or replace ATSSS rule" is indicated, the ATSSS rule with identity as indicated in ATSSS rule ID and contents as indicated in the following octets of the ATSSS rule parameter is added to the set of ATSSS rules. If an ATSSS rule with the same ATSSS rule ID does not exist in the set of ATSSS rules, a new rule is created and added. If an ATSSS rule with the same ATSSS rule ID exists in the set of ATSSS rules, the old rule is replaced with the new ATSSS rule. If "Delete ATSSS rule" is indicated, the ATSSS rule with identity as indicated in the ATSSS rule ID parameter is deleted from the set of ATSSS set of rules and octets a+5 and onwards of the ATSSS rule parameter are ignored. If no ATSSS rule with identity as indicated in the ATSSS rule ID parameter exists in the set of ATSSS rules, the Delete ATSSS rule operation is successful without changes to the set of ATSSS rules.

Precedence value of an ATSSS rule (octet 8)
The precedence value of an ATSSS rule field shall be used to specify the precedence of the ATSSS rule among all ATSSS rules. This field shall include the binary encoded value of the precedence value in the range from 0 to 255 (decimal). The higher the value of the precedence value field, the lower the precedence of the ATSSS rule is.
The traffic descriptor length field (octets 9 to 10) indicates length of the traffic descriptor field.

Traffic descriptor (octets 11 to f)
The traffic descriptor field is, as defined in table 5.2.1 in 3GPP TS 24.526 [5], of variable size and contains a variable number (at least one) of traffic descriptor components (NOTE 3). Each traffic descriptor component shall be encoded as a sequence of one octet traffic descriptor component type identifier and a traffic descriptor component value field. The traffic descriptor component type identifier shall be transmitted first.

Traffic descriptor component type identifier Bits
8	7	6	5	4	3	2		1
0	0	0	0	0	0	0		1			Match-all type
0	0	0	0	1	0	0		0			OS Id + OS App Id type (NOTE 1)
0	0	0	1	0	0	0		0			IPv4 remote address type
0	0	1	0	0	0	0		1			IPv6 remote address/prefix length type
0	0	1	1	0	0	0		0			Protocol identifier/next header type
0	1	0	1	0	0	0		0			Single remote port type
0	1	0	1	0	0	0		1			Remote port range type
0	1	0	1	0	0		1	0			IP 3 tuple type
0	1	1	0	0	0	0		0			Security parameter index type
0	1	1	1	0	0	0		0			Type of service/traffic class type
1	0	0	0	0	0	0		0			Flow label type
1	0	0	0	0	0	0		1			Destination MAC address type
1	0	0	0	0	0	1		1			802.1Q C-TAG VID type
1	0	0	0	0	1	0		0			802.1Q S-TAG VID type
1	0	0	0	0	1	0		1			802.1Q C-TAG PCP/DEI type
1	0	0	0	0	1	1		0			802.1Q S-TAG PCP/DEI type
1	0	0	0	0	1	1		1			Ethertype type
1	0	0	0	1	0	0		0			DNN type
1	0	0	1	0	0	0		1			Destination FQDN
1	0	0	1	0	0		1	0			Regular expression
1	0	1	0	0	0	0		0			OS App Id type
1	0	1	0	0	0	0		1			Destination MAC address range type
All other values are spare. If received they shall be interpreted as unknown.

Length of access selection descriptor (octet f+1)
Bits
8	7	6	5	4	3	2		1
0	0	0	0	0	0	1		1			If the steering mode is smallest delay
0	0	0	0	0	1		0		0		If the steering mode is not smallest delay and steering mode additional indicator is not included
0	0	0	0	0	1		0		1		If the steering mode is not smallest delay and steering mode additional indicator is included
All other values are spare.

Steering functionality (octet f+2)
The steering functionality field shall be encoded by one octet (octet f+2) as follows
Bits
8	7	6	5	4	3	2		1
0	0	0	0	0	0	0		1			UE’s supported steering functionality (NOTE 2)
0	0	0	0	0	0	1		0			MPTCP functionality
0	0	0	0	0	0	1		1			ATSSS-LL functionality
All other values are spare. If the UE does not support the received encoded steering functionality in the ATSSS rule, the UE shall ignore the ATSSS rule.

Steering mode (octet f+3)
The steering mode descriptor field shall be encoded by one octet (octet f+3) as follows:
Bits
8	7	6	5	4	3	2		1
0	0	0	0	0	0	0		1			Active-standby
0	0	0	0	0	0	1		0			Smallest delay
0	0	0	0	0	0	1		1			Load balancing
0	0	0	0	0	1	0		0			Priority based
All other values are spare.

Steering mode information (octet f+4)
If the steering mode is defined as active-standby, octet f+4 shall be defined as follows:
Bits
8	7	6	5	4	3		2			1
0	0	0	0	0	0		0			1		Active 3GPP and no standby
0	0	0	0	0	0		1			0		Active 3GPP and non-3GPP standby
0	0	0	0	0	0		1			1		Active non-3GPP and no standby
0	0	0	0	0	1		0			0		Active non-3GPP and 3GPP standby
All other values are spare.

If the steering mode is defined as smallest delay, Steering mode information shall not be included.

If the steering mode is defined as load balancing, octet f+4 shall be encoded to show the percentage of the SDF traffic transmitted over 3GPP access and non-3GPP access as follows:
Bits
8	7	6	5	4	3	2		1
0	0	0	0	0	0	0		1			100% over 3GPP and 0% over non-3GPP
0	0	0	0	0	0	1		0			90% over 3GPP and 10% over non-3GPP
0	0	0	0	0	0	1		1			80% over 3GPP and 20% over non-3GPP
0	0	0	0	0	1	0		0			70% over 3GPP and 30% over non-3GPP
0	0	0	0	0	1	0		1			60% over 3GPP and 40% over non-3GPP
0	0	0	0	0	1	1		0			50% over 3GPP and 50% over non-3GPP
0	0	0	0	0	1	1		1			40% over 3GPP and 60% over non-3GPP
0	0	0	0	1	0	0		0			30% over 3GPP and 70% over non-3GPP
0	0	0	0	1	0	0		1			20% over 3GPP and 80% over non-3GPP
0	0	0	0	1	0	1		0			10% over 3GPP and 90% over non-3GPP
0	0	0	0	1	0	1		1			0% over 3GPP and 100% over non-3GPP
All other values are spare.

If the steering mode is defined as priority-based, octet f+4 shall be encoded as:
Bits
8	7	6	5	4	3	2		1
0	0	0	0	0	0	0		1			3GPP is high priority access
0	0	0	0	0	0	1		0			non-3GPP is high priority access
All other values are spare.

Steering mode additional indicator (octetz)
The steering mode additional indicator provides information to adjust the traffic steering. The following operations exist.

LBPAO (load balancing percentages adjustment operation) (octet z, bits 2 to 1) is set as follows:
Bit
2	1
0	0	No additional operation
0	1	Autonomous load-balance operation is allowed
1	0	UE assistance operation is allowed
1	1	spare

Maximum RTT value (octets z+2 to z+3)
If the steering mode is defined as load balancing or priority based (octet f+3), the maximum RTT value field indicates binary encoded value of the maximum RTT in miliseconds (NOTE 4).

Maximum packet loss rate (octet s)
If the steering mode is defined as load balancing or priority based (octet f+3), the maximum packet loss rate field indicates the allowed percentage of packet rate lost as follows (NOTE 4):
Bits
8	7	6	5	4	3		2		1
0	0	0	0	0	0		0		0		0% packet loss rate
0	0	0	0	0	0		0		1		1% packet loss rate
				to
0	1	1	0	0	1		0		0		100% packet loss rate
All other values are spare (NOTE 5).

NOTE 1: For "OS Id + OS App Id type", the traffic descriptor component value field does not specify the OS version number or the version number of the application.
NOTE 2: This value shall be set by the SMF if the UE supports only one steering functionality, i.e. only "ATSSS Low-Layer functionality with any steering mode". The SMF knows the UE’s supported steering functionality during the MA PDU session establishment.
NOTE 3: Traffic descriptor components of an ATSSS rule are not required to be the same as the traffic descriptor components, defined in table 5.2.1 in 3GPP TS 24.526 [5].
NOTE 4: If the value is received for a steering mode other than load balancing or priority based, it shall be ignored.
NOTE 5: In this release of the specification if received, it shall be interpreted as value 100.

6.1.4 Network steering functionalities information

6.1.4.1 Definition of network steering functionalities information

6.1.4.1.1 MPTCP Functionality with any steering mode and the ATSSS-LL functionality with only the active-standby steering mode

In order for the UE to support the MPTCP functionality, the UE shall support the TCP extensions for multipath operation specified in IETF RFC 8684 [8].

When the UE indicates support for MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the active-standby steering mode and the network accepts to enable these functionalities for an MA PDU session of IP type in the UPF as specified in the clause 5.32.2 of 3GPP TS 23.501 [2], then the network shall provide the following information to the UE:

a) two "link-specific multipath" IP addresses/prefixes used only by the MPTCP functionality in the UE, one associated with the 3GPP access and another associated with the non-3GPP access;

NOTE: It is possible that the network provides the "link-specific multipath" IP addresses/prefix that is not routable via N6 (e.g. IPv6 link local address).

b) the IP address, port number and the type of one or more MPTCP proxies in the UPF; and

c) one or more ATSSS rules including an ATSSS rule for non-MPTCP traffic. The ATSSS rule for non-MPTCP traffic shall be composed of a precedence with value "255", a "match-all type" traffic descriptor, an "ATSSS-LL functionality" steering functionality and an "active-standby" steering mode.

In this release of the specification, the UPF shall support the Transport Converter as specified in IETF RFC 8803 [9].

In this release of the specification, the UE shall support the client extensions specified in IETF RFC 8803 [9], and only client-initiated multipath connections via a Transport Converter are supported.

The UE shall use the "link-specific multipath" addresses/prefixes to establish subflows over non-3GPP access and over 3GPP access.

When the MA PDU session is Ethernet type, the network shall not enable the MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the active-standby steering mode.

6.1.4.1.2 ATSSS-LL Functionality with any steering mode

When the UE indicates ATSSS-LL capability with any steering mode and the network accepts to enable this functionality for an MA PDU session of any supported type, then the network shall enable ATSSS-LL functionality with any steering mode in the UPF as specified in the clause 5.32.2 of 3GPP TS 23.501 [2] and provide one or more ATSSS rules to the UE.

In an ATSSS capable UE, the following ATSSS-LL requirements apply:

a) for an MA PDU session of Ethernet PDU session type, the ATSSS-LL functionality with any steering mode is mandatory; and

b) for an MA PDU session of IPv4, IPv6, or IPv4v6 PDU session type, if the UE does not support:

1) the MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the active-standby steering mode; and

2) the MPTCP functionality with any steering mode and the ATSSS-LL functionality with any steering mode,

then ATSSS-LL functionality with any steering mode is mandatory.

6.1.4.1.3 MPTCP functionality with any steering mode and the ATSSS-LL functionality with any steering mode

In order for the UE to support the MPTCP functionality, the UE shall support the TCP extensions for multipath operation specified in IETF RFC 8684[8].

When the UE indicates support for MPTCP functionality with any steering mode and the ATSSS-LL functionality with any steering mode and the network accepts to enable these functionalities for an MA PDU session of IP type in the UPF as specified in the clause 5.32.2 of 3GPP TS 23.501 [2], then the network shall provide the following information to the UE:

a) two "link-specific multipath" IP addresses/prefixes used only by the MPTCP functionality in the UE, one associated with the 3GPP access and another associated with the non-3GPP access;

b) the IP address, port number and the type of one or more MPTCP proxies in the UPF; and

c) one or more ATSSS rules.

In this release of the specification, the UPF shall support the Transport Converter as specified in IETF RFC 8803 [9].

The UE shall use the "link-specific multipath" addresses/prefixes to establish subflows over non-3GPP access and over 3GPP access.

When the MA PDU session is Ethernet type, the network shall not enable the MPTCP functionality with any steering mode and the ATSSS-LL functionality with any steering mode.

6.1.4.2 Encoding of network steering functionalities information

The network steering functionalities information contains:

a) addressing information for the ATSSS capable UE supporting MPTCP fiunctionality; and

b) addressing information and type for the MPTCP proxy;

and is encoded as shown in figure 6.1.4.2-1, figure 6.1.4.2-2 and table 6.1.4.2-1:

8	7	6	5	4	3	2	1
UE 3GPP IP address type								octet a+1
UE 3GPP IP address								octet a+2 octet k-1
UE non-3GPP IP address type								octet k
UE non-3GPP IP address								octet k+1 octet l-1
Length of MPTCP proxy information								octet l
MPTCP proxy information value 1								octet l+1


								octet m+2
MPTCP proxy information value 2								octet n


								octet o
MPTCP proxy information value n								octet p


								octet s

Figure 6.1.4.2-1: Network steering functionalities information including UE IP addresses and MPTCP proxy information

MPTCP proxy IP address type	octet l+1
MPTCP proxy IP address	octet l+2 octet m-1
MPTCP proxy port	octet m octet m+1
MPTCP proxy type	octet m+2

Figure 6.1.4.2-2: MPTCP proxy information

Table 6.1.4.2-1: UE IP addresses and MPTCP proxy information

UE 3GPP IP address type (octet a+1) is set as follows: Bits
8		7		6		5		4		3		2	1
0		0		0		0		0		0		0	1		IPv4
0		0		0		0		0		0		1	0		IPv6
0		0		0		0		0		0		1	1		IPv4v6

If the UE 3GPP IP address type indicates IPv4, then the UE 3GPP IP address field contains an IPv4 address in 4 octets.

If the UE 3GPP IP address type indicates IPv6, then the UE 3GPP IP address field contains an IPv6 address in 16 octets field and 1 octet prefix length field. The IPv6 address field shall be transmitted first.

If the UE 3GPP IP address type indicates IPv4v6, then the UE 3GPP IP address field contains two IP addresses. The first UE 3GPP IP address is an IPv4 address in 4 octets and the second UE 3GPP IP address is an IPv6 address field in 16 octets followed by 1 octet prefix length field.

UE non-3GPP IP address type (octet k) is set as follows: Bits
8	7		6		5		4		3		2			1
0	0		0		0		0		0		0			1		IPv4
0	0		0		0		0		0		1			0		IPv6
0	0		0		0		0		0		1			1		IPv4v6

If the UE non-3GPP IP address type indicates IPv4, then the UE non-3GPP IP address field contains an IPv4 address in 4 octets.

If the UE non-3GPP IP address type indicates IPv6, then the UE non-3GPP IP address field contains an IPv6 address in 16 octets field and 1 octet prefix length field. The IPv6 address field shall be transmitted first.

If the UE non-3GPP IP address type indicates IPv4v6, then the UE non-3GPP IP address field contains two IP addresses. The first UE non-3GPP IP address is an IPv4 address in 4 octets and the second UE non-3GPP IP address is an IPv6 address field in 16 octets followed by 1 octet prefix length field.

MPTCP proxy IP address type (octet l+1) is set as follows: Bits
8	7		6		5		4		3		2			1
0	0		0		0		0		0		0			1		IPv4
0	0		0		0		0		0		1			0		IPv6
0	0		0		0		0		0		1			1		IPv4v6

If the MPTCP proxy IP address type indicates IPv4, then the MPTCP proxy IP address field contains an IPv4 address in 4 octets.

If the MPTCP proxy IP address type indicates IPv6, then the MPTCP proxy IP address field contains an IPv6 address in 16 octets.

If the MPTCP proxy IP address type indicates IPv4v6, then the MPTCP proxy IP address field contains two IP addresses. The first MPTCP proxy IP address is an IPv4 address in 4 octets and the second MPTCP proxy IP address is an IPv6 address in 16 octets.

MPTCP proxy type (octet m+2) is set as follows: Bits
8	7		6		5		4		3		2			1
0	0		0		0		0		0		0			1		Transport converter
All other values are spare.

6.1.5 Measurement assistance information

6.1.5.1 Definition of measurement assistance information

The measurement assistance information is transmitted by the network to the UE.

If the UE is only capable of supporting MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the active-standby steering mode, the network may send measurement assistance information for the UE to send access availability/unavailability to the UPF. In this case, the UE and UPF shall not perform RTT measurements using PMF, the UE and UPF shall use the RTT measurements available at the MPTCP layer.

The measurement assistance information is defined in 3GPP TS 23.501 [2] and it contains:

a) addressing for the PMF in the UPF according to:

1) if the PDU session is IP type, the measurement assistance information contains IP address for the PMF with an allocated port number associated with the 3GPP access network and another allocated port number associated with non-3GPP access network for access performance measurements over the QoS flow of the default QoS rule, and optionally a QoS flow list according to figure 6.1.5.2-3 and figure 6.1.5.2-4 with the allocated port numbers to perform measurements over the QoS flows of non-default QoS rules; and

2) if the PDU session is Ethernet type, the measurement assistance information contains a MAC address associated with the 3GPP access network and another MAC address associated with the non-3GPP address network for the PMF for access performance measurements over the QoS flow of the default QoS rule, and optionally a QoS flow list according to figure 6.1.5.2-3 and figure 6.1.5.2-5 with the MAC addresses to perform for measurements over the QoS flows of non-default QoS rules; and

b) an indicator to report the availability and unavailability of an access network.

6.1.5.2 Encoding of measurement assistance information

The measurement assistance information contains addressing information for the PMF in the UPF and is encoded as shown in figure 6.1.5.2-1 and figure 6.1.5.2-2 and table 6.1.5.2-1 and table 6.1.5.2-2.

8	7	6	5	4	3	2	1
PMF IP address type									octet a+1
PMF IP address									octet a+2 octet b-5
PMF 3GPP port									octet b-4 octet b-3
PMF non-3GPP port									octet b-2 octet b-1
0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	APMQF		AARI	octet b
QoS flow list									octet b+1* octet c*

Figure 6.1.5.2-1: ATSSS parameter contents including one PMF IP address information

Table 6.1.5.2-1: PMF IP address type

PMF IP address type (octet a+1) is set as follows: Bits
8	7		6	5	4	3	2	1
0	0		0	0	0	0	0	1	IPv4
0	0		0	0	0	0	1	0	IPv6
0	0		0	0	0	0	1	1	IPv4IPv6
All other values are spare.

If the PMF IP address type indicates IPv4, then the PMF IP address field contains an IPv4 address in 4 octets.

If the PMF IP address type indicates IPv6, then the PMF IP address field contains an IPv6 address in 16 octets.

If the PMF IP address type indicates IPv4IPv6, then the PMF IP address field contains two IP addresses. The first PMF IP address is an IPv4 address in 4 octets and the second PMF IP address is an IPv6 address in 16 octets.

PMF 3GPP port (octets b-4 – b-3) is allocated port number associated with the 3GPP access network and is dedicated for the QoS flow of the default QoS flow.

PMF non-3GPP port (octets b-2 – b-1) is allocated port number associated with the non-3GPP access network and is dedicated for the QoS flow of the default QoS flow.

AARI (access availability reporting indicator) (octet b, bit 1) is set as follows: Bit
1
0		Do not report the access availability (NOTE)
1		Report the access availability

APMQF (access performance measurements per QoS flow indicator) (octet b, bit 2) is set as follows (NOTE 2): Bit
1
0		Perform access performance measurements using default QoS rule.
1		Perform access performance measurements using non-default QoS rule.

QoS flow list is according to figure 6.1.5.2-3, figure 6.1.5.2-4 and table 6.1.5.2-3.
NOTE 1: Even if AARI is set to "Do not report the access availability" during the MA PDU session establishment procedure, the UE still needs to perform access availability or unavailability report procedure over an access immediately after the MA PDU session is established to enable the UPF to determine the UDP port of the PMF in the UE or the UDP port and the IPv6 address of the PMF in the UE, as specified in clause 5.4.2.1.1. NOTE 2: If APMQF is set to "Perform access performance measurements using default QoS rule", the UE shall use octets b-4 and b-3 for PMF 3GPP port and octets b-2 and b-1 for PMF non-3GPP port and the UE shall ignore the QoS flow list, if provided. If APMQF is set to "Perform access performance measurements using non-default QoS rule" the UE shall use the information provided by the QoS flow list to perform the access performance measurements using the QoS flow of the non-default QoS rule.

8	7	6	5	4	3	2	1
PMF 3GPP MAC address								octet a+1 octet a+6
PMF non-3GPP MAC address								octet a+7 octet a+12
0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	APMQF	AARI	octet a+13
QoS flow list								octet a+14* octet b*

Figure 6.1.5.2-2: ATSSS parameter contents including one PMF MAC address information

Table 6.1.5.2-2: PMF MAC address type

PMF 3GPP MAC address contains a 6 octet MAC address associated with the 3GPP access network and is dedicated for the QoS flow of the default QoS flow.

PMF non-3GPP MAC address contains a 6 octet MAC address associated with the non-3GPP access network and is dedicated for the QoS flow of the default QoS flow.

AARI (access availability reporting indicator) (octet a+13, bit 1) is set as follows: Bit
1
0		Do not report the access availability (NOTE 1)
1		Report the access availability

APMQF (access performance measurements per QoS flow indicator) (octet a+13, bit 2) is and set as follows (NOTE 2): Bit
1
0		Perform access performance measurements using default QoS rule.
1		Perform access performance measurements using non-default QoS rule.

QoS flow list is according to figure 6.1.5.2-3, figure 6.1.5.2-5 and table 6.1.5.2-3.
NOTE 1: Even if AARI is set to "Do not report the access availability" during the MA PDU session establishment procedure, the UE still needs to perform access availability or unavailability report procedure over an access immediately after the MA PDU session is established to enable the UPF to determine the MAC address of the PMF in the UE as specified in clause 5.4.2.1.2. NOTE 2: If APMQF is set to "Perform access performance measurements using default QoS rule", the UE shall use octets a+1 through a+6 for PMF 3GPP MAC address and octets a+7 and a+12 for PMF non-3GPP MAC address and the UE shall ignore the QoS flow list, if provided. If APMQF is set to "Perform access performance measurements using non-default QoS rule" the UE shall use the information provided by the QoS flow list to perform the access performance measurements using the QoS flow of the non-default QoS rule.

8	7	6	5	4	3	2	1
Length of QoS flow contents								octet 1
QoS flow 1								octet 2 octet k
…								octet k+1* octet m-1*
QoS flow n								octet m* octet n*

Figure 6.1.5.2-3: QoS flow list information element

8	7		6	5	4	3	2	1
0 Spare		0 Spare	QFI						octet p
PMF 3GPP port									octet p+1 octet p+2
PMF non-3GPP port									octet p+3 octet p+4

Figure 6.1.5.2-4: QoS flow – IP address

8	7		6	5	4	3	2	1
0 SpareI		0 Spare	QFI						octet p
PMF 3GPP MAC address									octet p+1 octet p+6
PMF non-3GPP MAC address									octet p+7 octet p+12

Figure 6.1.5.2-5: QoS flow – MAC address

Table 6.1.5.2-3: QoS flow

QFI is defined in Table 9.11.4.12.1 of 3GPP TS 24.501 [6].

PMF 3GPP port contains a 2 octet port number, associated with the 3GPP access network for the target QoS flow.

PMF non-3GPP port contains a 2 octet port number, associated with the non-3GPP access network for the target QoS flow.

PMF 3GPP MAC address contains a 6 octet MAC address, associated with the 3GPP access network for the target QoS flow.

PMF non-3GPP MAC address contains a 6 octet MAC address, associated with the non-3GPP access network for the target QoS flow.

6.1.6 ATSSS PCO parameters

6.1.6.1 General

Clause 6.1.6 specifies PCO parameters used for ATSSS.

6.1.6.2 ATSSS request PCO parameter

The purpose of the ATSSS request PCO parameter is to provide UE parameters for MA PDU session management.

The ATSSS request PCO parameter container contents are coded as shown in figure 6.1.6.2-1 and table 6.1.6.2-1.

The ATSSS request PCO parameter container contents may be one or more octets long. If the ATSSS request PCO parameter container contents is longer than one octet, octets other than the first octet shall be ignored.

Spare

ATSSS-ST

octet 1

Figure 6.1.6.2-1: ATSSS request PCO parameter container contents

Table 6.1.6.2-1: ATSSS request PCO parameter container contents

Supported ATSSS steering functionalities and steering modes (ATSSS-ST) (octet 1, bits 1, 2, 3 and 4) (see NOTE)
This field indicates the 5GSM capability of ATSSS steering functionalities and steering modes.
Bits
4	3	2	1
0	0	0	1	ATSSS Low-Layer functionality with any steering mode supported
0	0	1	0	MPTCP functionality with any steering mode and ATSSS-LL functionality with only active-standby steering mode supported
0	0	1	1	MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode supported
All other values are reserved.

All other bits in octet 1 are spare and shall be coded as zero.

NOTE: If the ATSSS request PCO parameter is included in the PDN CONNECTIVITY REQUEST message with the request type information element set to "handover", the ATSSS-ST field is ignored.

6.1.6.3 ATSSS response with the length of two octets PCO parameter

The purpose of the ATSSS response with the length of two octets PCO parameter is to provide network parameters for MA PDU session management.

The ATSSS response with the length of two octets PCO parameter container contents are coded as shown in figure 6.1.6.3-1 and table 6.1.6.3-1.

The ATSSS response with the length of two octets PCO parameter container contents may be one or more octets long. If the ATSSS response with the length of two octets PCO parameter container contents is longer than as indicated in the figure 6.1.6.3-1, the octets after the last field of the figure 6.1.6.3-1 shall be ignored.

Spare

MAII

NSFII

octet 1

Network steering functionalities information length

octet 2*

octet 3*

Network steering functionalities information

octet 4*

octet n*

Measurement assistance information length

octet n+1*

octet n+2*

Measurement assistance information

octet n+3*

octet m*

Figure 6.1.6.3-1: ATSSS response with the length of two octets PCO parameter container contents

Table 6.1.6.3-1: ATSSS response with the length of two octets PCO parameter container contents

Network steering functionalities information indicator (NSFII) (octet 1, bit 1)
This bit indicates whether the network steering functionalities information length field and the network steering functionalities information are included.
Bit
1
0				Network steering functionalities information length field and network steering functionalities information field not included.
1				Network steering functionalities information length field and network steering functionalities information field included.

Measurement assistance information indicator (MAII) (octet 1, bit 2)
This bit indicates whether the measurement assistance information length field and the measurement assistance information field are included.
Bit
2
0				Measurement assistance information length field and the measurement assistance information field not included.
1				Measurement assistance information length field and the measurement assistance information field included.

All other bits in octet 1 are spare and shall be coded as zero.

The network steering functionalities information length field indicates length of the network steering functionalities information field.

The network steering functionalities information field is coded as specified in figure 6.1.4.2-1, figure 6.1.4.2-2 and table 6.1.4.2-1.

The measurement assistance information length field indicates length of the measurement assistance information field.

The measurement assistance information field is coded as specified in figure 6.1.5.2-1 and table 6.1.5.2-1, figure 6.1.5.2-2 and table 6.1.5.2-2.

6.2 Encoding of performance measurement function (PMF) protocol (PMFP)

6.2.1 Message functional definitions and format

6.2.1.1 General

The following PMFP messages are specified:

– PMFP echo request;

– PMFP echo response;

– PMFP access report;

– PMFP acknowledgement;

– PMFP UAD provisioning;

– PMFP UAD provisioning complete;

– PMFP UAT command;

– PMFP UAT complete;

– PMFP PLR count request;

– PMFP PLR count response;

– PMFP PLR report request; and

– PMFP PLR report response.

6.2.1.2 PMFP echo request

6.2.1.2.1 Message definition

The PMFP ECHO REQUEST message is sent by the UE to the UPF or by the UPF to the UE to initiate detection of RTT.

See table 6.2.1.2.1-1.

Message type: PMFP ECHO REQUEST

Significance: dual

Direction: UE to UPF or UPF to UE

Table 6.2.1.2.1-1: PMFP ECHO REQUEST message content

IEI	Information Element	Type/Reference	Presence	Format	Length
	PMFP echo request message identity	Message type 6.2.2.1	M	V	1
	EPTI	Extended procedure transaction identity 6.2.2.2	M	V	2
	RI	Request identity 6.2.2.5	M	V	1
70	Padding	Padding 6.2.2.6	O	TLV-E	3-1000

6.2.1.3 PMFP echo response

6.2.1.3.1 Message definition

The PMFP ECHO RESPONSE message is sent by the UPF to the UE or by the UE to the UPF as response to an PMFP ECHO REQUEST message to enable detection of RTT.

See table 6.2.1.3.1-1.

Message type: PMFP ECHO RESPONSE

Significance: dual

Direction: UE to UPF or UPF to UE

Table 6.2.1.3.1-1: PMFP ECHO RESPONSE message content

IEI	Information Element	Type/Reference	Presence	Format	Length
	PMFP echo response message identity	Message type 6.2.2.1	M	V	1
	EPTI	Extended procedure transaction identity 6.2.2.2	M	V	2
	RI	Request identity 6.2.2.5	M	V	1
70	Padding	Padding 6.2.2.6	O	TLV-E	3-1000

6.2.1.4 PMFP access report

6.2.1.4.1 Message definition

The PMFP ACCESS REPORT message is sent by the UE to the UPF to inform the UPF about access availability or unavailability.

See table 6.2.1.4.1-1.

Message type: PMFP ACCESS REPORT

Significance: dual

Direction: UE to UPF

Table 6.2.1.4.1-1: PMFP ACCESS REPORT message content

IEI	Information Element	Type/Reference	Presence	Format	Length
	PMFP access report message identity	Message type 6.2.2.1	M	V	1
	EPTI	Extended procedure transaction identity 6.2.2.2	M	V	2
	Access availability state	Access availability state 6.2.2.3	M	V	1/2
	Spare half octet	Spare half octet 6.2.2.4	M	V	1/2

6.2.1.5 PMFP acknowledgement

6.2.1.5.1 Message definition

The PMFP ACKNOWLEDGEMENT message is sent by the UPF to the UE to acknowledge reception of a PMFP ACCESS REPORT message.

See table 6.2.1.5.1-1.

Message type: PMFP ACKNOWLEDGEMENT

Significance: dual

Direction: UPF to UE

Table 6.2.1.5.1-1: PMFP ACKNOWLEDGEMENT message content

IEI

Information Element

Type/Reference

Presence

Format

Length

PMFP acknowledgement message identity

Message type

6.2.2.1

EPTI

Extended procedure transaction identity

6.2.2.2

6.2.1.6 PMFP UAD provisioning

6.2.1.6.1 Message definition

The PMFP UAD PROVISIONING message is sent by the UE to provide UE assistance data to the UPF.

See table 6.2.1.6.1-1.

Message type: PMFP UAD PROVISIONING

Significance: dual

Direction: UE to network

Table 6.2.1.6.1-1: PMFP UAD PROVISIONING message content

IEI	Information Element	Type/Reference	Presence	Format	Length
	PMFP UAD provisioning message identity	Message type 6.2.2.1	M	V	1
	EPTI	Extended procedure transaction identity 6.2.2.2	M	V	2
	DL distribution information	DL distribution information 6.2.2.8	M	V	1

6.2.1.7 PMFP PLR count request

6.2.1.7.1 Message definition

The PMFP PLR COUNT REQUEST message is sent by the UE or the UPF to initiate a PMFP PLR measurement procedure.

See table 6.2.1.7.1-1.

Message type: PMFP PLR COUNT REQUEST

Significance: dual

Direction: both

Table 6.2.1.7.1-1: PMFP PLR COUNT REQUEST message content

IEI

Information Element

Type/Reference

Presence

Format

Length

PMFP PLR count request message identity

Message type

6.2.2.1

EPTI

Extended procedure transaction identity

6.2.2.2

6.2.1.8 PMFP PLR count response

6.2.1.8.1 Message definition

The PMFP PLR COUNT RESPONSE message is sent by the UE to the UPF or the UPF to the UE to acknowledge reception of a PMFP PLR COUNT REQUEST message.

See table 6.2.1.8.1-1.

Message type: PMFP PLR COUNT RESPONSE

Significance: dual

Direction: both

Table 6.2.1.8.1-1: PMFP PLR COUNT RESPONSE message content

IEI

Information Element

Type/Reference

Presence

Format

Length

PMFP PLR count response message identity

Message type

6.2.2.1

EPTI

Extended procedure transaction identity

6.2.2.2

6.2.1.9 PMFP PLR report request

6.2.1.9.1 Message definition

The PMFP PLR REPORT REQUEST message is sent by either UE or UPF to request the report of the counting result.

See table 6.2.1.9.1-1.

Message type: PMFP PLR REPORT REQUEST

Significance: dual

Direction: both

Table 6.2.1.9.1-1: PMFP PLR REPORT REQUEST message content

IEI	Information Element	Type/Reference	Presence	Format	Length
	PMFP PLR report request message identity	Message type 6.2.2.1	M	V	1
	EPTI	Extended procedure transaction identity 6.2.2.2	M	V	2
	Additional measurement indication	Additional measurement indication 6.2.2.9	O	TV	1

6.2.1.9.2 Additional measurement indication

This IE is included in the message by either UE or UPF when the restart counting for another PLR measurement is required.

6.2.1.10 PMFP PLR report response

6.2.1.10.1 Message definition

The PMFP PLR REPORT RESPONSE message is sent by either UE or the UPF to respond the PMFP PLR REPORT REQUEST message and report the counting result.

See table 6.2.1.10.1-1.

Message type: PMFP PLR REPORT RESPONSE

Significance: dual

Direction: both

Table 6.2.1.10.1-1: PMFP PLR REPORT RESPONSE message content

IEI	Information Element	Type/Reference	Presence	Format	Length
	PMFP PLR report response message identity	Message type 6.2.2.1	M	V	1
	EPTI	Extended procedure transaction identity 6.2.2.2	M	V	2
	Counting result	Counting result 6.2.2.10	M	V	4
	Additional measurement indication	Additional measurement indication 6.2.2.9	O	TV	1

6.2.1.10.2 Additional measurement indication

This IE is included in the message by either UE or UPF to indicate whether to accept the request of restart counting for another PLR measurement in the PMFP PLR REPORT REQUEST message.

6.2.1.11 PMFP UAT command

6.2.1.11.1 Message definition

The PMFP UAT COMMAND message is sent by the UE to the UPF in order to terminate the UE assistance operation to the UPF.

See table 6.2.1.11.1-1.

Message type: PMFP UAT COMMAND

Significance: dual

Direction: UE to network

Table 6.2.1.11.1-1: PMFP UAT COMMAND message content

IEI

Information Element

Type/Reference

Presence

Format

Length

PMFP UAT command message identity

Message type

6.2.2.1

6.2.1.12 PMFP UAT complete

6.2.1.12.1 Message definition

The PMFP UAT COMPLETE message is sent by the UPF to the UE.

See table 6.2.1.12.1-1.

Message type: PMFP UAT COMPLETE

Significance: dual

Direction: network to UE

Table 6.2.1.12.1-1: PMFP UAT COMPLETE message content

IEI

Information Element

Type/Reference

Presence

Format

Length

PMFP UAT complete message identity

Message type

6.2.2.1

EPTI

Extended procedure transaction identity

6.2.2.2

6.2.1.13 PMFP UAD provisioning complete

6.2.1.13.1 Message definition

The PMFP UAD PROVISIONING COMPLETE message is sent by the UPF to the UE as response to PMFP UAD PROVISIONING message.

See table 6.2.1.13.1-1.

Message type: PMFP UAD PROVISIONING COMPLETE

Significance: dual

Direction: network to UE

Table 6.2.1.13.1-1: PMFP UAD PROVISIONING COMPLETE message content

IEI

Information Element

Type/Reference

Presence

Format

Length

PMFP UAD provisioning complete message identity

Message type

6.2.2.1

EPTI

Extended procedure transaction identity

6.2.2.2

6.2.2 Encoding of information element

6.2.2.1 Message type

Message type is a type 3 information element with length of 1 octet.

Table 6.2.2.1-1 defines the value part of the message type IE used in the PMFP.

Table 6.2.2.1-1: Message type

Bits
8	7	6	5	4	3	2	1
0	0	0	0	0	0	0	1	PMFP ECHO REQUEST message
0	0	0	0	0	0	1	0	PMFP ECHO RESPONSE message
0	0	0	0	0	0	1	1	PMFP ACCESS REPORT message
0	0	0	0	0	1	0	0	PMFP ACKNOWLEDGEMENT message

0	0	0	0	0	1	0	1	PMFP PLR COUNT REQUEST message
0	0	0	0	0	1	1	0	PMFP PLR COUNT RESPONSE message
0	0	0	0	1	0	0	1	PMFP UAD PROVISIONING message
0	0	0	0	0	1	1	1	PMFP PLR REPORT REQUEST message
0	0	0	0	1	0	0	0	PMFP PLR REPORT RESPONSE message
0	0	0	0	1	0	1	0	PMFP UAT COMMAND message
0	0	0	0	1	0	1	1	PMFP UAT COMPLETE message
0	0	0	0	1	1	0	0	PMFP UAD PROVISIONING COMPLETE message

All other values are reserved

6.2.2.2 Extended procedure transaction identity

The purpose of the extended procedure transaction identity information element is to enable distinguishing up to 10000H different bi-directional message flows. Such a message flow is called a transaction.

Extended procedure transaction identity is a type 3 information element with length of 2 octet.

The extended procedure transaction identity information element is coded as shown in figure 6.2.2.2-1 and table 6.2.2.2-1.

EPTI

octet 1

octet 2

Figure 6.2.2.2-1: Extended procedure transaction identity information element

Table 6.2.2.2-1: Extended procedure transaction identity information element

EPTI (octet 1 to octet 2)

Binary encoded EPTI value.

EPTI values between 0000H and 7FFFH indicate a UE-initiated transaction. EPTI values between 8000H and FFFFH indicate a UPF-initiated transaction.

6.2.2.3 Access availability state

The purpose of the access availability state information element is to provide information about availability of access.

The access availability state is a type 1 information element.

The access availability state information element is coded as shown in figure 6.2.2.3-1 and table 6.2.2.3-1.

Access availability state IEI

spare

AN3A

A3A

octet 1

Figure 6.2.2.3-1: Access availability state information element

Table 6.2.2.3-1: Access availability state information element

Availability over 3GPP access (A3A) (octet 1, bit 1)
Bit
1
0				3GPP access not available
1				3GPP access available

Availability over non-3GPP access (AN3A) (octet 1, bit 2)
Bit
2
0				non-3GPP access not available
1				non-3GPP access available

6.2.2.4 Spare half octet

This information element is used in the description of messages when an odd number of half octet type 1 information elements are used. This element is filled with spare bits set to zero and is placed in bits 5 to 8 of the octet unless otherwise specified.

6.2.2.5 Request identity

The purpose of the Request identity information element is to enable association of a PMF ECHO RESPONSE message with one of PMF ECHO REQUEST messages sent within one RTT measurement procedure.

The Request identity is a type 3 information element with length of 1 octet.

The Request identity information element is coded as shown in figure 6.2.2.5-1 and table 6.2.2.5-1.

8	7	6	5	4	3	2	1
Request identity value								octet 1

Figure 6.2.2.5-1: Request identity information element

Table 6.2.2.5-1: Request identity information element

Request identity value (octet 1)
Bits
8	7	6	5	4	3	2	1
0	0	0	0	0	0	0	0	\
to								} Request identity value
1	1	1	1	1	1	1	1	/

6.2.2.6 Padding

The purpose of the Padding information element is to extend the PMFP message to length requested by upper layers.

The Padding information information element is coded as shown in figure 6.2.2.6-1.

The Padding information is a type 6 information element with a minimum length of 3 octets.

Padding IEI

octet 1

Padding length

octet 2

octet 3

Spare

octets 3

octet n

Figure 6.2.2.6-1: Padding information element

6.2.2.7 Void

6.2.2.8 DL distribution information

The purpose of the DL distribution information information element is to provide a DL traffic distribution that can be applied by the UPF for all DL traffic that applies to the UE-assistance operation.

The DL distribution information is a type 3 information element with length of 2 octets.

The DL distribution information information element is coded as shown in figure 6.2.2.8-1 and table 6.2.2.8-1.

8	7	6	5	4	3	2	1
DL distribution information IEI								octet 1
DL distribution value								octet 2

Figure 6.2.2.8-1: DL distribution information information element

Table 6.2.2.8-1: DL distribution information information element

DL distribution value (octet 2)

Bits
8	7	6	5	4	3	2	1
0	0	0	0	0	0	0	1	100% over 3GPP and 0% over non-3GPP
0	0	0	0	0	0	1	0	90% over 3GPP and 10% over non-3GPP
0	0	0	0	0	0	1	1	80% over 3GPP and 20% over non-3GPP
0	0	0	0	0	1	0	0	70% over 3GPP and 30% over non-3GPP
0	0	0	0	0	1	0	1	60% over 3GPP and 40% over non-3GPP
0	0	0	0	0	1	1	0	50% over 3GPP and 50% over non-3GPP
0	0	0	0	0	1	1	1	40% over 3GPP and 60% over non-3GPP
0	0	0	0	1	0	0	0	30% over 3GPP and 70% over non-3GPP
0	0	0	0	1	0	0	1	20% over 3GPP and 80% over non-3GPP
0	0	0	0	1	0	1	0	10% over 3GPP and 90% over non-3GPP
0	0	0	0	1	0	1	1	0% over 3GPP and 100% over non-3GPP
All other values are spare.

6.2.2.9 Additional measurement indication

The purpose of the additional measurement indication information element is to indicate whether to restart counting for another PLR measurement.

The additional measurement indication is a type 1 information element.

The additional measurement indication information element is coded as shown in figure 6.2.2.9-1 and table 6.2.2.9-1.

Additional measurement indication IEI

spare

ACR

octet 1

Figure 6.2.2.9-1: Additional measurement indication information element

Table 6.2.2.9-1: Additional measurement indication information element

Restart counting (RC) (octet 1, bit 1)
Bit
1
0				Restart counting is not to be performed
1				Restart counting is to be performed

Bits 2 to 4 are spare and shall be coded as zero.

6.2.2.10 Counting result

The purpose of the counting result information element is to indicate the number of the counted packets.

The counting result is a type 3 information element with length of 5 octet.

The counting result information element is coded as shown in figure 6.2.2.10-1.

Counting result IEI

octet 1

Counting result

octet 2

octet 5

Figure 6.2.2.10-1: Counting result information element

Table 6.2.2.10-1: Counting result information element

Counting result (octet 1 to octet 5)

Binary encoded counting result value.

6.3 Encoding of 3GPP IEEE MAC based protocol family

Ethertype of the 3GPP IEEE MAC based protocol family is XYZ.

Editor’s note: ethertype of the 3GPP IEEE MAC based protocol family will be assigned by IEEE.

The MAC client data field of a MAC frame as specified in IEEE 802.3 [12] with the length/type field set to the ethertype of the 3GPP IEEE MAC based protocol family contains a 3GPP IEEE MAC based protocol family envelope. The 3GPP IEEE MAC based protocol family envelope is encoded as shown in figure 6.3-1 and table 6.3-1.

Protocol subtype

octet 1

Protocol data

octet 2

octet x

Figure 6.3-1: 3GPP IEEE MAC based protocol family envelope

Table 6.3-1: 3GPP IEEE MAC based protocol family envelope

Protocol subtype (octet 1) The protocol subtype field identifies protocol of the protocol data field.
Bits
8	7	6	5	4	3	2	1
0	0	0	0	0	0	0	1	Performance measurement function protocol (PMFP).
All other values are reserved.

Protocol data (octets 2 to x) If the protocol subtype field is set to "Performance measurement function protocol (PMFP)", the protocol data field shall be encoded as a sequence of a two octets PMFP message length field and a PMFP message field. The PMFP message length field shall indicate the length in octets of the PMFP message field. The PMFP message field shall contain a PMFP message as specified in clause 6.2.1.

NOTE: A sending entity shall not set the protocol subtype field to a reserved value. A receiving entity shall ignore a 3GPP IEEE MAC based protocol family envelope if the protocol subtype field is set to a reserved value.