Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.501  Word version:  18.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…   D.6.8   D.7… 
9.11.3.8 5GS tracking area identity  9.11.3.9 5GS tracking area identity list  9.11.3.9A 5GS update type  9.11.3.10 ABBA  9.11.3.12 Additional 5G security information  9.11.3.12A Additional information requested  9.11.3.13 Allowed PDU session status 
...

 

9.11.3.8  5GS tracking area identity  p. 862

The purpose of the 5GS tracking area identity information element is to provide an unambiguous identification of tracking areas within the area covered by the 5GS.
The 5GS tracking area identity information element is coded as shown in Figure 9.11.3.8.1 and Table 9.11.3.8.1.
The 5GS tracking area identity is a type 3 information element with a length of 7 octets.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.8.1: 5GS tracking area identity information element
Figure 9.11.3.8.1: 5GS tracking area identity information element
Up
MCC, Mobile country code (octets 2 and 3)
The MCC field is coded as in ITU-T Recommendation E212 [42], Annex A.
If the TAI is deleted the MCC and MNC shall take the value from the deleted TAI.
In abnormal cases, the MCC stored in the UE can contain elements not in the set {0, 1 ... 9}. In such cases the UE should transmit the stored values using full hexadecimal encoding. When receiving such an MCC, the network shall treat the TAI as deleted.
MNC, Mobile network code (octet 3 bits 5 to 8, octet 4)
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. For PCS 1900 for NA, Federal regulation mandates that a 3-digit MNC shall be used. However, a network operator may decide to use only two digits in the MNC in the TAI over the radio interface. In this case, bits 5 to 8 of octet 3 shall be coded as "1111". Mobile equipment shall accept a TAI coded in such a way.
In abnormal cases, the MNC stored in the UE can have:
  • digit 1 or 2 not in the set {0, 1 ... 9}, or
  • digit 3 not in the set {0, 1 ... 9, F} hex.
In such cases the UE shall transmit the stored values using full hexadecimal encoding. When receiving such an MNC, the network shall treat the TAI as deleted.
The same handling shall apply for the network, if a 3-digit MNC is sent by the UE to a network using only a 2-digit MNC.
TAC, Tracking area code (octets 5 to 7)
In the TAC field bit 8 of octet 5 is the most significant bit and bit 1 of octet 7 the least significant bit.
The coding of the tracking area code is the responsibility of each administration except that two values are used to mark the TAC, and hence the TAI, as deleted. Coding using full hexadecimal representation may be used. The tracking area code consists of 3 octets.
If a TAI has to be deleted, then all bits of the tracking area code shall be set to one with the exception of the least significant bit which shall be set to zero. If a USIM is inserted in a mobile equipment with the tracking area code containing all zeros, then the mobile equipment shall recognise this TAC as part of a deleted TAI.
Up

9.11.3.9  5GS tracking area identity list  p. 863

