9.11.4 5GS session management (5GSM) information elements

24.5013GPPNon-Access-Stratum (NAS) protocol for 5G System (5GS)Release 18Stage 3TS

9.11.4.1 5GSM capability

The purpose of the 5GSM capability information element is to indicate UE capability related to the PDU session management.

The 5GSM capability information element is coded as shown in figure 9.11.4.1.1 and table 9.11.4.1.1.

The 5GSM capability is a type 4 information element with a minimum length of 3 octets and a maximum length of 15 octets.

8

7

6

5

4

3

2

1

5GSM capability IEI

octet 1

Length of 5GSM capability contents

octet 2

TPMIC

ATSSS-ST

EPT-S1

MH6-PDU

RqoS

octet 3

0 Spare

0 Spare

0 Spare

0 Spare

0 Spare

0 Spare

SDNA EPC

APMQF

octet 4*

0

0

0

0

0

0

0

0

octet 5* -15*

Spare

Figure 9.11.4.1.1: 5GSM capability information element

Table 9.11.4.1.1: 5GSM capability information element

5GSM capability value

RqoS (octet 3, bit 1)

This bit indicates the 5GSM capability to support reflective QoS.

0

Reflective QoS not supported

1

Reflective QoS supported

Multi-homed IPv6 PDU session (MH6-PDU) (octet 3, bit 2)

This bit indicates the 5GSM capability for Multi-homed IPv6 PDU session.

0

Multi-homed IPv6 PDU session not supported

1

Multi-homed IPv6 PDU session supported

Ethernet PDN type in S1 mode (EPT-S1) (octet 3, bit 3)

This bit indicates UE’s 5GSM capability for Ethernet PDN type in S1 mode.

0

Ethernet PDN type in S1 mode not supported

1

Ethernet PDN type in S1 mode supported

Supported ATSSS steering functionalities and steering modes (ATSSS-ST) (octet 3, bits 4 to 7)

These bits indicate the 5GSM capability of ATSSS steering functionalities and steering modes

0

0

0

0

ATSSS not supported

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.

Transfer of port management information containers (TPMIC) (octet 3, bit 8)

This bit indicates the 5GSM capability to support transfer of port management information containers

0

Transfer of port management information containers not supported

1

Transfer of port management information containers supported

Access performance measurements per QoS flow rule (APMQF) (octet 4, bit1)

This bit indicates the 5GSM capability to support access performance measurements using the QoS flow of the non default QoS rule, that is used by the service data flow (SDF) traffic.

0

Access performance measurements per QoS flow not supported.

1

Access performance measurements per QoS flow supported.

Secondary DN authentication and authorization over EPC (SDNAEPC) (octet 4, bit 2)

This bit indicates the 5GSM capability to support secondary DN authentication and authorization over EPC

0

Secondary DN authentication and authorization over EPC not supported

1

Secondary DN authentication and authorization over EPC supported

All other bits in octet 4 to 15 are spare and shall be coded as zero, if the respective octet is included in the information element.

9.11.4.2 5GSM cause

The purpose of the 5GSM cause information element is to indicate the reason why a 5GSM request is rejected.

The 5GSM cause information element is coded as shown in figure 9.11.4.2.1 and table 9.11.4.2.1.

The 5GSM cause is a type 3 information element with a length of 2 octets.

8

7

6

5

4

3

2

1

5GSM cause IEI

octet 1

Cause value

octet 2

Figure 9.11.4.2.1: 5GSM cause information element

Table 9.11.4.2.1: 5GSM cause information element

Cause value (octet 2)

Bits

8

7

6

5

4

3

2

1

0

0

0

0

1

0

0

0

Operator determined barring

0

0

0

1

1

0

1

0

Insufficient resources

0

0

0

1

1

0

1

1

Missing or unknown DNN

0

0

0

1

1

1

0

0

Unknown PDU session type

0

0

0

1

1

1

0

1

User authentication or authorization failed

0

0

0

1

1

1

1

1

Request rejected, unspecified

0

0

1

0

0

0

0

0

Service option not supported

0

0

1

0

0

0

0

1

Requested service option not subscribed

0

0

1

0

0

0

1

1

PTI already in use

0

0

1

0

0

1

0

0

Regular deactivation

0

0

1

0

0

1

0

1

5GS QoS not accepted

0

0

1

0

0

1

1

0

Network failure

0

0

1

0

0

1

1

1

Reactivation requested

0

0

1

0

1

0

0

1

Semantic error in the TFT operation

0

0

1

0

1

0

1

0

Syntactical error in the TFT operation

0

0

1

0

1

0

1

1

Invalid PDU session identity

0

0

1

0

1

1

0

0

Semantic errors in packet filter(s)

0

0

1

0

1

1

0

1

Syntactical error in packet filter(s)

0

0

1

0

1

1

1

0

Out of LADN service area

0

0

1

0

1

1

1

1

PTI mismatch

0

0

1

1

0

0

1

0

PDU session type IPv4 only allowed

0

0

1

1

0

0

1

1

PDU session type IPv6 only allowed

0

0

1

1

0

1

1

0

PDU session does not exist

0

0

1

1

1

0

0

1

PDU session type IPv4v6 only allowed

0

0

1

1

1

0

1

0

PDU session type Unstructured only allowed

0

0

1

1

1

0

1

1

Unsupported 5QI value

0

0

1

1

1

1

0

1

PDU session type Ethernet only allowed

0

1

0

0

0

0

1

1

Insufficient resources for specific slice and DNN

0

1

0

0

0

1

0

0

Not supported SSC mode

0

1

0

0

0

1

0

1

Insufficient resources for specific slice

0

1

0

0

0

1

1

0

Missing or unknown DNN in a slice

0

1

0

1

0

0

0

1

Invalid PTI value

0

1

0

1

0

0

1

0

Maximum data rate per UE for user-plane integrity protection is too low

0

1

0

1

0

0

1

1

Semantic error in the QoS operation

0

1

0

1

0

1

0

0

Syntactical error in the QoS operation

0

1

0

1

0

1

0

1

Invalid mapped EPS bearer identity

0

1

0

1

0

1

1

0

UAS services not allowed

0

1

0

1

1

1

1

1

Semantically incorrect message

0

1

1

0

0

0

0

0

Invalid mandatory information

0

1

1

0

0

0

0

1

Message type non-existent or not implemented

0

1

1

0

0

0

1

0

Message type not compatible with the protocol state

0

1

1

0

0

0

1

1

Information element non-existent or not implemented

0

1

1

0

0

1

0

0

Conditional IE error

0

1

1

0

0

1

0

1

Message not compatible with the protocol state

0

1

1

0

1

1

1

1

Protocol error, unspecified

Any other value received by the UE shall be treated as 0001 1111, " Request rejected, unspecified ". Any other value received by the network shall be treated as 0110 1111, "protocol error, unspecified".

9.11.4.3 Always-on PDU session indication

The purpose of the Always-on PDU session indication information element is to indicate whether a PDU session is established as an always-on PDU session.

The Always-on PDU session indication information element is coded as shown in figure 9.11.4.3.1 and table 9.11.4.3.1.

The Always-on PDU session indication is a type 1 information element.

8

7

6

5

4

3

2

1

Always-on PDU session indication IEI

0

Spare

0

Spare

0

Spare

APSI

octet 1

Figure 9.11.4.3.1: Always-on PDU session indication

Table 9.11.4.3.1: Always-on PDU session indication

Always-on PDU session indication (APSI) (octet 1)

Bit

1

0

Always-on PDU session not allowed

1

Always-on PDU session required

Bits 2, 3 and 4 are spare and shall be coded as zero,

9.11.4.4 Always-on PDU session requested

The purpose of the Always-on PDU session requested information element is to indicate whether a PDU session is requested to be established as an always-on PDU session.

The Always-on PDU session requested information element is coded as shown in figure 9.11.4.4.1 and table 9.11.4.4.1.

The Always-on PDU session requested is a type 1 information element.

8

7

6

5

4

3

2

1

Always-on PDU session requested IEI

0

Spare

0

Spare

0

Spare

APSR

octet 1

Figure 9.11.4.4.1: Always-on PDU session requested

Table 9.11.4.4.1: Always-on PDU session requested

Always-on PDU session requested (APSR) (octet 1)

Bit

1

0

Always-on PDU session not requested

1

Always-on PDU session requested

Bits 2, 3 and 4 are spare and shall be coded as zero,

9.11.4.5 Allowed SSC mode

The purpose of the Allowed SSC mode information element is to indicate the SSC modes allowed to be used by the UE for the PDU session.

The Allowed SSC mode information element is coded as shown in figure 9.11.4.5.1 and table 9.11.4.5.1.

The Allowed SSC mode is a type 1 information element.

8

7

6

5

4

3

2

1

Allowed SSC mode IEI

0

Spare

SSC3

SSC2

SSC1

octet 1

Figure 9.11.4.5.1: Allowed SSC mode information element

Table 9.11.4.5.1: Allowed SSC mode information element

SSC1 (octet 1, bit 1)

Bit

1

0

SSC mode 1 not allowed

1

SSC mode 1 allowed

SSC2 (octet 1, bit 2)

Bit

2

0

SSC mode 2 not allowed

1

SSC mode 2 allowed

SSC3 (octet 1, bit 3)

Bit

3

0

SSC mode 3 not allowed

1

SSC mode 3 allowed

Bit 4 is spare and shall be encoded as zero.

9.11.4.6 Extended protocol configuration options

See subclause 10.5.6.3A in 3GPP TS 24.008 [12].

9.11.4.7 Integrity protection maximum data rate

The purpose of the integrity protection maximum data rate information element is for the UE to indicate to the network the maximum data rate per UE for user-plane integrity protection for uplink and the maximum data rate per UE for user-plane integrity protection for downlink that are supported by the UE.

The integrity protection maximum data rate is coded as shown in figure 9.11.4.7.1 and table 9.11.4.7.2.

The integrity protection maximum data rate is a type 3 information element with a length of 3 octets.

8

7

6

5

4

3

2

1

Integrity protection maximum data rate IEI

octet 1

Maximum data rate per UE for user-plane integrity protection for uplink

octet 2

Maximum data rate per UE for user-plane integrity protection for downlink

octet 3

Figure 9.11.4.7.1: Integrity protection maximum data rate information element

Table 9.11.4.7.2: Integrity protection maximum data rate information element

Maximum data rate per UE for user-plane integrity protection for uplink (octet 2)

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

0

64 kbps (NOTE 3)

0

0

0

0

0

0

0

1

NULL (NOTE 1)

1

1

1

1

1

1

1

1

Full data rate (NOTE 2)

All other values are spare and shall not be used by a UE compliant to the present version of this specification. If received they shall be interpreted as "64 kbps".

Maximum data rate per UE for user-plane integrity protection for downlink (octet 3)

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

0

64 kbps (NOTE 3)

0

0

0

0

0

0

0

1

NULL (NOTE 1)

1

1

1

1

1

1

1

1

Full data rate (NOTE 2)

All other values are spare and shall not be used by a UE compliant to the present version of this specification. If received they shall be interpreted as "64 kbps".

NOTE 1: This value shall be used when N3 data transfer is not supported by the UE or when the UE does not support standalone NR connected to 5GCN.

NOTE 2: If the UE supports N3 data transfer and supports standalone NR connected to 5GCN (this includes UEs supporting NR-NR dual connectivity, NR-E-UTRA dual connectivity with MN terminated bearers or both of them as described in 3GPP TS 37.340 [51]), then the UE shall use this value.

NOTE 3: The network can receive this value from a UE compliant to an earlier version of this specification.

9.11.4.8 Mapped EPS bearer contexts

The purpose of the mapped EPS bearer contexts information element is to indicate a set of EPS bearer contexts for a PDU session, as described in subclause 6.1.4.1.

