10.5.5 GPRS mobility management information elements
24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS
10.5.5.0 Additional update type
See subclause 9.9.3.0B in 3GPP TS 24.301 [120].
10.5.5.1 Attach result
The purpose of the attach result information element is to specify the result of a GPRS attach procedure.
The attach result is a type 1 information element.
The attach result information element is coded as shown in figure 10.5.117a/3GPP TS 24.008 and table 10.5.134a/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Attach result IEI |
FOP |
Result of attach |
octet 1 |
Figure 10.5.117a/3GPP TS 24.008: Attach result information element
Table 10.5.134a/3GPP TS 24.008: Attach result information element
Result of attach (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
1 |
GPRS only attached |
|
0 |
1 |
1 |
Combined GPRS/IMSI attached |
|
All other values are reserved. |
||||
Follow-on proceed (octet 1) |
||||
Bit |
||||
4 |
||||
0 |
Follow-on proceed |
|||
1 |
No follow-on proceed |
|||
Follow-on proceed is applicable only in Iu mode. This indication shall be ignored if received in A/Gb mode. |
10.5.5.2 Attach type
The purpose of the attach type information element is to indicate the type of the requested attach, i.e. whether the MS wants to perform a GPRS or combined GPRS attach.
The attach type is a type 1 information element.
The attach type information element is coded as shown in figure 10.5.117b/3GPP TS 24.008 and table 10.5.135b/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Attach type IEI |
FOR |
Type of attach |
octet 1 |
Figure 10.5.117b/3GPP TS 24.008: Attach type information element
Table 10.5.135b/3GPP TS 24.008: Attach type information element
Type of attach (octet 1, bit 1 to 3) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
1 |
GPRS attach |
|
0 |
1 |
0 |
Not used. This value was allocated in earlier versions of the protocol (Note1) |
|
0 |
1 |
1 |
Combined GPRS/IMSI attach |
|
1 |
0 |
0 |
Emergency attach |
|
All other values are interpreted as GPRS attach in this version of the protocol. |
||||
Follow-on request (octet 1, bit 4) |
||||
Bits |
||||
4 |
||||
0 |
No follow-on request pending |
|||
1 |
Follow-on request pending |
|||
Follow-on request pending is applicable only in Iu mode. |
||||
NOTE 1: The code point "010" if received by the network, it shall be interpreted as "Combined GPRS/IMSI attach". |
10.5.5.3 Ciphering algorithm
The purpose of the ciphering algorithm information element is to specify which ciphering algorithm shall be used.
The ciphering algorithm is a type 1 information element.
The ciphering algorithm information element is coded as shown in figure 10.5.119/3GPP TS 24.008 and table 10.5.136/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Ciphering algorithm IEI |
0 spare |
Type of algorithm |
octet 1 |
Figure 10.5.119/3GPP TS 24.008: Ciphering algorithm information element
Table 10.5.136/3GPP TS 24.008: Ciphering algorithm information element
Type of ciphering algorithm (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
ciphering not used |
|
0 |
0 |
1 |
GPRS Encryption Algorithm GEA/1 |
|
0 |
1 |
0 |
GPRS Encryption Algorithm GEA/2 |
|
0 |
1 |
1 |
GPRS Encryption Algorithm GEA/3 |
|
1 |
0 |
0 |
GPRS Encryption Algorithm GEA/4 |
|
1 |
0 |
1 |
GPRS Encryption Algorithm GEA/5 |
|
1 |
1 |
0 |
GPRS Encryption Algorithm GEA/6 |
|
1 |
1 |
1 |
GPRS Encryption Algorithm GEA/7 |
|
10.5.5.3a Integrity algorithm
The purpose of the integrity algorithm information element is to specify which integrity algorithm shall be used.
The integrity algorithm is a type 1 information element.
The integrity algorithm information element is coded as shown in figure 10.5.5.3a-1/3GPP TS 24.008 and table 10.5.5.3a-1/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Integrity algorithm IEI |
0 spare |
Type of algorithm |
octet 1 |
Figure 10.5.5.3a-1/3GPP TS 24.008: Integrity algorithm information element
Table 10.5.5.3a-1/3GPP TS 24.008: Integrity algorithm information element
Type of integrity algorithm (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
GPRS Integrity Algorithm GIA/4 |
|
0 |
0 |
1 |
GPRS Integrity Algorithm GIA/5 |
|
0 |
1 |
0 |
GPRS Integrity Algorithm GIA/6 |
|
0 |
1 |
1 |
GPRS Integrity Algorithm GIA/7 |
|
All other values are reserved. |
||||
10.5.5.4 TMSI status
The purpose of the TMSI status information element is to indicate whether a valid TMSI is available in the MS or not.
The TMSI status is a type 1 information element.
The TMSI status information element is coded as shown in figure 10.5.120/3GPP TS 24.008 and table 10.5.137/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||||
TMSI status |
0 |
0 |
0 |
TMSI |
octet 1 |
|||||||
IEI |
spare |
flag |
Figure 10.5.120/3GPP TS 24.008: TMSI status information element
Table 10.5.137/3GPP TS 24.008: TMSI status information element
TMSI flag (octet 1) |
||||
Bit |
||||
1 |
||||
0 |
no valid TMSI available |
|||
1 |
valid TMSI available |
|||
10.5.5.5 Detach type
The purpose of the detach type information element is to indicate which type of detach is requested by the MS. In the network to MS direction the detach type information element is used to indicate the reason why a detach request is sent.
The detach type is a type 1 information element.
The detach type information element is coded as shown in figure 10.5.121/3GPP TS 24.008 and table 10.5.138/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Detach type IEI |
Power off |
Type of detach |
octet 1 |
Figure 10.5.121/3GPP TS 24.008: Detach type information element
Table 10.5.138/3GPP TS 24.008: Detach type information element
Type of detach (octet 1) |
||||
In the MS to network direction: |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
1 |
GPRS detach |
|
0 |
1 |
0 |
IMSI detach |
|
0 |
1 |
1 |
Combined GPRS/IMSI detach |
|
All other values are interpreted as Combined GPRS/IMSI detach by this version of the protocol. |
||||
In the network to MS direction: |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
1 |
re-attach required |
|
0 |
1 |
0 |
re-attach not required |
|
0 |
1 |
1 |
IMSI detach (after VLR failure) |
|
All other values are interpreted as re-attach not required by this version of the protocol. |
||||
Power off (octet 1) |
||||
In the MS to network direction: |
||||
Bit |
||||
4 |
||||
0 |
normal detach |
|||
1 |
power switched off |
|||
In the network to MS direction the Power off bit shall be spare and set to zero. |
||||
10.5.5.6 DRX parameter
The purpose of the DRX parameter information element is to indicate whether the MS uses DRX mode or not.
The DRX parameter is a type 3 information element with a length of 3 octets.
The value part of a DRX parameter information element is coded as shown in table 10.5.139/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
DRX parameter IEI |
octet 1 |
|||||||||
SPLIT PG CYCLE CODE |
octet 2 |
|||||||||
CN Specific DRX cycle length coefficient and DRX value for S1 mode |
SPLIT on CCCH |
non-DRX timer |
octet 3 |
Figure 10.5.122/3GPP TS 24.008: DRX parameter information element
Table 10.5.139/3GPP TS 24.008: DRX parameter information element
SPLIT PG CYCLE CODE, octet 2 |
|||||
The octet contains the binary coded value of the SPLIT PG CYCLE CODE. The SPLIT PG CYCLE value is derived from the SPLIT PG CYCLE CODE as follows: |
|||||
0 |
704 (equivalent to no DRX) |
||||
1 to 64 |
1 to 64, respectively |
||||
65 |
71 |
||||
66 |
72 |
||||
67 |
74 |
||||
68 |
75 |
||||
69 |
77 |
||||
70 |
79 |
||||
71 |
80 |
||||
72 |
83 |
||||
73 |
86 |
||||
74 |
88 |
||||
75 |
90 |
||||
76 |
92 |
||||
77 |
96 |
||||
78 |
101 |
||||
79 |
103 |
||||
80 |
107 |
||||
81 |
112 |
||||
82 |
116 |
||||
83 |
118 |
||||
84 |
128 |
||||
85 |
141 |
||||
86 |
144 |
||||
87 |
150 |
||||
88 |
160 |
||||
89 |
171 |
||||
90 |
176 |
||||
91 |
192 |
||||
92 |
214 |
||||
93 |
224 |
||||
94 |
235 |
||||
95 |
256 |
||||
96 |
288 |
||||
97 |
320 |
||||
98 |
352 |
||||
All other values are reserved and shall be interpreted as 1 by this version of the protocol. |
|||||
SPLIT on CCCH, octet 3 (bit 4) |
|||||
0 |
Split pg cycle on CCCH is not supported by the mobile station |
||||
1 |
Split pg cycle on CCCH is supported by the mobile station |
||||
non-DRX timer, octet 3 |
|||||
bit |
|||||
3 |
2 |
1 |
|||
0 |
0 |
0 |
no non-DRX mode after transfer state |
||
0 |
0 |
1 |
max. 1 sec non-DRX mode after transfer state |
||
0 |
1 |
0 |
max. 2 sec non-DRX mode after transfer state |
||
0 |
1 |
1 |
max. 4 sec non-DRX mode after transfer state |
||
1 |
0 |
0 |
max. 8 sec non-DRX mode after transfer state |
||
1 |
0 |
1 |
max. 16 sec non-DRX mode after transfer state |
||
1 |
1 |
0 |
max. 32 sec non-DRX mode after transfer state |
||
1 |
1 |
1 |
max. 64 sec non-DRX mode after transfer state |
||
CN Specific DRX cycle length coefficient and DRX value for S1 mode, octet 3 This field represents two separate values. For Iu mode, it represents the ‘CN domain specific DRX cycle length’ as defined in 3GPP TS 25.331 [23c]. For S1 mode, it represents the DRX cycle parameter ‘T’ as defined in 3GPP TS 36.304 [121]. bit |
|||||
8 |
7 |
6 |
5 |
Iu and S1 mode specific |
|
0 |
0 |
0 |
0 |
For Iu mode, CN Specific DRX cycle length coefficient not specified by the MS, ie. the system information value ‘CN domain specific DRX cycle length’ is used . For S1 mode, DRX value not specified by the MS. |
|
0 |
1 |
1 |
0 |
CN Specific DRX cycle length coefficient 6 and T = 32 |
|
0 |
1 |
1 |
1 |
CN Specific DRX cycle length coefficient 7 and T = 64 |
|
1 |
0 |
0 |
0 |
CN Specific DRX cycle length coefficient 8 and T = 128 |
|
1 |
0 |
0 |
1 |
CN Specific DRX cycle length coefficient 9 and T = 256 |
|
All other values shall be interpreted as "CN Specific DRX cycle length coefficient not specified by the MS " and "DRX value not specified by the MS" by this version of the protocol. |
|||||
NOTE: For Iu mode and S1 mode, this field (octet 3 bits 8 to 5) is used, but was spare in earlier versions of this protocol. |
|||||
10.5.5.7 Force to standby
The purpose of the force to standby information element is to force the MS to stop the READY timer in order to prevent the MS to perform cell updates.
In Iu mode, the network shall always indicate force to standby not indicated in the force to standby information element.
The force to standby is a type 1 information element.
The force to standby information element is coded as shown in figure 10.5.123/3GPP TS 24.008 and table 10.5.140/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Force to standby IEI |
0 spare |
Force to standby value |
octet 1 |
Figure 10.5.123/3GPP TS 24.008: Force to standby information element
Table 10.5.140/3GPP TS 24.008: Force to standby information element
Force to standby value (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
Force to standby not indicated |
|
0 |
0 |
1 |
Force to standby indicated |
|
All other values are interpreted as |
||||
10.5.5.8 P-TMSI signature
The purpose of the P-TMSI signature information element is to identify a GMM context of an MS.
The P-TMSI signature is a type 3 information element with 4 octets length.
The P-TMSI signature information element is coded as shown in figure 10.5.124/3GPP TS 24.008 and table 10.5.141/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
P-TMSI signature IEI |
octet 1 |
|||||||
P-TMSI signature value |
octet 2 octet 4 |
Figure 10.5.124/3GPP TS 24.008: P-TMSI signature information element
Table 10.5.141/3GPP TS 24.008: P-TMSI signature information element
P-TMSI signature value |
Octets 2, 3 and 4 contain the binary representation of the P-TMSI signature. |
Bit 1 of octet 4 is the least significant bit and bit 8 of octet 2 is the most significant bit. |
10.5.5.8a P-TMSI signature 2
The purpose of the P-TMSI signature 2 information element is to identify a GMM context of an MS.
The P-TMSI signature 2 is a type 4 information element with 5 octets length.
The P-TMSI signature 2 information element is coded as shown in figure 10.5.124a/3GPP TS 24.008 and table 10.5.141a/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
P-TMSI signature 2 IEI |
octet 1 |
|||||||
Length of P-TMSI signature 2 contents |
octet 2 |
|||||||
P-TMSI signature 2 value |
octet 3 octet 5 |
Figure 10.5.124a/3GPP TS 24.008: P-TMSI signature 2 information element
Table 10.5.141a/3GPP TS 24.008: P-TMSI signature 2 information element
P-TMSI signature 2 value is coded as octets 2 to 4 of the P-TMSI signature IE. |
10.5.5.9 Identity type 2
The purpose of the identity type 2 information element is to specify which identity is requested.
The identity type 2 is a type 1 information element.
The identity type 2 information element is coded as shown in figure 10.5.125/3GPP TS 24.008 and table 10.5.142/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Identity type 2 IEI |
0 spare |
Type of identity |
octet 1 |
Figure 10.5.125/3GPP TS 24.008: Identity type 2 information element
Table 10.5.142/3GPP TS 24.008: Identity type 2 information element
Type of identity (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
1 |
IMSI |
|
0 |
1 |
0 |
IMEI |
|
0 |
1 |
1 |
IMEISV |
|
1 |
0 |
0 |
TMSI |
|
All other values are interpreted as IMSI by this version of the protocol. |
||||
10.5.5.10 IMEISV request
The purpose of the IMEISV request information element is to indicate that the IMEISV shall be included by the MS in the authentication and ciphering response message.
The IMEISV request is a type 1 information element.
The IMEISV request information element is coded as shown in figure 10.5.126/3GPP TS 24.008 and table 10.5.143/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
IMEISV request IEI |
0 spare |
IMEISV request value |
octet 1 |
Figure 10.5.126/3GPP TS 24.008: IMEISV request information element
Table 10.5.143/3GPP TS 24.008: IMEISV request information element
IMEISV request value (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
IMEISV not requested |
|
0 |
0 |
1 |
IMEISV requested |
|
All other values are interpreted as IMEISV not requested by this version of the protocol. |
||||
10.5.5.11 Receive N‑PDU Numbers list
The purpose of the Receive N‑PDU Numbers list information element is to specify the current SNDCP Receive N‑PDU Number values.
The Receive N‑PDU Number list is a type 4 information element with a length of 4 to 19 octets.
The value part of a Receive N‑PDU Number list information element is coded as shown in figure 10.5.127/3GPP TS 24.008 and table 10.5.144/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Receive N‑PDU Number list IEI |
octet 1 |
|||||||
Length of Receive N‑PDU Number list contents |
||||||||
Receive N‑PDU Number-list |
octet 3 octet 4 octet n* |
Figure 10.5.127/3GPP TS 24.008: Receive N‑PDU Number list information element
Table 10.5.144/3GPP TS 24.008: Receive N‑PDU Number list information element
Receive N‑PDU Number -list value ::= { < Receive N‑PDU Number-list > ::= < sapi : bit-string(4) > < Receive N‑PDU Number-value : bit-string(8) > { < Receive N‑PDU Number-list> | < null > } ; < nsapi > ::= < Receive N‑PDU Number-value > ::= { 0 | 1} (8) ; <Padding bits> ::= null | 0000; |
10.5.5.12 MS network capability
The purpose of the MS network capability information element is to provide the network with information concerning aspects of the mobile station related to GPRS. The contents might affect the manner in which the network handles the operation of the mobile station. The MS network capability information indicates general mobile station characteristics and it shall therefore, except for fields explicitly indicated, be independent of the frequency band of the channel it is sent on.
The MS network capability is a type 4 information element with a maximum of 10 octets length.
The value part of a MS network capabilityinformation element is coded as shown in figure 10.5.128/3GPP TS 24.008 and table 10.5.145/3GPP TS 24.008.
NOTE: The requirements for the support of the GEA algorithms in the MS are specified in 3GPP TS 43.020 [13].
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
MS network capability IEI |
octet 1 |
|||||||
Length of MS network capability contents |
octet 2 |
|||||||
MS network capability value |
octet 3-10 |
Figure 10.5.128/3GPP TS 24.008 MS network capability information element
Table 10.5.145/3GPP TS 24.008 MS network capability information element
<MS network capability value part> ::= <GEA1 bits> <PFC feature mode: bit> <Extended GEA bits> <LCS VA capability: bit> <PS inter-RAT HO from GERAN to UTRAN Iu mode capability: bit> <PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability: bit> <EMM Combined procedures Capability: bit> <ISR support: bit> <SRVCC to GERAN/UTRAN capability: bit> <EPC capability: bit> <NF capability: bit> <GERAN network sharing capability: bit> <User plane integrity protection support: bit> <GIA/4: bit> <GIA/5: bit> <GIA/6: bit> <GIA/7: bit> <ePCO IE indicator: bit> <Restriction on use of enhanced coverage capability: bit> <Dual connectivity of E-UTRA with NR capability: bit> <Spare bits>; <GEA1 bits> ::= < GEA/1 :bit>; <Extended GEA bits> ::= <GEA/2:bit><GEA/3:bit>< GEA/4:bit >< GEA/5:bit >< GEA/6:bit ><GEA/7:bit>; <Spare bits> ::= null | {<spare bit> < Spare bits >}; SS Screening Indicator 0 1 defined in 3GPP TS 24.080 [24] 1 0 defined in 3GPP TS 24.080 [24] 1 1 defined in 3GPP TS 24.080 [24] SM capabilities via dedicated channels 1 Mobile station supports mobile terminated point to point SMS via CS domain UCS2 support GPRS Encryption Algorithm GEA/1 (NOTE) SoLSA Capability Revision level indicator 1 used by a mobile station supporting R99 or later versions of the protocol PFC feature mode 0 Mobile station does not support BSS packet flow procedures 1 Mobile station does support BSS packet flow procedures GEA/2 (NOTE) 0 encryption algorithm GEA/2 not available GEA/3 (NOTE) 0 encryption algorithm GEA/3 not available GEA/4 (NOTE) 0 encryption algorithm GEA/4 not available GEA/5 (NOTE) 0 encryption algorithm GEA/5 not available GEA/6 (NOTE) 0 encryption algorithm GEA/6 not available GEA/7 (NOTE) 0 encryption algorithm GEA/7 not available LCS VA capability (LCS value added location request notification capability) This information field indicates the support of the LCS value added location request notification via PS domain as defined in 3GPP TS 23.271 [105]. 0 location request notification via PS domain not supported PS inter-RAT HO from GERAN to UTRAN Iu mode capability This information field indicates the support of the PS inter-RAT HO from GERAN to UTRAN Iu mode. 0 PS inter-RAT HO from GERAN to UTRAN Iu mode not supported PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability This information field indicates the support of the PS inter-RAT HO from GERAN to E-UTRAN S1 mode. A mobile station not compliant to the UE E-UTRA capability requirements as defined in 3GPP TS 36.306 [153] shall set this field to ‘0’. 0 PS inter-RAT HO from GERAN to E-UTRAN S1 mode not supported EMM Combined procedures capability This information field indicates the support of EMM combined procedures. The MS shall not change this information field from the one that was included in the GMM or EMM ATTACH REQUEST message. 0 Mobile station does not support EMM combined procedures ISR support 0 The mobile station does not support ISR. SRVCC to GERAN/UTRAN capability 0 SRVCC from UTRAN HSPA or E-UTRAN to GERAN/UTRAN not supported EPC capability This information field indicates if the MS supports access to the EPC via access networks other than GERAN or UTRAN.The network can use this information to decide whether to select a PDN Gateway or a GGSN. The MS shall set the indication to "0" if a SIM is inserted in the MS. 0 EPC not supported NF capability This information field indicates if the MS supports the notification procedure. 0 Mobile station does not support the notification procedure. GERAN network sharing capability This information field indicates if the MS supports GERAN network sharing. 0 Mobile station does not support GERAN network sharing. User plane integrity protection support 0 The mobile station does not support user plane integrity protection. GIA/4 (NOTE) 0 integrity algorithm GIA/4 not available GIA/5 (NOTE) 0 integrity algorithm GIA/5 not available GIA/6 (NOTE) 0 integrity algorithm GIA/5 not available GIA/7 (NOTE) 0 integrity algorithm GIA/5 not available ePCO IE indicator 1 used by a mobile station supporting extended protocol configuration options IE Restriction on use of enhanced coverage capability This information field indicates if the MS supports restriction on use of enhanced coverage 0 Mobile station does not support restriction on use of enhanced coverage Dual connectivity of E-UTRA with NR capability This information field indicates if the MS supports dual connectivity of E-UTRA with NR 0 Mobile station does not support dual connectivity of E-UTRA with NR |
NOTE: The requirements for the support of the GEA and the GIA algorithms in the MS are specified in 3GPP TS 43.020 [13]. |
10.5.5.12a MS Radio Access capability
The purpose of the MS Radio Access capability information element is to provide the radio part of the network with information concerning radio aspects of the mobile station. The contents might affect the manner in which the network handles the operation of the mobile station.
The MS Radio Access capability is a type 4 information element, with a maximum length of 52 octets.
The MS Radio Access capability information element is coded as shown in figure 10.5.128a/3GPP TS 24.008 and table 10.5.146/3GPP TS 24.008.
For the indication of the radio access capabilities the following conditions shall apply:
– Among the three Access Type Technologies GSM 900-P, GSM 900-E and GSM 900-R only one shall be present.
– Due to shared radio frequency channel numbers between GSM 1800 and GSM 1900, the mobile station should provide the relevant radio access capability for either GSM 1800 band OR GSM 1900 band, not both.
– The MS shall indicate its supported Access Technology Types during a single MM procedure.
– If the alternative coding by using the Additional access technologies struct is chosen by the mobile station, the mobile station shall indicate its radio access capability for the serving BCCH frequency band in the first included Access capabilities struct, if this information element is not sent in response to an Access Technologies Request from the network or if none of the requested Access Technology Types is supported by the MS. Otherwise, the mobile station shall include the radio access capabilities for the frequency bands it supports in the order of priority requested by the network (see 3GPP TS 44.060 [76]).
– The first Access Technology Type shall not be set to "1111".
For error handling the following shall apply:
If a received Access Technology Type is unknown to the receiver, it shall ignore all the corresponding fields.
If within a known Access Technology Type a receiver recognizes an unknown field it shall ignore it.
For more details about error handling of MS radio access capability see 3GPP TS 48.018 [86].
NOTE: The requirements for the support of the A5 algorithms in the MS are specified in 3GPP TS 43.020 [13].
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
MS Radio Access Capability IEI |
octet 1 |
|||||||
Length of MS Radio Access Capability contents |
octet 2 |
|||||||
MS RA capability value part |
octet 3-52 |
Figure 10.5.128a/3GPP TS 24.008 MS Radio Access Capability information element
Table 10.5.146/3GPP TS 24.008: MS Radio Access Capability Information Element
< MS RA capability value part > ::=
< MS RA capability value part struct >
<spare bits>**; — may be used for future enhancements
<MS RA capability value part struct >::= —recursive structure allows any number of Access technologies
{ { < Access Technology Type: bit (4) > exclude 1111
< Access capabilities : <Access capabilities struct> > }
| { < Access Technology Type: bit (4) == 1111 > — structure adding Access technologies with same capabilities
< Length : bit (7) > — length in bits of list of Additional access technologies and spare bits
< bit (val (Length))
& {
{ 1 < Additional access technologies: < Additional access technologies struct > > } ** 0
<spare bits>**
} >
}
}
{ 0 | 1 <MS RA capability value part struct> } ;
< Additional access technologies struct > ::=
< Access Technology Type : bit (4) >
< GMSK Power Class : bit (3) >
< 8PSK Power Class : bit (2) > ;
< Access capabilities struct > ::=
< Length : bit (7) > — length in bits of Content and spare bits
< bit (val (Length))
& {
<Access capabilities : <Content>>
<spare bits>**
} > ; — expands to the indicated length
< Content > ::=
< RF Power Capability : bit (3) >
{ 0 | 1 <A5 bits : <A5 bits> > } — zero means that the same values apply for parameters as in the immediately preceding Access capabilities field within this IE
< ES IND : bit >
< PS : bit >
< VGCS : bit >
< VBS : bit >
{ 0 | 1 < Multislot capability : Multislot capability struct > } — zero means that the same values for multislot parameters as given in an earlier Access capabilities field within this IE apply also here
— Additions in release 99
{ 0 | 1 < 8PSK Power Capability : bit(2) >}
< COMPACT Interference Measurement Capability : bit >
< Revision Level Indicator : bit >
< UMTS FDD Radio Access Technology Capability : bit > — 3G RAT
< UMTS 3.84 Mcps TDD Radio Access Technology Capability : bit > — 3G RAT
< CDMA 2000 Radio Access Technology Capability : bit > — 3G RAT
— Additions in release 4
< UMTS 1.28 Mcps TDD Radio Access Technology Capability: bit > — 3G RAT
< GERAN Feature Package 1 : bit >
{ 0 | 1 < Extended DTM GPRS Multi Slot Class : bit(2) >
< Extended DTM EGPRS Multi Slot Class : bit(2) > }
< Modulation based multislot class support : bit >
— Additions in release 5
{ 0 | 1 < High Multislot Capability : bit(2) > }
0 — The value ‘1’ was allocated in an earlier version of the protocol and shall not be used.
< GMSK Multislot Power Profile : bit (2) >
< 8-PSK Multislot Power Profile : bit (2) >
— Additions in release 6
< Multiple TBF Capability : bit >
< Downlink Advanced Receiver Performance : bit(2) >
< Extended RLC/MAC Control Message Segmentation Capability : bit >
< DTM Enhancements Capability : bit >
{ 0 | 1 < DTM GPRS High Multi Slot Class : bit(3) >
{ 0 | 1 < DTM EGPRS High Multi Slot Class : bit(3) > } }
< PS Handover Capability : bit >
— Additions in release 7
< DTM Handover Capability : bit >
{ 0 | 1 < Multislot Capability Reduction for Downlink Dual Carrier: bit (3) >
< Downlink Dual Carrier for DTM Capability : bit> }
< Flexible Timeslot Assignment : bit >
< GAN PS Handover Capability : bit >
< RLC Non-persistent Mode : bit >
< Reduced Latency Capability : bit >
< Uplink EGPRS2 : bit(2) >
< Downlink EGPRS2 : bit(2) >
— Additions in release 8
< E-UTRA FDD support : bit >
< E-UTRA TDD support : bit >
< GERAN to E-UTRA support in GERAN packet transfer mode: bit(2) >
< Priority-based reselection support : bit >
— Additions in release 9
< Enhanced Flexible Timeslot Assignment : Enhanced Flexible Timeslot Assignment struct>
< Indication of Upper Layer PDU Start Capability for RLC UM : bit >
< EMST Capability : bit >
< MTTI Capability : bit >
< UTRA CSG Cells Reporting : bit >
< E-UTRA CSG Cells Reporting : bit >
— Additions in release 10
< DTR Capability : bit >
< EMSR Capability : bit >
< Fast Downlink Frequency Switching Capability : bit >
< TIGHTER Capability : bit(2) >
— Additions in release 11
< FANR Capability : bit >
< IPA Capability : bit>
< GERAN Network Sharing support : bit>
< E-UTRA Wideband RSRQ measurements support : bit>
— Additions in release 12
< UTRA Multiple Frequency Band Indicators support : bit >
< E-UTRA Multiple Frequency Band Indicators support : bit >
{ 0 — DLMC not supported
| 1 < DLMC Capability : DLMC Capability struct > }
< Extended TSC Set Capability support : bit >
— Late addition of a release 11 feature
< Extended EARFCN value range: bit>
— Additions in release 13
< (EC-)PCH monitoring support: bit(2)>
— Additions in release 14
{ 0 — Default requirement as specified in TS 45.010 applies
| 1 < MS Sync Accuracy: bit (4) > }
< EC uplink coverage enhancement support : bit (1)>
— Additions in release 15
< MTA Access Security support: bit(1) >
< EC paging indication channel monitoring support: bit(1) >;
— error: struct too short, assume features do not exist
— error: struct too long, ignore data and jump to next Access technology
Table 10.5.146/3GPP TS 24.008 (continued): MS Radio Access Capability IE
< Multislot capability struct > ::= { 0 | 1 < GPRS multislot class : bit (5) > < GPRS Extended Dynamic Allocation Capability : bit > } { 0 | 1 < SMS_VALUE : bit (4) > < SM_VALUE : bit (4) > } — Additions in release 99 { 0 | 1 < ECSD multislot class : bit (5) > } { 0 | 1 < EGPRS multislot class : bit (5) > < EGPRS Extended Dynamic Allocation Capability : bit > } { 0 | 1 < DTM GPRS Multi Slot Class: bit(2)> <Single Slot DTM : bit> {0 | 1 <DTM EGPRS Multi Slot Class : bit(2)> } } ; — error: struct too short, assume features do not exist <A5 bits> ::= < A5/1 : bit> <A5/2 : bit> <A5/3 : bit> <A5/4 : bit> <A5/5 : bit> <A5/6 : bit> <A5/7 : bit>; — bits for circuit mode ciphering algorithms. These fields are not used by the network and may be excluded by the MS. < Enhanced Flexible Timeslot Assignment struct > ::= { 0 | 1 < Alternative EFTA Multislot Class : bit(4) > < EFTA Multislot Capability Reduction for Downlink Dual Carrier: bit (3) > }; < DLMC Capability struct > ::= { 0 | 1 < DLMC – Non-contiguous intra-band reception : bit(2) > < DLMC – Inter-band reception : bit(1) > } < DLMC – Maximum Bandwidth : bit(2) > < DLMC – Maximum Number of Downlink Timeslots : bit(6) > < DLMC – Maximum Number of Downlink Carriers : bit(3) > ; Access Technology Type All other values are treated as unknown by the receiver. A MS which does not support any GSM access technology type shall set this field to ‘0000’. RF Power Capability, GMSK Power Class (3 bit field) A MS which does not support any GSM access technology type shall set this field to ‘000’. 8PSK Power Capability (2 bit field) Bits 2 1 0 0 Reserved 0 1 Power class E1 1 0 Power class E2 1 1 Power class E3 The presence of this field also indicates 8PSK modulation capability in the uplink. 8PSK Power Class (2 bit field) Bits 2 1 0 0 8PSK modulation not supported for uplink 0 1 Power class E1 1 0 Power class E2 1 1 Power class E3 Additional access technologies struct This structure contains the GMSK Power Class and 8PSK Power Class for an additional Access Technology. All other capabilities for this indicated Access Technology are the same as the capabilities indicated by the preceding Access capabilities struct. A5/1 A5/2 The network shall accept any received value. 0 encryption algorithm A5/2 not available A5/3 A5/4 A5/5 A5/6 A5/7 ES IND – (Controlled early Classmark Sending) 0 "controlled early Classmark Sending" option is not implemented 1 "controlled early Classmark Sending" option is implemented |
Table 10.5.146/3GPP TS 24.008 (concluded): MS Radio Access Capability IE
PS – (Pseudo Synchronisation) VGCS – (Voice Group Call Service) VBS – (Voice Broadcast Service) 1 VBS capability and notifications wanted HSCSD Multi Slot Class GPRS Multi Slot Class ECSD Multi Slot Class EGPRS Multi Slot Class The same multislot capability is applicable also for EGPRS2 if supported. The same multislot capability is applicable also for Downlink Multi Carrier configuration if supported. The same multislot capability is applicable also for EC-GSM-IoT if supported, see 3GPP TS 43.064 [159]. GPRS Extended Dynamic Allocation Capability 1 Extended Dynamic Allocation Capability for GPRS is implemented If a multislot class type 1 MS indicates in the GPRS Multi Slot Class field the support of a multislot class for which three or more uplink timeslots can be assigned, Extended Dynamic Allocation for GPRS shall be implemented in the mobile station. EGPRS Extended Dynamic Allocation Capability 1 Extended Dynamic Allocation Capability for EGPRS and EGPRS2 (if supported) is implemented If a multislot class type 1 MS indicates in the EGPRS Multi Slot Class field the support of a multislot class for which three or more uplink timeslots can be assigned, Extended Dynamic Allocation for EGPRS and EGPRS2 (if supported) shall be implemented in the mobile station. SMS_VALUE (Switch-Measure-Switch) (4 bit field) Bits 0 0 0 0 1/4 timeslot (~144 microseconds) (SM_VALUE) Switch-Measure (4 bit field) Bits |
DTM GPRS Multi Slot Class (2 bit field) Bits This field shall contain one of the following values if the DTM GPRS High Multi Slot Class field is present: Multislot class 9 if DTM GPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41; Multislot class 11 if DTM GPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44. Single Slot DTM (1 bit field) Bit An MS indicating support for Extended DTM GPRS multislot class or Extended DTM EGPRS multislot class shall set this bit to ‘1’. The network may ignore the bit in this case. DTM EGPRS Multi Slot Class (2 bit field) This field shall contain one of the following values if the DTM EGPRS High Multi Slot Class field is present: Multislot class 9 if DTM EGPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41; Multislot class 11 if DTM EGPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44. The same multislot capability is applicable also for EGPRS2 if supported. COMPACT Interference Measurement Capability (1 bit field) 0 COMPACT Interference Measurement Capability is not implemented Revision Level Indicator (1 bit field) Bit UMTS FDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS FDD not supported 1 UMTS FDD supported UMTS 3.84 Mcps TDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS 3.84 Mcps TDD not supported 1 UMTS 3.84 Mcps TDD supported CDMA 2000 Radio Access Technology Capability (1 bit field) Bit 0 CDMA 2000 not supported 1 CDMA 2000 supported UMTS 1.28 Mcps TDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS 1.28 Mcps TDD not supported 1 UMTS 1.28 Mcps TDD supported GERAN Feature Package 1 (1 bit field) The support of interworking towards E-UTRA is indicated separately in the "GERAN to E-UTRA support in GERAN packet transfer mode" field. This field indicates whether the MS supports the GERAN Feature Package 1 (see 3GPP TS 44.060 [76]). It is coded as follows: 0 GERAN feature package 1 not supported. Extended DTM GPRS Multi Slot Class (2 bit field) This field indicates the extended DTM GPRS capabilities of the MS and shall be interpreted in conjunction with the DTM GPRS Multi Slot Class field. It is coded as follows, where ‘DGMSC’ denotes the DTM GPRS multislot class field: DGMSC Bit 2 1 Bit 2 1 0 0 0 0 Unused. If received, it shall be interpreted as ’01 00’ 0 0 0 1 Unused. If received, it shall be interpreted as ’01 00’ 0 0 1 0 Unused. If received, it shall be interpreted as ’01 00’ 0 0 1 1 Unused. If received, it shall be interpreted as ’01 00’ 0 1 0 0 Multislot class 5 supported 0 1 0 1 Multislot class 6 supported 0 1 1 0 Unused. If received, it shall be interpreted as ’01 00’ 0 1 1 1 Unused. If received, it shall be interpreted as ’01 00’ 1 0 0 0 Multislot class 9 supported 1 0 0 1 Multislot class 10 supported 1 0 1 0 Unused. If received, it shall be interpreted as ’10 00’ 1 0 1 1 Unused. If received, it shall be interpreted as ’10 00’ 1 1 0 0 Multislot class 11 supported 1 1 0 1 Unused. If received, it shall be interpreted as ’11 00’ 1 1 1 0 Unused. If received, it shall be interpreted as ’11 00’ 1 1 1 1 Unused. If received, it shall be interpreted as ’11 00’ The presence of this field indicates that the MS supports combined fullrate and halfrate GPRS channels in the downlink. When this field is not present, the MS supports the multislot class indicated by the DTM GPRS Multi Slot Class field. If this field is included, it shall contain one of the following values if the DTM GPRS High Multi Slot Class field is present: Multislot class 10 if DTM GPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41; Multislot class 11 if DTM GPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44. Extended DTM EGPRS Multislot Class (2 bit field) This field is not considered when the DTM EGPRS Multislot Class field is not included. This field indicates the extended DTM EGPRS multislot capabilities of the MS and shall be interpreted in conjunction with the DTM EGPRS Multislot Class field. This field is coded as the Extended DTM GPRS Multislot Class field. The presence of this field indicates that the MS supports combined fullrate and halfrate GPRS channels in the downlink. When this field is not present, the MS supports the multislot class indicated by the DTM EGPRS Multi Slot Class field. If this field is included, it shall contain one of the following values if the DTM EGPRS High Multi Slot Class field is present: Multislot class 10 if DTM EGPRS High Multi Slot Class is set to indicate Class 31/36 or Class 41; Multislot class 11 if DTM EGPRS High Multi Slot Class is set to indicate Classes 32/37, 33/38 or Classes 42, 43, 44. Modulation based multislot class support (1 bit field) Bit 0 "Modulation based multislot class" not supported 1 "Modulation based multislot class" supported High Multislot Capability (2 bit field) The High Multislot Capability is individually combined with each multislot class field sent by the MS (the possible multislot class fields are: GPRS multislot class, EGPRS multislot class) to extend the related multislot class to multislot classes 30 to 45, see 3GPP TS 45.002 [32]. The same capability is applicable also to EGPRS2 if supported. The same capability is applicable also to Downlink Multi Carrier configuration if supported. For each multislot class, the following mapping is done: Bits 2 1 coded multislot class field actual multislot class 0 0 8 30 0 0 10, 23, 28, 29 39 0 0 11, 20, 25 32 0 0 12, 21, 22, 26, 27 33 0 0 Any other Multislot Class field value 0 1 8 35 0 1 10, 19, 24 36 0 1 11, 23, 28, 29 45 0 1 12, 21, 22, 26, 27 38 0 1 Any other Multislot Class field value 1 0 8 40 1 0 10, 19, 24 41 1 0 11, 20, 25 42 1 0 12, 23, 28, 29 44 1 0 Any other Multislot Class field value 1 1 12, 21, 22, 26, 27 43 1 1 11, 20, 25 37 1 1 10, 19, 24 31 1 1 9, 23, 28, 29 34 1 1 Any other Multislot Class field value GMSK Multislot Power Profile (2 bit field) For detailed definitions, see the Mobile Station Classmark 3 information element. 8-PSK Multislot Power Profile (2 bit field) For detailed definitions, see the Mobile Station Classmark 3 information element. Multiple TBF Capability (1 bit field) Bit 0 Multiple TBF procedures in A/Gb mode not supported 1 Multiple TBF procedures in A/Gb mode supported Downlink Advanced Receiver Performance (2 bit field) This field indicates Downlink Advanced Receiver Performance capabilities of the MS (see 3GPP TS 45.005 [33]). Bits 2 1 0 0 Downlink Advanced Receiver Performance not supported 0 1 Downlink Advanced Receiver Performance – phase I supported 1 0 Downlink Advanced Receiver Performance – phase II supported The value ’11’ shall not be used by the MS. If the value ’11’ is received by the network, it shall be interpreted as ’10’ . Extended RLC/MAC Control Message Segmentation capability (1 bit field) Bit 0 Extended RLC/MAC control message segmentation not supported 1 Extended RLC/MAC control message segmentation supported DTM Enhancements Capability (1 bit field) Bit 0 The mobile station does not support enhanced DTM CS establishment and enhanced DTM CS release procedures. DTM GPRS High Multi Slot Class (3 bit field) Bit The presence of this field indicates that the MS supports the DTM extension to high multislot classes. When this field is not present, the MS supports the DTM multislot class indicated by the DTM GPRS Multi Slot Class field. The values ‘0 0 1’, ‘0 1 0’ and ‘0 1 1’ shall be interpreted as indicating DTM GPRS multislot class 36, 37 or 38 respectively in case the MS indicates support for one of the GPRS multislot classes 35 to 39; in all other cases those codepoints shall be interpreted as indicating DTM GPRS multislot class 31, 32 or 33 respectively. This field shall be ignored if the High Multislot Capability field is not present. DTM EGPRS High Multi Slot Class (3 bit field) The values ‘0 0 1’, ‘0 1 0’ and ‘0 1 1’ shall be interpreted as indicating DTM EGPRS multislot class 36, 37 or 38 respectively in case the MS indicates support for one of the EGPRS multislot classes 35 to 39; in all other cases those codepoints shall be interpreted as indicating DTM EGPRS multislot class 31, 32 or 33 respectively. This field shall be ignored if the High Multislot Capability field is not present. The same multislot capability is applicable also for EGPRS2 if supported. PS Handover Capability (1 bit field) This field indicates whether the mobile station supports PS Handover. The PS Handover Capability applies to all RATs and modes indicated as supported in this information element, except for E-UTRA, where the support is indicated separately in the "GERAN to E-UTRA support in GERAN packet transfer mode" field. Bit 0 The mobile station does not support PS Handover. 1 The mobile station supports PS Handover DTM Handover Capability (1 bit field) This field indicates whether the mobile station supports DTM Handover. The DTM Handover Capability applies to all RATs and modes indicated as supported in this information element. It is coded as follows: Bit 0 The mobile station does not support DTM Handover. 1 The mobile station supports DTM Handover Multislot Capability Reduction for Downlink Dual Carrier (3 bit field) This field indicates the receive multislot capability reduction of a dual carrier capable mobile station applicable to EGPRS and EGPRS2 support when EFTA is not used (see 3GPP TS 45.002 [32]). This reduction applies to the maximum number of downlink timeslots for dual carrier operation derived from the (DTM) EGPRS (high) multislot class. The field is coded as follows: Bit The presence of this field also indicates that the mobile station supports dual carrier in the downlink for EGPRS. Downlink Dual Carrier for DTM Capability (1 bit field) This field indicates whether the mobile station supports DTM during downlink dual carrier operation. Bit 0 The mobile station does not support DTM during downlink dual carrier operation 1 The mobile station supports DTM during downlink dual carrier operation If the mobile station supports DTM during downlink dual carrier operation as indicated by this field, the Multislot Capability Reduction for Downlink Dual Carrier field provided in the MS Radio Access Capability IE is applicable to EGPRS DTM support as well. Flexible Timeslot Assignment (1 bit field) This field indicates whether the mobile station supports Flexible Timeslot Assignment (see 3GPP TS 45.002 [32]). 0 The mobile station does not support Flexible Timeslot Assignment GAN PS Handover Capability (1 bit field) This field indicates whether or not the mobile station supports PS Handover from GERAN/UTRAN cell to a GAN cell. The field is coded as follows: Bit 0 The mobile station does not support PS Handover from GERAN/UTRAN cell to a GAN cell 1 The mobile station supports PS Handover from GERAN/UTRAN cell to a GAN cell RLC Non-persistent Mode Capability (1 bit field) This field indicates whether the mobile station supports RLC Non-persistent Mode (see 3GPP TS 44.060 [76]). 0 The mobile station does not support RLC Non-persistent Mode 1 The mobile station supports RLC Non-persistent Mode Reduced Latency Capability (1 bit field) This field indicates whether the mobile station supports Reduced TTI configurations and Fast Ack/Nack Reporting (see 3GPP TS 44.060 [76]) in packet transfer mode for both EGPRS and, if supported, EGPRS2. 0 The mobile station does not support Reduced TTI configurations and Fast Ack/Nack Reporting A mobile station whose multislot class does not allow the support of Reduced TTI configurations in packet transfer mode due to a limited number of uplink or downlink timeslots (see 3GPP TS 45.002 [32]) shall set the Reduced Latency Capability field to ‘0’. Uplink EGPRS2 (2 bit field) This field indicates whether the mobile station supports EGPRS2-A or EGPRS2-A and EGPRS2-B in the uplink. Bit 2 1 0 0 The mobile station does not support either EGPRS2-A or EGPRS2-B in the uplink 0 1 The mobile station supports EGPRS2-A in the uplink 1 0 The mobile station supports both EGPRS2-A and EGPRS2-B in the uplink 1 1 This value is not used in this release/version of the specifications. If received it shall be interpreted as ’10’ Downlink EGPRS2 (2 bit field) This field indicates whether the mobile station supports EGPRS2-A or EGPRS2-A and EGPRS2-B in the downlink. Bit 2 1 0 0 The mobile station does not support either EGPRS2-A or EGPRS2-B in the downlink 0 1 The mobile station supports EGPRS2-A in the downlink 1 0 The mobile station supports both EGPRS2-A and EGPRS2-B in the downlink 1 1 This value is not used in this release/version of the specifications. If received it shall be interpreted as ’10’ E-UTRA FDD support (1 bit field) Bit 0 E-UTRA FDD not supported 1 E-UTRA FDD supported E-UTRA TDD support (1 bit field) Bit 0 E-UTRA TDD not supported 1 E-UTRA TDD supported GERAN to E-UTRA support in GERAN packet transfer mode (2 bit field) This field indicates the capabilities supported by the mobile station in packet transfer mode for GERAN to E-UTRA interworking. If both "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to ‘0’, the bit field shall be set to ‘0 0’. If one or both of "E-UTRA FDD support" and "E-UTRA TDD support" bits are set to ‘1’, the bit field may be any of the listed values. The bit field is coded as follows: Bit 2 1 0 0 None 0 1 E-UTRAN Neighbour Cell measurements and MS autonomous cell reselection to E-UTRAN supported 1 0 CCN towards E-UTRAN, E-UTRAN Neighbour Cell measurement reporting and Network controlled cell 1 1 PS Handover to E-UTRAN supported in addition to capabilities indicated by ’01’ and ’10’ Priority-based reselection support (1 bit field) This field indicates whether the mobile station supports priority-based cell reselection. 0 Priority-based cell reselection not supported 1 Priority-based cell reselection supported Alternative EFTA multislot class (4 bit field) The presence of the Alternative EFTA multislot class field indicates that the mobile station supports Enhanced Flexible Timeslot Assignment, EFTA, (see 3GPP TS 45.002 [32]). This field shall be ignored if the High Multislot Capability field is not present. The Alternative EFTA multislot class field is used together with the (DTM) EGPRS (high) multislot class to determine the mobile stations capabilities when using Enhanced Flexible Timeslot Assignment, EFTA, and is coded as follows: Bit 4 3 2 1 0 0 0 0 No Alternative EFTA multislot class is indicated. Use (DTM) EGPRS (high) multislot class only. 0 0 0 1 Alternative EFTA multislot class 1 0 0 1 0 Alternative EFTA multislot class 2 0 0 1 1 Alternative EFTA multislot class 3 0 1 0 0 to 1 1 1 1 Unused. If received, these values shall be interpreted as ’0000’ EFTA Multislot Capability Reduction for Downlink Dual Carrier (3 bit field) This field indicates the receive multislot capability reduction of a dual carrier capable mobile station applicable to EGPRS and EGPRS2 support when Enhanced Flexible Timeslot Assignment is used (see 3GPP TS 45.002 [32]). This reduction applies to the maximum number of downlink timeslots for dual carrier operation derived from the Alternative EFTA Multislot Class field. The coding of this field is the same as the coding of the Multislot Capability Reduction for Downlink Dual Carrier field. This field shall be ignored if a mobile station does not support Downlink Dual Carrier. Indication of Upper Layer PDU Start Capability for RLC UM (1 bit field) This field indicates whether the mobile station supports "Indication of Upper Layer PDU Start for RLC UM" (see 3GPP TS 44.060 [76]) for RLC unacknowledged mode of operation. The field is coded as follows: 0 The mobile station does not support "Indication of Upper Layer PDU Start for RLC UM" 1 The mobile station supports "Indication of Upper Layer PDU Start for RLC UM" EMST Capability (1 bit field) This field indicates whether the mobile station supports Enhanced Multiplexing for Single TBF (EMST) (see 3GPP TS 44.060 [76]). 0 The mobile station does not support EMST 1 The mobile station supports EMST MTTI Capability (1 bit field) This field indicates whether the mobile station supports multiple TTI (MTTI) configurations (see 3GPP TS 44.060 [76]) Bit 0 MTTI configurations not supported 1 MTTI configurations supported UTRA CSG Cells Reporting (1 bit field) This field indicates whether the mobile station supports reporting of measurements and routing parameters (see 3GPP TS 44.060 [76]) for UTRAN CSG cells in packet transfer mode. This capability shall apply to each UTRA radio access mode supported by the mobile. Bit 0 Reporting of UTRAN CSG cells in packet transfer mode not supported 1 Reporting of UTRAN CSG cells in packet transfer mode supported E-UTRA CSG Cells Reporting (1 bit field) This field indicates whether the mobile station supports reporting of measurements and routing parameters (see 3GPP TS 44.060 [76]) for E-UTRAN CSG cells in packet transfer mode. This capability shall apply to each E-UTRA radio access mode supported by the mobile. Bit 0 Reporting of E-UTRAN CSG cells in packet transfer mode not supported 1 Reporting of E-UTRAN CSG cells in packet transfer mode supported DTR Capability (1 bit field) This field indicates whether the mobile station supports Dynamic Timeslot Reduction (DTR), see 3GPP TS 44.060 [76]. 0 The mobile station does not support DTR 1 The mobile station supports DTR EMSR Capability (1 bit field) This field indicates whether the mobile station supports Enhanced Multiplexing for Single RLC Entity (EMSR), see 3GPP TS 44.060 [76]. 0 The mobile station does not support EMSR 1 The mobile station supports EMSR Fast Downlink Frequency Switching Capability (1 bit field) This field indicates whether the mobile station supports fast downlink frequency switching between two consecutive TDMA frames (see 3GPP TS 45.002 [32]). 0 Fast downlink frequency switching not supported 1 Fast downlink frequency switching supported TIGHTER Capability (2 bit field) This field indicates Tightened Link Level Performance support in the MS (see 3GPP TS 45.005 [33]). The tightened performance applies to the traffic channels and signalling channels specified in 3GPP TS 45.005 [33]. Bits 2 1 0 0 TIGHTER not supported 0 1 TIGHTER supported for speech and signalling channels only 1 0 TIGHTER supported for speech and signalling channels and for GPRS and EGPRS, but not for EGPRS2 1 1 TIGHTER supported for speech and signalling channels and for GPRS, EGPRS and EGPRS2 FANR Capability (1 bit field) This field indicates whether the mobile station supports Fast Ack/Nack Reporting (see 3GPP TS 44.060 [76]) in packet transfer mode for EGPRS and, if supported, EGPRS2. If the mobile station indicates support for Reduced TTI configurations and Fast Ack/Nack Reporting using the Reduced Latency Capability Indicator then the network shall ignore FANR Capability information. 0 The mobile station does not support Fast Ack/Nack Reporting IPA Capability (1 bit field) This field indicates whether the mobile station supports Immediate Packet Assignment (IPA), see 3GPP TS 44.018 [84]. Bit 0 The mobile station does not support IPA 1 The mobile station supports IPA GERAN Network Sharing support (1 bit field) This field indicates whether the mobile station supports GERAN network sharing. A mobile station supporting GERAN network sharing shall also support the extended EARFCN value range in GERAN and indicate this in the respective bit. Bit 0 The mobile station does not support GERAN network sharing 1 The mobile station supports GERAN network sharing E-UTRA Wideband RSRQ measurements support (1 bit field) This field indicates whether the mobile station supports E-UTRA wideband RSRQ measurements (see 3GPP TS 45.008 [151]). Bit 0 The mobile station does not support E-UTRA wideband RSRQ measurements 1 The mobile station supports E-UTRA wideband RSRQ measurements UTRA Multiple Frequency Band Indicators support (1 bit field) This field indicates whether the mobile station supports multiple radio frequency bands in UTRAN (see 3GPP TS 25.331 [23c]) and whether it understands signalling of overlapping UTRA frequency bands (see 3GPP TS 44.060 [76]). Bit 0 The mobile station does not support Multiple Frequency Band Indicators in UTRAN 1 The mobile station supports Multiple Frequency Band Indicators in UTRAN E-UTRA Multiple Frequency Band Indicators support (1 bit field) This field indicates whether the mobile station supports multiple radio frequency bands in E-UTRAN (see 3GPP TS 36.331 [129]) and whether it understands signalling of overlapping E-UTRA frequency bands (see 3GPP TS 44.060 [76]). Bit 0 The mobile station does not support Multiple Frequency Band Indicators in E-UTRAN 1 The mobile station supports Multiple Frequency Band Indicators in E-UTRAN DLMC – Non-contiguous intra-band reception (2 bit field) This field indicates the intra-band non-contiguous reception mode (see 3GPP TS 45.005 [33]) supported by the mobile station in Downlink Multicarrier configurations. The absence of this field indicates that a mobile station does not support intra-band non-contiguous reception. Bit 2 1 0 0 Not supported 0 1 Supported in band E-GSM or GSM850 1 0 Supported in band DCS1800 or PCS1900 1 1 Supported in band E-GSM, or GSM850, or DCS1800 or PCS1900 DLMC – Inter-band reception (1 bit field) This field indicates the inter-band reception mode (see 3GPP TS 45.005 [33]) supported by the mobile station in Downlink Multicarrier configuration. The absence of this field indicates that a mobile station does not support inter-band reception. Bit 0 Not supported 1 Supported in band combination (E-GSM, DCS1800), or band combination (GSM850, PCS1900). DLMC – Maximum Bandwidth (2 bit field) This field indicates the maximum bandwidth supported by a mobile station. Bit 2 1 0 0 Bandwidth = 5 MHz 0 1 Bandwidth = 10 MHz 1 0 Bandwidth = 15 MHz 1 1 Bandwidth = 20 MHz DLMC – Maximum Number of Downlink Timeslots (6 bit field) This field indicates the maximum number of downlink timeslots supported by a mobile station in Downlink Multi Carrier configuration. Bit 6 5 4 3 2 1 0 0 0 0 0 0 6 TS supported 0 0 0 0 0 1 8 TS supported 0 0 0 0 1 0 10 TS supported 0 0 0 0 1 1 12 TS supported … … 1 1 1 1 0 1 128 TS supported 1 1 1 1 1 0 reserved 1 1 1 1 1 1 reserved DLMC – Maximum Number of Downlink Carriers (3 bit field) This field indicates the maximum number of downlink carriers supported by a mobile station in Downlink Multi Carrier configuration. Bit 3 2 1 0 0 0 2 carriers supported 0 0 1 4 carriers supported 0 1 0 6 carriers supported 0 1 1 8 carriers supported 1 0 0 10 carriers supported 1 0 1 12 carriers supported 1 1 0 14 carriers supported 1 1 1 16 carriers supported Extended TSC Set Capability support (1 bit field) This field indicates whether the mobile station supports the extended TSC sets when operating in the PS or CS domain (see 3GPP TS 45.002 [32]). Bit 0 The mobile station does not support Extended TSC sets 1 The mobile station supports Extended TSC sets Extended EARFCN value range (1 bit field) This field indicates whether the mobile station supports the extended EARFCN value range in GERAN (see 3GPP TS 44.060 [76]). Bit 0 The mobile station does not support extended EARFCN value range 1 The mobile station supports extended EARFCN value range (EC-)PCH monitoring support (2 bit field) This field indicates if the mobile station is capable of monitoring the PCH channel, the EC-PCH channel or both for paging based reachability. Bit 2 1 0 0 PCH supported 0 1 EC-PCH supported 1 0 PCH and EC-PCH supported 1 1 reserved EC-PCH support also indicates EC-GSM-IoT capability, see 3GPP TS 43.064 [159]. MS Sync Accuracy (4 bit field) This field indicates the guaranteed synchronization accuracy (i.e the assessment of the BTS timing) achievable by the MS when synchronizing to the downlink during the MTA and procedure and is coded as the MS Sync Accuracy field in 3GPP TS 49.031 [165]. EC uplink coverage enhancement support (1 bit field) This field indicates if the mobile station supports uplink coverage class CC5. Bit 0 The mobile station does not support uplink coverage class CC5 1 The mobile station supports uplink coverage class CC5 MTA Access Security support (1 bit field) This field indicates if the mobile station supports MTA Access Security comprising the support of the MTA Access Security and BSS Duplication Detection methods. Bit 0 The mobile station does not support MTA Access Security 1 The mobile station supports MTA Access Security EC paging indication channel monitoring support (1 bit field) This field indicates if the mobile station supports monitoring of the EC paging indication channel, see 3GPP TS 43.064 [159]. Bit 0 The mobile station does not support monitoring of the EC paging indication channel 1 The mobile station supports monitoring of the EC paging indication channel |
10.5.5.13 Spare
This is intentionally left spare.
10.5.5.14 GMM cause
The purpose of the GMM cause information element is to indicate the reason why a GMM request from the mobile station is rejected by the network.
The GMM cause information element is coded as shown in figure 10.5.129/3GPP TS 24.008 and table 10.5.147/3GPP TS 24.008.
The GMM cause is a type 3 information element with 2 octets length.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
GMM cause IEI |
octet 1 |
|||||||
Cause value |
octet 2 |
Figure 10.5.129/3GPP TS 24.008: GMM cause information element
Table 10.5.147/3GPP TS 24.008: GMM cause information element
Cause value (octet 2) |
|||||||||
Bits |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
IMSI unknown in HLR |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
Illegal MS |
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
IMEI not accepted |
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
Illegal ME |
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
GPRS services not allowed |
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
GPRS services and non-GPRS services not allowed |
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
MS identity cannot be derived by the network |
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
Implicitly detached |
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
PLMN not allowed |
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
0 |
Location Area not allowed |
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
1 |
Roaming not allowed in this location area |
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
GPRS services not allowed in this PLMN |
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
No Suitable Cells In Location Area |
|
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
MSC temporarily not reachable |
|
0 |
0 |
0 |
1 |
0 |
0 |
0 |
1 |
Network failure |
|
0 |
0 |
0 |
1 |
0 |
1 |
0 |
0 |
MAC failure |
|
0 |
0 |
0 |
1 |
0 |
1 |
0 |
1 |
Synch failure |
|
0 |
0 |
0 |
1 |
0 |
1 |
1 |
0 |
Congestion |
|
0 |
0 |
0 |
1 |
0 |
1 |
1 |
1 |
GSM authentication unacceptable |
|
0 |
0 |
0 |
1 |
1 |
0 |
0 |
1 |
Not authorized for this CSG |
|
0 |
0 |
0 |
1 |
1 |
1 |
0 |
0 |
SMS provided via GPRS in this routing area |
|
0 |
0 |
1 |
0 |
1 |
0 |
0 |
0 |
No PDP context activated |
|
0 |
0 |
1 |
1 |
0 |
0 |
0 |
0 |
} |
|
to |
} retry upon entry into a new cell |
||||||||
0 |
0 |
1 |
1 |
1 |
1 |
1 |
1 |
} |
|
0 |
1 |
0 |
1 |
1 |
1 |
1 |
1 |
Semantically incorrect message |
|
0 |
1 |
1 |
0 |
0 |
0 |
0 |
0 |
Invalid mandatory information |
|
0 |
1 |
1 |
0 |
0 |
0 |
0 |
1 |
Message type non-existent or not implemented |
|
0 |
1 |
1 |
0 |
0 |
0 |
1 |
0 |
Message type not compatible with the protocol state |
|
0 |
1 |
1 |
0 |
0 |
0 |
1 |
1 |
Information element non-existent or not implemented |
|
0 |
1 |
1 |
0 |
0 |
1 |
0 |
0 |
Conditional IE error |
|
0 |
1 |
1 |
0 |
0 |
1 |
0 |
1 |
Message not compatible with the protocol state |
|
0 |
1 |
1 |
0 |
1 |
1 |
1 |
1 |
Protocol error, unspecified |
|
Any other value received by the mobile station shall be treated as 0110 1111, "Protocol error, unspecified". Any other value received by the network shall be treated as 0110 1111, "Protocol error, unspecified". |
|||||||||
NOTE: The listed reject cause values are defined in annex G. |
10.5.5.15 Routing area identification
The purpose of the routing area identification information element is to provide an unambiguous identification of routing areas within the GPRS coverage area.
The routing area identification is a type 3 information element with 7 octets length.
The routing area identification information element is coded as shown in figure 10.5.130/3GPP TS 24.008 and table 10.5.148/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Routing Area Identification 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 |
||||||
LAC |
octet 5 |
|||||||
LAC cont’d |
octet 6 |
|||||||
RAC |
octet 7 |
Figure 10.5.130/3GPP TS 24.008: Routing area identification information element
Table 10.5.148/3GPP TS 24.008: Routing area identification information element
MCC, Mobile country code (octet 2 and 3) The MCC field is coded as in ITU-T Rec. E212, Annex A. If the RAI is deleted, the MCC and MNC shall take the value from the deleted RAI. In abnormal cases, the MCC stored in the mobile station can contain elements not in the set {0, 1 … 9}. In such cases the mobile station should transmit the stored values using full hexadecimal encoding. When receiving such an MCC, the network shall treat the RAI 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 RAI over the radio interface. In this case, bits 5 to 8 of octet 3 shall be coded as "1111". Mobile equipment shall accept RAI coded in such a way. NOTE 1: In earlier versions of this protocol, the possibility to use a one digit MNC in RAI was provided on the radio interface. However as this was not used this possibility has been deleted. NOTE 2: In earlier versions of this protocol, bits 5 to 8 of octet 3 were coded as "1111". Mobile equipment compliant with these earlier versions of the protocol may be unable to understand the 3-digit MNC format of the RAI, and therefore unable to register on a network broadcasting the RAI in this format. In abnormal cases, the MNC stored in the mobile station 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 mobile station shall transmit the stored values using full hexadecimal encoding. When receiving such an MNC, the network shall treat the RAI as deleted. The same handling shall apply for the network, if a 3-digit MNC is sent by the mobile station to a network using only a 2-digit MNC. LAC, Location area code (octet 5 and 6) In the LAC field bit 8 of octet 5 is the most significant bit and bit 1 of octet 6 the least significant bit. The coding of the location area code is the responsibility of each administration except that two values are used to mark the LAC, and hence the RAI, as deleted. Coding using full hexadecimal representation may be used. The location area code consists of 2 octets. If a RAI has to be deleted then all bits of the location area code shall be set to one with the exception of the least significant bit which shall be set to zero. If a SIM/USIM is inserted in a Mobile Equipment with the location area code containing all zeros, then the Mobile Equipment shall recognise this LAC as part of a deleted RAI. RAC, Routing area code (octet 7) In the RAC field bit 8 of octet 7 is the most significant. The coding of the routing area code is the responsibility of each administration. Coding using full hexadecimal representation may be used. The routing area code consists of 1 octet. |
10.5.5.15a Routing area identification 2
The purpose of the Routing area identification 2 information element is to provide an unambiguous identification of routing areas within the GPRS coverage area.
The Routing area identification 2 is a type 4 information element with a length of 8 octets.
The Routing area identification 2 information element is coded as shown in figure 10.5.130a/3GPP TS 24.008 and table 10.5.148a/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Routing area identification 2 IEI |
octet 1 |
|||||||
Length of routing area identification 2 contents |
octet 2 |
|||||||
octet 3 |
||||||||
Routing area identification 2 value |
||||||||
octet 8 |
Figure 10.5.130a/3GPP TS 24.008: Routing area identification 2 information element
Table 10.5.148a/3GPP TS 24.008: Routing area identification 2 information element
Routing area identification 2 value (octet 3 to 8) The routing area identification 2 value is coded as octet 2 to 7 of the Routing area identification information element. |
10.5.5.16 Spare
This is intentionally left spare.
10.5.5.17 Update result
The purpose of the update result information element is to specify the result of the associated updating procedure.
The update result is a type 1 information element.
The update result information element is coded as shown in figure 10.5.131/3GPP TS 24.008 and table 10.5.149/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Update result IEI |
FOP |
Update result value |
octet 1 |
Figure 10.5.131/3GPP TS 24.008: Update result information element
Table 10.5.149/3GPP TS 24.008: Update result information element
Update result value (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
RA updated |
|
0 |
0 |
1 |
combined RA/LA updated |
|
1 |
0 |
0 |
RA updated and ISR activated |
|
1 |
0 |
1 |
combined RA/LA updated and ISR activated |
|
All other values are reserved. |
||||
Follow-on proceed (octet 1, bit 4) |
||||
Bit |
||||
4 |
||||
0 |
Follow-on proceed |
|||
1 |
No follow-on proceed |
|||
Follow-on proceed is applicable only in Iu mode. This indication shall be ignored if received in A/Gb mode. |
10.5.5.18 Update type
The purpose of the update type information element is to specify the area the updating procedure is associated with.
The update type is a type 1 information element.
The update type information element is coded as shown in figure 10.5.132/3GPP TS 24.008 and table 10.5.150/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Update type IEI |
FOR |
Update type value |
octet 1 |
Figure 10.5.132/3GPP TS 24.008: Update type information element
Table 10.5.150/3GPP TS 24.008: Update type information element
Update type value (octet 1, bit 1 to 3) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
RA updating |
|
0 |
0 |
1 |
combined RA/LA updating |
|
0 |
1 |
0 |
combined RA/LA updating with IMSI attach |
|
0 |
1 |
1 |
Periodic updating |
|
All other values are reserved. |
||||
Follow-on request (octet 1, bit 4) |
||||
Bit |
||||
4 |
||||
0 |
No follow-on request pending |
|||
1 |
Follow-on request pending |
|||
Follow-on request pending is applicable only in Iu mode. |
||||
10.5.5.19 A&C reference number
The purpose of the A&C reference number information element is to indicate to the network in the AUTHENTICATION AND CIPHERING RESPONSE message which AUTHENTICATION AND CIPHERING REQUEST message the MS is replying to.
The A&C reference number is a type 1 information element.
The A&C reference number information element is coded as shown in figure 10.5.134/3GPP TS 24.008 and table 10.5.152/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
A&C reference number IEI |
A&C reference number value |
octet 1 |
Figure 10.5.134/3GPP TS 24.008: A&C reference number information element
Table 10.5.152/3GPP TS 24.008: A&C reference number information element
A&C reference number value (octet 1) |
Unformatted 4 bit field |
10.5.5.20 Service type
The purpose of the service type information element is to specify the purpose of the Service request procedure.
The service type is a type 1 information element.
The service type information element is coded as shown in figure 10.5.135/3GPP TS 24.008 and table 10.5.153a/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Service type IEI |
0 spare |
Service type |
octet 1 |
Figure 10.5.135/3GPP TS 24.008: Service type information element
Table 10.5.153a/3GPP TS 24.008: Service type information element
Service type value (octet 1) |
||||
Bits |
||||
3 |
2 |
1 |
||
0 |
0 |
0 |
Signalling |
|
0 |
0 |
1 |
Data |
|
0 |
1 |
0 |
Paging Response |
|
0 |
1 |
1 |
MBMS Multicast Service Reception |
|
1 |
0 |
0 |
MBMS Broadcast Service Reception |
|
All other values are reserved. |
||||
10.5.5.21 Cell Notification
The purpose of the Cell Notification information element is to indicate that the Cell Notification is supported by the network and shall be then used by MS.
The Cell Notification information element is coded as shown in figure 10.5.135a/3GPP TS 24.008.
The Cell Notification is a type 2 information element.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Cell Notification IEI |
octet 1 |
Figure 10.5.135a/3GPP TS 24.008: Cell Notification information element
10.5.5.22 PS LCS Capability
The purpose of the PS LCS Capability element is to indicate the positioning methods and additional positioning capabilities supported by the MS for the provision of location services (LCS) via the PS domain in Gb-mode.
The PS LCS Capability is a type 4 information element with a length of 4 octets.
The PS LCS Capability element is coded as shown in figure 10.5.135b/3GPP TS 24.008 and table 10.5.153b/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
PS LCS Capability IEI |
octet 1 |
|||||||
Length of PS LCS Capability contents |
octet 2 |
|||||||
MTA-E |
MTA-R |
APC |
OTD-A |
OTD-B |
GPS-A |
GPS-B |
GPS-C |
octet 3 |
0 |
0 |
Spare 0 |
0 |
0 |
0 |
MOTD |
MTA-A |
octet 4* |
Figure 10.5.135b/3GPP TS 24.008: PS LCS Capability information element
Table 10.5.153b/3GPP TS 24.008 PS LCS Capability information element
PS LCS Capability value (octet 3, bit 1 to 8) MTA-E (Multilateration Timing Advance using Extended Access Burst method) Bit 8 0 MTA-E not supported 1 MTA-E supported MTA-R (Multilateration Timing Advance using RLC data block method) Bit 7 0 MTA-R not supported 1 MTA-R supported APC (Additional Positioning Capabilities) Bit 6 0 Additional Positioning Capabilities which can be retrieved by RRLP are not supported 1 Additional Positioning Capabilities which can be retrieved by RRLP are supported OTD-A (MS assisted E-OTD) Bit 5 0 MS assisted E-OTD not supported 1 MS assisted E-OTD supported OTD-B (MS based E-OTD) Bit 4 0 MS based E-OTD not supported 1 MS based E-OTD supported GPS-A (MS assisted GPS) Bit 3 0 MS assisted GPS not supported 1 MS assisted GPS supported GPS-B (MS based GPS) Bit 2 0 MS based GPS not supported 1 MS based GPS supported GPS-C (Conventional GPS) Bit 1 0 Conventional GPS not supported 1 Conventional GPS supported PS LCS Capability value (octet 4, bit 1 to 2) MOTD (Multilateration Observed Time Difference) Bit 2 0 MOTD not supported 1 MOTD supported MTA-A (Multilateration Timing Advance using Access Burst method) Bit 1 0 MTA-A not supported 1 MTA-A supported Octet 4, bits 3-8 are spare and shall be coded as 0. |
10.5.5.23 Network feature support
The purpose of the network feature support information element is to indicate whether certain features are supported by the network. If this IE is not included then the respective features are not supported.
The network feature support is a type 1 information element.
The network feature support information element is coded as shown in figure 10.5.135c/3GPP TS 24.008 and table 10.5.153c/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Network feature support IEI |
LCS-MOLR |
MBMS |
IMS VoPS |
EMC BS |
octet 1 |
Figure 10.5.135c/3GPP TS 24.008: Network feature support information element
Table 10.5.153c/3GPP TS 24.008: Network feature support information element
Network feature support value (octet 1, bit 1 to 4) |
||||
LCS-MOLR (1 bit field) |
||||
Bit |
||||
4 |
||||
0 |
LCS-MOLR via PS domain not supported |
|||
1 |
LCS-MOLR via PS domain supported |
|||
MBMS (1 bit field) |
||||
Bit |
||||
3 |
||||
0 |
MBMS not supported |
|||
1 |
MBMS supported |
|||
IMS voice over PS session indicator (IMS VoPS) (1 bit field) |
||||
Bit |
||||
2 |
||||
0 |
IMS voice over PS session in Iu mode and A/Gb mode not supported |
|||
1 |
IMS voice over PS session supported in Iu mode, but not supported in A/Gb mode |
|||
Emergency bearer services indicator (EMC BS) (1 bit field) |
||||
Bit |
||||
1 |
||||
0 |
Emergency bearer services in Iu mode and A/Gb mode not supported |
|||
1 |
Emergency bearer services supported in Iu mode, but not supported in A/Gb mode |
|||
10.5.5.23A Additional network feature support
The purpose of the Additional network feature support information element is to indicate whether certain features are supported by the network.
The Additional network feature support is a type 4 information element with a length of 3 octets.
The Additional network feature support information element is coded as shown in figure 10.5.5.23A/3GPP TS 24.008 and table 10.5.5.23A/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||||||||
Additional network feature support IEI |
octet 1 |
||||||||||||||||
Length of additional network feature support contents |
octet 2 |
||||||||||||||||
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
ePCO |
RestrictEC |
GPRS-SMS |
octet 3 |
Figure 10.5.5.23A: Additional network feature support information element
Table 10.5.5.23A: Additional network feature support information element
GPRS-SMS supported (GPRS-SMS) (octet 3, bit 1) |
||||
Bit |
||||
1 |
||||
0 |
SMS via GPRS supported |
|||
1 |
SMS via GPRS not supported |
|||
Restriction on enhanced coverage (RestrictEC) (octet 3, bit 2) |
||||
Bit |
||||
2 |
||||
0 |
Enhanced coverage not restricted |
|||
1 |
Enhanced coverage restricted |
|||
ePCO IE supported (ePCO) (octet 3, bit 3) |
||||
Bit |
||||
3 |
||||
0 |
extended protocol configuration options IE not supported |
|||
1 |
extended protocol configuration options IE supported |
|||
Bits 4 to 8 of octet 3 are spare and shall be coded all zero. |
||||
10.5.5.24 Inter RAT information container
The purpose of the Inter RAT information container information element is to supply the network with Iu mode related information that needs to be transferred at PS inter-system handover to Iu mode (see 3GPP TS 43.129 [113]).
The Inter RAT information container information element is coded as shown in figure 10.5.150/3GPP TS 24.008.
The Inter RAT information container information element is a type 4 information element with a minimum length of 3 octets and a maximum length of 250 octets.
The Inter RAT information container contains:
– predefined configuration status information;
– mobile station security information to be used after handover to Iu mode, which includes the START-PS value that is stored by the MS at handover from Iu mode to A/Gb mode (see 3GPP TS 33.102 [5a]); and/or
– the specific Iu mode radio capabilities of the mobile station, i.e. UE RAC (see 3GPP TS 25.331 [23c]).
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Inter RAT information container IEI |
octet 1 |
|||||||
Length of inter RAT information container |
octet 2 |
|||||||
Inter RAT information container value part |
octet 3-250 |
Figure 10.5.150/3GPP TS 24.008: Inter RAT information container information element
The value part of the Inter RAT information container information element is the INTER RAT HANDOVER INFO as defined in 3GPP TS 25.331 [23c]. If this field includes padding bits, they are defined in 3GPP TS 25.331 [23c].
10.5.5.25 Requested MS information
The purpose of the Requested MS information information element is to indicate whether certain feature-related information is requested from the MS by the network. If this IE is not included then no information is requested.
The Requested MS information information element is coded as shown in figure 10.5.151/3GPP TS 24.008 and table 10.5.166/3GPP TS 24.008.
The Requested MS information is a type 1 information element.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
Requested MS information IEI |
I-RAT |
I-RAT2 |
0 0 Spare |
octet 1 |
Figure 10.5.151/3GPP TS 24.008: Requested MS information information element
Table 10.5.166/3GPP TS 24.008: Requested MS information information element
Requested MS information value (octet 1, bit 1 to 4) |
||||
I-RAT (1 bit field) |
||||
Bit |
||||
4 |
||||
0 |
Inter RAT information container IE not requested |
|||
1 |
Inter RAT information container IE requested |
|||
I-RAT2 (1 bit field) Bit 3 0 See NOTE. NOTE: The value ‘1’ was allocated in a previous version of the protocol and shall not be used. The behaviour of a mobile station receiving the Requested MS information IE with the I-RAT2 field set to the value ‘1’ is not specified. Network implementations following previous versions of the specification can set the I-RAT2 bit to request E-UTRAN Inter RAT information container IE, but an MS implementation following this version of the specification does not provide this information in the response and the procedure where the request is included can fail. |
10.5.5.26 UE network capability
See subclause 9.9.3.34 in 3GPP TS 24.301 [120].
10.5.5.27 E-UTRAN inter RAT information container
The purpose of the E-UTRAN inter RAT information container information element is to supply the network with E-UTRAN related information that needs to be transferred at Inter-RAT PS handover to E-UTRAN (see 3GPP TS 23.401 [122]).
The E-UTRAN inter RAT information container information element is coded as shown in figure 10.5.151/3GPP TS 24.008.
The E-UTRAN inter RAT information container information element is a type 4 information element with a minimum length of 3 octets and an upper length limit of 257 octets.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
E-UTRAN Inter RAT information container IEI |
octet 1 |
|||||||
Length of E-UTRAN Inter RAT information container |
octet 2 |
|||||||
E-UTRAN Inter RAT information container value part |
octet 3-257 |
Figure 10.5.151/3GPP TS 24.008: E-UTRAN inter RAT information container information element
The value part of the E-UTRAN inter RAT information container information element is formatted and coded according to the UE-EUTRA-Capability IE defined in 3GPP TS 36.331 [129].
10.5.5.28 Voice domain preference and UE’s usage setting
The purpose of the Voice domain preference and UE’s usage setting information element is to provide the network with the UE’s usage setting and the voice domain preference for WB-S1 mode. The network uses the UE’s usage setting and the voice domain preference for E-UTRAN (see 3GPP TS 24.167 [13B]) to select the RFSP index.
The UE’s usage setting bit indicates the value configured on the ME as defined in 3GPP TS 23.221 [131].
The voice domain preference for E-UTRAN bit indicates the value configured on the ME of the Voice domain preference for E-UTRAN as defined in 3GPP TS 24.167 [134].
The Voice domain preference and UE’s usage setting information element is coded as shown in figure 10.5.151A/3GPP TS 24.008 and table 10.5.166A/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||||
Voice domain preference and UE’s usage setting IEI |
octet 1 |
|||||||||||
Length of Voice domain preference and UE’s usage setting contents |
octet 2 |
|||||||||||
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
UE’s usage setting |
Voice domain preference for E-UTRAN |
octet 3 |
Figure 10.5.151A/3GPP TS 24.008: Voice domain preference and UE’s usage setting information element
Table 10.5.166A/3GPP TS 24.008: Voice domain preference and UE’s usage setting information element
Voice domain preference and UE’s usage setting value (octet 3, bit 1 to 3) |
||||
UE’s usage setting (1 bit field) |
||||
Bit |
||||
3 |
||||
0 |
Voice centric |
|||
1 |
Data centric |
|||
Voice domain preference for E-UTRAN (2 bit field) |
||||
Bit |
||||
2 |
1 |
|||
0 |
0 |
CS Voice only |
||
0 |
1 |
IMS PS Voice only |
||
1 |
0 |
CS voice preferred, IMS PS Voice as secondary |
||
1 |
1 |
IMS PS voice preferred, CS Voice as secondary |
||
MS not supporting IMS voice shall indicate "CS Voice only". MS only supporting IMS voice shall indicate "IMS PS Voice only". |
10.5.5.29 P-TMSI type
The purpose of the P-TMSI type information element is to indicate whether the P-TMSI included in the same message in an information element of type mobile identity, or the P-TMSI used by the MS to derive a foreign TLLI (see subclause 4.7.1.4.1) represents a native P-TMSI or a mapped P-TMSI.
The P-TMSI type information element information element is coded as shown in figure 10.5.5.29.1 and table 10.5.5.29.1.
The P-TMSI type is a type 1 information element.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
P-TMSI type IEI |
0 |
0 |
0 |
P-TMSI type |
octet 1 |
|||
spare |
Figure 10.5.5.29.1: P-TMSI type information element
Table 10.5.5.29.1: P-TMSI type information element
P-TMSI type (octet 1) |
||||
Bit |
||||
1 |
||||
0 |
Native P-TMSI |
|||
1 |
Mapped P-TMSI |
|||
Bits 2 to 4 of octet 1 are spare and shall be coded as zero. |
||||
10.5.5.30 Location Area Identification 2
The purpose of the Location Area Identification 2 information element is to provide an unambiguous identification of location areas within the area covered by the 3GPP system.
The Location Area Identification 2 information element is coded as shown in figure 10.5.5.30/3GPP TS 24.008 and table 10.5.5.30/3GPP TS 24.008.
The Location Area Identification 2 is a type 4 information element with 7 octets length.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Location Area Identification 2 IEI |
octet 1 |
|||||||
Length of Location Area Identification 2 IEI |
octet 2 |
|||||||
octet 3 |
||||||||
Location Area Identification 2 value |
||||||||
octet 7 |
Figure 10.5.5.30/3GPP TS 24.008: Location Area Identification 2 information element
Table 10.5.5.30/3GPP TS 24.008: Location Area Identification 2 information element
Location Area Identification 2 value (octet 3 to 7) The Location Area Identification 2 value is coded as octet 2 to 6 of the Location Area Identification information element. |
10.5.5.31 Network resource identifier container
The purpose of the Network resource identifier container information element is to provide a part of the allocated TMSI that the network will use to determine the actual NRI.
The Network resource identifier container is a type 4 information element with a length of 4 octets.
The Network resource identifier container information element is coded as shown in figure 10.5.5.31/3GPP TS 24.008 and table 10.5.5.31/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||||||
Network resource identifier container IEI |
octet 1 |
|||||||||||||
Length of Network resource identifier container contents |
octet 2 |
|||||||||||||
NRI container value |
octet 3 |
|||||||||||||
NRI container value |
spare
|
octet 4 |
Figure 10.5.5.31/3GPP TS 24.008 Network resource identifier container information element
Table 10.5.5.31/3GPP TS 24.008: Network resource identifier container information element
NRI container value (octet 3 and bit 7-8 of octet 4) The NRI container value consists of 10 bits which correspond to bits 23 to 14 of the valid TMSI. NRI container value shall start with bit 8 of octet 3, which corresponds to bit 23 of TMSI. Bit 7 of octet 4 corresponds to TMSI bit 14. Bits 6, 5, 4, 3, 2, and 1 in octet 4 are spare and shall be set to zero. |
10.5.5.32 Extended DRX parameters
The purpose of the Extended DRX parameters information element is to indicate that the MS wants to use eDRX and for the network to indicate the Paging Time Window length value and the extended DRX cycle value to be used for eDRX.
The Extended DRX parameters is a type 4 information element with a minimum length of 3 octets and a maximum length of 4 octets.
The Extended DRX parameters information element is coded as shown in figure 10.5.5.32/3GPP TS 24.008 and table 10.5.5.32/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Extended DRX parameters IEI |
octet 1 |
|||||||||
Length of Extended DRX parameters |
octet 2 |
|||||||||
Paging Time Window |
eDRX value |
octet 3 |
||||||||
Extended Paging Time Window |
octet 4* |
Figure 10.5.5.32/3GPP TS 24.008: Extended DRX parameters information element
Table 10.5.5.32/3GPP TS 24.008: Extended DRX parameters information element
Paging Time Window (PTW), octet 3 (bit 8 to 5) |
||||||||||||||||||||||
The field contains a PTW value. The PTW value can be applied for Iu mode, WB-S1 mode, NB-S1 mode, WB-N1 mode and NB-N1 mode as specified below. |
||||||||||||||||||||||
Iu mode The field contains the PTW value in seconds for Iu mode. The PTW value is used as specified in 3GPP TS 23.682 [133a]. The PTW value is derived as follows: |
||||||||||||||||||||||
bit |
||||||||||||||||||||||
8 |
7 |
6 |
5 |
Paging Time Window length |
||||||||||||||||||
0 |
0 |
0 |
0 |
0 seconds (PTW not used) |
||||||||||||||||||
0 |
0 |
0 |
1 |
1 second |
||||||||||||||||||
0 |
0 |
1 |
0 |
2 seconds |
||||||||||||||||||
0 |
0 |
1 |
1 |
3 seconds |
||||||||||||||||||
0 |
1 |
0 |
0 |
4 seconds |
||||||||||||||||||
0 |
1 |
0 |
1 |
5 seconds |
||||||||||||||||||
0 |
1 |
1 |
0 |
6 seconds |
||||||||||||||||||
0 |
1 |
1 |
1 |
7 seconds |
||||||||||||||||||
1 |
0 |
0 |
0 |
8 seconds |
||||||||||||||||||
1 |
0 |
0 |
1 |
9 seconds |
||||||||||||||||||
1 |
0 |
1 |
0 |
10 seconds |
||||||||||||||||||
1 |
0 |
1 |
1 |
12 seconds |
||||||||||||||||||
1 |
1 |
0 |
0 |
14 seconds |
||||||||||||||||||
1 |
1 |
0 |
1 |
16 seconds |
||||||||||||||||||
1 |
1 |
1 |
0 |
18 seconds |
||||||||||||||||||
1 |
1 |
1 |
1 |
20 seconds |
||||||||||||||||||
WB-S1 mode and WB-N1 mode The field contains the PTW value in seconds for WB-S1 mode and WB-N1 mode. The PTW value is used as specified in 3GPP TS 23.682 [133a] and 3GPP TS 23.501 [166]. The PTW value is derived as follows: bit |
||||||||||||||||||||||
8 |
7 |
6 |
5 |
Paging Time Window length |
||||||||||||||||||
0 |
0 |
0 |
0 |
1,28 seconds |
||||||||||||||||||
0 |
0 |
0 |
1 |
2,56 seconds |
||||||||||||||||||
0 |
0 |
1 |
0 |
3,84 seconds |
||||||||||||||||||
0 |
0 |
1 |
1 |
5,12 seconds |
||||||||||||||||||
0 |
1 |
0 |
0 |
6,4 seconds |
||||||||||||||||||
0 |
1 |
0 |
1 |
7,68 seconds |
||||||||||||||||||
0 |
1 |
1 |
0 |
8,96 seconds |
||||||||||||||||||
0 |
1 |
1 |
1 |
10,24 seconds |
||||||||||||||||||
1 |
0 |
0 |
0 |
11,52 seconds |
||||||||||||||||||
1 |
0 |
0 |
1 |
12,8 seconds |
||||||||||||||||||
1 |
0 |
1 |
0 |
14,08 seconds |
||||||||||||||||||
1 |
0 |
1 |
1 |
15,36 seconds |
||||||||||||||||||
1 |
1 |
0 |
0 |
16,64 seconds |
||||||||||||||||||
1 |
1 |
0 |
1 |
17,92 seconds |
||||||||||||||||||
1 |
1 |
1 |
0 |
19,20 seconds |
||||||||||||||||||
1 |
1 |
1 |
1 |
20,48 seconds |
||||||||||||||||||
NB-S1 mode and NB-N1 mode The field contains the PTW value in seconds for NB-S1 mode and NB-N1 mode. The PTW value is used as specified in 3GPP TS 23.682 [133a] and 3GPP TS 23.501 [166]. The PTW value is derived as follows: bit |
||||||||||||||||||||||
8 |
7 |
6 |
5 |
Paging Time Window length |
||||||||||||||||||
0 |
0 |
0 |
0 |
2,56 seconds |
||||||||||||||||||
0 |
0 |
0 |
1 |
5,12 seconds |
||||||||||||||||||
0 |
0 |
1 |
0 |
7,68 seconds |
||||||||||||||||||
0 |
0 |
1 |
1 |
10,24 seconds |
||||||||||||||||||
0 |
1 |
0 |
0 |
12,8 seconds |
||||||||||||||||||
0 |
1 |
0 |
1 |
15,36 seconds |
||||||||||||||||||
0 |
1 |
1 |
0 |
17,92 seconds |
||||||||||||||||||
0 |
1 |
1 |
1 |
20,48 seconds |
||||||||||||||||||
1 |
0 |
0 |
0 |
23,04 seconds |
||||||||||||||||||
1 |
0 |
0 |
1 |
25,6 seconds |
||||||||||||||||||
1 |
0 |
1 |
0 |
28,16 seconds |
||||||||||||||||||
1 |
0 |
1 |
1 |
30,72 seconds |
||||||||||||||||||
1 |
1 |
0 |
0 |
33,28 seconds |
||||||||||||||||||
1 |
1 |
0 |
1 |
35,84 seconds |
||||||||||||||||||
1 |
1 |
1 |
0 |
38,4 seconds |
||||||||||||||||||
1 |
1 |
1 |
1 |
40,96 seconds |
||||||||||||||||||
In NR connected to 5GCN, the Paging Time Window field is ignored and the PTW value is included in the Extended Paging Time Window field. |
||||||||||||||||||||||
eDRX value, octet 3 (bit 4 to 1) |
||||||||||||||||||||||
The field contains an eDRX value. The eDRX values are applied for A/Gb mode, Iu mode, S1 mode and N1 mode as specified below. A/Gb mode The field contains the eDRX value for A/Gb mode. The GERAN eDRX cycle length duration and Number of 51-MF per GERAN eDRX cycle values are derived from the eDRX value as follows: |
||||||||||||||||||||||
bit |
||||||||||||||||||||||
4 |
3 |
2 |
1 |
GERAN eDRX cycle length duration |
Number of 51-MF per GERAN eDRX cycle |
|||||||||||||||||
0 |
0 |
0 |
0 |
~1,88 seconds (NOTE 1, NOTE 2) |
8 |
|||||||||||||||||
0 |
0 |
0 |
1 |
~3,76 seconds (NOTE 1, NOTE 2) |
16 |
|||||||||||||||||
0 |
0 |
1 |
0 |
~7,53 seconds (NOTE 1, NOTE 2) |
32 |
|||||||||||||||||
0 |
0 |
1 |
1 |
12,24 seconds (NOTE 2) |
52 |
|||||||||||||||||
0 |
1 |
0 |
0 |
24,48 seconds (NOTE 2) |
104 |
|||||||||||||||||
0 |
1 |
0 |
1 |
48,96 seconds (NOTE 2) |
208 |
|||||||||||||||||
0 |
1 |
1 |
0 |
97,92 seconds (NOTE 2) |
416 |
|||||||||||||||||
0 |
1 |
1 |
1 |
195,84 seconds (NOTE 2) |
832 |
|||||||||||||||||
1 |
0 |
0 |
0 |
391,68 seconds (NOTE 2) |
1664 |
|||||||||||||||||
1 |
0 |
0 |
1 |
783,36 seconds (NOTE 2) |
3328 |
|||||||||||||||||
1 |
0 |
1 |
0 |
1566,72 seconds (NOTE 2) |
6656 |
|||||||||||||||||
1 |
0 |
1 |
1 |
3133,44 seconds (NOTE 2) |
13312 |
|||||||||||||||||
All other values shall be interpreted as 0000 by this version of the protocol. |
||||||||||||||||||||||
NOTE 1: The listed values are rounded. NOTE 2: The value in seconds can be calculated with the formula ((3,06 / 13) * (Number of 51-MF)). See 3GPP TS 45.001 [157], subclause 5.1. |
||||||||||||||||||||||
Iu mode |
||||||||||||||||||||||
The field contains the eDRX value for Iu mode. The UTRAN eDRX cycle length duration value is derived from the eDRX value as follows: |
||||||||||||||||||||||
bit |
||||||||||||||||||||||
4 |
3 |
2 |
1 |
UTRAN eDRX cycle length duration |
||||||||||||||||||
0 |
0 |
0 |
0 |
10,24 seconds |
||||||||||||||||||
0 |
0 |
0 |
1 |
20,48 seconds |
||||||||||||||||||
0 |
0 |
1 |
0 |
40,96 seconds |
||||||||||||||||||
0 |
0 |
1 |
1 |
81,92 seconds |
||||||||||||||||||
0 |
1 |
0 |
0 |
163,84 seconds |
||||||||||||||||||
0 |
1 |
0 |
1 |
327,68 seconds |
||||||||||||||||||
0 |
1 |
1 |
0 |
655,36 seconds |
||||||||||||||||||
0 |
1 |
1 |
1 |
1310,72 seconds |
||||||||||||||||||
1 |
0 |
0 |
0 |
1966,08 seconds |
||||||||||||||||||
1 |
0 |
0 |
1 |
2621,44 seconds |
||||||||||||||||||
All other values shall be interpreted as 0000 by this version of the protocol. |
||||||||||||||||||||||
S1 mode, NB-N1 mode, and WB-N1 mode The field contains the eDRX value for S1 mode, NB-N1 mode, and WB-N1 mode. The eDRX cycle length duration value and the eDRX cycle parameter ‘TeDRX‘ as defined in 3GPP TS 36.304 [121] are derived from the eDRX value as follows: |
||||||||||||||||||||||
bit |
||||||||||||||||||||||
4 |
3 |
2 |
1 |
eDRX cycle length duration |
eDRX cycle parameter ‘TeDRX‘ |
|||||||||||||||||
0 |
0 |
0 |
0 |
5,12 seconds (NOTE 4) |
NOTE 3 |
|||||||||||||||||
0 |
0 |
0 |
1 |
10,24 seconds (NOTE 4) |
20 |
|||||||||||||||||
0 |
0 |
1 |
0 |
20,48 seconds |
21 |
|||||||||||||||||
0 |
0 |
1 |
1 |
40,96 seconds |
22 |
|||||||||||||||||
0 |
1 |
0 |
0 |
61,44 seconds (NOTE 5) |
6 |
|||||||||||||||||
0 |
1 |
0 |
1 |
81,92 seconds |
23 |
|||||||||||||||||
0 |
1 |
1 |
0 |
102,4 seconds (NOTE 5) |
10 |
|||||||||||||||||
0 |
1 |
1 |
1 |
122,88 seconds (NOTE 5) |
12 |
|||||||||||||||||
1 |
0 |
0 |
0 |
143,36 seconds (NOTE 5) |
14 |
|||||||||||||||||
1 |
0 |
0 |
1 |
163,84 seconds |
24 |
|||||||||||||||||
1 |
0 |
1 |
0 |
327,68 seconds |
25 |
|||||||||||||||||
1 |
0 |
1 |
1 |
655,36 seconds |
26 |
|||||||||||||||||
1 |
1 |
0 |
0 |
1310,72 seconds |
27 |
|||||||||||||||||
1 |
1 |
0 |
1 |
2621,44 seconds |
28 |
|||||||||||||||||
1 |
1 |
1 |
0 |
5242,88 seconds (NOTE 6) |
29 |
|||||||||||||||||
1 |
1 |
1 |
1 |
10485,76 seconds (NOTE 6) |
210 |
|||||||||||||||||
All other values shall be interpreted as 0000 by this version of the protocol. NOTE 3: For E-UTRAN, and for E-UTRA connected to 5GCN, eDRX cycle length duration of 5,12 seconds the eDRX cycle parameter ‘TeDRX‘ is not used as a different algorithm compared to the other values is applied. See 3GPP TS 36.304 [121] for details. |
||||||||||||||||||||||
NOTE 4: The value is applicable only in WB-S1 mode and in WB-N1 mode. If received in NB-S1 mode or in NB-N1 mode it is interpreted as if the Extended DRX parameters IE were not included in the message by this version of the protocol. NOTE 5: The value is applicable only in WB-S1 mode and in WB-N1 mode. If received in NB-S1 mode or in NB-N1 mode it is interpreted as 0010 by this version of the protocol. NOTE 6: The value is applicable only in NB-S1 mode and in NB-N1 mode. If received in WB-S1 mode or in WB-N1 mode it is interpreted as 1101 by this version of the protocol. |
||||||||||||||||||||||
NR connected to 5GCN The field contains the eDRX value for NR connected to 5GCN. The eDRX cycle length duration value and the eDRX cycle parameter ‘TeDRX‘ as defined in 3GPP TS 38.304 [183] are derived from the eDRX value as follows: |
||||||||||||||||||||||
bit |
||||||||||||||||||||||
4 |
3 |
2 |
1 |
eDRX cycle length duration |
eDRX cycle parameter ‘TeDRX‘ |
|||||||||||||||||
0 |
0 |
0 |
0 |
2,56 seconds |
NOTE 7 |
|||||||||||||||||
0 |
0 |
0 |
1 |
5,12 seconds |
NOTE 7 |
|||||||||||||||||
0 |
0 |
1 |
0 |
10,24 seconds |
20 |
|||||||||||||||||
0 |
0 |
1 |
1 |
20,48 seconds |
21 |
|||||||||||||||||
0 |
1 |
0 |
0 |
40,96 seconds |
22 |
|||||||||||||||||
0 |
1 |
0 |
1 |
81,92 seconds |
23 |
|||||||||||||||||
0 |
1 |
1 |
0 |
163,84 seconds |
24 |
|||||||||||||||||
0 |
1 |
1 |
1 |
327,68 seconds |
25 |
|||||||||||||||||
1 |
0 |
0 |
0 |
655,36 seconds |
26 |
|||||||||||||||||
1 |
0 |
0 |
1 |
1310,72 seconds |
27 |
|||||||||||||||||
1 |
0 |
1 |
0 |
2621,44 seconds |
28 |
|||||||||||||||||
1 |
0 |
1 |
1 |
5242,88 seconds |
29 |
|||||||||||||||||
1 |
1 |
0 |
0 |
10485,76 seconds |
210 |
|||||||||||||||||
All other values shall be interpreted as 0000 by this version of the protocol. NOTE 7: For NR connected to 5GCN, eDRX cycle length durations of 2,56 seconds or 5,12 seconds the eDRX cycle parameter ‘TeDRX‘ is not used as a different algorithm compared to the other values is applied. See 3GPP TS 38.304 [183] for details. NOTE 8: For NR connected to 5GCN, in this release of the specification, eDRX cycle length durations larger than 10,24 seconds are not supported for the UE in 5GMM-CONNECTED mode with RRC inactive indication. |
||||||||||||||||||||||
Extended Paging Time Window (ePTW), octet 4 (bit 8 to 1) The field contains a PTW value. The PTW value is applied for NR connected to 5GCN as specified below. NR connected to 5GCN The field contains the PTW value for NR connected to 5GCN. The PTW value is used as specified in 3GPP TS 23.501 [166]. The PTW value is derived as follows: bit |
||||||||||||||||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
Paging Time Window length |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1,28 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
2,56 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
3,84 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
5,12 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
6,4 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
7,68 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
8,96 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
10,24 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
11,52 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
12,8 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
14,08 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
15,36 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
1 |
0 |
0 |
16,64 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
1 |
0 |
1 |
17,92 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
19,20 seconds |
||||||||||||||
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
20,48 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
21,76 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
0 |
0 |
1 |
23,04 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
0 |
1 |
0 |
24,32 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
0 |
1 |
1 |
25,6 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
1 |
0 |
0 |
26,88 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
1 |
0 |
1 |
28,16 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
1 |
1 |
0 |
29,44 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
0 |
1 |
1 |
1 |
30,72 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
0 |
0 |
0 |
32 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
0 |
0 |
1 |
33,28 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
0 |
1 |
0 |
34,56 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
35,84 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
1 |
0 |
0 |
37,12 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
1 |
0 |
1 |
38,4 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
39,68 seconds |
||||||||||||||
0 |
0 |
0 |
1 |
1 |
1 |
1 |
1 |
40,96 seconds |
||||||||||||||
All other values shall be interpreted as 00000000 by this version of the protocol. |
10.5.5.33 Message authentication code
The purpose of the Message authentication code information element is to protect the integrity of a NAS message.
The Message authentication code is a type 3 information element with 6 octets length.
The Message authentication code information element is coded as shown in figure 10.5.5.33-1/3GPP TS 24.008 and table 10.5.5.33-1/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Message authentication code IEI |
octet 1 |
|||||||
Length of message authentication code contents |
octet 2 |
|||||||
Message authentication code value |
octet 3 octet 6 |
Figure 10.5.5.33-1/3GPP TS 24.008: Message authentication code information element
Table 10.5.5.33-1/3GPP TS 24.008: Message authentication code information element
Message authentication code value (octet 3 to 6) This field contains the 32 bit message authentication code calculated for GMM integrity protection. Bit 1 of octet 3 contains the most significant bit, and bit 8 of octet 6 the least significant bit of these 4 octets. |
10.5.5.34 User Plane integrity indicator
The purpose of the User Plane integrity indicator information element is to indicate to the MS that it shall integrity protect user plane data in LLC layer.
The User Plane integrity indicator is allocated by the network and sent with the ATTACH ACCEPT message or ROUTING AREA UPDATE ACCEPT message to the mobile station.
The User Plane integrity indicator information element is coded as shown in figure 10.5.5.34-1/3GPP TS 24.008 and table 10.5.5.34-1/3GPP TS 24.008.
In A/Gb mode, in the case when a UMTS security context is established and if the MS supports integrity protection, , the purpose of the User Plane integrity indicator information element is to request the MS to start integrity protection of user plane data in LLC layer.
The User Plane integrity indicator is a type 1 information element.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
User Plane Integrity Indicator IEI |
0 spare |
0 spare |
0 spare |
Integrity indicator |
octet 1 |
Figure 10.5.5.34-1/3GPP TS 24.008 User Plane integrity indicator information element
Table 10.5.5.34-1/3GPP TS 24.008: User Plane integrity indicator information element
User Plane integrity indicator (octet 1) Bits |
|||
1 |
|||
0 |
MS shall disable integrity protection of user plane data in LLC layer |
||
1 |
MS shall enable integrity protection of user plane data in LLC layer |
||
Bits 2 to 4 are spare and shall be set to "0". |
10.5.5.35 DCN-ID
The purpose of the DCN-ID information element is to provide a DCN-ID for the registered PLMN to the MS.
The DCN-ID is a type 4 information element with 4 octets length.
The DCN-ID information element is coded as shown in figure 10.5.5.35-1/3GPP TS 24.008 and table 10.5.5.35-1/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
DCN-ID IEI |
octet 1 |
|||||||
Length of DCN-ID contents |
octet 2 |
|||||||
DCN-ID value |
octet 3 octet 4 |
Figure 10.5.5.35-1/3GPP TS 24.008: DCN-ID information element
Table 10.5.5.35-1/3GPP TS 24.008: DCN-ID information element
DCN-ID value (octet 3 to 4) This field contains the 16 bit DCN-ID. The coding of the DCN-ID value part is defined in 3GPP TS 23.003 [2]. |
10.5.5.36 PLMN identity of the CN operator
The purpose of the PLMN identity of the CN operator information element is to indicate the PLMN identity of the CN operator that has accepted the GPRS attach request or routing area update request in a shared network or in a multi-operator core network (MOCN) with common GERAN.
The PLMN identity of the CN operator is a type 4 information element with 5 octets length.
The PLMN identity of the CN operator information element is coded as shown in figure 10.5.5.36-1/3GPP TS 24.008 and table 10.5.5.36-1/3GPP TS 24.008.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
PLMN identity of the CN operator IEI |
octet 1 |
|||||||
Length of PLMN identity of the CN operator 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 10.5.5.36-1/3GPP TS 24.008 PLMN identity of the CN operator information element
Table 10.5.5.36-1/3GPP TS 24.008: PLMN identity of the CN operator information element
MCC, Mobile country code (octet 3, octet 4 bits 1 to 4) The MCC field is coded as in ITU-T Rec. E212, 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. 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 over the radio interface. In this case, bits 5 to 8 of octet 4 shall be coded as "1111". Mobile equipment shall accept MNC coded in such a way. |
10.5.5.37 Non-3GPP NW provided policies
The purpose of the Non-3GPP NW provided policies information element is to indicate to the MS whether emergency numbers provided via non-3GPP access (see 3GPP TS 24.302 [156]) can be used to initiate UE detected emergency calls.
The Non-3GPP NW provided policies is indicated by the network and sent with the ATTACH ACCEPT message or ROUTING AREA UPDATE ACCEPT message to the mobile station.
The Non-3GPP NW provided policies information element is coded as shown in figure 10.5.5.37-1/3GPP TS 24.008 and table 10.5.5.37-1/3GPP TS 24.008.
The Non-3GPP NW provided policies is a type 1 information element.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Non-3GPP NW provided policies IEI |
0 spare |
0 spare |
0 spare |
N3EN indicator |
octet 1 |
Figure 10.5.5.37-1/3GPP TS 24.008 Non-3GPP NW provided policies IE
Table 10.5.5.37-1/3GPP TS 24.008: Non-3GPP NW provided policies IE
Non-3GPP emergency number (N3EN) indicator (octet 1) Bits |
|||
1 |
|||
0 |
use of non-3GPP emergency numbers not permitted |
||
1 |
use of non-3GPP emergency numbers permitted |
||
Bits 2 to 4 are spare and shall be set to "0". |