9 Parameters and coding
24.5023GPPAccess to the 3GPP 5G Core Network (5GCN) via non-3GPP access networksRelease 18TS
9.1 General
This clause describes the encoding of the parameters which are exchanged between the UE and the network. This clause is further divided into three clauses; 3GPP specific coding information, IETF specific coding information and NAS message envelope.
The clauses for the 3GPP specific coding information and IETF specific coding information describe how to encode the messages and parameters belonging to 3GPP and IETF. The clause for NAS message envelope describes how to encode the NAS message envelope in order to frame a NAS message prior to its encapsulation within a TCP payload.
9.2 3GPP specific coding information
9.2.1 GUAMI
The purpose of the GUAMI information element is to provide the globally unique AMF ID.
The GUAMI information element is coded as shown in figures 9.2.1-1 and table 9.2.1-1.
The GUAMI is a type 3 information element with a length of 7 octets.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
GUAMI IEI |
octet 1 |
|||||||
MCC digit 2 |
MCC digit 1 |
octet 2 |
||||||
MNC digit 3 |
MCC digit 3 |
octet 3 |
||||||
MNC digit 2 |
MNC digit 1 |
octet 4 |
||||||
AMF region ID |
octet 5 |
|||||||
AMF set ID |
octet 6 |
|||||||
AMF set ID (continued) |
AMF pointer |
octet 7 |
Figure 9.2.1-1: GUAMI information element
Table 9.2.1-1: GUAMI information element
MCC, Mobile country code (octet 2, octet 3 bits 1 to 4) The MCC field is coded as in ITU-T Recommendation E.212 [21], Annex A. |
MNC, Mobile network code (octet 4, octet 3 bits 5 to 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 3 shall be coded as "1111". |
AMF Region ID (octet 5) This field contains the binary encoding of the AMF Region ID. Bit 8 of octet 5 is the most significant bit and bit 1 of octet 5 is the least significant bit. |
AMF Set ID (octet 6, octet 7 bits 7 to 8) This field contains the binary encoding of the AMF Set ID. Bit 8 of octet 6 is the most significant bit and bit 7 of octet 7 is the least significant bit. |
AMF Pointer (octet 7 bits 1 to 6) This field contains the binary encoding of the AMF Pointer. Bit 6 of octet 7 is the most significant bit and bit 1 of octet 7 is the least significant bit. |
9.2.2 Establishment cause for non-3GPP access
The purpose of the Establishment cause for non-3GPP access information element is to provide the establishment cause for non-3GPP access.
The Establishment cause for non-3GPP access information element is coded as shown in figures 9.2.2-1 and table 9.2.2-1.
The Establishment cause for non-3GPP access is a type 3 information element with length of 2 octets.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Establishment cause for non-3GPP access IEI |
octet 1 |
|||||||
0 Spare |
0 Spare |
0 Spare |
0 Spare |
N3AEC |
octet 2 |
Figure 9.2.2-1: Establishment cause for non-3GPP access information element
Table 9.2.2-1: Establishment cause for non-3GPP access information element
Establishment cause for non-3GPP access (N3AEC) (octet 2 bits 1 to 4) Bits 4 3 2 1 0 0 0 0 emergency 0 0 0 1 highPriorityAccess 0 0 1 1 mo-Signalling 0 1 0 0 mo-Data 1 0 0 0 mps-PriorityAccess 1 0 0 1 mcs-PriorityAccess 1 0 1 0 mo-SMS 1 0 1 1 mo-VoiceCall 1 1 0 0 mo-VideoCall All other values are spare values. The receiving entity shall treat a spare value as 0100, "mo-Data". |
9.2.3 PLMN ID
The purpose of the PLMN ID information element is to indicate the PLMN identity of the selected PLMN.
The PLMN ID is a type 4 information element with a length of 5 octets.
The PLMN ID information element is coded as shown in figure 9.2.3-1 and table 9.2.3-1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
PLMN ID IEI |
octet 1 |
|||||||
Length of PLMN ID contents |
octet 2 |
|||||||
MCC digit 2 |
MCC digit 1 |
octet 3 |
||||||
MNC digit 3 |
MCC digit 3 |
octet 4 |
||||||
MNC digit 2 |
MNC digit 1 |
octet 5 |
Figure 9.2.3-1: PLMN ID information element
Table 9.2.3-1: PLMN ID information element
MCC, Mobile country code (octet 3, octet 4 bits 1 to 4) The MCC field is coded as in ITU-T Recommendation E.212 [42], Annex A MNC, Mobile network code (octet 5, octet 4 bits 5 to 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 4 shall be coded as "1111". Mobile equipment shall accept MNC coded in such a way. |
9.2.4 IKEv2 Notify Message Type value
9.2.4.1 General
The IKEv2 Notify Message Type is specified in IETF RFC 7296 [6].
The Notify Message Type with a value (in decimal) in the range 0 – 16383 is intended for reporting errors, where:
– value range between 0 and 8191 is defined in IETF RFC 7296 [6]; and
– value range between 8192 and 16383 is reserved for private error usage.
The Notify Message Type with a value (in decimal) in the range 16384 – 65535 is intended for reporting status, where:
– value range between 16384 and 40959 is defined in IETF RFC 7296 [6]; and
– value range between 40960 and 65535 is reserved for private status usage.
9.2.4.2 Private Notify Message – Error Types
The Private Notify Message Error Types defined in table 9.2.4.2-1 are error notifications which indicate an error while negotiating an IKEv2 SA or IPsec SA. Refer to table 9.2.4.2-1 for more details on what each error type means.
Table 9.2.4.2-1: Private Error Types
Notify Message |
Value |
Descriptions |
CONGESTION |
15500 |
This error type is used to indicate that the requested service was rejected because of congestion in the network. |
NO_RESOURCES_OVER_N3GPP |
15501 |
This error type is used by the UE to indicate the failure of reserving the QoS resources over non-3GPP access for the QoS flows associated with the child SA. |
In the present specification, only the private notify message error type values between 15500 and 15599 shall be allocated to a Notify payload.
The private notify message error type values:
– between 9950 and 9999;
– between 10950 and 10999;
– between 11950 and 11999;
– between 12950 and 12999;
– between 13950 and 13999; and
– between 14950 and 14999;
shall not be allocated to a Notify payload defined in the present specification.
9.2.4.3 Private Notify Message – Status Types
The Private Notify Message Status Types defined in table 9.2.4.3-1 are used to indicate status notifications or additional information in a Notify payload which may be added to an IKEv2 message or IKE_AUTH request or IKE_AUTH response message according to the procedures described in the present document. Refer to table 9.2.4.3‑1 for more details on what each status type means.
Table 9.2.4.3-1: Private Status Types
Notify Message |
Value |
Descriptions |
5G_QOS_INFO |
55501 |
This status when present indicates 5G_QOS_INFO Notify payload encoded according to clause 9.3.1.1 |
NAS_IP4_ADDRESS |
55502 |
This status when present indicates NAS_IP4_ADDRESS Notify payload encoded according to clause 9.3.1.2. |
NAS_IP6_ADDRESS |
55503 |
This status when present indicates NAS_IP6_ADDRESS Notify payload encoded according to clause 9.3.1.3. |
UP_IP4_ADDRESS |
55504 |
This status when present indicates UP_IP4_ADDRESS Notify payload encoded according to clause 9.3.1.4. |
UP_IP6_ADDRESS |
55505 |
This status when present indicates UP_IP6_ADDRESS Notify payload encoded according to clause 9.3.1.5. |
NAS_TCP_PORT |
55506 |
This status when present indicates NAS_TCP_PORT Notify payload encoded according to clause 9.3.1.6. |
N3GPP_BACKOFF_TIMER |
55507 |
This status when present indicates N3GPP_BACKOFF_TIMER Notify payload encoded according to clause 9.3.1.7. |
In the present specification, only the private notify message status type values between 55500 and 55599 shall be allocated to a Notify payload.
The private notify message status type values:
– between 49950 and 49999;
– between 50950 and 50999;
– between 51950 and 51999;
– between 52950 and 52999;
– between 53950 and 53999; and
– between 54950 and 54999;
shall not be allocated to a Notify payload defined in the present specification.
9.2.5 TNGF IPv4 contact info
The purpose of the TNGF IPv4 contact info information element is to indicate the IPv4 address of the TNGF to be used for IKE SA establishment over trusted non-3GPP access network.
The TNGF IPv4 contact info is a type 4 information element with a length of 6 octets.
The TNGF IPv4 contact info information element is coded as shown in figure 9.2.5-1 and table 9.2.5-1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
TNGF IPv4 contact info IEI |
octet 1 |
|||||||
Length of TNGF IPv4 contact info contents |
octet 2 |
|||||||
TNGF IPv4 address |
octet 3 – 6 |
Figure 9.2.5-1: TNGF IPv4 contact info information element
Table 9.2.5-1: TNGF IPv4 contact info information element
TNGF IPv4 address contains IPv4 address of the TNGF for IKE SA establishment over trusted non-3GPP access network. |
9.2.6 TNGF IPv6 contact info
The purpose of the TNGF IPv6 contact info information element is to indicate the IPv6 address of the TNGF to be used for IKE SA establishent.
The TNGF IPv6 contact info is a type 4 information element with a length of 18 octets.
The TNGF IPv6 contact info information element is coded as shown in figure 9.2.6-1 and table 9.2.6-1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
TNGF IPv6 contact info IEI |
octet 1 |
|||||||
Length of TNGF IPv6 contact info contents |
octet 2 |
|||||||
TNGF IPv6 address |
octet 3 – 18 |
Figure 9.2.6-1: TNGF IPv6 contact info information element
Table 9.2.6-1: TNGF IPv6 contact info information element
TNGF IPv6 address contains IPv6 address of the TNGF for IKE SA establishment over trusted non-3GPP access network. |
9.2.7 NID
The purpose of the NID information element is to indicate the NID of the selected SNPN.
The NID is a type 4 information element with a length of 8 octets.
The NID information element is coded as shown in figure 9.2.7-1 and table 9.2.7-1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
NID IEI |
octet 1 |
|||||||
Length of NID contents |
octet 2 |
|||||||
NID value digit 1 |
Assignment mode |
octet 3 |
||||||
NID value digit 3 |
NID value digit 2 |
octet 4 |
||||||
NID value digit 5 |
NID value digit 4 |
octet 5 |
||||||
NID value digit 7 |
NID value digit 6 |
octet 6 |
||||||
NID value digit 9 |
NID value digit 8 |
octet 7 |
||||||
0 0 0 0 Spare |
NID value digit 10 |
octet 8 |
Figure 9.2.7-1: NID information element
Table 9.2.7-1: NID information element
Assignment mode (octet 3 bits 1 to 4) This field contains the binary encoding of the assignment mode of the NID as defined in 3GPP TS 23.003 [8]. NID value (octet 3 bits 5 to 8, octets 4 to 7, octet 8 bits 1 to 4) This field contains the binary encoding of each hexadecimal digit of the NID value as defined in 3GPP TS 23.003 [8]. Bits 5 to 8 of octet 8 are spare and shall be coded as zero. |
9.3 IETF RFC coding information
9.3.1 IKEv2 Notify payloads
9.3.1.1 5G_QOS_INFO Notify payload
The 5G_QOS_INFO payload is used to indicate:
a) the PDU session identity;
b) zero or more QFIs;
c) optionally a DSCP value associated with the child SA;
d) whether the child SA is the default child SA; and
e) if trusted non-3GPP access, Additional QoS Information or if untrusted non-3GPP access, optionally Additional QoS Information.
The 5G_QOS_INFO payload is coded according to figure 9.3.1.1-1 and table 9.3.1.1-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3 – 4 |
|||||||
Length |
5 |
|||||||
PDU Session Identity |
6 |
|||||||
Number of QFIs |
7 |
|||||||
QFI List |
8* – x* |
|||||||
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
QoSI |
DCSI |
DSCPI |
x+1 |
DSCP |
x+2* |
|||||||
Additional QoS Information |
x+3* – x+y* |
Figure 9.3.1.1-1: 5G_QOS_INFO Notify payload format
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Number of parameters |
x+3 |
|||||||
Parameters list |
x+4 – x+y |
Figure 9.3.1.1-2: Additional QoS Information
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Parameter 1 |
x+4 – x+k |
|||||||
Parameter 2 |
x+k+1 – x+p |
|||||||
… |
x+p+1 – x+q |
|||||||
Parameter m |
x+q+1 – x+y |
Figure 9.3.1.1-3: Parameters list
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Parameter identifier |
x+4 |
|||||||
Length of parameter contents |
x+5 |
|||||||
Parameter contents |
x+6 – x+k |
Figure 9.3.1.1-4: Parameter
Table 9.3.1.1-1: 5G_QOS_INFO Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
|
Octet 2 is the SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55501 to indicate the 5G_QOS_INFO. |
|
Octet 5 is the Length field. This field indicates the length in octets of the 5G_QOS_INFO Value field. |
|
Octet 6 is the PDU Session Identity field. This field indicates the PDU session associated with the child SA for user plane. |
|
Octet 7 is the Number of QFIs field. This field indicates the number of QFIs in the QFI list. |
|
Octet 8 to octet x is the QFI List field. This field indicates those QoS flows associated with the child SA. Every QFI is coded as the QFI field in the QoS rule defined in 3GPP TS 24.501 [4]. |
|
Octet x+1, bit 0 is the DSCP included field (DSCPI). 0 DSCP field is not included. 1 DSCP field is included. |
|
Octet x+1, bit 1 is the indication of whether the child SA is the default child SA (DCSI). 0 the child SA is not the default child SA. 1 the child SA is the default child SA. |
|
Octet x+1, bit 2 is the Additional QoS Information indication field (QoSI) 0 Additional QoS Information is not included. 1 Additional QoS Information is included. |
|
Octet x+2 is the DSCP field. If included, this field indicates the DSCP marking for all IP packets sent over this child SA. |
|
Octet x+3 to octet x+y is the Additional QoS Information field which is included if the access network is the trusted non-3GPP access network, and is optionally included if the access network is the untrusted non-3GPP access network. This field is encoded as defined in table 9.3.1.1-2. |
|
Table 9.3.1.1-2: Additional QoS Information
Octet x+3 is number of parameters 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 7 through 0 of octet x+3 where bit 7 is the most significant and bit 0 is the least significant bit. |
The parameter identifier field is used to identify each parameter included in the parameters list and it contains the binary coding of the parameter identifier. Bit 7 of the parameter identifier field contains the most significant bit and bit 0 contains the least significant bit. The following parameter identifiers are specified: Bits 7 6 5 4 3 2 1 0 If the parameters list contains a parameter identifier that is not supported by the receiving entity the corresponding parameter shall be discarded. |
If the parameter identifier indicates QoS characteristics, the parameter contents field contains the following representation: Octet 1 is the resource type with binary representation: Bits 7 6 5 4 3 2 1 0 Octet 2 is the priority level with 1 as the highest priority and 127 as the lowest priority ((see clause 9.3.1.84 in 3GPP TS 38.413 [29], see NOTE), and the binary representation is: Bits 7 6 5 4 3 2 1 0 0 1 1 1 1 1 1 1 Octets 3 and 4 are the packet delay budget and is a factor of 0.5ms (see clause 9.3.1.80 in 3GPP TS 38.413 [29], see NOTE), where the factor has the following binary representation: Bits 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 Octets 5 and 6 are the packet error rate where octet 5 is scalar and octet 6 represents exponent. The packet error rate is calculated as {scalar x10 – exponent} (see clause 9.3.1.81 in 3GPP TS 38.413 [29]) The binary representation of scalar and exponent are: Bits 7 6 5 4 3 2 1 0 0 0 0 0 1 0 0 1 Octets 7 and 8 are the averaging window and is included if the resource type is GBR. Averaging window is a factor of 0.5ms with default value of 2000ms (see clause 9.3.1.82 in 3GPP TS 38.413 [29], see NOTE), where the factor has the following binary representation: Bits 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 Octets 9 and 10 are the maximum data burst volume and is included if the resource type is delayed critical GBR. Maximum data burst volume is the maximum number of the bytes for the data volume (see clause 9.3.1.83 in 3GPP TS 38.413 [29], see NOTE), where the maximum number of bytes has the following binary representation: Bits 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 For GBR and delayed critical GBR resource types if 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) Bits 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 value is not used 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. For GBR and delayed critical GBR resource types if 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) The coding is identical to that of the unit of the guaranteed flow bit rate for downlink. 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. For GBR and delayed critical GBR resource types if 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 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 downlink. 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. For GBR and delayed critical GBR resource types if the parameter identifier indicates " MFBR uplink", the parameter contents field contains one octet indicating the unit of the maximum flow bit rate for uplink followed by two octets containing the value of the maximum flow bit rate for downlink. 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. For GBR and delayed critical GBR resource types if the parameter identifier indicates "Notification Control", the parameter identifier shall be ignored in this release. For GBR and delayed critical GBR resource types if the parameter identifier indicates "Maximum Packet Loss Rate downlink", the parameter contents field contains the ratio of the lost downlink packets per number of downlink packets sent, expressed in tenth of percent (see clause 9.3.1.79 in 3GPP TS 38.413 [29], see NOTE), with the binary representation: Bits 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0 For GBR and delayed critical GBR resource types if the parameter identifier indicates "Maximum Packet Loss Rate uplink", the parameter contents field contains the ratio of the lost uplink packets per number of uplink packets sent, expressed in tenth of percent (see clause 9.3.1.79 in 3GPP TS 38.413 [29]), with the binary representation: Bits 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0 |
NOTE: The protocol specified in 3GPP TS 29.413 [39] uses IEs specified in 3GPP TS 38.413 [29]. |
9.3.1.2 NAS_IP4_ADDRESS Notify payload
The NAS_IP4_ADDRESS payload is used to indicate the inner IPv4 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for NAS message transport.
The NAS_IP4_ADDRESS payload is coded according to figure 9.3.1.2-1 and table 9.3.1.2-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3 – 4 |
|||||||
IPv4 address |
5 – 8 |
Figure 9.3.1.2-1: NAS_IP4_ADDRESS Notify payload format
Table 9.3.1.2-1: NAS_IP4_ADDRESS Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55502 to indicate the NAS_IP4_ADDRESS. |
Octet 5 to octet 8 is the IPv4 address field. The IPv4 address field contains the inner IPv4 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for NAS message transport. |
9.3.1.3 NAS_IP6_ADDRESS Notify payload
The NAS_IP6_ADDRESS payload is used to indicate the inner IPv6 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for NAS message transport.
The NAS_IP6_ADDRESS payload is coded according to figure 9.3.1.3-1 and table 9.3.1.3-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3 – 4 |
|||||||
IPv6 address |
5 – 20 |
Figure 9.3.1.3-1: NAS_IP6_ADDRESS Notify payload format
Table 9.3.1.3-1: NAS_IP6_ADDRESS Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55503 to indicate the NAS_IP6_ADDRESS. |
Octet 5 to octet 20 is the IPv6 address field. The IPv6 address field contains the inner IPv6 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for NAS message transport. |
9.3.1.4 UP_IP4_ADDRESS Notify payload
The UP_IP4_ADDRESS payload is used to indicate the inner IPv4 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted on-3GPP access for GRE user data packet transport.
The UP_IP4_ADDRESS payload is coded according to figure 9.3.1.4-1 and table 9.3.1.4-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3 – 4 |
|||||||
IPv4 address |
5 – 8 |
Figure 9.3.1.4-1: UP_IP4_ADDRESS Notify payload format
Table 9.3.1.4-1: UP_IP4_ADDRESS Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55504 to indicate the UP_IP4_ADDRESS. |
Octet 5 to octet 8 is the IPv4 address field. The IPv4 address field contains the inner IPv4 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted on-3GPP access for GRE user data packet transport. |
9.3.1.5 UP_IP6_ADDRESS Notify payload
The UP_IP6_ADDRESS payload is used to indicate the inner IPv6 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for GRE user data packet transport.
The UP_IP6_ADDRESS payload is coded according to figure 9.3.1.5-1 and table 9.3.1.5-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3 – 4 |
|||||||
IPv6 address |
5 – 20 |
Figure 9.3.1.5-1: UP_IP6_ADDRESS Notify payload format
Table 9.3.1.5-1: UP_IP6_ADDRESS Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55505 to indicate the UP_IP6_ADDRESS. |
Octet 5 to octet 20 is the IPv6 address field. The IPv6 address field contains the inner IPv6 address of the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access for GRE user data packet transport. |
9.3.1.6 NAS_TCP_PORT Notify payload
The NAS_TCP_PORT payload is used to indicate the port number for the connection of the inner TCP transport protocol for the NAS message transport.
The NAS_TCP_PORT payload is coded according to figure 9.3.1.6-1 and table 9.3.1.6-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3 – 4 |
|||||||
Port Number |
5 – 6 |
Figure 9.3.1.6-1: NAS_TCP_PORT Notify payload format
Table 9.3.1.6-1: NAS_TCP_PORT Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55506 to indicate the NAS_TCP_PORT. |
Octet 5 and octet 6 are the Port Number field which contains the port number of the connection for the inner TCP transport protocol for the NAS message transport. |
9.3.1.7 N3GPP_BACKOFF_TIMER Notify payload
The N3GPP_BACKOFF_TIMER Notify payload is used to indicate the value of the back-off timer.
The N3GPP_BACKOFF_TIMER Notify payload is coded according to figure 9.3.1.7-1 and table 9.3.1.7-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol ID |
1 |
|||||||
SPI Size |
2 |
|||||||
Notify Message Type |
3-4 |
|||||||
Backoff Timer Value |
5 |
Figure 9.3.1.7-1: N3GPP_BACKOFF_TIMER Notify payload format
Table 9.3.1.7-1: N3GPP_BACKOFF_TIMER Notify payload value
Octet 1 is defined in IETF RFC 7296 [6] |
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 55507 to indicate the N3GPP_BACKOFF_TIMER. |
Octet 5 is the Backoff Timer Value field. This field indicates the value of the back-off timer. It is coded as the value part (as specified in 3GPP TS 24.007 [22] for type 4 IE) of the GPRS timer 3 information element defined in 3GPP TS 24.008 [28] clause 10.5.7.4a (NOTE). |
NOTE: The GPRS Timer 3 IEI field and the length of GPRS Timer 3 contents field of the GPRS timer 3 information element are not included in the value of the back-off timer. |
9.3.2 EAP-5G method
9.3.2.1 General
The messages of EAP-5G method are EAP requests and EAP responses as specified in IETF RFC 3748 [9] clause 4.1 and use coding of the expanded method type as described in IETF RFC 3748 [9] clause 5.7.
The sending entity shall set the value of a spare bit to zero. The receiving entity shall ignore the value of a spare bit.
9.3.2.2 Message format
9.3.2.2.1 EAP-Request/5G-Start message
EAP-Request/5G-Start message is coded as specified in figure 9.3.2.2.1-1 and table 9.3.2.2.1-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Code |
1 |
|||||||
Identifier |
2 |
|||||||
Length |
3 – 4 |
|||||||
Type |
5 |
|||||||
Vendor-Id |
6 – 8 |
|||||||
Vendor-Type |
9 – 12 |
|||||||
Message-Id |
13 |
|||||||
Spare |
14 |
|||||||
Extensions |
15 – m |
Figure 9.3.2.2.1-1: EAP-Request/5G-Start message
Table 9.3.2.2.1-1: EAP-Request/5G-Start message
Code field is set to 1 (decimal) as specified in IETF RFC 3748 [9] clause 4.1 and indicates request. |
Identifier field is set as specified in IETF RFC 3748 [9] clause 4.1. |
Length field is set as specified in IETF RFC 3748 [9] clause 4.1 and indicates the length of the EAP-Request/5G-Start message in octets. |
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] clause 5.7 and indicates the expanded type. |
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
Vendor-Type field is set to EAP-5G method identifier of 3 (decimal) as specified in 3GPP TS 33.402 [10] annex C. |
Message-Id field is set to 5G-Start-Id of 1 (decimal). |
Spare field consists of spare bits. |
Extensions field is an optional field and consists of spare bits. |
9.3.2.2.2 EAP-Response/5G-NAS message
EAP-Response/5G-NAS message is coded as specified in figure 9.3.2.2.2-1 and table 9.3.2.2.2-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Code |
1 |
|||||||
Identifier |
2 |
|||||||
Length |
3 – 4 |
|||||||
Type |
5 |
|||||||
Vendor-Id |
6 – 8 |
|||||||
Vendor-Type |
9 – 12 |
|||||||
Message-Id |
13 |
|||||||
Spare |
14 |
|||||||
AN-parameters length |
15-16 |
|||||||
AN-parameters |
17 – (17+x) |
|||||||
NAS-PDU length |
(18+x) – (19+x) |
|||||||
NAS-PDU |
(20+x) – (n+x) |
|||||||
Extended-AN-parameters length |
(n+x+1)-(n+x+2) |
|||||||
Extended-AN-parameters |
(n+x+3) – (n+x+3+y) |
|||||||
Extensions |
(n+x+4+y) – (n+x+4+y+z) |
Figure 9.3.2.2.2-1: EAP-Response/5G-NAS message
Table 9.3.2.2.2-1: EAP-Response/5G-NAS message
Code field is set to 2 (decimal) as specified in IETF RFC 3748 [9] clause 4.1 and indicates response. |
Identifier field is set as specified in IETF RFC 3748 [9] clause 4.1. |
Length field is set as specified in IETF RFC 3748 [9] clause 4.1 and indicates the length of the EAP-Response/5G-NAS message in octets. |
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] clause 5.7 and indicates the expanded type. |
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
Vendor-Type field is set to EAP-5G method identifier of 3 (decimal) as specified in 3GPP TS 33.402 [10] annex C. |
Message-Id field is set to 5G-NAS-Id of 2 (decimal). |
Spare field consists of spare bits. |
AN-parameters length indicates the length of the AN-parameters field in octets |
AN-parameters field is coded according to figure 9.3.2.2.2-2 and table 9.3.2.2.2-2. |
NAS-PDU length field indicates the length of NAS-PDU field in octets. |
NAS-PDU field contains a NAS message from the UE as specified in 3GPP TS 24.501 [4]. |
Extended-AN-parameters length field indicates the length of the extended-AN-parameters field in octets. |
Extended-AN-parameters field is coded according to figure 9.3.2.2.2-4 and table 9.3.2.2.2-4. |
Extensions field is an optional field and consists of spare bits. |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
AN-parameter 1 |
octet 17 octet a |
|||||||
AN-parameter 2 |
octet a+1 octet b |
|||||||
… |
octet b+1 octet k |
|||||||
AN-parameter n |
octet k+1 octet 17+x |
Figure 9.3.2.2.2-2: AN-parameters field
Table 9.3.2.2.2-2: AN-parameters field
Each AN-parameter field is coded according to figure 9.3.2.2.2-3 and table 9.3.2.2.2-3. |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
AN-parameter type |
octet a+1 |
|||||||
AN-parameter length |
octet a+2 |
|||||||
AN-parameter value |
octet a+3 octet b |
Figure 9.3.2.2.2-3: AN-parameter field
Table 9.3.2.2.2-3: AN-parameter field
The AN-parameter length field indicates the length of the AN-parameter value field. |
The AN-parameter type field indicates the type of the AN-parameter value field. Sending entity shall not set the AN-parameter type field to a spare value. Receiving entity shall ignore any AN-parameter field with the AN-parameter type field set to a spare value. |
The following AN-parameter type field values are specified: – 01H (GUAMI); – 02H (selected PLMN ID); – 03H (requested NSSAI); – 04H (establishment cause for non-3GPP access); – 05H (selected NID); – 06H (UE identity); and – 07H (onboarding indication). All other values of the AN-parameter type field are spare. Receiving entity shall ignore an AN-parameter field with the AN-parameter type field set to a spare value. |
When the AN-parameter type field indicates the GUAMI, the AN-parameter value field is coded as value part (as specified in 3GPP TS 24.007 [22] for type 3 information element) of GUAMI information element as specified in clause 9.2.1. |
When the AN-parameter type field indicates the selected PLMN ID, the AN-parameter value field is coded according to value part of PLMN ID information element as specified in clause 9.2.3. |
When the AN-parameter type field indicates the requested NSSAI, the AN-parameter value field is coded according to value part of NSSAI information element as specified in clause 9.11.3.37 of 3GPP TS 24.501 [4]. |
When the AN-parameter type field indicates the establishment cause for non-3GPP access, the AN-parameter value field is coded as value part (as specified in 3GPP TS 24.007 [22] for type 3 information element) of the Establishment cause for non-3GPP access information element as specified in clause 9.2.2. |
When the AN-parameter type field indicates the selected NID, the AN-parameter value field is coded according to the value part of the NID information element as specified in clause 9.2.7. |
When the AN-parameter type field indicates the UE identity, the AN-parameter value field is coded according to the value part of the 5GS mobile identity information element for type of identity 5G-GUTI or for type of identity SUCI as specified in clause 9.11.3.4 of 3GPP TS 24.501 [4]. When the AN-parameter type field indicates the onboarding indication, the value of AN-parameter length is 0, i.e. the AN-parameter value field is not present. |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
Extended-AN-parameter 1 |
octet (n+x+3) octet c |
|||||||
Extended-AN-parameter 2 |
octet c+1 octet d |
|||||||
… |
octet d+1 octet e |
|||||||
Extended-AN-parameter n |
octet e+1 octet (n+x+3+y) |
Figure 9.3.2.2.2-4: Extended-AN-parameters field
Table 9.3.2.2.2-4: Extended-AN-parameters field
Each extended-AN-parameter field is coded according to figure 9.3.2.2.2-5 and table 9.3.2.2.2-5. |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
Extended-AN-parameter type |
octet c+1 |
|||||||
Extended-AN-parameter length |
octet c+2 octet c+3 |
|||||||
Extended-AN-parameter value |
octet c+4 octet d |
Figure 9.3.2.2.2-5: Extended-AN-parameter field
Table 9.3.2.2.2-5: AN-parameter field
The extended-AN-parameter length field indicates the length of the extended-AN-parameter value field. |
The extended-AN-parameter type field indicates the type of the extended-AN-parameter value field. |
The following extended-AN-parameter type field values are specified: – 06H (UE identity). All other values of the extended-AN-parameter type field are spare. Sending entity shall not set the extended-AN-parameter type field to a spare value. Receiving entity shall ignore any extended-AN-parameter field with the extended-AN-parameter type field set to a spare value. |
When the extended-AN-parameter type field indicates the UE identity, the extended-AN-parameter value field is coded according to the value part of the 5GS mobile identity information element for type of identity SUCI as specified in clause 9.11.3.4 of 3GPP TS 24.501 [4]. |
9.3.2.2.3 EAP-Request/5G-NAS message
EAP-Request/5G-NAS message is coded as specified in figure 9.3.2.2.3-1and table 9.3.2.2.3-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Code |
1 |
|||||||
Identifier |
2 |
|||||||
Length |
3 – 4 |
|||||||
Type |
5 |
|||||||
Vendor-Id |
6 – 8 |
|||||||
Vendor-Type |
9 – 12 |
|||||||
Message-Id |
13 |
|||||||
Spare |
14 |
|||||||
NAS-PDU length |
15 – 16 |
|||||||
NAS-PDU |
17 – n |
|||||||
Extensions |
n+1 – z |
Figure 9.3.2.2.3-1: EAP-Request/5G-NAS message
Table 9.3.2.2.3-1: EAP-Request/5G-NAS message
Code field is set to 1 (decimal) as specified in IETF RFC 3748 [9] clause 4.1 and indicates request. |
Identifier field is set as specified in IETF RFC 3748 [9] clause 4.1. |
Length field is set as specified in IETF RFC 3748 [9] clause 4.1 and indicates the length of the EAP-Request/5G-NAS message in octets. |
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] clause 5.7 and indicates the expanded type. |
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
Vendor-Type field is set to EAP-5G method identifier of 3 (decimal) as specified in 3GPP TS 33.402 [10] annex C. |
Message-Id field is set to 5G-NAS-Id of 2 (decimal). |
Spare field consists of spare bits. |
NAS-PDU length field indicates the length of NAS-PDU field in octets. |
NAS-PDU field contains a NAS message from the AMF as specified 3GPP TS 24.501 [4]. |
Extensions field is an optional field and consists of spare bits. |
9.3.2.2.4 EAP-Response/5G-Stop message
EAP-Response/5G-Stop message is coded as specified in figure 9.3.2.2.4-1 and table 9.3.2.2.4-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Code |
1 |
|||||||
Identifier |
2 |
|||||||
Length |
3 – 4 |
|||||||
Type |
5 |
|||||||
Vendor-Id |
6 – 8 |
|||||||
Vendor-Type |
9 – 12 |
|||||||
Message-Id |
13 |
|||||||
Spare |
14 |
|||||||
Extensions |
15 – m |
Figure 9.3.2.2.4-1: EAP-Response/5G-Stop message
Table 9.3.2.2.4-1: EAP-Response/5G-Stop message
Code field is set to 2 (decimal) as specified in IETF RFC 3748 [9] clause 4.1 and indicates response. |
Identifier field is set as specified in IETF RFC 3748 [9] clause 4.1. |
Length field is set as specified in IETF RFC 3748 [9] clause 4.1 and indicates the length of the EAP-Response/5G-Stop message in octets. |
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] clause 5.7 and indicates the expanded type. |
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
Vendor-Type field is set to EAP-5G method identifier of 3 (decimal) as specified in 3GPP TS 33.402 [10] annex C. |
Message-Id field is set to 5G-Stop-Id of 4 (decimal). |
Spare field consists of spare bits. |
Extensions field is an optional field and consists of spare bits. |
9.3.2.2.5 EAP-Request/5G-Notification message
EAP-Request/5G-Notification message is coded as specified in figure 9.3.2.2.5-1 and table 9.3.2.2.5-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Code |
1 |
|||||||
Identifier |
2 |
|||||||
Length |
3 – 4 |
|||||||
Type |
5 |
|||||||
Vendor-Id |
6 – 8 |
|||||||
Vendor-Type |
9 – 12 |
|||||||
Message-Id |
13 |
|||||||
Spare |
14 |
|||||||
AN-parameters length |
15 – 16 |
|||||||
AN-parameters |
17 – n |
|||||||
Extensions |
n+1 – m |
Figure 9.3.2.2.5-1: EAP-Request/5G-Notification message
Table 9.3.2.2.5-1: EAP-Request/5G-Notification message
Code field is set to 1 (decimal) as specified in IETF RFC 3748 [9] clause 4.1 and indicates request. |
Identifier field is set as specified in IETF RFC 3748 [9] clause 4.1. |
Length field is set as specified in IETF RFC 3748 [9] clause 4.1 and indicates the length of the EAP-Request/5G-Notification message in octets. |
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] clause 5.7 and indicates the expanded type. |
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
Vendor-Type field is set to EAP-5G method identifier of 3 (decimal) as specified in 3GPP TS 33.402 [10] annex C. |
Message-Id field is set to 5G-Notification-Id of 3 (decimal). |
Spare field consists of spare bits. |
AN-parameters length indicates the length of the AN-parameters field in octets |
AN-Parameters field is coded according to figure 9.3.2.2.5-2 and table 9.3.2.2.5-2. |
Extensions field is an optional field and consists of spare bits. |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
AN-parameter 1 |
octet 17 octet a |
|||||||
AN-parameter 2 |
octet a+1 octet b |
|||||||
… |
octet b+1 octet k |
|||||||
AN-parameter n |
octet k+1 octet n |
Figure 9.3.2.2.5-2: AN-parameters field
Table 9.3.2.2.5-2: AN-parameters field
Each AN-parameter field is coded according to figure 9.3.2.2.5-3 and table 9.3.2.2.5-3. |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
AN-parameter type |
octet a+1 |
|||||||
AN-parameter length |
octet a+2 |
|||||||
AN-parameter value |
octet a+3 octet b |
Figure 9.3.2.2.5-3: AN-parameter field
Table 9.3.2.2.5-3: AN-parameter field
The AN-parameter length field indicates the length of the AN-parameter value field. |
The AN-parameter type field indicates the type of the AN-parameter value field. Sending entity shall not set the AN-parameter type field to a spare value. Receiving entity shall ignore any AN-parameter field with the AN-parameter type field set to a spare value. |
The following AN-parameter type field values are specified: – 01H (TNGF IPv4 contact info); – 02H (TNGF IPv6 contact info); All other values of the AN-parameter type field are spare. Receiving entity shall ignore an AN-parameter field with the AN-parameter type field set to a spare value. |
When the AN-parameter type field indicates the TNGF IPv4 contact info, the AN-parameter value field is coded as value part (as specified in 3GPP TS 24.007 [22] for type 3 information element) of TNGF IPv4 contact info information element as specified in clause 9.2.5. |
When the AN-parameter type field indicates the TNGF IPv6 contact info, the AN-parameter value field is coded as value part (as specified in 3GPP TS 24.007 [22] for type 3 information element) of TNGF IPv6 contact info information element as specified in clause 9.2.6. |
9.3.2.2.6 EAP-Response/5G-Notification message
EAP-Response/5G-Notification message is coded as specified in figure 9.3.2.2.6-1 and table 9.3.2.2.6-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Code |
1 |
|||||||
Identifier |
2 |
|||||||
Length |
3 – 4 |
|||||||
Type |
5 |
|||||||
Vendor-Id |
6 – 8 |
|||||||
Vendor-Type |
9 – 12 |
|||||||
Message-Id |
13 |
|||||||
Spare |
14 |
|||||||
Extensions |
15-z |
Figure 9.3.2.2.6-1: EAP-Response/5G-Notification message
Table 9.3.2.2.6-1: EAP-Response/5G-Notification message
Code field is set to 2 (decimal) as specified in IETF RFC 3748 [9] clause 4.1 and indicates response. |
Identifier field is set as specified in IETF RFC 3748 [9] clause 4.1. |
Length field is set as specified in IETF RFC 3748 [9] clause 4.1 and indicates the length of the EAP-Response/5G-Notification message in octets. |
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] clause 5.7 and indicates the expanded type. |
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
Vendor-Type field is set to EAP-5G method identifier of 3 (decimal) as specified in 3GPP TS 33.402 [10] annex C. |
Message-Id field is set to 5G-Notification-Id of 3 (decimal). |
Spare field consists of spare bits. |
Extensions field is an optional field and consists of spare bits. |
9.3.3 GRE encapsulated user data packet
GRE encapsulated user data packet is coded according to figure 9.3.3-1 and table 9.3.3-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
GRE header |
1 – 8 |
|||||||
Payload packet |
9 – x |
Figure 9.3.3-1: GRE encapsulated user data packet
Table 9.3.3-1: GRE encapsulated user data packet
Octet 1 to octet 8 are the GRE header field defined in IETF RFC 2784 [14] and IETF RFC 2890 [15]. The GRE header field is coded according to figure 9.3.3-2 and table 9.3.3-2. |
Octet 9 to octet x are the Payload packet field. The Payload packet field contains one user data packet. |
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
C |
Reserved0 |
K |
S |
Reserved0 |
1 |
|||
Reserved0 |
Ver |
2 |
||||||
Protocol type |
3 – 4 |
|||||||
Key |
5 – 8 |
Figure 9.3.3-2: GRE header field
Table 9.3.3-2: GRE header field
Bit 7 of octet 1 is the C bit defined in IETF RFC 2784 [14]. The C bit is set to zero. |
Bits 6, 3, 2, 1 and 0 of octet 1 and bits 7, 6, 5, 4, and 3 of octet 2 are the Reserved0 field defined in IETF RFC 2784 [14] and IETF RFC 2890 [15]. |
Bit 5 of octet 1 is the K bit defined in IETF RFC 2890 [15]. The K bit is set to one. |
Bit 4 of octet 1 is the S bit defined in IETF RFC 2890 [15]. The S bit is set to zero. |
Bits 2, 1 and 0 of octet 2 is the Ver field defined in IETF RFC 2784 [14]. |
Octet 3 and octet 4 are the Protocol Type field defined in IETF RFC 2784 [14]. The Protocol Type field is set to zero. (see NOTE) |
Octet 5 to octet 8 are the Key field defined in IETF RFC 2890 [15]. The Key field is coded according to figure 9.3.3-3 and table 9.3.3-3. |
NOTE: The receiving entity shall ignore value of the Protocol Type field. |
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
0 Spare |
0 Spare |
QFI |
5 |
|||||
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
6 |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
7 |
RQI |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
8 |
Figure 9.3.3-3: Key field of GRE header
Table 9.3.3-3: Key field of GRE header
RQI (octet 8, bit 7) |
|||||||
Bit |
|||||||
7 |
|||||||
0 |
RQI is not indicated |
||||||
1 |
RQI is indicated |
||||||
QFI (octet 5, bits 5 to 0) |
|||||||
Bits |
|||||||
5 |
4 |
3 |
2 |
1 |
0 |
||
0 |
0 |
0 |
0 |
0 |
0 |
QFI 0 |
|
to |
|||||||
1 |
1 |
1 |
1 |
1 |
1 |
QFI 63 |
|
9.4 NAS message envelope
NAS message envelope is used to frame the NAS message prior to its encapsulation as the TCP payload in the inner IP datagram.
NAS message envelope is encoded according to figure 9.4-1 and table 9.4-1.
Bits |
||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Length |
1 – 2 |
|||||||
NAS Message |
3 – m |
Figure 9.4-1: NAS message envelope format
Table 9.4-1: NAS message envelope value
Octet 1 and Octet 2 indicate the Length field. The Length field contains the length of the NAS message in bytes. |
Octet 3 to octet m indicate the NAS Message field. The NAS Message field contains the NAS message which is to be framed in prior to encapsulation as the TCP payload in the inner IP datagram of the transmitted IP packet. |
Annex A (informative):
Change history
Change history |
|||||||
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
2017-10-23 |
CT1#106 |
C1-174508 |
Initial Draft provided to CT1#106. |
0.0.0 |
|||
2017-11 |
CT1#106 |
C1-174572 |
Includes the contribution agreed by CT1 at CT1#106. |
0.1.0 |
|||
2017-12 |
CT1#107 |
C1-175315, C1-174945, C1-174947, C1-174948, C1-175317 |
Incorporates the agreed P-CRs for TS 24.502 from CT1#107 plus editorial changes and reference updates by the rapporteur. |
0.2.0 |
|||
2017-12 |
Additional editorial changes by the rapporteur |
0.2.1 |
|||||
2018-02 |
CT1#108 |
C1-180055, C1-180475, C1-180691, C1-180692, C1-180700 |
Incorporates the agreed P-CRs for TS 24.502 from CT1#108 plus editorial changes and reference updates by the rapporteur. |
0.3.0 |
|||
2018-03 |
CT1#109 |
C1-181454, C1-181704, C1-181249, C1-181327, C1-181489, C1-181490, C1-181491, C1-181498, C1-181499, C1-181600, C1-181602 |
Incorporates the agreed P-CRs for TS 24.502 from CT1#109 plus editorial changes, reference and styles updates by the rapporteur. |
0.4.0 |
|||
2018-04 |
CT1#110 |
C1-182494, C1-182175, C1-182403, C1-182680, C1-182700, C1-182722, C1-182794, C1-182807, C1-182818, C1-182819, C1-182843 |
Incorporates the agreed P-CRs from CT1#110 plus editorial changes, reference and styles updates by the rapporteur. |
0.5.0 |
|||
2018-05 |
CT1#111 |
C1-183037, C1-183040, C1-183046, C1-183047, C1-183733, C1-183734, C1-183735, C1-183783, C1-183828, C1-183829 |
Incorporates the agreed P-CRs from CT1#111 plus editorial changes, reference and styles updates by the rapporteur. |
0.6.0 |
|||
2018-06 |
CT-80 |
CP-181095 |
Version 1.0.0 created for presentation to TSG CT#80 for information and approval. |
1.0.0 |
|||
2018-06 |
CT-80 |
Version 15.0.0 created after approval |
15.0.0 |
||||
2018-09 |
CT-81 |
CP-182143 |
0001 |
2 |
F |
Correction for providing GUAMI as part of AN parameters |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0002 |
2 |
F |
Correction for coding of non-3GPP access establishment cause AN parameter |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0003 |
2 |
F |
Correction for N3AN node selection |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0004 |
1 |
B |
Including GUAMI as AN-parameters during registration for non-3GPP access |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0005 |
2 |
B |
Coding of AN-parameters in EAP 5G-NAS message |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0007 |
3 |
B |
3GPP specific IKEv2 private Notify Message Types |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0011 |
2 |
F |
Changing Transport Mode to Tunnel Mode for IPsec Tunnel |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0014 |
1 |
F |
Clarification on ANDSP |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0018 |
F |
Definition of new notify payloads |
15.1.0 |
|
2018-09 |
CT-81 |
CP-182143 |
0019 |
1 |
F |
Corrections for liveness check |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0022 |
3 |
F |
Signalling IPsec SA establishment not accepted by the network |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0023 |
1 |
B |
User plane IPsec SA establishment not accepted |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0024 |
2 |
F |
NAI as identifier for non-3GPP access |
15.1.0 |
2018-09 |
CT-81 |
CP-182143 |
0027 |
1 |
B |
IKE SA deletion procedure handling |
15.1.0 |
2018-09 |
CT-81 |
Editorial corrections |
15.1.1 |
||||
2018-12 |
CT-82 |
CP-183042 |
0029 |
2 |
F |
Correction of name fields and protocol numbers |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0030 |
2 |
F |
Correction for default user plane SA indication |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0031 |
1 |
F |
Correction for DSCP in outer IP header carrying uplink user data packet |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0032 |
F |
Corrections for coding of establishment cause for non-3GPP access |
15.2.0 |
|
2018-12 |
CT-82 |
CP-183042 |
0033 |
1 |
F |
Removing an editor’s note |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0034 |
F |
Editor’s note on usage of Any_PLMN entry configuration |
15.2.0 |
|
2018-12 |
CT-82 |
CP-183042 |
0036 |
2 |
F |
Local deletion of IKE SA and child SAs |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0037 |
2 |
F |
IKE SA and child SAs deletion by UE due to rekeying failure |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0038 |
F |
Correction on child user plane IPsec SA establishment description |
15.2.0 |
|
2018-12 |
CT-82 |
CP-183042 |
0039 |
F |
Resolve the editor note on liveness check |
15.2.0 |
|
2018-12 |
CT-82 |
CP-183042 |
0040 |
2 |
B |
TCP protocol as inner transport layer protocol for NAS signaling |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0041 |
1 |
F |
Clarification and clean up |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0043 |
1 |
F |
Correction on N3AN node configuration information |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0044 |
F |
Correcting automatic and manual mode procedures |
15.2.0 |
|
2018-12 |
CT-82 |
CP-183042 |
0045 |
2 |
F |
SUPI and SUCI as user identities |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0047 |
2 |
F |
Correct determination of country the UE is located in |
15.2.0 |
2018-12 |
CT-82 |
CP-183042 |
0049 |
1 |
F |
Backoff timer in IKE_AUTH response |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0050 |
1 |
F |
AMF congestion when establishing security association and editors note |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0051 |
1 |
B |
AMF congestion when receiving NAS message |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0053 |
2 |
F |
Correcting the name of ITU-T Recommendation E.212 |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0054 |
1 |
F |
Remove of an editorial note |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0055 |
1 |
F |
Correction on WLAN selection |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0056 |
3 |
F |
Establishment of TCP connection for transport of NAS messages |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0059 |
2 |
F |
Alignment of the PLMN determination |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0060 |
2 |
F |
Correct WLAN selection procedure |
15.3.0 |
2019-03 |
CT-83 |
CP-190090 |
0062 |
D |
Correction to definition of the PCF abbreviation |
15.3.0 |
|
2019-03 |
CT-83 |
CP-190090 |
0063 |
F |
Correct empty clause |
15.3.0 |
|
2019-06 |
CT-84 |
CP-191125 |
0065 |
F |
Release of TCP connection for transport of NAS messages |
15.4.0 |
|
2019-06 |
CT-84 |
CP-191125 |
0069 |
1 |
F |
Clarification for untrusted non-3GPP access |
15.4.0 |
2019-06 |
CT-84 |
CP-191125 |
0082 |
1 |
F |
IPsec SA modification procedure |
15.4.0 |
2019-06 |
CT-84 |
CP-191136 |
0066 |
1 |
F |
Error in EAP-Response/5G-NAS message coding |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0067 |
1 |
B |
EAP-5G extensions for trusted non-3GPP access |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0071 |
1 |
B |
Update to the scope for trusted non-3GPP access |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0072 |
2 |
B |
Introduction of trusted non-3GPP access description |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0073 |
5 |
B |
QoS for non-3GPP access |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0074 |
5 |
B |
Authentication and authorization for accessing 5GS |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0075 |
3 |
B |
Update to WLAN selection procedure because of trusted non-3GPP access |
16.0.0 |
2019-06 |
CT-84 |
CP-191148 |
0079 |
B |
N3IWF FQDN configured in a UE to support access to PLMN/SNPN services via SNPN/PLMN |
16.0.0 |
|
2019-06 |
CT-84 |
CP-191136 |
0080 |
1 |
D |
Editorial changes |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0081 |
2 |
F |
Adding text to General section of clause 9 entitled "Parameters and coding" |
16.0.0 |
2019-06 |
CT-84 |
CP-191136 |
0083 |
D |
Alignment of capitalizations |
16.0.0 |
|
2019-06 |
CT-84 |
CP-191137 |
0084 |
3 |
B |
TNAN and PLMN selection procedures using trusted WLAN |
16.0.0 |
2019-06 |
CT-84 |
CP-191136 |
0085 |
1 |
F |
Reference to IEEE Std 802.11 |
16.0.0 |
2019-06 |
CT-84 |
CP-191148 |
0086 |
1 |
B |
A dedicated child SA and a DSCP value for QoS flows |
16.0.0 |
2019-06 |
CT-84 |
CP-191137 |
0087 |
2 |
B |
Update to the scope for wireline access networks |
16.0.0 |
2019-09 |
CT-85 |
CP-192059 |
0068 |
5 |
B |
UE registration for trusted non-3GPP access |
16.1.0 |
2019-09 |
CT-85 |
CP-192058 |
0090 |
1 |
F |
Adding a general clause |
16.1.0 |
2019-09 |
CT-85 |
CP-192059 |
0092 |
2 |
B |
Text modification for trusted non-3GPP access |
16.1.0 |
2019-09 |
CT-85 |
CP-192058 |
0093 |
1 |
F |
Modification for untrusted non-3GPP access |
16.1.0 |
2019-09 |
CT-85 |
CP-192059 |
0094 |
1 |
C |
Address EN on PLMN Selector list |
16.1.0 |
2019-09 |
CT-85 |
CP-192058 |
0095 |
B |
Forbidden PLMNs for non-3GPP access to 5GCN |
16.1.0 |
|
2019-09 |
CT-85 |
CP-192045 |
0097 |
1 |
A |
Protocol type field in GRE encapsulated user data packet |
16.1.0 |
2019-12 |
CT-86 |
CP-193100 |
0099 |
F |
Remove the content under the void clause |
16.2.0 |
|
2019-12 |
CT-86 |
CP-193100 |
0100 |
1 |
B |
Registration, Session establishment and session release of 5G capable over WLAN (N5CW) device |
16.2.0 |
2019-12 |
CT-86 |
CP-193100 |
0101 |
3 |
F |
Removal of an editor’s note |
16.2.0 |
2019-12 |
CT-86 |
CP-193119 |
0102 |
1 |
F |
FQDN for N3IWF selection to access PLMN services via an SNPN |
16.2.0 |
2019-12 |
CT-86 |
CP-193092 |
0103 |
3 |
F |
Apply ANDSP of equivalent PLMN |
16.2.0 |
2019-12 |
CT-86 |
CP-193119 |
0104 |
3 |
F |
Addition of NID to AN parameters |
16.2.0 |
2019-12 |
CT-86 |
CP-193100 |
0106 |
1 |
B |
WLAN and PLMN selection procedures for a N5CW device |
16.2.0 |
2019-12 |
CT-86 |
CP-193100 |
0107 |
F |
Scope correction |
16.2.0 |
|
2019-12 |
CT-86 |
CP-193100 |
0108 |
1 |
B |
PLMN selection for wireline access |
16.2.0 |
2019-12 |
CT-86 |
CP-193100 |
0109 |
B |
QoS handling for wireline access |
16.2.0 |
|
2020-03 |
CT-87e |
CP-200113 |
0110 |
3 |
B |
EAP-5G handling and transport of NAS messages for wireline access |
16.3.0 |
2020-03 |
CT-87e |
CP-200113 |
0111 |
2 |
B |
Additional QoS Information in an untrusted non-3GPP network |
16.3.0 |
2020-03 |
CT-87e |
CP-200113 |
0113 |
1 |
F |
Removal of an editor’s note |
16.3.0 |
2020-03 |
CT-87e |
CP-200129 |
0115 |
C |
Updating length of NID |
16.3.0 |
|
2020-03 |
CT-87e |
CP-200113 |
0116 |
1 |
B |
Support of authentication and registration of N5GC devices via wireline access |
16.3.0 |
2020-03 |
CT-87e |
CP-200113 |
0118 |
1 |
B |
SUPI and SUCI for legacy wireline access |
16.3.0 |
2020-06 |
CT-88e |
CP-201090 |
0120 |
5 |
A |
Correct N3AN node selection due to LI |
16.4.0 |
2020-06 |
CT-88e |
CP-201106 |
0121 |
F |
Add handling for UE configured to use timer T3245 in 5GS for non-3GPP access |
16.4.0 |
|
2020-06 |
CT-88e |
CP-201108 |
0122 |
1 |
F |
Inclusion of requested NSSAI in AN parameters |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0123 |
1 |
F |
Removal of editor’s notes |
16.4.0 |
2020-06 |
CT-88e |
CP-201090 |
0125 |
2 |
A |
Remove USE_TRANSPORT_MODE in response |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0126 |
1 |
B |
Error type on failure of reserving QoS resources over non-3GPP access |
16.4.0 |
2020-06 |
CT-88e |
CP-201106 |
0130 |
1 |
F |
Extending congestion notification to capture N3IWF or TNGF overload |
16.4.0 |
2020-06 |
CT-88e |
CP-201106 |
0131 |
1 |
F |
Enable N3IWF to initiate TCP connection establishment upon failure |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0134 |
1 |
F |
Access network parameters |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0135 |
1 |
F |
Correction of TNGF procedure |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0143 |
1 |
B |
SUPI/SUCI of N5GC devices |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0136 |
3 |
F |
Correcting reference |
16.4.0 |
2020-06 |
CT-88e |
CP-201106 |
0138 |
1 |
F |
Correcting editorial errors |
16.4.0 |
2020-06 |
CT-88e |
CP-201106 |
0139 |
1 |
F |
Resolution of editor’s notes under clauses 7.3.4 and 7.3.5 |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0140 |
1 |
F |
N5CW device registration and IP assignment |
16.4.0 |
2020-06 |
CT-88e |
CP-201106 |
0141 |
1 |
F |
Resolution of editor’s notes under clauses 7.5.5 and 7.5.6 |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0142 |
1 |
F |
Resolution of editor’s note under clause 7.3A.4.2 |
16.4.0 |
2020-09 |
CT-89e |
CP-202152 |
0144 |
1 |
F |
W-CP connection in 24.502 |
16.5.0 |
2020-09 |
CT-89e |
CP-202170 |
0148 |
1 |
F |
Correction in N3AN node selection involving SNPN |
16.5.0 |
2020-09 |
CT-89e |
CP-202149 |
0150 |
F |
Remove editor’s notes of child SA deletion procedure |
16.5.0 |
|
2020-09 |
CT-89e |
CP-202149 |
0151 |
1 |
F |
Corrections on encodings and typos in 24502 |
16.5.0 |
2020-09 |
CT-89e |
CP-202149 |
0152 |
F |
Corrections on the encoding of the 5G_QOS_INFO Notify payload |
16.5.0 |
|
2020-09 |
CT-89e |
CP-202174 |
0146 |
D |
Editorial clean up |
17.0.0 |
|
2020-09 |
CT-89e |
CP-202174 |
0147 |
2 |
F |
Handling of the OVERLOAD START message in the NWu interface |
17.0.0 |
2020-09 |
CT-89e |
CP-202174 |
0149 |
1 |
F |
Correction on handling of USE_TRANSPORT_MODE |
17.0.0 |
2020-12 |
CT-90e |
CP-203175 |
0153 |
1 |
F |
Alignment of the removing of PLMN from the list of "forbidden PLMNs for non-3GPP access to 5GCN" |
17.1.0 |
2020-12 |
CT-90e |
CP-203177 |
0155 |
A |
Clarification on NAI provided by N5CW device |
17.1.0 |
|
2020-12 |
CT-90e |
CP-203177 |
0157 |
A |
Resolve editor notes on trusted access selection |
17.1.0 |
|
2020-12 |
CT-90e |
CP-203177 |
0167 |
A |
Resolution of the editor’s notes on the procedure for determining whether it is mandatory to select a PLMN in the visited country |
17.1.0 |
|
2020-12 |
CT-90e |
CP-203175 |
0169 |
2 |
F |
Establishment cause in non-3GPP access |
17.1.0 |
2020-12 |
CT-90e |
CP-203177 |
0173 |
1 |
A |
Correction to trusted connectivity |
17.1.0 |
2020-12 |
CT-90e |
CP-203177 |
0175 |
2 |
A |
Correction to procedures for non 5G capable over WLAN (N5CW) devices |
17.1.0 |
2020-12 |
CT-90e |
CP-203224 |
0176 |
1 |
F |
Setting TCP source port number |
17.1.0 |
2021-03 |
CT-91e |
CP-210114 |
0181 |
2 |
A |
SNPN access operation mode |
17.2.0 |
2021-03 |
CT-91e |
CP-210114 |
0183 |
1 |
A |
Update of N3IWF selection procedure for access to SNPN services via a PLMN |
17.2.0 |
2021-03 |
CT-91e |
CP-210116 |
0187 |
F |
Optionally include Additional QoS Information for untrusted non-3GPP |
17.2.0 |
|
2021-03 |
CT-91e |
CP-210116 |
0188 |
1 |
F |
Clarification on IKE SA and signalling IPsec SA establishment on untrusted access |
17.2.0 |
2021-06 |
CT#92e |
CP-211130 |
0171 |
7 |
A |
Correct N3AN node selection due to permitted home routing |
17.3.0 |
2021-06 |
CT#92e |
CP-211148 |
0192 |
F |
EAP encoding corrections |
17.3.0 |
|
2021-06 |
CT#92e |
CP-211148 |
0186 |
5 |
F |
MMTEL Voice and MMTEL Video in non-3GPP |
17.3.0 |
2021-06 |
CT#92e |
CP-211148 |
0191 |
1 |
F |
Clarification on TAC determination for FQDN |
17.3.0 |
2021-06 |
CT#92e |
CP-211148 |
0193 |
1 |
F |
AN parameters encoding corrections |
17.3.0 |
2021-09 |
CT#93e |
CP-212156 |
0194 |
1 |
C |
N3IWF selection for emergency services |
17.4.0 |
2021-09 |
CT#93e |
CP-212156 |
0195 |
1 |
F |
SUCI transport via trusted non-3GPP access |
17.4.0 |
2022-03 |
CT#95e |
CP-220245 |
0197 |
1 |
B |
Support of QoS differentiation in case of accessing via UE-to-network relay |
17.5.0 |
2022-03 |
CT#95e |
CP-220282 |
0198 |
1 |
B |
Add support of 5G NSWO |
17.5.0 |
2022-06 |
CT#96 |
CP-221199 |
0200 |
1 |
A |
Correcting NAS transport between 5G RG and W-AGF to accommodate latest BBF developments |
17.6.0 |
2022-06 |
CT#96 |
CP-221213 |
0202 |
1 |
F |
Addition of condition for deleting SA procedure |
17.6.0 |
2022-06 |
CT#96 |
CP-221222 |
0203 |
1 |
F |
NSWO NAI corrections |
17.6.0 |
2022-06 |
CT#96 |
CP-221222 |
0199 |
2 |
B |
NSWO roaming support |
17.6.0 |
2022-12 |
CT#98e |
CP-223137 |
0206 |
2 |
B |
Added PLMN List with AAA connectivity to 5GC IE |
17.7.0 |
2022-12 |
CT#98e |
CP-223137 |
0211 |
1 |
B |
PLMN lists for non-3GPP access |
17.7.0 |
2022-12 |
CT#98e |
CP-223120 |
0212 |
1 |
B |
SNPN for trusted non-3GPP access |
18.0.0 |
2022-12 |
CT#98e |
CP-223120 |
0213 |
1 |
B |
Extend AN-parameters field for accessing SNPN using non-3GPP access |
18.0.0 |
2022-12 |
CT#98e |
CP-223157 |
0214 |
F |
Clarification to the error type "NO_RESOURCES_OVER_N3GPP" |
18.0.0 |
|
2022-12 |
CT#98e |
CP-223157 |
0215 |
1 |
F |
Clarification to UE handling on DSCP header field |
18.0.0 |
2022-12 |
CT#98e |
CP-223120 |
0216 |
1 |
B |
WLAN discovery and selection procedure in SNPN |
18.0.0 |
2022-12 |
CT#98e |
CP-223120 |
0217 |
2 |
B |
SNPN selection procedures for using trusted non-3GPP access |
18.0.0 |