The mapped EPS bearer contexts information element is a type 6 information element with a minimum length of 7 octet and a maximum length of 65538 octets.

The mapped EPS bearer contexts information element is coded as shown in figure 9.11.4.8.1, figure 9.11.4.8.2, figure 9.11.4.8.3 and table 9.11.4.8.1.

8

7

6

5

4

3

2

1

Mapped EPS bearer contexts IEI

octet 1

Length of Mapped EPS bearer contexts contents

octet 2

octet 3

Mapped EPS bearer context 1

octet 4

octet u

Mapped EPS bearer context 2

octet u+1

octet v

octet v+1

octet w

Mapped EPS bearer context n

octet w+1

octet x

Figure 9.11.4.8.1: Mapped EPS bearer contexts

8

7

6

5

4

3

2

1

EPS bearer identity

octet 4

Length of Mapped EPS bearer context

octet 5

octet 6

Operation code

0

Spare

E bit

Number of EPS parameters

octet 7

EPS parameters list

octet 8*

octet u*

Figure 9.11.4.8.2: Mapped EPS bearer context

8

7

6

5

4

3

2

1

EPS parameter identifier 1

octet 8

Length of EPS parameter contents 1

octet 9

EPS parameter contents 1

octet 10

octet h

EPS parameter identifier 2

octet h+1

Length of EPS parameter contents 2

octet h+2

EPS parameter contents 2

octet h+3

octet i

octet i+1

octet j

EPS parameter identifier N

octet j+1

Length of EPS parameter contents N

octet j+2

EPS parameter contents N

octet j+3

octet u

Figure 9.11.4.8.3: EPS parameters list

Table 9.11.4.8.1: Mapped EPS bearer contexts information element

EPS bearer identity (octet 4)

Bits 5 to 8 contain the EPS bearer identity, and are coded as specified in subclause 9.3.2 of 3GPP TS 24.301 [15]. Bits 1 to 4 are spare and shall be coded as zero.

Operation code (bits 8 to 7 of octet 7)
Bits
8 7

0 0 Reserved
0 1 Create new EPS bearer

1 0 Delete existing EPS bearer

1 1 Modify existing EPS bearer

Bit 6 of octet 7 is spare and shall be coded as zero.

E bit (bit 5 of octet 7)

For the "create new EPS bearer" operation, the E bit is encoded as follows:

Bit
5

0 parameters list is not included (NOTE)

1 parameters list is included

For the "modify existing EPS bearer" operation, the E bit is encoded as follows:

Bit
5

0 extension of previously provided parameters list

1 replacement of all previously provided parameters list

If the E bit is set to "parameters list is included", the number of EPS parameters field has non-zero value. If the E bit is set to "extension of previously provided parameters list" or "replacement of previously provided parameters list", the number of parameters field has non-zero value.

For the "create new EPS bearer" operation and "delete existing EPS bearer" operation, bit 5 of octet 7 is ignored.

Number of EPS parameters (bits 4 to 1 of octet 7)

The number of EPS parameters contains the binary coding for the number of EPS parameters in the EPS parameters list field. The number of EPS parameters field is encoded in bits 4 through 1 of octet 7 where bit 4 is the most significant and bit 1 is the least significant bit.

EPS parameters list (octets 8 to u)

The EPS parameters list contains a variable number of EPS parameters.

Each EPS parameter included in the EPS parameters list is of variable length and consists of:

– an EPS parameter identifier (1 octet);
– the length of the EPS parameter contents (1 octet); and
– the EPS parameter contents itself (variable amount of octets).

The EPS parameter identifier field is used to identify each EPS parameter included in the EPS parameters list and it contains the hexadecimal coding of the EPS parameter identifier. Bit 8 of the EPS parameter identifier field contains the most significant bit and bit 1 contains the least significant bit. In this version of the protocol, the following EPS parameter identifiers are specified:

– 01H (Mapped EPS QoS parameters);
– 02H (Mapped extended EPS QoS parameters); and

– 03H (Traffic flow template).

– 04H (APN-AMBR).

– 05H (extended APN-AMBR).

If the EPS parameters list contains an EPS parameter identifier that is not supported by the receiving entity the corresponding EPS parameter shall be discarded.

The length of EPS parameter contents field contains the binary coded representation of the length of the EPS parameter contents field. The first bit in transmission order is the most significant bit.

When the parameter identifier indicates mapped EPS QoS parameters, the length and parameter contents field are coded as specified in subclause 9.9.4.3 of 3GPP TS 24.301 [15].

When the parameter identifier indicates mapped extended EPS QoS parameters, the length and parameter contents field are coded as specified in subclause 9.9.4.30 of 3GPP TS 24.301 [15].

When the parameter identifier indicates traffic flow template, the length and parameter contents field are coded from octet 2 as shown figure 10.5.144 and table 10.5.16.2 of 3GPP TS 24.008 [12].

When the parameter identifier indicates APN-AMBR, the length and parameter contents field are coded as specified in subclause 9.9.4.2 of 3GPP TS 24.301 [15].

When the parameter identifier indicates Extended APN-AMBR, the length and parameter contents field are coded as specified in subclause 9.9.4.29 of 3GPP TS 24.301 [15].

NOTE: This value shall not be used In this version of the specification.

9.11.4.9 Maximum number of supported packet filters

The purpose of the Maximum number of supported packet filters information element is for the UE to indicate to the network the maximum number of packet filters, associated with signaled QoS rules, that can be supported by the UE for the PDU session that is being established, when the PDU session type "IPv4", "IPv6", "IPv4v6" or "Ethernet".

The Maximum number of supported packet filters is coded as shown in figure 9.11.4.9.1 and table 9.11.4.9.1.

The Maximum number of supported packet filters is a type 3 information element with a length of 3 octets.

8

7

6

5

4

3

2

1

Maximum number of supported packet filters IEI

octet 1

Maximum number of supported packet filters

octet 2

Maximum number of supported packet filters (continued)

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

octet 3

Figure 9.11.4.9.1: Maximum number of supported packet filters information element

Table 9.11.4.9.1: Maximum number of supported packet filters information element

Maximum number of supported packet filters (octet 2 to 3)

In the Maximum number of supported packet filters field bit 8 of the first octet is the most significant bit and bit 6 of second octet is the least significant bit. Bit 5 to bit 1 of the second octet are spare bits and shall be coded as zero.

The number of supported packet filters shall be in the range of 17 to 1024.

9.11.4.10 PDU address

The purpose of the PDU address information element is to assign to the UE:

– an IPv4 address associated with a PDU session;

– an interface identifier for the IPv6 link local address associated with the PDU session; or

– an IPv4 address and an interface identifier for the IPv6 link local address, associated with the PDU session.

This purpose of the PDU address information element is also to enable the W-AGF acting on behalf of the FN-RG to provide an interface identifier for the IPv6 link local address associated with the PDU session suggested to be allocated to the FN-RG, and to enable the SMF to provide SMF’s IPv6 link local address to the W-AGF acting on behalf of the FN-RG.

The PDU address information element is coded as shown in figure 9.11.4.10.1 and table 9.11.4.10.1.

The PDU address is a type 4 information element with minimum length of 7 octets and a maximum length of 31 octets.

8

7

6

5

4

3

2

1

PDU address IEI

octet 1

Length of PDU address contents

octet 2

0

Spare

0

Spare

0

Spare

0

Spare

SI6LLA

PDU session type value

octet 3

PDU address information

octet 4

octet n

SMF’s IPv6 link local address

octet (n+1)*

octet (n+16)*

Figure 9.11.4.10.1: PDU address information element

Table 9.11.4.10.1: PDU address information element

PDU session type value (octet 3, bits 1 to 3)

Bits

3

2

1

0

0

1

IPv4

0

1

0

IPv6

0

1

1

IPv4v6

All other values are reserved.

SI6LLA (SMF’s IPv6 link local address) bit (octet 3, bit 4) (see NOTE)

Bit

4

0

SMF’s IPv6 link local address field is absent

1

SMF’s IPv6 link local address field is present

Bits 5 to 8 of octet 3 are spare and shall be coded as zero.

PDU address information (octet 4 to n)

If the PDU session type value indicates IPv4, the PDU address information in octet 4 to octet 7 contains an IPv4 address.

If the PDU session type value indicates IPv6, the PDU address information in octet 4 to octet 11 contains an interface identifier for the IPv6 link local address.

If the PDU session type value indicates IPv4v6, the PDU address information in octet 4 to octet 11 contains an interface identifier for the IPv6 link local address and in octet 12 to octet 15 contains an IPv4 address.

SMF’s IPv6 link local address (octet n+1 to n+16)

SMF’s IPv6 link local address field contains SMF’s IPv6 link local address.

NOTE: In the UE to network direction, the SI6LLA bit shall be set to "SMF’s IPv6 link local address field is absent".

9.11.4.11 PDU session type

The purpose of the PDU session type information element is to indicate type of the PDU session.

The PDU session type information element is coded as shown in figure 9.11.4.11.1 and table 9.11.4.11.1.

The PDU session type is a type 1 information element.

8

7

6

5

4

3

2

1

PDU session type IEI

0

Spare

PDU session type value

octet 1

Figure 9.11.4.11.1: PDU session type information element

Table 9.11.4.11.1: PDU session type information element

PDU session type value (octet 1, bit 1 to bit 3)

Bits

3

2

1

0

0

1

IPv4

0

1

0

IPv6

0

1

1

IPv4v6

1

0

0

Unstructured

1

0

1

Ethernet

1

1

1

reserved

All other values are unused and shall be interpreted as "IPv4v6", if received by the UE or the network.

9.11.4.12 QoS flow descriptions

The purpose of the QoS flow descriptions information element is to indicate a set of QoS flow descriptions to be used by the UE, where each QoS flow description is a set of parameters as described in subclause 6.2.5.1.1.4.

The QoS flow descriptions information element is a type 6 information element with a minimum length of 6 octets. The maximum length for the information element is 65538 octets.

The QoS flow descriptions information element is coded as shown in figure 9.11.4.12.1, figure 9.11.4.12.2, figure 9.11.4.12.3, figure 9.11.4.12.4, and table 9.11.4.12.1.

8

7

6

5

4

3

2

1

QoS flow descriptions IEI

octet 1

Length of QoS flow descriptions contents

octet 2

octet 3

QoS flow description 1

octet 4

octet u

QoS flow description 2

octet u+1

octet v

octet v+1

octet w

QoS flow description n

octet w+1

octet x

Figure 9.11.4.12.1: QoS flow descriptions information element

8

7

6

5

4

3

2

1

0

Spare

0

Spare

QFI

octet 4

Operation code

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

octet 5

0

Spare

E

Number of parameters

octet 6

Parameters list

octet 7*

octet u*

Figure 9.11.4.12.2: QoS flow description

8

7

6

5

4

3

2

1

Parameter 1

octet 7

octet m

Parameter 2

octet m+1

octet n

octet n+1

octet o

Parameter n

octet o+1

octet u

Figure 9.11.4.12.3: Parameters list

8

7

6

5

4

3

2

1

Parameter identifier

octet 7

Length of parameter contents

octet 8

Parameter contents

octet 9

octet m

Figure 9.11.4.12.4: Parameter

Table 9.11.4.12.1: QoS flow descriptions information element

QoS flow identifier (QFI) (bits 6 to 1 of octet 4)

QFI field contains the QoS flow identifier.

Bits

6 5 4 3 2 1

0 0 0 0 0 0 no QoS flow identifier assigned

0 0 0 0 0 1 QFI 1

to

1 1 1 1 1 1 QFI 63

The network shall not set the QFI value to 0.

Operation code (bits 8 to 6 of octet 5)

Bits

8 7 6

