Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.501  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   4.15…   5…   5.2…   5.3…   5.3.2…   5.3.7…   5.3.19…   5.4…   5.4.1.3…   5.4.2…   5.4.4…   5.4.5…   5.4.6…   5.5…   5.5.1.2.4   5.5.1.2.5…   5.5.1.3…   5.5.1.3.4   5.5.1.3.5…   5.5.2…   5.6…   5.6.2…   6…   6.1.4…   6.2…   6.3…   6.3.2…   6.3.3…   6.4…   6.4.1.4…   6.4.2…   6.5…   7…   8…   8.2.9…   8.3…   9…   9.11.2…   9.11.2.10…   9.11.3…   9.11.3.4…   9.11.3.8…   9.11.3.14…   9.11.3.18C…   9.11.3.29…   9.11.3.33…   9.11.3.39…   9.11.3.45…   9.11.3.50…   9.11.3.53A…   9.11.3.68…   9.11.3.75…   9.11.4…   9.11.4.10…   9.11.4.13…   9.11.4.16…   9.11.4.30…   9.12   10…   A…   B…   C…   D…   D.6…   D.6.3…

 

9.11.2  Common information elementsWord‑p. 650

9.11.2.1  Additional informationWord‑p. 650

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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.1.1: Additional information information element
Up
Additional information value (octet 3 to octet n)
The coding of the additional information value is dependent on the LCS application.
Up

9.11.2.1A  Access typeWord‑p. 650

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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.1A.1: Access type information element
Up
Access type value (octet 1, bit 1 to bit 2)
Bits
2 1
0 13GPP access
1 0Non-3GPP access
All other values are reserved.
Up

9.11.2.1B  DNN |R16|Word‑p. 651

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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.1B.1: DNN information element
Up
A DNN value field contains an APN as defined in TS 23.003.

9.11.2.2  EAP messageWord‑p. 651

The purpose of the EAP message information element is to transport an EAP message as specified in RFC 3748.
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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.2.1: EAP message information element
Up
EAP message (octet 4 to n)
An EAP message as specified in RFC 3748.
Up

9.11.2.3  GPRS timerWord‑p. 652

9.11.2.4  GPRS timer 2Word‑p. 652

9.11.2.5  GPRS timer 3Word‑p. 652

9.11.2.6  Intra N1 mode NAS transparent containerWord‑p. 652

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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.6.1: Intra N1 mode NAS transparent container information element
Up
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
0a new KAMF has not been calculated by the network
1a 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)
Up

9.11.2.7  N1 mode to S1 mode NAS transparent containerWord‑p. 653

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 TS 38.331. For these cases the coding of the information element identifier and length information is defined in TS 38.331.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.7.1: N1 mode to S1 mode NAS transparent container information element
Up
Sequence number (octet 2)
This field is coded as the Sequence number information element (see subclause 9.10).
Up

9.11.2.8  S-NSSAIWord‑p. 653

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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.8.1: S-NSSAI information element
Up
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 1SST
0 0 0 0 0 0 1 0SST and mapped HPLMN SST
0 0 0 0 0 1 0 0SST and SD
0 0 0 0 0 1 0 1SST, SD and mapped HPLMN SST
0 0 0 0 1 0 0 0SST, 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 TS 23.003. 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 TS 23.003. 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 TS 23.003.
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 TS 23.003.
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.
Up

9.11.2.9  S1 mode to N1 mode NAS transparent containerWord‑p. 655

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.
Reproduction of 3GPP TS 24.501, Figure 9.11.2.9.1: S1 mode to N1 mode NAS transparent container information element
Up
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 TS 33.501)
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.
Up

Up   Top   ToC