9.11.2 Common information elements

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

9.11.2.1 Additional information

The purpose of the Additional information information element is to provide additional information to upper layers in relation to the NAS transport mechanism.

The Additional information information element is coded as shown in figure 9.11.2.1.1 and table 9.11.2.1.1.

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

8

7

6

5

4

3

2

1

Additional information IEI

octet 1

Additional information length

octet 2

Additional information value

octets 3-n

Figure 9.11.2.1.1: Additional information information element

Table 9.11.2.1.1 : Additional information information element

Additional information value (octet 3 to octet n)

The coding of the additional information value is dependent on the LCS application.

9.11.2.1A Access type

The purpose of the access type information element is to indicate the access type over which the signalling or user data is pending to be sent to the UE.

The access type is a type 1 information element.

The access type information element is coded as shown in figure 9.11.2.1A.1 and table 9.11.2.1A.1.

8

7

6

5

4

3

2

1

Access type

IEI

0

spare

Access type

octet 1

Figure 9.11.2.1A.1: Access type information element

Table 9.11.2.1A.1: Access type information element

Access type value (octet 1, bit 1 to bit 2)

Bits

2

1

0

1

3GPP access

1

0

Non-3GPP access

All other values are reserved.

9.11.2.1B DNN

The purpose of the DNN information element is to identify the data network.

The DNN information element is coded as shown in figure 9.11.2.1B.1.

The DNN is a type 4 information element with a minimum length of 3 octets and a maximum length of 102 octets.

8

7

6

5

4

3

2

1

DNN IEI

octet 1

Length of DNN contents

octet 2

DNN value

octet 3

octet n

Figure 9.11.2.1B.1: DNN information element

A DNN value field contains an APN as defined in 3GPP TS 23.003 [4].

9.11.2.2 EAP message

The purpose of the EAP message information element is to transport an EAP message as specified in IETF RFC 3748 [34].

The EAP message information element is coded as shown in figure 9.11.2.2.1 and table 9.11.2.2.1.

The EAP message is a type 6 information element with minimum length of 7 octets and maximum length of 1503 octets.

8

7

6

5

4

3

2

1

EAP message IEI

octet 1

Length of EAP message contents

octet 2

octet 3

EAP message

octet 4

octet n

Figure 9.11.2.2.1: EAP message information element

Table 9.11.2.2.1: EAP message information element

EAP message (octet 4 to n)

An EAP message as specified in IETF RFC 3748 [34].

9.11.2.3 GPRS timer

See subclause 10.5.7.3 in 3GPP TS 24.008 [12].

9.11.2.4 GPRS timer 2

See subclause 10.5.7.4 in 3GPP TS 24.008 [12].

9.11.2.5 GPRS timer 3

See subclause 10.5.7.4a in 3GPP TS 24.008 [12].

9.11.2.6 Intra N1 mode NAS transparent container

The purpose of the Intra N1 mode NAS transparent container information element is to provide the UE with parameters that enable the UE to handle the 5G NAS security context after N1 mode to N1 mode handover.

The Intra N1 mode NAS transparent container information element is coded as shown in figure 9.11.2.6.1 and table 9.11.2.6.1.

The Intra N1 mode NAS transparent container is a type 4 information element with a length of 9 octets.

The value part of the Intra N1 mode NAS transparent container information element is included in specific information elements within some RRC messages sent to the UE.

NOTE: For these cases the coding of the information element identifier and length information of RRC is defined in 3GPP TS 38.331 [30].

8

7

6

5

4

3

2

1

Intra N1 mode NAS transparent container IEI

octet 1

Length of Intra N1 mode NAS transparent container contents

octet 2

Message authentication code

octet 3

octet 6

Type of ciphering algorithm

Type of integrity protection algorithm

octet 7

0

0
Spare

0

KACF

TSC

Key set identifier in 5G

octet 8

Sequence number

octet 9

Figure 9.11.2.6.1: Intra N1 mode NAS transparent container information element

Table 9.11.2.6.1: Intra N1 mode NAS transparent container information element

Message authentication code (octet 3 to 6)