The purpose of the 5GS tracking area identity list information element is to transfer a list of tracking areas from the network to the UE.
The coding of the information element allows combining different types of lists. The lists of type "00" and "01" allow a more compact encoding, when the different TAIs are sharing the PLMN identity.
The 5GS tracking area identity list information element is coded as shown in Figure 9.11.3.9.1, Figure 9.11.3.9.2, Figure 9.11.3.9.3, Figure 9.11.3.9.4 and Table 9.11.3.9.1.
The 5GS tracking area identity list is a type 4 information element, with a minimum length of 9 octets and a maximum length of 114 octets. The list can contain a maximum of 16 different tracking area identities.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.9.1: 5GS tracking area identity list information element
Figure 9.11.3.9.1: 5GS tracking area identity list information element
Up
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.9.2: Partial tracking area identity list - type of list =
Figure 9.11.3.9.2: Partial tracking area identity list - type of list = "00"
Up
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.9.3: Partial tracking area identity list - type of list =
Figure 9.11.3.9.3: Partial tracking area identity list - type of list = "01"
Up
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.9.4: Partial tracking area identity list - type of list =
Figure 9.11.3.9.4: Partial tracking area identity list - type of list = "10"
Up
Value part of the Tracking area identity list information element (octets 3 to n)
The value part of the Tracking area identity list information element consists of one or several partial tracking area identity lists. The length of each partial tracking area identity list can be determined from the 'type of list' field and the 'number of elements' field in the first octet of the partial tracking area identity list.
The UE shall store the complete list received. If more than 16 TAIs are included in this information element, the UE shall store the first 16 TAIs and ignore the remaining octets of the information element.
Partial tracking area identity list:
Type of list (octet 1)
Bits
7 6
0 0list of TACs belonging to one PLMN or SNPN, with non-consecutive TAC values
0 1list of TACs belonging to one PLMN or SNPN, with consecutive TAC values
1 0list of TAIs belonging to different PLMNs (see NOTE)
All other values are reserved.
Number of elements (octet 1)
Bits
5 4 3 2 1
0 0 0 0 01 element
0 0 0 0 12 elements
0 0 0 1 03 elements
…
0 1 1 0 114 elements
0 1 1 1 015 elements
0 1 1 1 116 elements
All other values are unused and shall be interpreted as 16, if received by the UE.
Bit 8 of octet 1 is spare and shall be coded as zero.
For type of list = "00" and number of elements = k:
octet 2 to 4 contain the MCC+MNC, and
for j = 1, …, k:
octets 3j+2 to 3j+4 contain the TAC of the j-th TAI belonging to the partial list,
For type of list = "01" and number of elements = k:
octet 2 to 4 contain the MCC+MNC, and
octets 5 to 7 contain the TAC of the first TAI belonging to the partial list.
The TAC values of the other k-1 TAIs are TAC+1, TAC+2, …, TAC+k-1.
For type of list = "10" and number of elements = k:
for j = 1, …, k.
octets 6j-4 to 6j-2 contain the MCC+MNC, and
octets 6j-1 to 6j+1 contain the TAC of the j-th TAI belonging to the partial list.
MCC, Mobile country code
The MCC field is coded as in ITU-T Recommendation E.212 [42], Annex A.
MNC, Mobile network code
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, MNC digit 3 shall be coded as "1111".
TAC, Tracking area code
In the TAC field bit 8 of the first octet is the most significant bit and bit 1 of third octet the least significant bit.
The coding of the tracking area code is the responsibility of each administration. Coding using full hexadecimal representation may be used. The tracking area code consists of 3 octets.
NOTE:
If the "list of TAIs belonging to different PLMNs" is used, the PLMNs included in the list need to be present in the list of "equivalent PLMNs". This type of list is not applicable in an SNPN.
Up

9.11.3.9A  5GS update type  p. 868

The purpose of the 5GS update type IE is to allow the UE to provide additional information to the network when performing a registration procedure.
The 5GS update type information element is coded as shown in Figure 9.11.3.9A.1 and Table 9.11.3.9A.1.
The 5GS update type is a type 4 information element with a length of 3 octets.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.9A.1: 5GS update type information element
Figure 9.11.3.9A.1: 5GS update type information element
Up
SMS over NAS transport requested (SMS requested) (octet 3, bit 1)
0SMS over NAS not supported
1SMS over NAS supported
NG-RAN Radio Capability Update (NG-RAN-RCU) (octet 3, bit 2)
0UE radio capability update not needed
1UE radio capability update needed
For a list of RATs for which a radio capability update can be triggered by means of this indication see subclause 5.5.1.3.2, case n).
5GS Preferred CIoT network behaviour (5GS PNB-CIoT) (octet 3, bits 3 and 4)
Bits
4 3
0 0no additional information
0 1control plane CIoT 5GS optimization
1 0user plane CIoT 5GS optimization
1 1reserved
EPS Preferred CIoT network behaviour (EPS-PNB-CIoT) (octet 3, bits 5 and 6)
Bits
6 5
0 0no additional information
0 1control plane CIoT EPS optimization
1 0user plane CIoT EPS optimization
1 1reserved
Coverage loss indication (CLI) (octet 3, bit 7)
0No coverage loss indication
1Coverage loss due to discontinuous coverage
Bits 7 to 8 of octet 3 are spare and shall be coded as zero.
Up