0 0 1 Create new QoS flow description

0 1 0 Delete existing QoS flow description

0 1 1 Modify existing QoS flow description

All other values are reserved.

E bit (bit 7 of octet 6)

For the "create new QoS flow description" operation, the E bit is encoded as follows:

Bit
7

0 reserved

1 parameters list is included

For the "Delete existing QoS flow description" operation, the E bit is encoded as follows:

Bit
7

0 parameters list is not included

1 reserved

For the "modify existing QoS flow description" operation, the E bit is encoded as follows:

Bit
7

0 extension of previously provided parameters

1 replacement of all previously provided parameters

If the E bit is set to "parameters list is not included", the number of parameters field has zero value. If the E bit is set to "parameters list is included", the number of parameters field has non-zero value. If the E bit is set to "extension of previously provided parameters" or "replacement of all previously provided parameters", the number of parameters field has non-zero value. If the E bit is set to "extension of previously provided parameters" and one of the parameters in the new parameters list already exists in the previously provided parameters, the parameter shall be set to the new value.

Number of parameters (bits 6 to 1 of octet 6)

The number of parameters field contains the binary coding for the number of parameters in the parameters list field. The number of parameters field is encoded in bits 6 through 1 of octet 6 where bit 6 is the most significant and bit 1 is the least significant bit.

Parameters list (octets 7 to u)

The parameters list contains a variable number of parameters.

Each parameter included in the parameters list is of variable length and consists of:

– a parameter identifier (1 octet);
– the length of the parameter contents (1 octet); and
– the parameter contents itself (variable amount of octets).

The parameter identifier field is used to identify each parameter included in the parameters list and it contains the hexadecimal coding of the parameter identifier. Bit 8 of the parameter identifier field contains the most significant bit and bit 1 contains the least significant bit. In this version of the protocol, the following parameter identifiers are specified:

– 01H (5QI);
– 02H (GFBR uplink);

– 03H (GFBR downlink);

– 04H (MFBR uplink);

– 05H (MFBR downlink);

– 06H (Averaging window); and

– 07H (EPS bearer identity).

If the parameters list contains a parameter identifier that is not supported by the receiving entity the corresponding parameter shall be discarded.

The length of parameter contents field contains the binary coded representation of the length of the parameter contents field. The first bit in transmission order is the most significant bit.

When the parameter identifier indicates 5QI, the parameter contents field contains the binary representation of 5G QoS identifier (5QI) that is one octet in length.

5QI:

Bits

8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 Reserved

0 0 0 0 0 0 0 1 5QI 1

0 0 0 0 0 0 1 0 5QI 2

0 0 0 0 0 0 1 1 5QI 3

0 0 0 0 0 1 0 0 5QI 4

0 0 0 0 0 1 0 1 5QI 5

0 0 0 0 0 1 1 0 5QI 6

0 0 0 0 0 1 1 1 5QI 7

0 0 0 0 1 0 0 0 5QI 8

0 0 0 0 1 0 0 1 5QI 9

0 0 0 0 1 0 1 0 5QI 10

0 0 0 0 1 0 1 1

to Spare

0 1 0 0 0 0 0 0

0 1 0 0 0 0 0 1 5QI 65

0 1 0 0 0 0 1 0 5QI 66

0 1 0 0 0 0 1 1 5QI 67

0 1 0 0 0 1 0 0 Spare

0 1 0 0 0 1 0 1 5QI 69

0 1 0 0 0 1 1 0 5QI 70

0 1 0 0 0 1 1 1 5QI 71

0 1 0 0 1 0 0 0 5QI 72

0 1 0 0 1 0 0 1 5QI 73

0 1 0 0 1 0 1 0 5QI 74

0 1 0 0 1 0 1 1 5QI 75

0 1 0 0 1 1 0 0 5QI 76

0 1 0 0 1 1 0 1

to Spare

0 1 0 0 1 1 1 0

0 1 0 0 1 1 1 1 5QI 79

0 1 0 1 0 0 0 0 5QI 80

0 1 0 1 0 0 0 1 Spare

0 1 0 1 0 0 1 0 5QI 82

0 1 0 1 0 0 1 1 5QI 83

0 1 0 1 0 1 0 0 5QI 84

0 1 0 1 0 1 0 1 5QI 85

0 1 0 1 0 1 1 0 5QI 86

0 1 0 1 0 1 1 0 5QI 87

0 1 0 1 1 0 0 0 5QI 88

0 1 0 1 1 0 0 1 5QI 89

0 1 0 1 1 0 1 0 5QI 90

0 1 0 1 1 0 1 1

0 1 0 1 1 0 1 1

to Spare

0 1 1 1 1 1 1 1

1 0 0 0 0 0 0 0

to Operator-specific 5QIs

1 1 1 1 1 1 1 0

1 1 1 1 1 1 1 1 Reserved

The network shall consider all other values not explicitly defined in this version of the protocol as unsupported.

If the UE receives a 5QI value (excluding the reserved 5QI values) that it does not understand, the UE shall choose a 5QI value from the set of 5QI values defined in this version of the protocol (see 3GPP TS 23.501 [8]) and associated with:

– GBR QoS flows, if the QoS flow includes a GFBR uplink parameter, a GFBR downlink parameter, a MFBR uplink parameter and a MFBR downlink parameter; and

– non-GBR QoS flows, if the QoS flow does not include any one of a GFBR uplink parameter, a GFBR downlink parameter, a MFBR uplink parameter or a MFBR downlink parameter.

The UE shall use this chosen 5QI value for internal operations only. The UE shall use the received 5QI value in subsequent NAS signalling procedures.

When the parameter identifier indicates "GFBR uplink", the parameter contents field contains one octet indicating the unit of the guaranteed flow bit rate for uplink followed by two octets containing the value of the guaranteed flow bit rate for uplink.

Unit of the guaranteed flow bit rate for uplink (octet 1)

Bits

8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 value is not used (see NOTE 2)

0 0 0 0 0 0 0 1 value is incremented in multiples of 1 Kbps

0 0 0 0 0 0 1 0 value is incremented in multiples of 4 Kbps

0 0 0 0 0 0 1 1 value is incremented in multiples of 16 Kbps

0 0 0 0 0 1 0 0 value is incremented in multiples of 64 Kbps

0 0 0 0 0 1 0 1 value is incremented in multiples of 256 Kbps

0 0 0 0 0 1 1 0 value is incremented in multiples of 1 Mbps

0 0 0 0 0 1 1 1 value is incremented in multiples of 4 Mbps

0 0 0 0 1 0 0 0 value is incremented in multiples of 16 Mbps

0 0 0 0 1 0 0 1 value is incremented in multiples of 64 Mbps

0 0 0 0 1 0 1 0 value is incremented in multiples of 256 Mbps

0 0 0 0 1 0 1 1 value is incremented in multiples of 1 Gbps

0 0 0 0 1 1 0 0 value is incremented in multiples of 4 Gbps

0 0 0 0 1 1 0 1 value is incremented in multiples of 16 Gbps

0 0 0 0 1 1 1 0 value is incremented in multiples of 64 Gbps

0 0 0 0 1 1 1 1 value is incremented in multiples of 256 Gbps

0 0 0 1 0 0 0 0 value is incremented in multiples of 1 Tbps

0 0 0 1 0 0 0 1 value is incremented in multiples of 4 Tbps

0 0 0 1 0 0 1 0 value is incremented in multiples of 16 Tbps

0 0 0 1 0 0 1 1 value is incremented in multiples of 64 Tbps

0 0 0 1 0 1 0 0 value is incremented in multiples of 256 Tbps

0 0 0 1 0 1 0 1 value is incremented in multiples of 1 Pbps

0 0 0 1 0 1 1 0 value is incremented in multiples of 4 Pbps

0 0 0 1 0 1 1 1 value is incremented in multiples of 16 Pbps

0 0 0 1 1 0 0 0 value is incremented in multiples of 64 Pbps

0 0 0 1 1 0 0 1 value is incremented in multiples of 256 Pbps

Other values shall be interpreted as multiples of 256 Pbps in this version of the protocol.

Value of the guaranteed flow bit rate for uplink (octets 2 and 3)

Octets 2 and 3 represent the binary coded value of the guaranteed flow bit rate for uplink in units defined by the unit of the guaranteed flow bit rate for uplink.

When the UE indicates subscribed GFBR for uplink, the "GFBR uplink" parameter is not included in the "Parameters list".

When the parameter identifier indicates "GFBR downlink", the parameter contents field contains one octet indicating the unit of the guaranteed flow bit rate for downlink followed by two octets containing the value of the guaranteed flow bit rate for downlink.

Unit of the guaranteed flow bit rate for downlink (octet 1)

The coding is identical to that of the unit of the guaranteed flow bit rate for uplink.

Value of the guaranteed flow bit rate for downlink (octets 2 and 3)

Octets 2 and 3 represent the binary coded value of the guaranteed flow bit rate for downlink in units defined by the unit of the guaranteed flow bit rate for downlink.

When the UE indicates subscribed GFBR for downlink, the "GFBR downlink" parameter is not included in the "Parameters list".

When the parameter identifier indicates "MFBR uplink", the parameter contents field contains the one octet indicating the unit of the maximum flow bit rate for uplink followed by two octets containing the value of maximum flow bit rate for uplink.

Unit of the maximum flow bit rate for uplink (octet 1)

The coding is identical to that of the unit of the guaranteed flow bit rate for uplink.

Value of the maximum flow bit rate for uplink (octets 2 and 3)

Octets 2 and 3 represent the binary coded value of the maximum flow bit rate for uplink in units defined by the unit of the maximum flow bit rate for uplink.

When the UE indicates subscribed MFBR for uplink, the "MFBR uplink" parameter is not included in the "Parameters list".

When the parameter identifier indicates "MFBR downlink", the parameter contents field contains one octet indicating the unit of the maximum flow bit rate for downlink followed by two octets containing the value of the maximum flow bit rate for downlink.

Unit of the maximum flow bit rate for downlink (octet 1)

The coding is identical to that of the unit of the guaranteed flow bit rate for uplink.

Value of the maximum flow bit rate for downlink (octets 2 and 3)

Octets 2 and 3 represent the binary coded value of the maximum flow bit rate for downlink in units defined by the unit of the maximum flow bit rate for downlink.

When the UE indicates subscribed MFBR for downlink, the "MFBR downlink" parameter is not included in the "Parameters list".

In this version of the protocol, for messages specified in the present document, the sending entity shall not request 0 kbps for both the maximum flow bit rate for downlink and the maximum flow bit rate for uplink at the same time. Any entity receiving a request for 0 kbps in both the maximum flow bit rate for downlink and the maximum flow bit rate for uplink shall consider that as a syntactical error (see clause 7).

When the parameter identifier indicates "averaging window", the parameter contents field contains the binary representation of the averaging window for both uplink and downlink in milliseconds and the parameter contents field is two octets in length.

When the parameter identifier indicates EPS bearer identity, the length of EPS bearer identity is one octet, bits 5 to 8 of the parameter contents contain the EPS bearer identity as specified in subclause 9.3.2 of 3GPP TS 24.301 [15] (see NOTE) and bits 1 to 4 of the parameter contents are spare and shall be coded as zero. The UE shall not include the EPS bearer identity parameter in any mobile originated 5GSM messages.

NOTE 1: The total number of EPS bearer identities included in all QoS flow descriptions of a UE cannot exceed fifteen.

NOTE 2: In this release of the specifications if received it shall be interpreted as value is incremented in multiples of 1 Kbps. In earlier releases of specifications, the interpretation of this value is up to implementation.

9.11.4.13 QoS rules

The purpose of the QoS rules information element is to indicate a set of QoS rules to be used by the UE, where each QoS rule is a set of parameters as described in subclause 6.2.5.1.1.2:

a) for classification and marking of uplink user traffic; and

b) for identification of a QoS flow which the network is to use for a particular downlink user traffic.

NOTE: The UE needs to be aware of a QoS flow which the network is to use for a particular downlink user traffic e.g. to determine whether a resource is available for downlink media of a media stream of an SDP media description provided by the UE in an IMS session.

The QoS rules may contain a set of packet filters consisting of zero or more packet filters for UL direction, zero or more packet filters for DL direction, zero or more packet filters for both UL and DL directions or any combinations of these. The set of packet filters determine the traffic mapping to QoS flows.

The QoS rules information element is a type 6 information element with a minimum length of 7 octets. The maximum length for the information element is 65538 octets.

The QoS rules information element is coded as shown in figure 9.11.4.13.1, figure 9.11.4.13.2, figure 9.11.4.13.3, figure 9.11.4.13.4 and table 9.11.4.13.1.

8

7

6

5

4

3

2

1

QoS rules IEI

octet 1

Length of QoS rules IE

octet 2

octet 3

QoS rule 1

octet 4

octet u

QoS rule 2

octet u+1

octet v

octet v+1

octet w

QoS rule n

octet w+1

octet x

Figure 9.11.4.13.1: QoS rules information element

8

7

6

5

4

3

2

1

QoS rule identifier

octet 4

Length of QoS rule

octet 5

octet 6

Rule operation code

DQR bit

Number of packet filters

octet 7

Packet filter list

octet 8*

octet m*

QoS rule precedence

octet m+1*

0

Spare

Segregation

QoS flow identifier (QFI)

octet m+2*

Figure 9.11.4.13.2: QoS rule (u=m+2)

8

7

6

5

4

3

2

1

0

0

0

0

Packet filter identifier 1

octet 8

Spare

0

0

0

0

Packet filter identifier 2

octet 9

Spare

0

0

0

0

Packet filter identifier N

octet N+7

Spare

Figure 9.11.4.13.3: Packet filter list when the rule operation is "modify existing QoS rule and delete packet filters" (m=N+7)

8

7

6

5

4

3

2

1

0

0

Packet filter direction 1

Packet filter identifier 1

octet 8

Spare

Length of packet filter contents 1

octet 9

Packet filter contents 1

octet 10

octet m

0

0

Packet filter direction 2

Packet filter identifier 2

octet k+1

Spare

Length of packet filter contents 2

octet k+2

Packet filter contents 2

octet k+3

octet n

octet n+1

octet y

0

0

Packet filter direction N

Packet filter identifier N

octet y+1

Spare

Length of packet filter contents N

octet y+2

Packet filter contents N

octet y+3

octet m

Figure 9.11.4.13.4: Packet filter list when the rule operation is "create new QoS rule", or "modify existing QoS rule and add packet filters" or "modify existing QoS rule and replace all packet filters"

Table 9.11.4.13.1: QoS rules information element

QoS rule identifier (octet 4)

The QoS rule identifier field is used to identify the QoS rule.

Bits

8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 no QoS rule identifier assigned

0 0 0 0 0 0 0 1 QRI 1

to

1 1 1 1 1 1 1 1 QRI 255

The network shall not set the QRI value to 0.

QoS rule precedence (octet m+1)

The QoS rule precedence field is used to specify the precedence of the QoS rule among all QoS rules (both the signalled QoS rules as described in subclause 6.2.5.1.1.2 and the derived QoS rules as described in subclause 6.2.5.1.1.3) associated with the PDU session of the QoS flow. This field includes the binary coded value of the QoS rule precedence in the range from 0 to 255 (decimal). The higher the value of the QoS rule precedence field, the lower the precedence of that QoS rule is. For the "delete existing QoS rule" operation, the QoS rule precedence value field shall not be included. For the "create new QoS rule" operation, the QoS rule precedence value field shall be included.

The value 80 (decimal) is reserved.

Segregation bit (bit 7 of octet m+2) (see NOTE 1)

In the UE to network direction the segregation bit indicates whether the UE is requesting the network to bind service data flows described by the QoS rule to a dedicated QoS Flow and it is encoded as follows. In the network to UE direction this bit is spare.

Bit

7

0 Segregation not requested

1 Segregation requested

QoS flow identifier (QFI) (bits 6 to 1 of octet m+2) (see NOTE 1)

The QoS flow identifier (QFI) field contains the QoS flow identifier.

Bits

6 5 4 3 2 1

0 0 0 0 0 0 no QoS flow identifier assigned

0 0 0 0 0 1 QFI 1

to

1 1 1 1 1 1 QFI 63

The network shall not set the QFI value to 0.

For the "delete existing QoS rule" operation, the QoS flow identifier value field shall not be included. For the "create new QoS rule" operation, the QoS flow identifier value field shall be included.

DQR bit (bit 5 of octet 7)

The DQR bit indicates whether the QoS rule is the default QoS rule and it is encoded as follows:

Bit

5

0 the QoS rule is not the default QoS rule.

1 the QoS rule is the default QoS rule.

Rule operation code (bits 8 to 6 of octet 7)
Bits
8 7 6

0 0 0 Reserved
0 0 1 Create new QoS rule

0 1 0 Delete existing QoS rule

0 1 1 Modify existing QoS rule and add packet filters

1 0 0 Modify existing QoS rule and replace all packet filters

1 0 1 Modify existing QoS rule and delete packet filters

1 1 0 Modify existing QoS rule without modifying packet filters

1 1 1 Reserved

Number of packet filters (bits 4 to 1 of octet 7)

The number of packet filters contains the binary coding for the number of packet filters in the packet filter list. The number of packet filters field is encoded in bits 4 through 1 of octet 7 where bit 4 is the most significant and bit 1 is the least significant bit. For the "delete existing QoS rule" operation and for the "modify existing QoS rule without modifying packet filters" operation, the number of packet filters shall be coded as 0. For the "create new QoS rule" operation and the "modify existing QoS rule and replace all packet filters" operation, the number of packet filters shall be greater than or equal to 0 and less than or equal to 15. For all other operations, the number of packet filters shall be greater than 0 and less than or equal to 15.

Packet filter list (octets 8 to m)

The packet filter list contains a variable number of packet filters.

For the "delete existing QoS rule" operation, the length of QoS rule field is set to one.

For the "delete existing QoS rule" operation and the "modify existing QoS rule without modifying packet filters" operation, the packet filter list shall be empty.

For the "modify existing QoS rule and delete packet filters" operation, the packet filter list shall contain a variable number of packet filter identifiers. This number shall be derived from the coding of the number of packet filters field in octet 7.

For the "create new QoS rule" operation and for the "modify existing QoS rule and replace all packet filters" operation, the packet filter list shall contain 0 or a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 7.

For the "modify existing QoS rule and add packet filters" operation, the packet filter list shall contain a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 7.

Each packet filter is of variable length and consists of

a packet filter direction (2 bits);
– a packet filter identifier (4 bits);
– the length of the packet filter contents (1 octet); and
– the packet filter contents itself (variable amount of octets).

The packet filter direction field is used to indicate for what traffic direction the filter applies.

Bits

6 5

0 0 reserved

0 1 downlink only (see NOTE 2)

1 0 uplink only

1 1 bidirectional

The packet filter identifier field is used to identify each packet filter in a QoS rule. The least significant 4 bits are used. When the UE requests to "create new QoS rule", "modify existing QoS rule and replace all packet filters" or "modify existing QoS rule and add packet filters", the packet filter identifier values shall be set to 0.

The length of the packet filter contents field contains the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order is the most significant bit.

The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component shall be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier shall be transmitted first.

In each packet filter, there shall not be more than one occurrence of each packet filter component type. Among the "IPv4 remote address type" and "IPv6 remote address/prefix length type" packet filter components, only one shall be present in one packet filter. Among the "IPv4 local address type" and "IPv6 local address/prefix length type" packet filter components, only one shall be present in one packet filter. Among the "single local port type" and "local port range type" packet filter components, only one shall be present in one packet filter. Among the "single remote port type" and "remote port range type" packet filter components, only one shall be present in one packet filter. Among the "destination MAC address type" and "destination MAC address range type" packet filter components, only one shall be present in one packet filter. Among the "source MAC address type" and "source MAC address range type" packet filter components, only one shall be present in one packet filter. If the "match-all type" packet filter component is present in the packet filter, no other packet filter component shall be present in the packet filter and the length of the packet filter contents field shall be set to one. If the "Ethertype type" packet filter component is present in the packet filter and the "Ethertype type" packet filter component value is neither "0800H" (for IPv4) nor "86DDH" (for IPv6), no IP packet filter component shall be present in the packet filter.

The term "IP packet filter component" refers to "IPv4 remote address type", "IPv4 local address type", "IPv6 remote address/prefix length type", "IPv6 local address/prefix length type", "Protocol identifier/Next header type", "Single local port type", "Local port range type", "Single remote port type", "Remote port range type", "Security parameter index type", "Type of service/Traffic class type" and "Flow label type".

The term local refers to the UE and the term remote refers to an external network entity.

Packet filter component type identifier
Bits
8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 1 Match-all type (see NOTE 2)
0 0 0 1 0 0 0 0 IPv4 remote address type
0 0 0 1 0 0 0 1 IPv4 local address type
0 0 1 0 0 0 0 1 IPv6 remote address/prefix length type
0 0 1 0 0 0 1 1 IPv6 local address/prefix length type
0 0 1 1 0 0 0 0 Protocol identifier/Next header type
0 1 0 0 0 0 0 0 Single local port type
0 1 0 0 0 0 0 1 Local port range 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 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 0 Source 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 Destination MAC address range type
1 0 0 0 1 0 0 1 Source MAC address range type

All other values are reserved.

The description and valid combinations of packet filter component type identifiers in a packet filter are defined in 3GPP TS 23.501 [8].

For "match-all type", the packet filter component shall not include the packet filter component value field.

For "IPv4 remote address type", the packet filter component value field shall be encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address mask field. The IPv4 address field shall be transmitted first.

For "IPv4 local address type", the packet filter component value field shall be encoded as defined for "IPv4 remote address type".

For "IPv6 remote address/prefix length type", the packet filter component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and one octet prefix length field. The IPv6 address field shall be transmitted first.

For "IPv6 local address/prefix length type", the packet filter component value field shall be encoded as defined for "IPv6 remote address /prefix length".

For "protocol identifier/Next header type", the packet filter component value field shall be encoded as one octet which specifies the IPv4 protocol identifier or Ipv6 next header.

For "single local port type" and "single remote port type", the packet filter component value field shall be encoded as two octets which specify a port number.

For "local port range type" and "remote port range type", the packet filter component value field shall be encoded as a sequence of a two octet port range low limit field and a two octet port range high limit field. The port range low limit field shall be transmitted first.

For "security parameter index", the packet filter component value field shall be encoded as four octets which specify the IPSec security parameter index.

For "type of service/traffic class type", the packet filter component value field shall be encoded as a sequence of a one octet type-of-service/traffic class field and a one octet type-of-service/traffic class mask field. The type-of-service/traffic class field shall be transmitted first.

For "flow label type", the packet filter component value field shall be encoded as three octets which specify the IPv6 flow label. The bits 8 through 5 of the first octet shall be spare whereas the remaining 20 bits shall contain the IPv6 flow label.

For "destination MAC address type" and "source MAC address type", the packet filter component value field shall be encoded as 6 octets which specify a MAC address. When the packet filter direction field indicates "bidirectional", the destination MAC address is the remote MAC address and the source MAC address is the local MAC address.

For "802.1Q C-TAG VID type", the packet filter component value field shall be encoded as two octets which specify the VID of the customer-VLAN tag (C-TAG). The bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall contain the VID. If there are more than one C-TAG in the Ethernet frame header, the outermost C-TAG is evaluated.