This field is coded as the Message authentication code information element (see subclause 9.8).

Type of integrity protection algorithm (octet 7, bit 1 to 4) and
type of ciphering algorithm (octet 7, bit 5 to 8)

These fields are coded as the type of integrity protection algorithm and type of ciphering algorithm in the NAS security algorithms information element (see subclause 9.11.3.34).

K_AMF_change_flag (KACF) (octet 8, bit 5)

Bit

5

0

a new KAMF has not been calculated by the network

1

a new KAMF has been calculated by the network

Key set identifier in 5G (octet 8, bit 1 to 3) and
Type of security context flag (TSC) (octet 8, bit 4)

These fields are coded as the NAS key set identifier and type of security context flag in the NAS key set identifier information element (see subclause 9.11.3.32).

Sequence number (octet 9)

This field is coded as the Sequence number information element (see subclause 9.10)

9.11.2.7 N1 mode to S1 mode NAS transparent container

The purpose of the N1 mode to S1 mode NAS transparent container information element is to provide the UE with information that enables the UE to create a mapped EPS security context.

The N1 mode to S1 mode NAS transparent container information element is coded as shown in figure 9.11.2.7.1 and table 9.11.2.7.1.

The N1 mode to S1 mode NAS transparent container is a type 3 information element with a length of 2 octets.

The value part of the N1 mode to S1 mode NAS transparent container information element is included in specific information elements within some RRC messages sent to the UE; see 3GPP TS 38.331 [30]. For these cases the coding of the information element identifier and length information is defined in 3GPP TS 38.331 [30].

8

7

6

5

4

3

2

1

N1 mode to S1 mode NAS transparent container IEI

octet 1

Sequence number

octet 2

Figure 9.11.2.7.1: N1 mode to S1 mode NAS transparent container information element

Table 9.11.2.7.1: N1 mode to S1 mode NAS transparent container information element

Sequence number (octet 2)

This field is coded as the Sequence number information element (see subclause 9.10).

9.11.2.8 S-NSSAI

The purpose of the S-NSSAI information element is to identify a network slice.

The S-NSSAI information element is coded as shown in figure 9.11.2.8.1 and table 9.11.2.8.1.

The S-NSSAI is a type 4 information element with a minimum length of 3 octets and a maximum length of 10 octets.

8

7

6

5

4

3

2

1

S-NSSAI IEI

octet 1

Length of S-NSSAI contents

octet 2

SST

octet 3

SD

octet 4*

octet 6*

Mapped HPLMN SST

octet 7*

Mapped HPLMN SD

octet 8*

octet 10*

Figure 9.11.2.8.1: S-NSSAI information element

Table 9.11.2.8.1: S-NSSAI information element

Length of S-NSSAI contents (octet 2)

This field indicates the length of the included S-NSSAI contents, and it can have the following values. Depending on the value of the length field the following S-NSSAI contents are included:

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

1

SST

0

0

0

0

0

0

1

0

SST and mapped HPLMN SST

0

0

0

0

0

1

0

0

SST and SD

0

0

0

0

0

1

0

1

SST, SD and mapped HPLMN SST

0

0

0

0

1

0

0

0

SST, SD, mapped HPLMN SST and mapped HPLMN SD

All other values are reserved.

Slice/service type (SST) (octet 3)

This field contains the 8 bit SST value. The coding of the SST value part is defined in 3GPP TS 23.003 [4]. If this IE is included during the network slice-specific authentication and authorization procedure, this field contains the 8 bit SST value of an S-NSSAI in the S-NSSAI(s) of the HPLMN or the RSNPN.

Slice differentiator (SD) (octet 4 to octet 6)

This field contains the 24 bit SD value. The coding of the SD value part is defined in 3GPP TS 23.003 [4]. If this IE is included during the network slice-specific authentication and authorization procedure, this field contains the 24 bit SD value of an S-NSSAI in the S-NSSAI(s) of the HPLMN or the RSNPN.

If the SST encoded in octet 3 is not associated with a valid SD value, and the sender needs to include a mapped HPLMN SST (octet 7) and a mapped HPLMN SD (octets 8 to 10), then the sender shall set the SD value (octets 4 to 6) to "no SD value associated with the SST".