9.11.3.10  ABBA  p. 869

The purpose of the ABBA information element is to enable the bidding down protection of security features.
The ABBA information element is coded as shown in Figure 9.11.3.10.1 and Table 9.11.3.10.1.
The ABBA is a type 4 information element with a minimum length of 4 octets and maximum length of 257 octets.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.10.1: ABBA information element
Figure 9.11.3.10.1: ABBA information element
Up
ABBA contents (octet 3-n):
indicate set of security features defined for 5GS as described in TS 33.501.
NOTE 1:
If the UE receives the ABBA IE with a length that is set to a value of 2 and with a value of 0000H, the UE shall use the length and the contents of the ABBA IE as received from the network.
NOTE 2:
If the UE receives the ABBA IE with a length that is set to a value larger than 2 or with a value that is different from 0000H, the UE shall use the length and the contents of the ABBA IE as received from the network.
Up

9.11.3.11  Void

9.11.3.12  Additional 5G security information  p. 870

The purpose of the Additional 5G security information information element is to provide the UE with additional security parameters (e.g. horizontal derivation parameter) or to request the UE to retransmit an initial NAS message during a security mode control procedure as defined in TS 33.501. The UE uses these parameters for completion of security mode control procedure.
The Additional 5G security information information element is coded as shown in Figure 9.11.3.12.1 and Table 9.11.3.12.1.
The Additional 5G security information is a type 4 information element with a length of 3 octets.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.12.1: Additional 5G security information information element
Figure 9.11.3.12.1: Additional 5G security information information element
Up
Horizontal derivation parameter (HDP) (octet 3, bit 1)
0KAMF derivation is not required
1KAMF derivation is required
Retransmission of initial NAS message request (octet 3, bit 2)
0Retransmission of the initial NAS message not requested
1Retransmission of the initial NAS message requested
Bits 3 to 8 of octet 3 are spare and shall be coded as zero.
Up

9.11.3.12A  Additional information requested |R16|  p. 870

The purpose of the Additional information requested information element is to enable the UE to request ciphering keys for deciphering of ciphered broadcast assistance data.
The Additional information requested information element is coded as shown in Figure 9.11.3.12A.1 and Table 9.11.3.12A.1.
The Additional information requested is a type 4 information element with a length of 3 octets.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.12A.1: Additional information requested information element
Figure 9.11.3.12A.1: Additional information requested information element
Up
Ciphering keys for ciphered broadcast assistance data (CipherKey) (octet 3, bit 1)
0ciphering keys for ciphered broadcast assistance data not requested
1ciphering keys for ciphered broadcast assistance data requested
Bits 8 to 2 of octet 3 are spare and shall be coded as zero.
Up

9.11.3.13  Allowed PDU session status  p. 871

The purpose of the Allowed PDU session status information element is to indicate to the network user-plane resources of PDU sessions associated with non-3GPP access that are allowed to be re-established over 3GPP access or if there is no PDU session(s) for which the UE allows the user-plane resources to be re-established over 3GPP access.
The Allowed PDU session status information element is coded as shown in Figure 9.11.3.13.1 and Table 9.11.3.13.1.
The Allowed PDU session status is a type 4 information element with minimum length of 4 octets and maximum length of 34 octets.
Reproduction of 3GPP TS 24.501, Fig. 9.11.3.13.1: Allowed PDU session status information element
Figure 9.11.3.13.1: Allowed PDU session status information element
Up
PSI(x) shall be coded as follows:
PSI(0):
Bit 1 octet 3 is spare and shall be coded as zero.
PSI(1) - PSI(15):
0indicates that the user-plane resources of corresponding PDU session is not allowed to be re-established over 3GPP access.
1indicates that the user-plane resources of corresponding PDU session can be re-established over 3GPP access.
If there is no PDU session for which the user-plane resources can be re-established over 3GPP access, all bits in PSI(1) - PSI(15) shall be coded as zero.
All bits in octet 5 to 34 are spare and shall be coded as zero, if the respective octet is included in the information element.
Up

Up   Top   ToC