For "802.1Q S-TAG VID type", the packet filter component value field shall be encoded as two octets which specify the VID of the service-VLAN tag (S-TAG). The bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall contain the VID. If there are more than one S-TAG in the Ethernet frame header, the outermost S-TAG is evaluated.

For "802.1Q C-TAG PCP/DEI type", the packet filter component value field shall be encoded as one octet which specifies the 802.1Q C-TAG PCP and DEI. The bits 8 through 5 of the octet shall be spare, the bits 4 through 2 contain the PCP and bit 1 contains the DEI. If there are more than one C-TAG in the Ethernet frame header, the outermost C-TAG is evaluated.

For "802.1Q S-TAG PCP/DEI type", the packet filter component value field shall be encoded as one octet which specifies the 802.1Q S-TAG PCP. The bits 8 through 5 of the octet shall be spare, the bits 4 through 2 contain the PCP and bit 1 contains the DEI. If there are more than one S-TAG in the Ethernet frame header, the outermost S-TAG is evaluated.

For "ethertype type", the packet filter component value field shall be encoded as two octets which specify an ethertype.

For "destination MAC address range type", the packet filter component value field shall be encoded as a sequence of a 6 octet destination MAC address range low limit field and a 6 octet destination MAC address range high limit field. The destination MAC address range low limit field shall be transmitted first. When the packet filter direction field indicates "bidirectional", the destination MAC address range is the remote MAC address range.

For "source MAC address range type", the packet filter component value field shall be encoded as a sequence of a 6 octet source MAC address range low limit field and a 6 octet source MAC address range high limit field. The source MAC address range low limit field shall be transmitted first. When the packet filter direction field indicates "bidirectional", the source MAC address is the local MAC address range.

NOTE 1: Octet m+2 shall not be included without octet m+1.

NOTE 2: The "Match-all type" packet filter component type identifier shall not be used with packet filter direction "downlink only".

9.11.4.14 Session-AMBR

The purpose of the Session-AMBR information element is to indicate the initial subscribed PDU session aggregate maximum bit rate when the UE establishes a PDU session or to indicate the new subscribed PDU session aggregate maximum bit rate if it is changed by the network.

The Session-AMBR information element is coded as shown in figure 9.11.4.14.1 and table 9.11.4.14.1.

The Session-AMBR is a type 4 information element with a length of 8 octets.

8

7

6

5

4

3

2

1

Session-AMBR IEI

octet 1

Length of Session-AMBR contents

octet 2

Unit for Session-AMBR for downlink

octet 3

Session-AMBR for downlink

octet 4-5

Unit for Session-AMBR for uplink

octet 6

Session-AMBR for uplink

octet 7-8

Figure 9.11.4.14.1: Session-AMBR information element

Table 9.11.4.14.1: Session-AMBR information element

Unit for Session-AMBR for downlink (octet 3)

0 0 0 0 0 0 0 0 value is not used (see NOTE)

0 0 0 0 0 0 0 1 value is incremented in multiples of 1 Kbps

0 0 0 0 0 0 1 0 value is incremented in multiples of 4 Kbps

0 0 0 0 0 0 1 1 value is incremented in multiples of 16 Kbps

0 0 0 0 0 1 0 0 value is incremented in multiples of 64 Kbps

0 0 0 0 0 1 0 1 value is incremented in multiples of 256 kbps

0 0 0 0 0 1 1 0 value is incremented in multiples of 1 Mbps

0 0 0 0 0 1 1 1 value is incremented in multiples of 4 Mbps

0 0 0 0 1 0 0 0 value is incremented in multiples of 16 Mbps

0 0 0 0 1 0 0 1 value is incremented in multiples of 64 Mbps

0 0 0 0 1 0 1 0 value is incremented in multiples of 256 Mbps

0 0 0 0 1 0 1 1 value is incremented in multiples of 1 Gbps

0 0 0 0 1 1 0 0 value is incremented in multiples of 4 Gbps

0 0 0 0 1 1 0 1 value is incremented in multiples of 16 Gbps

0 0 0 0 1 1 1 0 value is incremented in multiples of 64 Gbps

0 0 0 0 1 1 1 1 value is incremented in multiples of 256 Gbps

0 0 0 1 0 0 0 0 value is incremented in multiples of 1 Tbps

0 0 0 1 0 0 0 1 value is incremented in multiples of 4 Tbps

0 0 0 1 0 0 1 0 value is incremented in multiples of 16 Tbps

0 0 0 1 0 0 1 1 value is incremented in multiples of 64 Tbps

0 0 0 1 0 1 0 0 value is incremented in multiples of 256 Tbps

0 0 0 1 0 1 0 1 value is incremented in multiples of 1 Pbps

0 0 0 1 0 1 1 0 value is incremented in multiples of 4 Pbps

0 0 0 1 0 1 1 1 value is incremented in multiples of 16 Pbps

0 0 0 1 1 0 0 0 value is incremented in multiples of 64 Pbps

0 0 0 1 1 0 0 1 value is incremented in multiples of 256 Pbps

Other values shall be interpreted as multiples of 256 Pbps in this version of the protocol.

Session-AMBR for downlink (octets 4 and 5)

Octets 4 and 5 represent the binary coded value of PDU session aggregated maximum bit rate for downlink in units defined by octet 3.

Unit for Session-AMBR for uplink (octet 6)

The coding is identical to the unit coding defined for Session-AMBR for downlink (octet 3)

Session-AMBR for uplink (octets 7 and 8)

Octets 7 and 8 represent the binary coded value of PDU session aggregated maximum bit rate for uplink in units defined by octet 6.

NOTE: In this release of the specifications if received it shall be interpreted as value is incremented in multiples of 1 Kbps. In earlier releases of specifications, the interpretation of this value is up to implementation.

9.11.4.15 SM PDU DN request container

The purpose of the SM PDU DN request container information element is to carry a DN-specific identity of the UE in the network access identifier (NAI) format.

The SM PDU DN request container information element is coded as shown in figure 9.11.4.15.1 and table 9.11.4.15.1.

The SM PDU DN request container is a type 4 information element with minimal length of 3 octets and maximum length of 255 octets.

8

7

6

5

4

3

2

1

SM PDU DN request container information IEI

octet 1

SM PDU DN request container information length

octet 2

DN-specific identity

octets 3*-n*

Figure 9.11.4.15.1: SM PDU DN request container information element

Table 9.11.4.15.1: SM PDU DN request container information element

DN-specific identity (octet 3 to octet n)

A DN-specific identity of the UE in the network access identifier (NAI) format according to IETF RFC 7542 [37], encoded as UTF-8 string.

9.11.4.16 SSC mode

The purpose of the SSC mode information element is to indicate SSC mode.

The SSC mode information element is coded as shown in figure 9.11.4.16.1 and table 9.11.4.16.1.

The SSC mode is a type 1 information element.

8

7

6

5

4

3

2

1

SSC mode IEI

0

Spare

SSC mode value

octet 1

Figure 9.11.4.16.1: SSC mode information element

Table 9.11.4.16.1: SSC mode information element

SSC mode value (octet 1, bit 1 to bit 4)

Bits

3

2

1

0

0

1

SSC mode 1

0

1

0

SSC mode 2

0

1

1

SSC mode 3

1

0

0

unused; shall be interpreted as "SSC mode 1", if received by the network

1

0

1

unused; shall be interpreted as "SSC mode 2", if received by the network

1

1

0

unused; shall be interpreted as "SSC mode 3", if received by the network

All other values are reserved.

9.11.4.17 Re-attempt indicator

The purpose of the Re-attempt indicator information element is to indicate a condition under which the UE is allowed in the current PLMN or its equivalent PLMN(s) for the same DNN, to re-attempt a session management procedure (see 3GPP TS 24.301 [15]) corresponding to the 5GS session management procedure which was rejected by the network.

The Re-attempt indicator information element is coded as shown in figure 9.11.4.17.1 and table 9.11.4.17.1.

The Re-attempt indicator is a type 4 information element with a length of 3 octets.

8

7

6

5

4

3

2

1

Re-attempt indicator IEI

octet 1

Length of Re-attempt indicator contents

octet 2

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

EPLMNC

RATC

octet 3

Figure 9.11.4.17.1: Re-attempt indicator

Table 9.11.4.17.1: Re-attempt indicator

RATC (octet 3, bit 1)

Bit

1

0

UE is allowed to re-attempt the procedure in S1 mode

1

UE is not allowed to re-attempt the procedure in S1 mode

EPLMNC (octet 3, bit 2)

Bit

2

0

UE is allowed to re-attempt the procedure in an equivalent PLMN

1

UE is not allowed to re-attempt the procedure in an equivalent PLMN

Bits 3 to 8 of octet 3 are spare and shall be encoded as zero.

9.11.4.18 5GSM network feature support

The purpose of the 5GSM network feature support information element is to indicate whether certain session management related features are supported by the network.

The 5GSM network feature support information element is coded as shown in figure 9.11.4.18.1 and table 9.11.4.18.1.

The 5GSM network feature support is a type 4 information element with a minimum length of 3 octets and a maximum length of 15 octets.

8

7

6

5

4

3

2

1

5GSM network feature support IEI

octet 1

Length of 5GSM network feature support contents

octet 2

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

EPT-S1

octet 3

0

0

0

0

0

0

0

0

octet 4* -15*

Spare

Figure 9.11.4.18.1: 5GSM network feature support information element

Table 9.11.4.18.1: 5GSM network feature support information element

5GSM network feature support contents

Ethernet PDN type in S1 mode (IEPT-S1) (octet 3, bit 1)

This bit indicates network’s capability for Ethernet PDN type in S1 mode.

0

Ethernet PDN type in S1 mode not supported

1

Ethernet PDN type in S1 mode supported

All other bits in octet 3 to 15 are spare and shall be coded as zero, if the respective octet is included in the information element.

9.11.4.19 Void

9.11.4.20 Serving PLMN rate control

See subclause 9.9.4.28 in 3GPP TS 24.301 [15].

9.11.4.21 5GSM congestion re-attempt indicator

The purpose of the 5GSM congestion re-attempt indicator information element is to indicate whether the back-off timer is applied in the registered PLMN or all PLMNs, and additionally to indicate whether the back-off timer is applied in the current access type or both 3GPP access type and non-3GPP access type.

The 5GSM congestion re-attempt indicator information element is coded as shown in figure 9.11.4.21.1 and table 9.11.4.21.1.

The 5GSM congestion re-attempt indicator is a type 4 information element with a length of 3 octets.

8

7

6

5

4

3

2

1

5GSM congestion re-attempt indicator IEI

octet 1

Length of 5GSM congestion re-attempt indicator contents

octet 2

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

CATBO

ABO

octet 3

Figure 9.11.4.21.1: 5GSM congestion re-attempt indicator

Table 9.11.4.21.1: 5GSM congestion re-attempt indicator

ABO (All PLMNs Back-off timer) (octet 3, bit 1)

Bit

1

0

The back-off timer is applied in the registered PLMN.

1

The back-off timer is applied in all PLMNs.

CATBO (Current Access Type Back-off Timer) (octet 3, bit 2)

Bit

2

0

The back-off timer is applied in both 3GPP access type and non-3GPP access type

1

The back-off timer is applied in the current access type

Bits 3 to 8 of octet 3 are spare and shall be encoded as zero.

9.11.4.22 ATSSS container

The purpose of the ATSSS container information element is to transfer parameters associated with ATSSS.

The ATSSS container information element is coded as shown in figure 9.11.4.22.1 and table 9.11.4.22.1.

The ATSSS container is a type 6 information element with a minimum length of 3 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

ATSSS container IEI

octet 1