mapped HPLMN Slice/service type (SST) (octet 7)

This field contains the 8 bit SST value of an S-NSSAI in the S-NSSAI(s) of the HPLMN to which the SST value is mapped. The coding of the SST value part is defined in 3GPP TS 23.003 [4].

mapped HPLMN Slice differentiator (SD) (octet 8 to octet 10)

This field contains the 24 bit SD value of an S-NSSAI in the S-NSSAI(s) of the HPLMN to which the SD value is mapped. The coding of the SD value part is defined in 3GPP TS 23.003 [4].

NOTE 1: Octet 3 shall always be included.

NOTE 2: If the octet 4 is included, then octet 5 and octet 6 shall be included.

NOTE 3: If the octet 7 is included, then octets 8, 9, and 10 may be included.

NOTE 4: If the octet 8 is included, then octet 9 and octet 10 shall be included.

NOTE 5: If only HPLMN S-NSSAI or RSNPN S-NSSAI is included, then octets 7 to 10 shall not be included.

9.11.2.9 S1 mode to N1 mode NAS transparent container

The purpose of the S1 mode to N1 mode NAS transparent container information element is to provide the UE with parameters that enable the UE to create a mapped 5G NAS security context and take this context into use after inter-system change to N1 mode in 5GMM-CONNECTED mode.

The S1 mode to N1 mode NAS transparent container information element is coded as shown in figure 9.11.2.9.1 and table 9.11.2.9.1.

The S1 mode to N1 mode NAS transparent container is a type 4 information element with a length of 10 octets.

The value part of the S1 mode to N1 mode NAS transparent container information element is included in specific information elements within some RRC messages sent to the UE.

NOTE: For these cases the coding of the information element identifier and length information of RRC is defined in 3GPP TS 38.331 [30].

8

7

6

5

4

3

2

1

S1 mode to N1 mode NAS transparent container IEI

octet 1

Length of S1 mode to N1 mode NAS transparent container contents

octet 2

Message authentication code

octet 3

octet 6

Type of ciphering algorithm

Type of integrity protection algorithm

octet 7

0

Spare

NCC

TSC

Key set identifier in 5G

octet 8

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

octet 9

octet 10

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

Figure 9.11.2.9.1: S1 mode to N1 mode NAS transparent container information element

Table 9.11.2.9.1: S1 mode to N1 mode NAS transparent container information element

Message authentication code (octet 3 to 6)

This field is coded as the Message authentication code information element (see subclause 9.8).

Type of integrity protection algorithm (octet 7, bit 1 to 4) and
type of ciphering algorithm (octet 7, bit 5 to 8)

These fields are coded as the type of integrity protection algorithm and type of ciphering algorithm in the NAS security algorithms information element (see subclause 9.11.3.34).

NCC (octet 8, bits 5 to 7)

This field contains the 3 bit Next hop chaining counter (see 3GPP TS 33.501 [24])

Key set identifier in 5G (octet 8, bit 1 to 3) and
type of security context flag (TSC) (octet 8, bit 4)

These fields are coded as the NAS key set identifier and type of security context flag in the NAS key set identifier information element (see subclause 9.11.3.32).

Octets 9 and 10 are spare and shall be coded as zero.

NOTE: In earlier versions of this protocol, octets 9 and 10 can have any value. In this version of the protocol, octets 9 and 10 can always be ignored by the UE.

9.11.2.10 Service-level-AA container

The purpose of the Service-level-AA container information element is to transfer upper layer information for authentication and authorization between the UE and the network.

The Service-level-AA container information element is coded as shown in figure 9.11.2.10.1, figure 9.11.2.10.2, figure 9.11.2.10.3, figure 9.11.2.10.4 and table 9.11.2.10.1.

The Service-level-AA container is a type 6 information element with a minimum length of 6 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

Service-level-AA container IEI

octet 1

Length of Service-level-AA container contents

octet 2

octet 3

octet 4

Service-level-AA container contents

