9.11.2 Common information elements
24.5013GPPNon-Access-Stratum (NAS) protocol for 5G System (5GS)Release 18Stage 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 |
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 |
|
|
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 |
|
|
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 subscribed SNPN 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 |
|
|
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 |
|
|
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 information element 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 |
|||||||||
|
Value of service-level-AA parameter |
octet xi +4 octet n |
|||||||||
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])
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) |
|
B- |
Service-level-AA service status indication |
Service-level-AA service status indication (see subclause 9.11.2.18) |
|
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 information element 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. |
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 information element 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 19.4.2.1 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 information element is a type 6 information element with minimum length of 4 octets and maximum length of 65538 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 information element is a type 4 information element with 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 |
C2AR |
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 field (SLAR) (octet 3, bits 1 and 2) |
|||
|
Bits |
|||
|
1 |
2 |
||
|
0 |
0 |
No information |
|
|
0 |
1 |
Service level authentication and authorization was successful. |
|
|
1 |
0 |
Service level authentication and authorization was not successful or service level authorization is revoked. |
|
|
1 |
1 |
Reserved |
|
|
C2 authorization result field (C2AR) (octet 3, bits 3 and 4) |
|||
|
Bits |
|||
|
3 |
4 |
||
|
0 |
0 |
No information |
|
|
0 |
1 |
C2 authorization was successful. |
|
|
1 |
0 |
C2 authorization was not successful or C2 authorization is revoked. |
|
|
1 |
1 |
Reserved |
|
|
Bits 5 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 information element is a type 4 information element with 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 (see NOTE 1) |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
C2 authorization payload (see NOTE 2) |
|
|
All other values are spare, and the receiving entity shall ignore the service-level-AA payload type value set to a spare value. |
|||||||||
|
NOTE 1: If the service-level-AA payload type indicates UUAA payload, the field for the service-level-AA payload of the Service-level AA payload information element is an application layer payload for UUAA procedure between the UE supporting UAS services and the USS. NOTE 2: If the service-level-AA payload type indicates C2 authorization payload, the field for the service-level-AA payload of the Service-level-AA payload information element is an application layer payload for C2 authorization procedure between the UE supporting UAS services and the USS. |
|||||||||
9.11.2.16 Void
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 information element 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 |
|
9.11.2.18 Service-level-AA service status indication
The purpose of the Service-level-AA service status indication information element is to provide an indication of the service availability to the UE.
The Service-level-AA service status indication information element is coded as shown in figure 9.11.2.18.1 and table 9.11.2.18.1.
The Service-level-AA service status indication information element is a type 4 information element with a length of 3 octets.
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||||||||||
|
Service-level-AA service status indication IEI |
octet 1 |
||||||||||||||||||
|
Length of Service-level-AA service status indication |
octet 2 |
||||||||||||||||||
|
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
UAS |
octet 3 |
||||||||||
Figure 9.11.2.18.1: Service-level-AA-service-status indication information element
Table 9.11.2.18.1: Service-level-AA-service-status indication information element
|
UAS (octet 3, bit 1) |
||
|
Bit |
||
|
1 |
||
|
0 |
UAS services not enabled |
|
|
1 |
UAS services enabled |
|
|
Bits 2 to 8 of octet 3 are spare and shall be encoded as zero. |
||