Length of ATSSS container contents

octet 2

octet 3

ATSSS container contents

octet 4*

octet x*

Figure 9.11.4.22.1: ATSSS container information element

Table 9.11.4.22.1: ATSSS container information element

ATSSS container contents are defined in 3GPP TS 24.193 [13B].

9.11.4.23 Control plane only indication

The purpose of the control plane only indication information element is to indicate that a PDU session is only for control plane CIoT 5GS optimization.

The control plane only indication information element is coded as shown in figure 9.11.4.23.1.

The control plane only indication is a type 1 information element.

8

7

6

5

4

3

2

1

Control plane only indication IEI

0

Spare

0

Spare

0

Spare

CPOI value

octet 1

Figure 9.11.4.23.1: Control plane only indication information element

Table 9.11.4.23.1: Control plane only indication information element

Control plane only indication value (CPOI) (octet 1)

Bit

1

0

reserved

1

PDU session can be used for control plane CIoT 5GS optimization only

The value 0 is reserved. If received, it shall be interpreted as if the control plane only indication IE was not included in the message.

Bits 4 to 2 of octet 1 are spare and shall be all encoded as zero.

9.11.4.24 IP header compression configuration

The purpose of the IP header compression configuration information element is to negotiate ROHC channel setup parameters specified in IETF RFC 5795 [39B] and, optionally, provide additional header compression context setup parameters.

The IP header compression configuration information element is coded as shown in figure 9.11.4.24.1 and table 9.11.4.24.1.

The IP header compression configuration is a type 4 information element with a minimum length of 5 octets and a maximum length of 257 octets.

The optional Additional IP header compression parameters container field conveys the additional header compression context setup parameters as specified in 3GPP TS 23.501 [8] in a generic container. This field corresponds to the profile-specific information in the header of the ROHC IR packet type in IETF RFC 5795 [39B].

8

7

6

5

4

3

2

1

IP header compression configuration IEI

octet 1

Length of IP header compression configuration contents

octet 2

Spare

P0x0104

P0x0103

P0x0102

P0x0006

P0x0004

P0x0003

P0x0002

octet 3

MAX_CID

octet 4

octet 5

Additional IP header compression context setup parameters type

octet 6*

Additional IP header compression context setup parameters container

octet 7*

octet n*

Figure 9.11.4.24.1: IP header compression configuration information element

Table 9.11.4.24.1: IP header compression configuration information element

ROHC Profiles (octet 3)

The ROHC Profiles shall indicate which of the ROHC profiles is supported. When a particular bit is set to 1, this indicates that the corresponding profile is supported. The No Compression profile 0x0000 (see IETF RFC 5795 [39B]) shall always be supported. When all the bits are set to 0, this indicates that only the No Compression profile 0x0000 is supported.

Profile 0x0002 support indicator (see IETF RFC 3095 [33A] and IETF RFC 4815 [38A]) (octet 3 bit 1)

0 RoHC profile 0x0002 (UDP/IP) is not supported

1 RoHC profile 0x0002 (UDP/IP) is supported

Profile 0x0003 support indicator (see IETF RFC 3095 [33A] and IETF RFC 4815 [38A]) (octet 3 bit 2)

0 RoHC profile 0x0003 (ESP/IP) is not supported

1 RoHC profile 0x0003 (ESP/IP) is supported

Profile 0x0004 support indicator (see IETF RFC 3843 [34A] and IETF RFC 4815 [38A]) (octet 3 bit 3)

0 RoHC profile 0x0004 (IP) is not supported

1 RoHC profile 0x0004 (IP) is supported

Profile 0x0006 support indicator (see IETF RFC 6846 [40B]) (octet 3 bit 4)

0 RoHC profile 0x0006 (TCP/IP) is not supported

1 RoHC profile 0x0006 (TCP/IP) is supported

Profile 0x0102 support indicator (see IETF RFC 5225 [39A]) (octet 3 bit 5)

0 RoHC profile 0x0102 (UDP/IP) is not supported

1 RoHC profile 0x0102 (UDP/IP) is supported

Profile 0x0103 support indicator (see IETF RFC 5225 [39A]) (octet 3 bit 6)

0 RoHC profile 0x0103 (ESP/IP) is not supported

1 RoHC profile 0x0103 (ESP/IP) is supported

Profile 0x0104 support indicator (see IETF RFC 5225 [39A]) (octet 3 bit 7)

0 RoHC profile 0x0104 (IP) is not supported

1 RoHC profile 0x0104 (IP) is supported

Bits 8 is spare and shall be set to 0.

MAX_CID (octet 4 and octet 5)

This is the MAX_CID value as specified in 3GPP TS 36.323 [25]. It is encoded in binary coding with a value in the range from 1 to 16383.

Additional IP header compression context parameters type (octet 6).

The Additional IP header compression context parameters type octet indicates the profile associated with the profile-specific information in the Additional IP header compression context parameters container.

Bits

8 7 6 5 4 3 2 1 Type

0 0 0 0 0 0 0 0 0x0000 (No Compression)

0 0 0 0 0 0 0 1 0x0002 (UDP/IP)

0 0 0 0 0 0 1 0 0x0003 (ESP/IP)

0 0 0 0 0 0 1 1 0x0004 (IP)

0 0 0 0 0 1 0 0 0x0006 (TCP/IP)

0 0 0 0 0 1 0 1 0x0102 (UDP/IP)

0 0 0 0 0 1 1 0 0x0103 (ESP/IP)

0 0 0 0 0 1 1 1 0x0104 (IP)

0 0 0 0 1 0 0 0 Other

0 0 0 0 1 0 0 1

to

1 1 1 1 1 1 1 1 Spare

Additional IP header compression context parameters container (octets 7 to n).

Additional IP header compression context parameters container carries the profile-specific information (see IETF RFC 5795 [39B]). The maximum size is 251 octets.

NOTE: If the Additional IP header compression context setup parameters container is included, then the Additional IP header compression context parameters type shall be included in the octet 6.

9.11.4.25 DS-TT Ethernet port MAC address

The purpose of the DS-TT Ethernet port MAC address information element is to signal the MAC address of the DS-TT Ethernet port used for a PDU session of "Ethernet" PDU session type.

The DS-TT Ethernet port MAC address information element is coded as shown in figure 9.11.4.25.1 and table 9.11.4.25.1.

The DS-TT Ethernet port MAC address is a type 4 information element with a length of 8 octets.

8

7

6

5

4

3

2

1

DS-TT Ethernet port MAC address IEI

octet 1

Length of DS-TT Ethernet port MAC address contents

octet 2

octet 3

DS-TT Ethernet port MAC address contents

octet 8

Figure 9.11.4.25.1: DS-TT Ethernet port MAC address information element

Table 9.11.4.25.1: DS-TT Ethernet port MAC address information element

DS-TT Ethernet port MAC address contents (octets 3 to 8)

The DS-TT Ethernet port MAC address contents consist of the binary representation of the MAC address of the DS-TT Ethernet port used for the PDU session, starting with the LSB bit of the first octet of the MAC address included in bit 1 of octet 3.

9.11.4.26 UE-DS-TT residence time

The purpose of the UE-DS-TT residence time information element is to signal the time taken within the UE and the DS-TT to forward a packet i.e. between the ingress of the UE and the DS-TT port in the DL direction, or between the DS-TT port and the egress of the UE in the UL direction.

The UE- DS-TT residence time information element is coded as shown in figure 9.11.4.26.1 and table 9.11.4.26.1.

The UE-DS-TT residence time is a type 4 information element with a length of 10 octets.

8

7

6

5

4

3

2

1

UE-DS-TT residence time IEI

octet 1

Length of UE-DS-TT residence time contents

octet 2

octet 3

UE-DS-TT residence time contents

octet 10

Figure 9.11.4.26.1: UE-DS-TT residence time information element

Table 9.11.4.26.1: UE-DS-TT residence time information element

UE-DS-TT residence time contents (octets 3 to 10)

The UE-DS-TT residence time contents contain the UE-DS-TT residence time encoded as specified for the correctionField in IEEE Std 1588-2019 [43B], with the LSB bit of the first octet of the UE-DS-TT residence time included in bit 1 of octet 3. If the UE-DS-TT residence time.is too big to be represented, all bits of octets 3 to 10 shall be coded as "1" except the MSB bit of octet 10.

9.11.4.27 Port management information container

The purpose of the Port management information container information element is to transport a port management service message as specified in clause 8 of 3GPP TS 24.539 [19BA].

The Port management information container information element is coded as shown in figure 9.11.4.27.1 and table 9.11.4.27.1.

The Port management information container is a type 6 information element with a minimum length of 4 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

Port management information container IEI

octet 1

Length of Port management information container contents

octet 2

octet 3

Port management information container

octet 4

octet n

Figure 9.11.4.27.1: Port management information container information element

Table 9.11.4.27.1: Port management information container information element

Port management information container (octet 4 to n)

A port management service message as specified in clause 8 of 3GPP TS 24.539 [19BA].

9.11.4.28 Ethernet header compression configuration

The purpose of the Ethernet header compression configuration information element is to negotiate the use of EHC and the length of the CID field in the EHC packet (see 3GPP TS 38.323 [29]).

The Ethernet header compression configuration information element is coded as shown in figure 9.11.4.28.1 and table 9.11.4.28.1.

The Ethernet header compression configuration is a type 4 information element with the length of 3 octets.

8

7

6

5

4

3

2

1

Ethernet header compression configuration IEI

octet 1

Length of Ethernet header compression configuration contents

octet 2

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

CID Length

octet 3

Figure 9.11.4.28.1: Ethernet header compression configuration information element

Table 9.11.4.28.1: Ethernet header compression configuration information element

Length of CID field value (CID Length) (octet 3 bits 1 and 2)

Bit

2

1

0

0

Ethernet header compression not used

0

1

7 bits

1

0

15 bits

All other values shall be interpreted as "7 bits".

Bits 3 to 8 of octet 3 are spare and shall be coded as zero.

9.11.4.29 Remote UE context list

The purpose of the Remote UE context list information element is to provide identity and optionally IP address of a 5G ProSe remote UE connected to, or disconnected from, a UE acting as a 5G ProSe layer-3 UE-to-network relay.

The Remote UE context list information element is coded as shown in figure 9.11.4.29.1, figure 9.11.4.29.2, table 9.11.4.29.1 and table 9.11.4.29.2.

The Remote UE context list is a type 6 information element with a minimum length of 16 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

Remote UE context list IEI

octet 1

Length of remote UE context list contents

octet 2

octet 3

Number of remote UE contexts

octet 4

Remote UE context 1

octet 5

octet a

octet a+1*

octet b*

Remote UE context k

octet b+1*

octet c*

Figure 9.11.4.29.1: Remote UE context list

Table 9.11.4.29.1: Remote UE context list

Remote UE context (octet 5 etc)

The contents of remote UE context are applicable for one individual UE and are coded as shown in figure 9.11.4.29.2 and table 9.11.4.29.2.

8

7

6

5

4

3

2

1

Length of remote UE context

octet 5

0

Spare

0

Spare

0

Spare

0

Spare

Remote UE ID format

Remote UE ID type

octet 6

Length of remote UE ID

octet 7

Remote UE ID

octet 8

octet q

Octet j*

Spare

UPRI4I

TPRI4I

Protocol used by remote UE

octet j+1*

Address information

octet j+2*

octet j+k*

HPLMN ID

octet (j+k+1)*

octet (j+k+3)*

Figure 9.11.4.29.2: Remote UE context

Table 9.11.4.29.2: Remote UE context list information element

Remote UE ID type (bits 1 to 3 of octet 6)

Bits

3

2

1

0

0

1

UP-PRUK ID

0

1

0

CP-PRUK ID

All other values are reserved.