octet n

Figure 9.11.2.10.1: Service-level-AA container information element

8

7

6

5

4

3

2

1

Service-level-AA parameter 1

octet 4

octet x1

Service-level-AA parameter 2

octet x1+1*

octet x2*

……

Service-level-AA parameter n

octet xi +1*

octet n*

Figure 9.11.2.10.2: Service-level-AA container contents

8

7

6

5

4

3

2

1

Type of service-level-AA parameter

octet xi +1

Length of service-level-AA parameter

octet xi +2

Value of service-level-AA parameter

octet xi +3

octet n

Figure 9.11.2.10.3: Service-level-AA parameter (when the type of service-level-AA parameter field contains an IEI of a type 4 information element as specified in 3GPP TS 24.007 [11])

8

7

6

5

4

3

2

1

Type of service-level-AA parameter

octet xi +1

Length of service-level-AA parameter

octet xi +2

octet xi +3

Figure 9.11.2.10.4: Service-level-AA parameter (when the type of service-level-AA parameter field contains an IEI of a type 6 information element as specified in 3GPP TS 24.007 [11])

8

7

6

5

4

3

2

1

Service-level-AA payload type

octet xi +1

octet xi +3

Service-level-AA payload

octet xi +4

octet n

Figure 9.11.2.10.5: Service-level-AA parameter (when Service-level-AA payload type and its associated Service-level-AA payload are included in the Service-level-AA container contents)

8

7

6

5

4

3

2

1

Type of service-level-AA parameter

Value of service-level-AA parameter

octet xi+1

Figure 9.11.2.10.6: Service-level-AA parameter (when the type of service-level-AA parameter field contains an IEI of a type 1 information element as specified in 3GPP TS 24.007 [11])

Editor’s note: Format of Service-level-AA parameter with Type of service-level-AA parameter set to a value between 0x80 and 0xFF is FFS.

Table 9.11.2.10.1: Service-level-AA container information element

Service-level-AA container contents (octet 4 to octet n); max value of 65535 octets

The error handlings for service-level-AA parameters specified in subclauses 7.6.1, 7.6.3 and 7.7.1 shall apply to the service-level-AA parameters included in the Service-level-AA container contents.

Service-level-AA parameters

Type of service-level-AA parameter (octet xi +1)

This field contains the IEI of the service-level-AA parameter.

Length of service-level-AA parameter

This field indicates binary coded length of the value of the service-level-AA parameter.

Value of service-level-AA parameter

This field contains the value of the service-level-AA parameter with the value part of the referred information element based on following service-level-AA parameter reference.

The receiving entity shall ignore service-level-AA parameter with type of service-level-AA parameter field containing an unknown IEI.

IEI (hexadecimal)

Service-level-AA parameter name

Service-level-AA parameter reference

10

Service-level device ID

Service-level device ID (see subclause 9.11.2.11)

20

Service-level-AA server address

Service-level-AA server address (see subclause 9.11.2.12)

30

Service-level-AA response

Service-level-AA response (see subclause 9.11.2.14)

40

Service-level-AA payload type

Service-level-AA payload type (see subclause 9.11.2.15) (NOTE)

70

Service-level-AA payload

Service-level-AA payload (see subclause 9.11.2.13)

A-

Service-level-AA pending indication

Service-level-AA pending indication (see subclause 9.11.2.17)

NOTE: A Service-level-AA payload type is always followed by the associated Service-level-AA payload as shown in figure 9.11.2.10.5.

9.11.2.11 Service-level device ID

The purpose of the Service-level device ID information element is to carry the necessary identity for authentication and authorization by the external DN.

The Service-level device ID information element is coded as shown in figure 9.11.2.11.1 and table 9.11.2.11.1.

The Service-level device ID is a type 4 information element with minimum length of 3 octets and maximum length of 257 octets.

8

7

6

5

4

3

2

1

Service-level device ID IEI

octet 1

Service-level device ID length

octet 2

Service-level device ID

octets 3-y

Figure 9.11.2.11.1: Service-level device ID information element

Table 9.11.2.11.1: Service-level device ID information element

