9 Parameters and coding

24.5023GPPAccess to the 3GPP 5G Core Network (5GCN) via non-3GPP access networksRelease 16TS

9.1 General

This subclause describes the encoding of the parameters which are exchanged between the UE and the network. This subclause is further divided into three subclauses; 3GPP specific coding information, IETF specific coding information and NAS message envelope.

The subclauses 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 subclause 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".

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

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
(in decimal)

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
(in decimal)

Descriptions

5G_QOS_INFO

55501

This status when present indicates 5G_QOS_INFO Notify payload encoded according to subclause 9.3.1.1

NAS_IP4_ADDRESS

55502

This status when present indicates NAS_IP4_ADDRESS Notify payload encoded according to subclause 9.3.1.2.

NAS_IP6_ADDRESS

55503

This status when present indicates NAS_IP6_ADDRESS Notify payload encoded according to subclause 9.3.1.3.

UP_IP4_ADDRESS

55504

This status when present indicates UP_IP4_ADDRESS Notify payload encoded according to subclause 9.3.1.4.

UP_IP6_ADDRESS

55505

This status when present indicates UP_IP6_ADDRESS Notify payload encoded according to subclause 9.3.1.5.

NAS_TCP_PORT

55506

This status when present indicates NAS_TCP_PORT Notify payload encoded according to subclause 9.3.1.6.

N3GPP_BACKOFF_TIMER

55507

This status when present indicates N3GPP_BACKOFF_TIMER Notify payload encoded according to subclause 9.3.1.7.

In the present specification, only the private notify message error 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. 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
0 0 0 0 0 0 0 1 QoS characteristics;
0 0 0 0 0 0 1 0 Maximum Flow Bit Rate downlink (MFBR downlink);
0 0 0 0 0 0 1 1 Maximum Flow Bit Rate uplink (MFBR uplink);
0 0 0 0 0 1 0 0 Guaranteed Flow Bit Rate downlink (GFBR downlink);
0 0 0 0 0 1 0 1 Guaranteed Flow Bit Rate uplink (GFBR uplink);
0 0 0 0 0 1 1 0 Notification Control;
0 0 0 0 0 1 1 1 Maximum Packet Loss Rate downlink; and
0 0 0 0 1 0 0 0 Maximum Packet Loss Rate uplink.
All other values are spare.

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
0 0 0 0 0 0 0 0 GBR
0 0 0 0 0 0 0 1 Delayed critical GBR
0 0 0 0 0 0 1 0 Non GBR
All other values are spare.

Octet 2 is the priority level with 1 as the highest priority and 127 as the lowest priority ((see subclause 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 0 0 0 0 0 0 1
thru

0 1 1 1 1 1 1 1
All other values are spare.

Octets 3 and 4 are the packet delay budget and is a factor of 0.5ms (see subclause 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 0 0 0 0 0 0 0 0 0 0
thru

0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1
All other values are spare.

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 subclause 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 0 0 0 0
thru

0 0 0 0 1 0 0 1
All other values are spare.

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 subclause 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 0 0 0 0 0 0 0 0 0 0 0 0
thru

0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
All other values are spare.

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 subclause 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 0 0 0 0 0 0 0 0 0 0 0 0
thru

0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
All other values are spare.

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
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 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 subclause 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 0 0 0 0 0 0 0 0 0 0
thru

0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0
All other values are spare.

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 subclause 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 0 0 0 0 0 0 0 0 0 0
thru

0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0
All other values are spare.

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] subclause 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] subclause 4.1 and use coding of the expanded method type as described in IETF RFC 3748 [9] subclause 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] subclause 4.1 and indicates request.

Identifier field is set as specified in IETF RFC 3748 [9] subclause 4.1.

Length field is set as specified in IETF RFC 3748 [9] subclause 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] subclause 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

Extensions

n+x+1 – z+x

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] subclause 4.1 and indicates response.

Identifier field is set as specified in IETF RFC 3748 [9] subclause 4.1.

Length field is set as specified in IETF RFC 3748 [9] subclause 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] subclause 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].

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.1-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); and

– 06H (UE identity).

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 subclause 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 subclause 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 subclause 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 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 subclause 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 subclause 9.2.7.

When the AN-parameter type field indicates the UE identity, the AN-parameter value field is coded according to 5GS mobile identity information element for type of identity 5G-GUTI or for type of identity SUCI as specified in subclause 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-1, figure 9.3.2.2.3-2, and figure 9.3.2.2.3-3 and table 9.3.2.2.3-1, table 9.3.2.2.3-2, and table 9.3.2.2.3-3.

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] subclause 4.1 and indicates request.

Identifier field is set as specified in IETF RFC 3748 [9] subclause 4.1.

Length field is set as specified in IETF RFC 3748 [9] subclause 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] subclause 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-Request/5G-Stop message

EAP-Request/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-Request/5G-Stop message

Table 9.3.2.2.4-1: EAP-Request/5G-Stop message

Code field is set to 1 (decimal) as specified in IETF RFC 3748 [9] subclause 4.1 and indicates request.

Identifier field is set as specified in IETF RFC 3748 [9] subclause 4.1.

Length field is set as specified in IETF RFC 3748 [9] subclause 4.1 and indicates the length of the EAP-Request/5G-Stop message in octets.

Type field is set to 254 (decimal) as specified in IETF RFC 3748 [9] subclause 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] subclause 4.1 and indicates request.

Identifier field is set as specified in IETF RFC 3748 [9] subclause 4.1.

Length field is set as specified in IETF RFC 3748 [9] subclause 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] subclause 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 subclause 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 subclause 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] subclause 4.1 and indicates response.

Identifier field is set as specified in IETF RFC 3748 [9] subclause 4.1.

Length field is set as specified in IETF RFC 3748 [9] subclause 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] subclause 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 subclause

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 subclause 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 subclause

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-12

CT-90e

CP-203177

0154

F

Clarification on NAI provided by N5CW device

16.6.0

2020-12

CT-90e

CP-203177

0156

1

F

Resolve editor notes on trusted access selection

16.6.0

2020-12

CT-90e

CP-203177

0160

F

Resolution of the editor’s notes on the procedure for determining whether it is mandatory to select a PLMN in the visited country

16.6.0

2020-12

CT-90e

CP-203177

0172

F

Correction to trusted connectivity

16.6.0

2020-12

CT-90e

CP-203177

0174

1

F

Correction to procedures for non 5G capable over WLAN (N5CW) devices

16.6.0

2021-03

CT-91e

CP-210114

0180

2

F

SNPN access operation mode

16.7.0

2021-03

CT-91e

CP-210114

0182

1

F

Update of N3IWF selection procedure for access to SNPN services via a PLMN

16.7.0

2021-06

CT-92e

CP-211130

0184

3

F

Correct N3AN node selection due to permitted home routing

16.8.0

2022-06

CT-96

CP-221199

0204

1

F

Correcting NAS transport between 5G RG and W-AGF to accommodate latest BBF developments

16.9.0