Remote UE ID format (bit 4 of octet 6) (NOTE)

Bit

4

0

Network access identifier (NAI)

1

64-bit string

Bits 5 to 8 of octet 6 are spare and shall be coded as zero.

Remote UE ID (octet 8 to octet j)

The UP-PRUK ID or the CP-PRUK ID of the 5G ProSe Remote UE.

Protocol used by remote UE (octet j+1, bits 1 to 3)

Bits

3

2

1

0

0

0

No IP info

0

0

1

IPv4

0

1

0

IPv6

1

0

0

Unstructured

1

0

1

Ethernet

All other values are reserved.

TCP port range for IPv4 indicator (TPRI4I) (octet j+1, bits 4)

Bit

4

0

TCP port range for IPv4 absent

1

TCP port range for IPv4 present

UDP port range for IPv4 indicator (UPRI4I) (octet j+1, bits 5)

Bit

5

0

UDP port range for IPv4 absent

1

UDP port range for IPv4 present

Bits 4 to 8 of octet j+1 are spare and shall be coded as zero.

If the Protocol used by remote UE indicates IPv4 and:

– TPRI4I bit indicates "TCP port range for IPv4 absent" and UPRI4I bit indicates "UDP port range for IPv4 absent", the Address information in octet j+2 to octet j+5 contains the IPv4 address.

– TPRI4I bit indicates "TCP port range for IPv4 present" and UPRI4I bit indicates "UDP port range for IPv4 absent", the Address information in octet j+2 to octet j+9 contains the IPv4 address followed by the TCP port range field.

– TPRI4I bit indicates "TCP port range for IPv4 absent" and UPRI4I bit indicates "UDP port range for IPv4 present", the Address information in octet j+2 to octet j+9 contains the IPv4 address followed by the UDP port range field.

– TPRI4I bit indicates "TCP port range for IPv4 present" and UPRI4I bit indicates "UDP port range for IPv4 present", the Address information in octet j+2 to octet j+13 contains the IPv4 address followed by the UDP port range field followed by the TCP port range field.

See NOTE.

The UDP port range field consists of the lowest UDP port number field followed by the highest UDP port number field, of the UDP port range assigned to the remote UE in the NAT function of 5G ProSe layer-3 UE-to-network relay.

The TCP port range field consists of the lowest TCP port number field followed by highest TCP port number field, of the TCP port range assigned to the remote UE in the NAT function of 5G ProSe layer-3 UE-to-network relay.

Each port number field is two octets long and bit 8 of first octet of the port number field represents the most significant bit of the port number and bit 1 of second octet of the port number field the least significant bit.

If the Protocol used by remote UE indicates IPv6, the Address information in octet j+2 to octet j+9 contains the /64 IPv6 prefix of a remote UE. Bit 8 of octet j+2 represents the most significant bit of the /64 IPv6 prefix and bit 1 of octet j+9 the least significant bit.

If the Protocol used by remote UE indicates Ethernet, the Address information in octet j+2 to octet j+7 contains the remote UE MAC address. Bit 8 of octet j+2 represents the most significant bit of the MAC address and bit 1 of octet j+7 the least significant bit.

If the Protocol used by remote UE indicates Unstructured, the Address information octets are not included.

If the Protocol used by remote UE indicates No IP info, the Address information octets are not included

If the Remote UE ID type field indicates "PRUK ID" and the Remote UE ID format field indicates "64-bit string", then the HPLMN ID field is present otherwise the HPLMN ID field is absent. The HPLMN ID field indicates HPLMN ID of the 5G ProSe remote UE and is coded as value part of the PLMN ID information element as specified in 3GPP TS 24.554 [19E] subclause 11.3.33 starting with the second octet.

NOTE: In the present release of the specification, providing information for IP protocols other than UDP or TCP is not specified

9.11.4.30 Requested MBS container

The purpose of the Requested MBS container information element is for UE to request to join or leave one or more multicast MBS sessions.

The Requested MBS container information element is coded as shown in figure 9.11.4.30.1, figure 9.11.4.30.2, figure 9.11.4.30.3, figure 9.11.4.30.4 and table 9.11.4.30.1.

The Requested MBS container is a type 6 information element with a minimum length of 8 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

Requested MBS container IEI

octet 1

Length of Requested MBS container contents

octet 2

octet 3

multicast MBS session information 1

octet 4

octet i

multicast MBS session information 2

octet i+1*

octet l*

octet l+1*

octet m*

multicast MBS session information p

octet m+1*

octet n*

Figure 9.11.4.30.1: Requested MBS container information element

8

7

6

5

4

3

2

1

0

0

0

0

MBS operation

Type of multicast MBS session ID

octet 4

spare

multicast MBS session ID

octet 5

octet i

Figure 9.11.4.30.2: multicast MBS session information

8

7

6

5

4

3

2

1

TMGI

octet 5

octet i

Figure 9.11.4.30.3: multicast MBS session ID for Type of multicast MBS session ID = "Temporary Mobile Group Identity (TMGI)"

8

7

6

5

4

3

2

1

Source IP address information

octet 5

octet v

Destination IP address information

Octet v+1

Octet i

Figure 9.11.4.30.4: multicast MBS session ID for Type of multicast MBS session ID = "Source specific IP multicast address for IPv4" or "Source specific IP multicast address for IPv6"

Table 9.11.4.30.1: Requested MBS container information element

Type of multicast MBS session ID (bits 1 to 2 of octet 4)

Bits

2

1

0

1

Temporary Mobile Group Identity (TMGI)

1

0

Source specific IP multicast address for IPv4

1

1

Source specific IP multicast address for IPv6

All other values are reserved.

MBS operation (bits 3 to 4 of octet 4)

Bits

4

3

0

1

Join multicast MBS session

1

0

Leave multicast MBS session

All other values are reserved.

Bits 5 to 8 of octet 4 are spare and shall be coded as zero.

If Type of multicast MBS session ID is set to "Temporary Mobile Group Identity (TMGI)", the multicast MBS session ID contains the TMGI (octet 5 to i) and is coded as described in subclause 10.5.6.13 in 3GPP TS 24.008 [12] starting from octet 2. The structure of the TMGI is defined in 3GPP TS 23.003 [4].

If Type of multicast MBS session ID is set to "Source specific IP multicast address for IPv4" or " Source specific IP multicast address for IPv6", the multicast MBS session ID contains the Source IP address information and the Destination IP address information.

Source IP address information (octet 5 to v)

This field contains the IP unicast address used as source address in IP packets for identifying the source of the multicast service.

If the type of multicast MBS session ID indicates "Source specific IP multicast address for IPv4", the Source IP address information in octet 5 to octet 8 contains an IPv4 address. If the type of multicast MBS session ID indicates "Source specific IP multicast address for IPv6", the Source IP address information in octet 5 to octet 20 contains an IPv6 address.

Destination IP address information (octet v+1 to i)

This field contains the IP multicast address used as destination address in related IP packets for identifying a multicast service associated with the source.

If the type of multicast MBS session ID indicates "Source specific IP multicast address for IPv4", the Destination IP address information in octet v+1 to octet v+4 contains an IPv4 address. If the type of multicast MBS session ID indicates "Source specific IP multicast address for IPv6", the Source IP address information in octet v+1 to octet v+16 contains an IPv6 address.

9.11.4.31 Received MBS container

The purpose of the Received MBS container information element is to indicate to the UE the information of the multicast MBS sessions that the network accepts or rejects the UE to join, the information of the multicast MBS sessions that the UE is removed from, or the information of the updated MBS service area.

The Received MBS container information element is coded as shown in figure 9.11.4.31.1, figure 9.11.4.31.2, figure 9.11.4.31.3, figure 9.11.4.31.4, figure 9.11.4.31.5, figure 9.11.4.31.6, figure 9.11.4.31.7, figure 9.11.4.31.8, figure 9.11.4.31.9, figure 9.11.4.31.10, figure 9.11.4.31.11 and table 9.11.4.31.1.

The Received MBS container is a type 6 information element with a minimum length of 9 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

Received MBS container IEI

octet 1

Length of Received MBS container contents

octet 2

octet 3

Received MBS information 1

octet 4

octet i

Received MBS information 2

octet i+1*

octet l*

octet l+1*

octet m*

Received MBS information p

octet m+1*

octet n*

Figure 9.11.4.31.1: Received MBS container information element

8

7

6

5

4

3

2

1

Rejection cause

MSAI

MD

octet 4

0

0

0

IPAT

MSCI

MTI

IPAE

octet 5

spare

TMGI

octet 6

octet j

Source IP address information

octet j+1*

octet v*

Destination IP address information

octet v+1*

octet k*

MBS service area

octet k+1*

octet s*

MBS timers

octet s+1*

octet i*

MBS security container

octet i+1*

octet e*

Figure 9.11.4.31.2: Received MBS information

8

7

6

5

4

3

2

1

MBS TAI list

octet k+1*

octet i*

Figure 9.11.4.31.3: MBS service area for MBS service area indication = "MBS service area included as MBS TAI list"

8

7

6

5

4

3

2

1

NR CGI list

octet k+1*

octet i*

Figure 9.11.4.31.4: MBS service area for MBS service area indication = "MBS service area included as NR CGI list"

8

7

6

5

4

3

2

1

MBS TAI list

octet k+1*

octet y*

NR CGI list

octet y+1*

octet i*

Figure 9.11.4.31.5: MBS service area for MBS service area indication = "MBS service area included as MBS TAI list and NR CGI list"

8

7

6

5

4

3

2

1

Length of NR CGI list contents

octet k+1*

NR CGI 1

octet k+2*

octet k+9*

NR CGI 2

octet k+10*

octet k+17*

octet k+18*

octet c*

NR CGI w

octet c+1*

octet s*

Figure 9.11.4.31.6: NR CGI list

8

7

6

5

4

3

2

1

NR Cell ID

octet k+1*

octet k+5*

MCC digit 2

MCC digit 1

octet k+6*

MNC digit 3

MCC digit 3

octet k+7*

MNC digit 2

MNC digit 1

octet k+8*

Figure 9.11.4.31.7: NR CGI

8

7

6

5

4

3

2

1

MBS start time

octet s+1*

octet s+6*

Figure 9.11.4.31.8: MBS timers for MBS timer indication = "MBS start time"

8

7

6

5

4

3

2

1

MBS back-off timer

octet s+1*

Figure 9.11.4.31.9: MBS timers for MBS timer indication = "MBS back-off timer"

8

7

6

5

4

3

2

1

Number of MBS security keys sets

octet i+1*

MBS security keys set 1

octet i+2*

octet t*

MBS security keys set 2

octet t+1*

octet g*

octet g+1*

octet v*

MBS security keys set q

octet v+1*

octet e*

Figure 9.11.4.31.10: MBS security container

8

7

6

5

4

3

2

1

0

spare

MTKI

octet i+2*

Key domain ID

octet i+3*

octet i+5*

MSK ID

octet i+6*

octet i+9*

MSK

octet i+10*

octet i+25*

MTK ID

octet i+26*

octet i+27*

Encrypted MTK

octet i+28*

octet i+43*

Figure 9.11.4.31.11: MBS security keys set

Table 9.11.4.31.1: Received MBS container information element

MBS decision (MD) (bits 1 to 3 of octet 4)

The MD indicates the network decision of the join requested by the UE, the network requests to remove the UE from the multicast MBS session or the network request to update the MBS service area or the security information of multicast MBS session.

Bits

3

2

1

0

0

1

MBS service area update

0

1

0

MBS join is accepted

0

1

1

MBS join is rejected

1

0

0

Remove UE from multicast MBS session

1

0

1

MBS security information update

All other values are unused in this version of the specification and interpreted as 000 if received.