Service-level device ID (octet 3 to octet y)

A Service-level device ID encoded as UTF-8 string.

Editor’s note (ID_UAS, CR#3103): It is FFS what formats of Service-level device ID need to be supported, and if it is to be defined in 3GPP TS 23.003 [4] under the responsibility of CT4.

9.11.2.12 Service-level-AA server address

The purpose of the Service-level-AA server address information element is to carry the address of the service level authentication and authorization server.

The Service-level-AA server address information element is coded as shown in figure 9.11.2.12.1 and table 9.11.2.12.1.

The Service-level-AA server address is a type 4 information element with minimum length of 4 octets and maximum length of 258 octets.

8

7

6

5

4

3

2

1

Service-level-AA server address IEI

octet 1

Service-level-AA server address length

octet 2

Service-level-AA server address type

octet 3

Service-level-AA server address

octets 4-z

Figure 9.11.2.12.1: Service-level-AA server address information element

Table 9.11.2.12.1: Service-level-AA server address information element

Service-level-AA server address type (octet 3):

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

1

IPv4

0

0

0

0

0

0

1

0

IPv6

0

0

0

0

0

0

1

1

IPv4v6

0

0

0

0

0

1

0

0

FQDN

All other values are spare.

If the Service-level-AA server address type indicates IPv4, then the Service-level-AA server address field contains an IPv4 address in octet 4 to octet 7.

If the Service-level-AA server address type indicates IPv6, then the Service-level-AA server address field contains an IPv6 address in octet 4 to octet 19.

If the Service-level-AA server address type indicates IPv4v6, then the Service-level-AA server address field contains two IP addresses. The first IP address is an IPv4 address in octet 4 to octet 7. The second IP address is an IPv6 address in octet 8 to octet 23.

If the Service-level-AA server address type indicates FQDN, octet 4 to octet z is encoded as defined in subclause 28.3.2.2.2 in 3GPP TS 23.003 [4].

9.11.2.13 Service-level-AA payload

The purpose of the Service-level-AA payload information element is to carry the upper layer payload for authentication and authorization between the UE and the service-level-AA server.

The Service-level-AA payload information element is coded as shown in figure 9.11.2.13.1 and table 9.11.2.13.1.

The Service-level-AA payload is a type 6 information element with minimum length of 4 octets and maximum length of 65535 octets.

8

7

6

5

4

3

2

1

Service-level-AA payload IEI

octet 1

Service-level-AA payload length

octet 2

octet 3

Service-level-AA payload

octets 4-s

Figure 9.11.2.13.1: Service-level-AA payload information element

Table 9.11.2.13.1: Service-level-AA payload information element

Service-level-AA payload (octet 4 to octet s)

A payload for authentication and authorization transparently transported and which is provided from/to the upper layers.

9.11.2.14 Service-level-AA response

The purpose of the Service-level-AA response information element is to provide information regarding the service level authentication and authorization request, e.g. to indicate that the authentication and authorization request to the service level authentication server was successful, or to notify that service level authorization is revoked.

The Service-level-AA response information element is coded as shown in figure 9.11.2.14.1 and table 9.11.2.14.1.

The Service-level-AA response is a type 4 information element with minimum length of 3 octets.

8

7

6

5

4

3

2

1

Service-level-AA response IEI

octet 1

Service-level-AA response length

octet 2

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

0

Spare

SLAR

octet 3

Figure 9.11.2.14.1: Service-level-AA response information element

Table 9.11.2.14.1: Service-level-AA response information element

Service-level-AA result bit (SLAR) (octet 3, bit 1)

Bit

1

0

Service level authentication and authorization was successful

1

Service level authentication and authorization was not successful or service level authorization is revoked

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

9.11.2.15 Service-level-AA payload type

The purpose of the Service-level-AA payload type information element is to indicates type of payload included in the Service-level-AA payload information element.

The Service-level-AA payload type information element is coded as shown in figure 9.11.2.15.1 and table 9.11.2.15.1.

The Service-level-AA payload type is a type 4 information element with minimum length of 3 octets.

8

7

6

5

4

3

2

1

Service-level-AA payload type IEI

octet 1

Service-level-AA payload type length

octet 2

Service-level-AA payload type

octet 3

Figure 9.11.2.15.1: Service-level-AA payload type information element

Table 9.11.2.15.1: Service-level-AA payload type information element

Service-level-AA payload type (octet 3):

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

1

UUAA payload

0

0

0

0

0

0

1

0

C2 authorization payload

All other values are reserved.

9.11.2.16 C2 authorization payload

The purpose of the C2 authorization payload information element is to exchange the information regarding C2 pairing authorization and flight authorization, between the UAV and the USS.

The C2 authorization payload information element is coded as shown in figure 9.11.2.16.1, figure 9.11.2.16.2, figure 9.11.2.16.3 and table 9.11.2.16.1.

The C2 authorization payload is a type 6 information element with a minimum length of 6 octets and a maximum length of 65538 octets.

8

7

6

5

4

3

2

1

C2 authorization payload IEI

octet 1

Length of C2 authorization payload contents

octet 2

octet 3

octet 4

C2 authorization payload contents

octet n

Figure 9.11.2.16.1: C2 authorization payload information element

8

7

6

5

4

3

2

1

C2 authorization payload parameter 1

octet 4

octet x1

C2 authorization payload parameter 2

octet x1+1*

octet x2*

……

C2 authorization payload parameter n

octet xi +1*

octet n*

Figure 9.11.2.16.2: C2 authorization payload contents

8

7

6

5

4

3

2

1

Type of C2 authorization payload parameter

octet xi +1

Length of C2 authorization payload parameter

octet xi +2

octet xi +3

Value of C2 authorization payload parameter

octet xi +4

octet n

Figure 9.11.2.16.3: C2 authorization payload parameter is a type 4 information element

Table 9.11.2.16.1: C2 authorization payload information element

C2 authorization payload (octet 4 to octet n); max value of 65535 octets

Type of C2 authorization payload parameter (octet xi +1):

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

1

UAV-C pairing information

0

0

0

0

0

0

1

0

Flight authorization information

0

0

0

0

0

0

1

1

C2 authorization result

0

0

0

0

0

1

0

0

C2 session security information

All other values are spare.

The receiving entity shall ignore C2 authorization payload parameter with type of C2 authorization payload parameter field containing an unknown IEI.

If the type of C2 authorization payload parameter indicates UAV-C pairing information, then the field for the value of C2 authorization payload parameter contains identification information of UAV-C to pair. The format of the UAV-C pairing information is out of the scope of 3GPP.

If the type C2 authorization payload parameter indicates flight authorization information, then the field for the value of C2 authorization payload parameter contains UAV flight authorization information. The format of the flight authorization information is out of the scope of 3GPP.

If the type of the C2 authorization payload parameter indicates C2 authorization result, then the field of the value of C2 authorization payload parameter contains:

Bits

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

0

C2 authorization failed

0

0

0

0

0

0

0

1

C2 authorization succeeded

All other values are spare.

The UAV shall consider any other value for C2 authorization result field as a failure for C2 authorization.

If the type of the C2 authorization payload parameter indicates C2 session security information, then the field of the value of C2 authorization payload parameter contains information for secure communications with the USS, The format of the C2 session security information is out of the scope of 3GPP.

9.11.2.17 Service-level-AA pending indication

The purpose of the Service-level-AA pending indication information element is to provide an indication that the service level authentication and authorization procedure is to be performed.

The Service-level-AA pending indication information element is coded as shown in figure 9.11.2.17.1 and table 9.11.2.17.1.

The Service-level-AA pending indication is a type 1 information element.

8

7

6

5

4

3

2

1

Service-level-AA pending indication IEI

0

Spare

0

Spare

0

Spare

SLAPI

octet 1

Figure 9.11.2.17.1: Service-level-AA pending indication

Table 9.11.2.17.1: Service-level-AA pending indication

Service-level-AA pending indication (SLAPI) (octet 1, bit 1)

Bit

1

0

reserved

1

Service-level-AA procedure is to be performed