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. |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
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) 0 0 Reserved 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 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 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 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); – 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 0 reserved 1 parameters list is included For the "Delete existing QoS flow description" operation, the E bit is encoded as follows: Bit 0 parameters list is not included 1 reserved For the "modify existing QoS flow description" operation, the E bit is encoded as follows: Bit 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 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); – 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) 0 0 0 Reserved 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); 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 0 0 0 0 0 0 0 1 Match-all type (see NOTE 2) 1 0 0 0 0 0 0 1 Destination MAC address 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. |