If MD is set to "MBS join is rejected" or “Remove UE from multicast MBS session”, bits 6 to 8 of octet 4 shall contain the Rejection cause which indicates the reason of rejecting the MBS join request or the reason of removing the UE from multicast MBS session, respectively, otherwise bits 6 to 8 of octet 4 are spare and shall be coded as zero.

MBS service area indication (MSAI) (bits 4 and 5 of octet 4)

The MSAI indicates whether and how the MBS service area is included in the IE.

Bits

5

4

0

0

MBS service area not included

0

1

MBS service area included as MBS TAI list

1

0

MBS service area included as NR CGI list

1

1

MBS service area included as MBS TAI list and NR CGI list

Rejection cause (bits 6 to 8 of octet 4)

The Rejection cause indicates the reason of rejecting the join request or the reason of removing the UE from the MBS session.

Bits

8

7

6

0

0

0

No additional information provided

0

0

1

Insufficient resources

0

1

0

User is not authorized to use MBS service

0

1

1

multicast MBS session has not started or will not start soon

1

0

0

User is outside of local MBS service area

1

0

1

Session context not found

1

1

0

multicast MBS session is released

All other values are unused in this version of the specification and interpreted as 000 if received.

IP address existence (IPAE) (bit1 of octet 5)

The IPAE indicates whether the Source IP address information and Destination IP address information are included in the IE or not.

Bit

1

0

Source and destination IP address information not included

1

Source and destination IP address information included

If IPAE is set to "Source and destination IP address information included", Source IP address information and Destination IP address information shall be included in the IE, otherwise Source IP address information and Destination IP address information shall not be included in the IE.

MBS timer indication (MTI) (bits 2 and 3 of octet 5)

The MTI indicates whether there is MBS timer included in the IE or not.

Bit

3

2

0

0

No MBS timers included

0

1

MBS start time included

1

0

MBS back-off timer included

All other values are unused in this version of the specification and interpreted as 00 if received

MBS security container indication (MSCI) (bit 4 of octet 5)

The MSCI indicates whether the MBS security container is included in the IE or not

Bit

4

0

MBS security container not included

1

MBS security container included

IP address type (IPAT) (bit 5 of octet 5)

The IPAT indicates the type of the source IP address information and destination IP address information. This field is ignored when IPAE is set to "Source and destination IP address information not included".

Bit

5

0

Source IP address information and destination IP address information are IPv4

1

Source IP address information and destination IP address information are IPv6

Bits 6 to 8 of octet 5 are spare and shall be coded as zero.

TMGI (octets 6 to j)

The TMGI is coded as described in subclause 10.5.6.13 in 3GPP TS 24.008 [12] starting from octet 2. The structure of the TMGI is defined in 3GPP TS 23.003 [4].

Source IP address information (octet j+1 to v)

This field contains the IP unicast address used as source address in IP packets for identifying the source of the multicast service. The value of this field is copied from the corresponding source IP address information in the requested MBS container. If the IPAT indicates "Source and destination IP address information are IPv4", the Source IP address information in octet j+1 to octet j+4 contains an IPv4 address. If the IPAT indicates "Source and destination IP address information are IPv6", the Source IP address information in octet j+1 to octet j+16 contains an IPv6 address

Destination IP address information (octet v+1 to k)

This field contains the IP multicast address used as destination address in related IP packets for identifying a multicast service associated with the source. The value of this field is copied from the corresponding destination IP address information in the requested MBS container. If the IPAT indicates "Source and destination IP address information are IPv4", the Destination IP address information in octet v+1 to octet v+4 contains an IPv4 address. If the IPAT indicates "Source and destination IP address information are IPv6", the Destination IP address information in octet v+1 to octet v+16 contains an IPv6 address.

MBS service area (octet k+1 to s)

The MBS service area contains the MBS TAI list, the NR CGI list or both, that identifies the service area(s) for a local MBS service.

MBS TAI list (octet k+1 to s)

The MBS TAI list is coded as octet 2 and above of the 5GS tracking area identity list IE defined in subclause 9.11.3.9.

NR CGI (octet k+2 to k+9)

The NR CGI globally identifies an NR cell. It contains the NR Cell ID and the PLMN ID of that cell.

NR Cell ID (octet k+2 to k+6)

The NR Cell ID consists of 36 bits identifying an NR Cell ID as specified in subclause 9.3.1.7 of 3GPP TS 38.413 [31], in hexadecimal representation. Bit 8 of octet y+1 is the most significant bit and bit 5 of octet y+5 is the least significant bit. Bits 1 to 4 of octet y+5 are spare and shall be coded as zero.

MCC, Mobile country code (octet k+6 and bits 1 to 4 octet k+7)

The MCC field is coded as in ITU-T Recommendation E.212 [42], annex A.

MNC, Mobile network code (bits 5 to 8 of octet k+7 and octet k+8)

The coding of this field is the responsibility of each administration but BCD coding shall be used. The MNC shall consist of 2 or 3 digits. If a network operator decides to use only two digits in the MNC, bits 5 to 8 of octet k+7 shall be coded as "1111".

The MCC and MNC digits are coded as octets 6 to 8 of the Temporary mobile group identity IE in figure 10.5.154 of 3GPP TS 24.008 [12].

MBS start time (octets s+1 to s+6)

The MBS start time is coded as described in subclause 10.5.3.9 in 3GPP TS 24.008 [12] starting from octet 2 till octet 7.

MBS back-off timer (octet s+1)

The MBS back-off timer is coded as octet 3 described in subclause 10.5.7.4a in 3GPP TS 24.008 [12].

MTK indication (MTKI) (bit1 of octet i+2)

The MTKI indicates whether the MTK ID and Encrypted MTK are included in the MBS security keys set or not.

Bit

1

0

MTK ID and Encrypted MTK not included

1

MTK ID and Encrypted MTK included

Bits 2 to 8 of octet i+2 are spare and shall be coded as zero

Key domain ID (octet i+3 to i+5)

The key domain ID is 3 bytes long and is defined in 3GPP TS 33.246 [57].

MBS Service Key Identifier (MSK ID) (octets i+6 to i+9)

The MSK ID is 4 bytes long and is defined in 3GPP TS 33.246 [57].

MBS Service Key (MSK) (octets i+10 to i+25)

The MSK is 16 bytes long and is defined in 3GPP TS 33.246 [57].

MBS Traffic Key Identifier (MTK ID) (octets i+26 to i+27)

The MTK ID is 2 bytes long and is defined in 3GPP TS 33.246 [57].

Encrypted MBS Traffic Key (Encrypted MTK) (octets i+28 to i+43)

The Encrypted MTK is 16 bytes long and contains the encrypted version of MTK using MSK as defined in 3GPP TS 33.246 [57].

NOTE: The IPAE bit is not expected to be set to "Source and destination IP address information included" when the MBS decision (MD) indicates "Remove UE from multicast MBS session".

9.11.4.32 PDU session pair ID

The purpose of the PDU session pair ID information element is to indicate a PDU session pair ID.

The PDU session pair ID information element is coded as shown in figure 9.11.4.32.1 and table 9.11.4.32.1.

The PDU session pair ID is a type 4 information element with a length of 3 octets.

8

7

6

5

4

3

2

1

PDU session pair ID IEI

octet 1

Length of PDU session pair ID IE

octet 2

PDU session pair ID

octet 3

Figure 9.11.4.32.1: PDU session pair ID information element

Table 9.11.4.32.1: PDU session pair ID information element

PDU session pair ID (octet 3)

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

0

PDU session pair ID 0

to

to

0

0

0

0

0

1

1

0

PDU session pair ID 6

All other values are reserved.

9.11.4.33 RSN

The purpose of the RSN information element is to indicate an RSN.

The RSN information element is coded as shown in figure 9.11.4.33.1 and table 9.11.4.33.1.

The RSN is a type 4 information element with a length of 3 octets.

8

7

6

5

4

3

2

1

RSN IEI

octet 1

Length of RSN IE

octet 2

RSN

octet 3

Figure 9.11.4.33.1: RSN information element

Table 9.11.4.33.1: RSN information element

RSN (octet 3)

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

0

v1

0

0

0

0

0

0

0

1

v2

All other values are spare and shall not be used by a UE compliant to the present version of this specification.

9.11.4.34 ECS address

The purpose of the ECS address information element is to indicate the ECS address (either IPv4 address, IPv6 address, or FQDN) and the associated spatial validity condition.

The ECS address information element is coded as shown in figure 9.11.4.34-1, figure 9.11.4.34-2, table 9.11.4.34-1, and table 9.11.4.34-2.

The ECS address information element is a type 6 information element with minimum length of 8 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

ECS address IEI

octet 1

Length of ECS address contents

octet 2

octet 3

Type of ECS address

Type of spatial validity condition

octet 4

ECS address

octet 5

octet a

Spatial validity condition contents

octet (a+1)*

octet n*

Figure 9.11.4.34-1: ECS address information element

8

7

6

5

4

3

2

1

Length of spatial validity condition contents

octet (a+1)

octet (a+2)

Spatial validity information 1

octet b

octet c

Spatial validity information 2

octet (c+1)*

octet d*

octet (d+1)*

octet e*

Spatial validity information N

octet (e+1)*

octet n*

Figure 9.11.4.34-2: Spatial validity condition contents

Table 9.11.4.34-1: ECS address information element

Type of ECS address (octet 4, bit 1 to 4)

Bits

4

3

2

1

0

0

0

0

IPv4

0

0

0

1

IPv6

0

0

1

0

FQDN

1

1

1

1

Unspecified

All other values are spare. The receiving entity shall ignore an ECS address IE with type of ECS address containing a spare value.

Type of spatial validity condition (octet 4, bit 5 to 8)

Bits

8

7

6

5

0

0

0

0

No spatial validity condition

0

0

0

1

Geographical service area

0

0

1

0

Tracking area

0

0

1

1

Country-wide

All other values are spare. The receiving entity shall ignore a spatial validity condition with type of spatial validity condition containing an unknown value.

If the type of ECS address indicates IPv4, then the ECS address field contains an IPv4 address in octet 5 to octet 8.

If the type of ECS address indicates IPv6, then the ECS address field contains an IPv6 address in octet 5 to octet 20 and is encoded according to IETF RFC 4291 [RFC4291].

If the type of ECS address indicates FQDN, then the ECS address field contains in octet 5 the length of FQDN value and in octet 6 to octet a an FQDN value encoded as defined in subclause 19.4.2 in 3GPP TS 23.003 [4].

If the type of ECS address indicates unspecified, then the remaining fields of ECS address information element shall be passed to the upper layers.

Spatial validity condition contents (octet (a+1)* to n*)

The spatial validity condition contents contain a variable number of spatial validity condition information.

Table 9.11.4.34-2: Spatial validity condition contents

If the type of spatial validity condition of the ECS address indicates No spatial validity condition, then the spatial validity condition information field is empty.

If the type of spatial validity condition of the ECS address indicates geographical service area, then the spatial validity condition information field contains a geographical service area which is specified by geographical descriptions as defined in 3GPP TS 23.032 [4B].

If the type of spatial validity condition of the ECS address indicates tracking area, then the spatial validity condition information field contains a TAI as defined in subclause 9.11.3.8 starting from octet 2.

If the type of spatial validity condition of the ECS address indicates country-wide, then the spatial validity condition information field contains an MCC as defined in in ITU-T Recommendation E.212 [42], annex A. The first MCC digit is coded in bit 1 to 4 of the octet b, the second MCC digit is coded in bit 5 to 8 of the octet b, and the third MCC digit is coded in bit 1 to 4 of the octet b+1. Bit 5 to bit 8 of the octet b+1 shall be padded with 1. If only two digits are used for for MCC, octet b+1 shall be padded with 1.

9.11.4.35 Void