8 PDUs and parameters specific to the present document
24.3023GPPAccess to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networksRelease 18Stage 3TS
8.0 General
The least significant bit of a field is represented by the lowest numbered bit of the highest numbered octet of the field. When the field extends over more than one octet, the order of bit values progressively decreases as the octet number increases.
Figure 8.0-1 shows an example of a field where the most significant bit of the field is marked MSB and the least significant bit of the field is marked LSB.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
MSB |
x |
x |
x |
x |
x |
x |
x |
octet 1 |
|
x |
x |
x |
x |
x |
x |
x |
x |
|
|
x |
x |
x |
x |
x |
x |
x |
LSB |
octet N |
Figure 8.0-1: Example of bit ordering of a field
NOTE: IETF RFCs adopted different numbering of bits, such that the least significant bit of a field is represented by the highest numbered bit of the field.
8.1 3GPP specific coding information defined within present document
8.1.1 Access Network Identity format and coding
8.1.1.1 Generic format of the Access Network Identity
The Access Network Identity shall take the generic format of an octet string without terminating null characters. The length indicator for the ANID is 2 bytes long, see IETF RFC 5448 [38]. Representation as a character string is allowed, but this character string shall be converted into an octet string of maximum length 253 according to UTF-8 encoding rules as specified in IETF RFC 3629 [34] before the Access Network Identity is input to the Key Derivation Function, as specified in 3GPP TS 33.402 [15], used in the Access Network Identity indication from 3GPP AAA server to UE, cf. clause 8.2.2 or during authentication for NSWO in 5GS as specified in annex S of 3GPP TS 33.501 [78]. The ANID is structured as an ANID Prefix and none, one or more ANID additional character strings separated by the colon character ":". In case additional ANID strings are not indicated the complete ANID consists of the ANID Prefix character string only. The ANID shall be represented by Unicode characters encoded as UTF-8 as specified in IETF RFC 3629 [34] and formatted using Normalization Form KC (NFKC) as specified in Unicode 5.1.0, Unicode Standard Annex #15; Unicode Normalization Forms [41].
8.1.1.2 Definition of Access Network Identities for Specific Access Networks
Table 8.1.1.2-1 specifies the list of Access Network Identities defined by 3GPP in the context of non-3GPP access to EPC.
Table 8.1.1.2-1: Access Network Identities in the context of non-3GPP access to EPC
|
Access Network Identity |
Type of Access Network |
|
|
ANID Prefix |
Additional ANID strings |
|
|
"HRPD" constant character string, see NOTE 1 and NOTE 2 |
No additional ANID string, see NOTE 2 and NOTE 6 |
cdma2000® HRPD access network |
|
"WIMAX" constant character string, see NOTE 1 |
No additional ANID string, see NOTE 3 and NOTE 6 |
WiMAX access network |
|
"WLAN" constant character string, see NOTE 1 |
No additional ANID string, see NOTE 4 and NOTE 6 |
WLAN access network |
|
"ETHERNET" constant character string, see NOTE 1 |
No additional ANID string, see NOTE 5 and NOTE 6 |
Fixed access network |
|
All other character strings |
Not applicable |
Not defined, see NOTE 6 and Annex B |
|
NOTE 1: The quotes are not part of the definition of the character string. NOTE 2: The value of the ANID Prefix for cdma2000® HRPD access networks is defined in 3GPP2 X.S0057 [20]. 3GPP2 is responsible for specifying possible additional ANID strings applicable to the "HRPD" ANID Prefix. NOTE 3: WiMAX Forum is responsible for specifying possible additional ANID strings applicable to the "WIMAX" ANID Prefix. NOTE 4: IEEE 802 is responsible for specifying possible additional ANID strings applicable to the "WLAN" ANID Prefix. NOTE 5: IEEE 802 is responsible for specifying possible additional ANID strings applicable to the "ETHERNET" ANID Prefix. NOTE 6: Additional ANID Prefixes and ANID strings can be added to this table following the procedure described in the informative Annex B. |
||
Table 8.1.1.2-2 specifies the list of Access Network Identities defined by 3GPP in the context of access to 5GCN.
Table 8.1.1.2-2: Access Network Identities in the context of access to 5GCN
|
Access Network Identity |
Type of Access Network |
|
|
ANID Prefix |
Additional ANID strings |
|
|
SNN-service-code, which is "5G" constant character string, see NOTE 1 and NOTE 2 |
SNN-network-identifier, see NOTE 2 |
N/A, see NOTE 3 |
|
NOTE 1: The quotes are not part of the definition of the character string. NOTE 2: Serving network name (SNN) specified in 3GPP TS 24.501 [76] is used as 5G Access Network Identity. In case of NSWO in 5GS, SNN is "5G:NSWO" as specified in 3GPP TS 24.501 [76]. NOTE 3: Type of Access Network is not applicable for 5G Access Network Identity. |
||
8.1.2 IKEv2 Notify Message Type value
8.1.2.1 Generic
The IKEv2 Notify Message Type is specified in IETF RFC 7296 [28].
The Notify Message Type with a value (in decimal) between 8192 and 16383 is reserved for private error usage.
The Notify Message Type with a value (in decimal) between 40960 and 65535 is reserved for private status usage.
Only the private IKEv2 Notify Message Types used for this specification are specified in this clause.
8.1.2.2 Private Notify Message – Error Types
The Private Notify Message, Error Types defined in table 8.1.2.2-1 are error notifications which indicates an error while negotiating an IKEv2 SA for the PDN connection to the APN requested by the UE. Refer to table 8.1.2.2-1 for more details on what each error type means.
Table 8.1.2.2-1: Private Error Types
|
Notify Message |
Value |
Descriptions |
|
PDN_CONNECTION_REJECTION |
8192 |
With an IP address information in Notification Data field: The PDN connection corresponding to the IP address information has been rejected. Without Notification Data field: The PDN connection corresponding to the requested APN has been rejected. No additional PDN connections to the given APN can be established. If the rejected PDN connection is the first PDN connection for the given APN, this APN is not allowed for the UE. |
|
MAX_CONNECTION_REACHED |
8193 |
The PDN connection has been rejected. No additional PDN connections can be established for the UE due to the network policies or capabilities. The maximum number of PDN connections per UE allowed to be established simultaneously is limited by the number of EPS bearer identities (see clause 11.2.3.1.5 of 3GPP TS 24.007 [48]) or by the number of PDU session IDs (see clause 11.2.3.1b of 3GPP TS 24.007 [48]). |
|
SEMANTIC_ERROR_IN_THE_TFT_OPERATION |
8241 |
This error type is used to indicate that the requested service was rejected due to a semantic error in the TFT operation included in the request. |
|
SYNTACTICAL_ERROR_IN_THE_TFT_OPERATION |
8242 |
This error type is used to indicate that the requested service was rejected due to a syntactical error in the TFT operation included in the request. |
|
SEMANTIC_ERRORS_IN_PACKET_FILTERS |
8244 |
This error type is used to indicate that the requested service was rejected due to a semantic error in the packet filter(s) included in the request. |
|
SYNTACTICAL_ERRORS_IN_PACKET_FILTERS |
8245 |
This error type is used to indicate that the requested service was rejected due to a syntactical error in the packet filter(s) included in the request. |
|
NON_3GPP_ACCESS_TO_EPC_NOT_ALLOWED |
9000 |
Corresponds to: – DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the UE is not allowed to use non-3GPP access to EPC. |
|
USER_UNKNOWN |
9001 |
Corresponds to: – DIAMETER_ERROR_USER_UNKNOWN Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the user identified by the IMSI is unknown. |
|
NO_APN_SUBSCRIPTION |
9002 |
Corresponds to: – DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the requested APN is not included in the user’s profile, and therefore is not authorized for that user.. |
|
AUTHORIZATION_REJECTED |
9003 |
Corresponds to: – DIAMETER_AUTHORIZATION_REJECTED Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the user is barred from using the non-3GPP access or the subscribed APN. |
|
ILLEGAL_ME |
9006 |
Corresponds to: – DIAMETER_ERROR_ILLEGAL_EQUIPMENT Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the ME used is not accepted by the network. |
|
NETWORK_FAILURE |
10500 |
Corresponds to: – DIAMETER_ERROR_UNABLE_TO_COMPLY Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the network has determined that the requested procedure cannot be completed successfully due to network failure. |
|
RAT_TYPE_NOT_ALLOWED |
11001 |
Corresponds to: – DIAMETER_RAT_TYPE_NOT_ALLOWED Result code IE as specified in 3GPP TS 29.273 [17]; or – Other scenarios when the access type is restricted to the user. |
|
IMEI_NOT_ACCEPTED |
11005 |
The emergency PDN connection request has been rejected since the network does not accept an emergency service request using an IMEI. |
|
PLMN_NOT_ALLOWED |
11011 |
Corresponds to: – DIAMETER_ERROR_ROAMING_NOT_ALLOWED Result code IE as specified in 3GPP TS 29.273 [17]; – The ePDG performs PLMN filtering (based on roaming agreements) and rejects the request from the UE; or – Other scenarios when the UE requests service in a PLMN where the UE is not allowed to operate. |
|
UNAUTHENTICATED_ EMERGENCY_ NOT_SUPPORTED |
11055 |
The emergency PDN connection request has been rejected due to authentication has failed or authentication cannot proceed at AAA server, and the ePDG does not support an emergency service request using an unauthenticated IMSI. |
The private notify message error type values:
– between 9950 and 9999;
– between 10950 and 10999;
– between 11950 and 11999;
– between 12950 and 12999;
– between 13950 and 13999;
– between 14950 and 14999; and
– between 15500 and 15599;
will not be allocated to a Notify payload defined in the present specification.
The private notify message error type values between 15500 and 15599 shall be allocated in 3GPP TS 24.502 [77].
8.1.2.3 Private Notify Message – Status Types
The Private Notify Message Status Types defined in table 8.1.2.3-1 are used to indicate status notifications or additional information in a Notify payload which may be added to an IKEv2 message or IKE_AUTH request or IKE_AUTH response message according to the procedures described in the present document. Refer to table 8.1.2.3‑1 for more details on what each status type means.
Table 8.1.2.3-1: Private Status Types
|
Notify Message |
Value |
Descriptions |
|
REACTIVATION_REQUESTED_CAUSE |
40961 |
The IPsec tunnel associated to a PDN connection is released with a cause requesting the UE to reestablish the IPsec tunnel for the same PDN Connection after its release. |
|
BACKOFF_TIMER |
41041 |
The value of the backoff timer is included in the BACKOFF_TIMER Notify payload as specified in clause 8.2.9.1. |
|
PDN_TYPE_IPv4_ONLY_ALLOWED |
41050 |
This value is used by the network to indicate that only PDN type IPv4 is allowed for the requested PDN connectivity. |
|
PDN_TYPE_IPv6_ONLY_ALLOWED |
41051 |
This value is used by the network to indicate that only PDN type IPv6 is allowed for the requested PDN connectivity. |
|
DEVICE_IDENTITY |
41101 |
The device identity type and/or identity value are included in the DEVICE_IDENTITY Notify payload as specified in clause 8.2.9.2. |
|
EMERGENCY_SUPPORT |
41112 |
This status when present indicates that the ePDG supports emergency service. The EMERGENCY_SUPPORT Notify payload is coded according to clause 8.2.9.7. |
|
EMERGENCY_CALL_NUMBERS |
41134 |
Additional local emergency call numbers that the UE may use for detecting UE initiated emergency calls. The EMERGENCY_CALL_NUMBERS Notify payload is coded according to clause 8.2.9.8. |
|
NBIFOM_GENERIC_CONTAINER |
41288 |
The NBIFOM parameters are included in the NBIFOM_GENERIC_CONTAINER Notify payload as specified in clause 8.2.9.3. |
|
P-CSCF_RESELECTION_SUPPORT |
41304 |
This status when present indicates that the UE supports the P-CSCF restoration extension for untrusted WLAN |
|
PTI |
41501 |
An INFORMATIONAL request message of an ePDG-initiated modification procedure is initiated by another INFORMATIONAL request message of an UE-initiated modification procedure. The PTI Notify payload is coded according to clause 8.2.9.5. |
|
IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY |
42011 |
This status when present indicates that the UE supports IKEv2 multiple bearer PDN connectivity. The IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload is coded according to clause 8.2.9.9. |
|
EPS_QOS |
42014 |
This status when present indicates EPS QoS. The EPS_QOS Notify payload is coded according to clause 8.2.9.10. |
|
EXTENDED_EPS_QOS |
42015 |
This status when present indicates extended EPS QoS. The EXTENDED_EPS_QOS Notify payload is coded according to clause 8.2.9.10A. |
|
TFT |
42017 |
This status when present indicates TFT. The TFT Notify payload is coded according to clause 8.2.9.11. |
|
MODIFIED_BEARER |
42020 |
This status when present indicates sender’s ESP SPI. The MODIFIED_BEARER Notify payload is coded according to clause 8.2.9.12. |
|
APN_AMBR |
42094 |
This status when present indicates APN-AMBR. The APN_AMBR Notify payload is coded according to clause 8.2.9.13. |
|
EXTENDED_APN_AMBR |
42095 |
This status when present indicates extended APN-AMBR. The EXTENDED_APN_AMBR Notify payload is coded according to clause 8.2.9.14. |
|
N1_MODE_CAPABILITY |
51015 |
This status when present indicates support of N1 mode or N1 mode capability is disabled. The N1_MODE_CAPABILITY Notify payload is coded according to clause 8.2.9.15. |
|
N1_MODE_INFORMATION |
51115 |
This status when present indicates N1 mode information. The N1_MODE_INFORMATION Notify payload is coded according to clause 8.2.9.16. |
|
N1_MODE_S_NSSAI_PLMN_ID |
52216 |
This status when present indicates the PLMN ID that the S-NSSAI relates to. The N1_MODE_S_NSSAI_PLMN_ID Notify payload is coded according to clause 8.2.9.17. |
The private notify message status type values:
– between 49950 and 49999;
– between 50950 and 50999;
– between 51950 and 51999;
– between 52950 and 52999;
– between 53950 and 53999;
– between 54950 and 54999; and
– between 55500 and 55599;
will not be allocated to a Notify payload defined in the present specification.
The private notify message status type values between 55500 and 55599 shall be allocated in 3GPP TS 24.502 [77].
8.1.3 ANDSF Push Information
8.1.3.1 General
The values of the ANDSF Push Information sent to the UE using the GAA bootstrap framework for ANDSF Push as specified in clause 6.8.2.2.2 are defined in this clause.
8.1.3.2 ANDSF Push Information values
The ANDSF Push Information defined in table 8.1.3.2-1 indicates the X-WAP-Application-ID field (Push Application ID) for ANDSF in the WSP header.
Table 8.1.3.2-1: ANDSF Push Information values
|
WSP header attribute |
Value |
Short code |
Descriptions |
|
X-WAP-Application-ID |
x-3gpp.gba.andsf.ua |
0x9071 |
The application identity indicates ANDSF |
8.1.4 PDUs for TWAN connection modes
8.1.4.0 General
The PDUs defined in this clause are used when SCM, MCM or both are supported.
The sending entity shall set value of spare bit to zero. The receiving entity shall ignore value of spare bit
8.1.4.1 Message
The message is coded according to figure 8.1.4.1-1 and table 8.1.4.1-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Message type |
octet 1 |
|||||||
|
Item list |
octet 2 octet Z |
|||||||
Figure 8.1.4.1-1: Message
Table 8.1.4.1-1: Message
|
Message type field is coded according to table 8.1.4.1-2. The message is ignored if Message type field containing a value other than those in table 8.1.4.1-2 is received. Optional Item list field contains sequence of items, each of which is coded according to clause 8.1.4.2. The receiving entity does not assume that a certain order of items will be used in the Item list. When the receiving entity does not recognize an item in the Item list, that particular item is ignored, and the receiving entity continues to process the rest of the items in the Item list. The Item list field includes at maximum one item of each type described in clause 8.1.4.2. |
Table 8.1.4.1-2: Message type
|
Message type is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
CONNECTION_CAPABILITY |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
SCM_REQUEST |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
SCM_RESPONSE |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
MCM_REQUEST |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
MCM_RESPONSE |
|
8.1.4.2 Item
The Item is coded according to figure 8.1.4.2-1 and table 8.1.4.2-1:
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Type |
octet 1 |
|||||||
|
Length |
octet 2 |
|||||||
|
Value |
octet 3 octet Z |
|||||||
Figure 8.1.4.2-1: Item
Table 8.1.4.2-1: Item
|
Type field is coded according to the table 8.1.4.2-2. When the Type field contains a type other than those specified in table 8.1.4.2-2, the entire Item is ignored. |
|
Length field indicates the number of octets in the Value field. |
|
Value field contains the parameter value of the type of item. |
Table 8.1.4.2-2: Types of item
|
The type field is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
CONNECTIVITY_TYPE |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
ATTACHMENT_TYPE |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
APN |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
PDN_TYPE |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
AUTHORIZATIONS |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
CONNECTION_MODE_CAPABILITY |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
PROTOCOL_CONFIGURATION_OPTIONS |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
CAUSE |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
IPV4_ADDRESS |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
IPV6_INTERFACE_IDENTIFIER |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
TWAG_CP_ADDRESS |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
TWAG_UP_MAC_ADDRESS |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
0 |
SUPPORTED_WLCP_TRANSPORTS |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
1 |
Tw1 |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
ACCESS CAUSE |
|
8.1.4.3 CONNECTIVITY_TYPE item
When the Type field of this item, according to clause 8.1.4.2, indicates the CONNECTIVITY_TYPE, then the Length field of this item is set to 1 and the Value field of this item is coded according to table 8.1.4.3-1.
Table 8.1.4.3-1: CONNECTIVITY_TYPE value
|
The Connectivity type value is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
PDN connection connectivity type |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
NSWO connectivity type |
|
|
All other values are interpreted as "PDN connection connectivity type". When the Connectivity Type item is received by the 3GPP AAA server, it indicates that the indicated connectivity type is requested. When the Connectivity Type item is received by the UE, it indicates that the indicated connectivity type is authorized. |
|||||||||
8.1.4.4 ATTACHMENT_TYPE item
When the Type field of this item according to clause 8.1.4.2 indicates the ATTACHMENT_TYPE, then the Length field of this item is set to 1 and the Value field of this item is coded according to table 8.1.4.4-1.
Table 8.1.4.4-1: ATTACHMENT_TYPE value
|
The ATTACHMENT TYPE value is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
Initial attach |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
Handover attach |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
Emergency attach |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
Emergency handover |
|
|
All other values are interpreted as "Initial attach". |
|||||||||
8.1.4.5 APN item
When the Type field of this item according to clause 8.1.4.2 indicates the APN, then the Value field of this item contains the APN as described in 3GPP TS 23.003 [3]. When received by the 3GPP AAA server, it indicates the requested APN. When received by the UE, it indicates the selected APN.
8.1.4.6 PDN_TYPE item
When the Type field of this item according to clause 8.1.4.2 indicates the PDN_TYPE, then the Length field of this item is set to 1 and the Value field of this item is coded according to table 8.1.4.6-1.
Table 8.1.4.6-1: PDN_TYPE value
|
The PDN type value is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
IPv4 – when received by the 3GPP AAA server, it indicates that IPv4 is requested. When received by the UE, it indicates that IPv4 is supported. |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
IPv6 – when received by the 3GPP AAA server, it indicates that IPv6 is requested. When received by the UE, it indicates that IPv6 is supported. |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
IPv4v6 – when received by the 3GPP AAA server, it indicates that IPv4, IPv6 or both are requested. When received by the UE, it indicates that both IPv4 and IPv6 are supported. |
|
|
All other values are interpreted as "IPv6". |
|||||||||
8.1.4.7 AUTHORIZATIONS item
When the Type field of this item according to clause 8.1.4.2 indicates the AUTHORIZATIONS, then the Length field of this item is set to 1 and the Value field of this item is coded according to figure 8.1.4.7-1 and table 8.1.4.7-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||||||||
|
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
NSWOA |
octet 1 |
Figure 8.1.4.7-1: AUTHORIZATIONS value
Table 8.1.4.7-1: AUTHORIZATIONS value
|
The authorization value is coded as follows: |
||
|
UE authorization to use NSWO (NSWOA) (octet 1, bit 0) |
||
|
0 |
UE is not authorized to use NSWO |
|
|
1 |
UE is authorized to use NSWO |
|
|
Bit 1 to bit 7 of octet 1 are spare. |
||
8.1.4.8 CONNECTION_MODE_CAPABILITY item
When the Type field of this item according to clause 8.1.4.2 indicates the CONNECTION_MODE_CAPABILITY, then the Length field of this item is set to 1 and the Value field of this item is coded according to figure 8.1.4.8-1 and table 8.1.4.8-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||||||||
|
0 Spare |
0 Spare |
0 Spare |
0 Spare |
ES |
TSMCI |
MCMI |
SMCI |
octet 1 |
Figure 8.1.4.8-1: CONNECTION_MODE_CAPABILITY value
Table 8.1.4.8-1: CONNECTION_MODE_CAPABILITY value
|
The Connection Mode Capability value is coded as follows: |
||
|
Support of SCM (SCMI) (octet 1, bit 0) |
||
|
0 |
SCM is not supported |
|
|
1 |
SCM is supported |
|
|
Support of MCM (MCMI) (octet 1, bit 1) |
||
|
0 |
MCM is not supported |
|
|
1 |
MCM is supported |
|
|
Support of TSCM (TSCMI) (octet 1, bit 2) |
||
|
0 |
TSCM is not supported |
|
|
1 |
TSCM is supported |
|
|
Support of emergency services (ES) (octet 1, bit 3) |
||
|
0 |
emergency services are not supported |
|
|
1 |
emergency services are supported |
|
|
Bit 4 to bit 7 of octet 1 are spare. |
||
8.1.4.9 PROTOCOL_CONFIGURATION_OPTIONS item
When the Type field of this item according to clause 8.1.4.2 indicates the PROTOCOL_CONFIGURATION_OPTIONS, then the Value field of this item is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the protocol configuration options information element defined in 3GPP TS 24.008 [46] clause 10.5.6.3.
NOTE: The protocol configuration options IEI field and the length of protocol configuration options contents field of the protocol configuration options information element are not included in the Value field of the PROTOCOL_CONFIGURATION_OPTIONS item.
8.1.4.10 CAUSE item
8.1.4.10.1 General
When the Type field of this item according to clause 8.1.4.2 indicates the CAUSE, then the Length field of this item is set to 1 and the Value field of this item is coded according to table 8.1.4.10-1. If the CAUSE item is received by the 3GPP AAA server, the item is ignored.
Semantics of the Cause values are defined in clause 8.1.4.10.2.
Table 8.1.4.10-1: CAUSE value
|
The Cause value is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
Operator determined barring |
|
|
0 |
0 |
0 |
1 |
1 |
0 |
1 |
0 |
Insufficient resources |
|
|
0 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
Unknown APN |
|
|
0 |
0 |
0 |
1 |
1 |
1 |
0 |
0 |
Unknown PDN type |
|
|
0 |
0 |
0 |
1 |
1 |
1 |
0 |
1 |
User authentication failed |
|
|
0 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
Request rejected by PDN GW |
|
|
0 |
0 |
0 |
1 |
1 |
1 |
1 |
1 |
Request rejected, unspecified |
|
|
0 |
0 |
1 |
0 |
0 |
0 |
0 |
0 |
Service option not supported |
|
|
0 |
0 |
1 |
0 |
0 |
0 |
0 |
1 |
Requested service option not subscribed |
|
|
0 |
0 |
1 |
0 |
0 |
0 |
1 |
0 |
Service option temporarily out of order |
|
|
0 |
0 |
1 |
0 |
0 |
1 |
1 |
0 |
Network failure |
|
|
0 |
0 |
1 |
1 |
0 |
0 |
1 |
0 |
PDN type IPv4 only allowed |
|
|
0 |
0 |
1 |
1 |
0 |
0 |
1 |
1 |
PDN type IPv6 only allowed |
|
|
0 |
0 |
1 |
1 |
0 |
1 |
1 |
0 |
PDN connection does not exist |
|
|
0 |
1 |
1 |
0 |
1 |
1 |
1 |
1 |
Protocol error, unspecified |
|
|
0 |
1 |
1 |
1 |
0 |
0 |
0 |
1 |
Multiple accesses to a PDN connection not allowed |
|
|
All other values received by the UE are treated as 01101111, "Protocol error, unspecified". |
|||||||||
8.1.4.10.2 Causes
Cause #8 – Operator determined barring
This cause is used by the network to indicate that the requested service was rejected due to operator determined barring.
Cause #26 – Insufficient resources
This cause is used by the network to indicate that the requested service cannot be provided due to insufficient resources.
Cause #27 – Unknown APN
This cause is used by the network to indicate that the requested service was rejected because the access point name could not be resolved.
Cause #28 – Unknown PDN type
This cause is used by the network to indicate that the requested service was rejected by the external packet data network because the PDN type could not be recognised.
Cause #29 – User authentication failed
This cause is used by the network to indicate that the requested service was rejected by the external packet data network due to a failed user authentication.
Cause #30 – Request rejected by PDN GW
This cause is used by the network to indicate that the requested service or operation was rejected by the PDN GW.
Cause #31 – Request rejected, unspecified
This cause is used by the network to indicate that the requested service or operation was rejected due to unspecified reasons.
Cause #32 – Service option not supported
This cause is used by the network when the UE requests a service which is not supported by the PLMN.
Cause #33 – Requested service option not subscribed
This cause is sent when the UE requests a service option for which it has no subscription.
Cause #34 – Service option temporarily out of order
This cause is sent when the network cannot service the request because of temporary outage of one or more functions required for supporting the service.
Cause #38 – Network failure
This cause is used by the network to indicate that the requested service was rejected due to an error situation in the network.
Cause #50 – PDN type IPv4 only allowed
This value is used by the network to indicate that only PDN type IPv4 is allowed for the requested PDN connectivity.
Cause #51 – PDN type IPv6 only allowed
This value is used by the network to indicate that only PDN type IPv6 is allowed for the requested PDN connectivity.
Cause #54 – PDN connection does not exist
This value is used by the network at handover from a 3GPP access network to indicate that the network does not have any information about the requested PDN connection.
Cause #111 – Protocol error, unspecified
This value is used to report a protocol error event only when no other value applies.
Cause #113 – Multiple accesses to a PDN connection not allowed
This value is used by the network to indicate that an additional access to the PDN connection as specified in 3GPP TS 24.161 [69] is not allowed.
This clause shows the numbers in the decimal numeration system.
8.1.4.11 IPV4_ADDRESS item
When the Type field of this item according to clause 8.1.4.2 indicates the IPV4_ADDRESS, then the Length field of this item is set to 4 and the Value field of this item contains an IPv4 address allocated to the UE for the PDN connection.
8.1.4.12 IPV6_INTERFACE_IDENTIFIER item
When the Type field of this item according to clause 8.1.4.2 indicates the IPV6_INTERFACE_IDENTIFIER, then the Length field of this item is set to 8 and the Value field of this item contains an IPv6 interface identifier allocated to the UE for the PDN connection to be used to build the IPv6 link local address.
8.1.4.13 TWAG_CP_ADDRESS item
When the Type field of this item according to clause 8.1.4.2 indicates the TWAG_CP_ADDRESS, then the Value field of this item contains one or two TWAG control plane addresses and is coded according to figure 8.1.4.13-1 and table 8.1.4.13-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
TWAG CP address type |
octet 1 |
|||||||
|
TWAG CP addresses |
octet 2 octet Z |
|||||||
Figure 8.1.4.13-1: TWAG_CP_ADDRESS item value
Table 8.1.4.13-1: TWAG_CP_ADDRESS item value
|
The TWAG CP address type field (octet 1) is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
IPv4 |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
IPv6 |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
IPv4IPv6 |
|
|
All other values of the TWAG CP address type field are interpreted as "IPv4". |
|||||||||
|
If the TWAG CP address type field indicates IPv4, then the TWAG CP addresses field contains one TWAG control plane address consisting of an IPv4 address in octet 2 to octet 5. |
|||||||||
|
If the TWAG CP address type field indicates IPv6, then the TWAG CP addresses field contains one TWAG control plane address consisting of an IPv6 address in octet 2 to octet 17. |
|||||||||
|
If the TWAG CP address type field indicates IPv4IPv6, then the TWAG CP addresses field contains two TWAG control plane addresses. The first TWAG control plane address consists of an IPv4 address in octet 2 to octet 5, the second TWAG control plane address consists of an IPv6 address in octet 6 to octet 21. |
|||||||||
8.1.4.14 TWAG_UP_MAC_ADDRESS item
When the Type field of this item according to clause 8.1.4.2 indicates the TWAG_UP_MAC_ADDRESS, then the Length field of this item is set to 6 and the Value field of this item contains a TWAG user plane MAC address allocated to the PDN connection. The MAC address is defined in clause 8 of IEEE Std 802 [58].
8.1.4.15 SUPPORTED_WLCP_TRANSPORTS item
When the Type field of this item according to clause 8.1.4.2 indicates the SUPPORTED_WLCP_TRANSPORTS, then the Length field of this item is set to 1 and the Value field of this item is coded according to figure 8.1.4.15-1 and table 8.1.4.15-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||||||||
|
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
0 Spare |
WLCPoUDPoIPv6 |
WLCPoUDPoIPv4 |
octet 1 |
Figure 8.1.4.15-1: SUPPORTED_WLCP_TRANSPORTS value
Table 8.1.4.15-1: SUPPORTED_WLCP_TRANSPORTS value
|
The Supported WLCP transport value is coded as follows: |
||
|
WLCP over UDP over IPv4 support (WLCPoUDPoIPv4) (octet 1, bit 0) |
||
|
0 |
WLCP over UDP over IPv4 is not supported. |
|
|
1 |
WLCP over UDP over IPv4 is supported. |
|
|
WLCP over UDP over IPv6 support (WLCPoUDPoIPv6) (octet 1, bit 1) |
||
|
0 |
WLCP over UDP over IPv6 is not supported. |
|
|
1 |
WLCP over UDP over IPv6 is supported. |
|
|
Bit 2 to bit 7 of octet 1 are spare. |
||
8.1.4.16 Tw1 item
When the Type field of this item according to clause 8.1.4.2 indicates the Tw1, then the Value field of this item is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the GPRS timer 3 information element defined in 3GPP TS 24.008 [46] clause 10.5.7.4a.
NOTE: The GPRS Timer 3 IEI field and the length of GPRS Timer 3 contents field of the GPRS timer 3 information element are not included in the Value field of the Tw1 item.
8.1.4.17 ACCESS_CAUSE item
8.1.4.17.1 General
When the Type field of this item according to clause 8.1.4.2 indicates the ACCESS_CAUSE, then the Length field of this item is set to 1 and the Value field of this item is coded according to table 8.1.4.17-1.
Table 8.1.4.17-1: ACCESS_CAUSE value
|
The Access cause value is coded as follows. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
Non-3GPP access to EPC not allowed |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
RAT type now allowed |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
Illegal ME |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
PLMN not allowed |
|
8.1.4.17.2 Access causes
Access cause #2- Non-3GPP access to EPC not allowed
This cause is used by the network to indicate that the requested service was rejected due to the user subscription data does not support EPS services from non-3GPP access.
Access cause #3- RAT type not allowed
This cause is used by the network to indicate that the requested service was rejected due to the WLAN is not allowed.
Access cause #6- Illegal ME
This cause is sent to the UE if the ME used is not acceptable to the network, e.g. prohibit listed.
Access cause #11- PLMN not allowed
This cause is used by the network to indicate that the requested service was rejected due to the PLMN where the UE is roaming into is not allowed.
8.2 IETF RFC coding information defined within present document
8.2.1 IPMS attributes
8.2.1.1 AT_IPMS_IND attribute
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute Type = AT_IPMS_IND |
octet 1 |
|||||||
|
Length = 1 |
octet 2 |
|||||||
|
Value |
octet 3 octet 4 |
|||||||
Figure 8.2.1.1: AT_IPMS_IND attribute
Table 8.2.1.1: AT_IPMS_IND attribute
|
Octet 1 indicates the type of attribute as AT_IPMS_IND with a value of 137. |
|||||||||
|
Octet 2 is the length of this attribute which shall be set to 1 as per IETF RFC 4187 [33] |
|||||||||
|
Octet 3 and 4 is the value of this attribute. Octet 3 is reserved and shall be coded as zero. Octet 4 shall be set as follows. All other values are reserved. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Protocol Supported |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
DSMIPv6 only |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
NBM only |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
MIPv4 only |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
DSMIPv6 and NBM both supported |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
MIPv4 and NBM both supported |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
0 |
DSMIPv6 and NBM Supported;DSMIPv6 preferred |
|
|
0 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
DSMIPv6 and NBM Supported; NBM preferred |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
MIPv4 and NBM supported; MIPv4 preferred |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
MIPv4 and NBM supported; NBM preferred |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
MIPv4 and DSMIPv6 supported; MIPv4 preferred |
|
|
0 |
0 |
0 |
0 |
1 |
0 |
1 |
1 |
MIPv4 and DSMIPv6 supported; DSMIPv6 preferred |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
0 |
MIPv4, DSMIPv6 and NBM supported; MIPv4 preferred |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
0 |
1 |
MIPv4, DSMIPv6 and NBM supported; DSMIPv6 preferred |
|
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
MIPv4, DSMIPv6 and NBM supported; NBM preferred |
|
8.2.1.2 AT_IPMS_RES attribute
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute Type = AT_IPMS_RES |
octet 1 |
|||||||
|
Length = 1 |
octet 2 |
|||||||
|
Value |
octet 3 octet 4 |
|||||||
Figure 8.2.1.2: AT_IPMS_RES attribute.
Table 8.2.1.2: AT_IPMS_RES attribute
|
Octet 1 indicates the type of attribute as AT_IPMS_RES with a value of 138. |
|||||||||
|
Octet 2 is the length of this attribute which shall be set to 1 as per IETF RFC 4187 [33] |
|||||||||
|
Octet 3 and 4 is the value of this attribute. Octet 3 is reserved and shall be coded as zero. Octet 4 shall be set as follows. All other values are reserved. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Protocol Selected |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
DSMIPv6 |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
NBM |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
MIPv4 |
|
8.2.2 Access Network Identity indication attribute
8.2.2.1 Access Network Identity in the AT_KDF_INPUT attribute
The Access Network Identity is indicated in the Network Name Field of the AT_KDF_INPUT attribute as specified in IETF RFC 5448 [38]. The Network Name Field shall contain the Access Network Identity as specified in clause 8.1.1 of this specification.
NOTE: IETF in IETF RFC 5448 [38] refers to this specification for the value of the Network Name field.
8.2.3 Trust relationship indication attribute
8.2.3.1 AT_TRUST_IND attribute
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute Type = AT_TRUST_IND |
octet 1 |
|||||||
|
Length = 1 |
octet 2 |
|||||||
|
Value |
octet 3 octet 4 |
|||||||
Figure 8.2.3.1-1: AT_TRUST_IND attribute
Table 8.2.3.1-1: AT_TRUST_IND attribute
|
Octet 1 indicates the type of attribute as AT_TRUST_IND with a value of 139. |
|||||||||
|
Octet 2 is the length of this attribute which shall be set to 1 as per IETF RFC 4187 [33] |
|||||||||
|
Octet 3 and 4 is the value of the attribute. Octet 3 is reserved and shall be coded as zero. Octet 4 shall be set as follows. All other values are reserved. |
|||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Indicated Trust Relationship |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
Trusted |
|
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
UnTrusted |
|
8.2.4 IKEv2 Configuration Payloads attributes
8.2.4.1 HOME_AGENT_ADDRESS attribute
The HOME_AGENT_ADDRESS attribute is shown in figure 8.2.4.1-1. The length of the HOME_AGENT_ADDRESS attribute is 16 or 20 bytes. The IPv4 Home Agent Address field is optional. The HA’s IPv6 and IPv4 addresses are laid out respectively in IPv6 Home Agent Address and IPv4 Home Agent Address fields in big endian order (aka most significant byte first, or network byte order), see IETF RFC 7296 [28].
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
R |
Attribute Type |
1 |
||||||
|
Attribute Type |
2 |
|||||||
|
Length |
3, 4 |
|||||||
|
IPv6 Home Agent Address |
5 – 20 |
|||||||
|
IPv4 Home Agent Address |
21 – 24 |
|||||||
Figure 8.2.4.1-1: HOME_AGENT_ADDRESS attribute
The R bit in the first octet is defined in IETF RFC 7296 [28].
The Attribute Type indicating HOME_AGENT_ADDRESS is of the value 19.
8.2.4.2 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute
The TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute is coded according to figure 8.2.4.2-1 and table 8.2.4.2-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
R |
Attribute Type |
1 |
||||||
|
Attribute Type |
2 |
|||||||
|
Length |
3, 4 |
|||||||
|
Timeout Period |
5 – 8 |
|||||||
Figure 8.2.4.2-1: TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute
Table 8.2.4.2-1: TIMEOUT_PERIOD_FOR_LIVENESS_CHECK value
|
Bit 7 of Octet 1 is the R bit defined in IETF RFC 7296 [28]. The R bit is the reserved bit set to zero. |
|
Bits 0 through 6 of Octet 1 and Octet 2 is the Attribute Type field. The Attribute Type field is set to value 24 to indicate the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK. Octet 3 and Octet 4 is the Length field. This field indicates the length in octets of the Timeout Period field. This field is set to 0 or 4. |
|
Octets 5, 6, 7 and 8 are the Timeout Period field. If the Timeout Period field is included, it indicates the timeout period for liveness check in seconds encoded in the binary format. If the Timeout Period field is not included in the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute by the UE, the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK indicates the UE’s support of receiving the timeout period for liveness check. |
8.2.5 Full name for network and short name for network
8.2.5.1 AT_FULL_NAME_FOR_NETWORK attribute
The AT_FULL_NAME_FOR_NETWORK attribute is coded according to figure 8.2.5.1-1 and table 8.2.5.1-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute Type = AT_FULL_NAME_FOR_NETWORK |
octet 1 |
|||||||
|
Length |
octet 2 |
|||||||
|
Full name length |
octet 3 |
|||||||
|
Full name value |
octet 4 octet n |
|||||||
|
Padding |
octet n+1 octet m |
|||||||
Figure 8.2.5.1-1: AT_FULL_NAME_FOR_NETWORK attribute
Table 8.2.5.1-1: AT_FULL_NAME_FOR_NETWORK attribute
|
Octet 1 indicates the type of this attribute as AT_FULL_NAME_FOR_NETWORK with a value of 141. |
|
Octet 2 is the length of this attribute in multiples of 4 octets as specified in RFC 4187 [33]. |
|
Octet 3 is the full name length field and contains the length of the full name value field in octets. |
|
The full name value field starts at octet 4 and its length is indicated by the full name length field. The full name value field indicates the "full length name of the network" that the network wishes the UE to associate with MCC and MNC in the realm of the NAI used during authentication. The structure of the full name value field is the same as the structure of the Network Name defined in 3GPP TS 24.008 [46] clause 10.5.3.5a except for the Network Name IEI and the Length of Network Name contents which are not included. |
|
The optional padding field starts after the last octet of the full name value field. Each octet of this field is set to zero by sending entity and ignored by receiving entity. |
8.2.5.2 AT_SHORT_NAME_FOR_NETWORK attribute
The AT_SHORT_NAME_FOR_NETWORK attribute is coded according to figure 8.2.5.2-1 and table 8.2.5.2-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute Type = AT_SHORT_NAME_FOR_NETWORK |
octet 1 |
|||||||
|
Length |
octet 2 |
|||||||
|
Short name length |
octet 3 |
|||||||
|
Short name value |
octet 4 octet n |
|||||||
|
Padding |
octet n+1 octet m |
|||||||
Figure 8.2.5.2-1: AT_SHORT_NAME_FOR_NETWORK attribute
Table 8.2.5.2-1: AT_SHORT_NAME_FOR_NETWORK attribute
|
Octet 1 indicates the type of this attribute as AT_SHORT_NAME_FOR_NETWORK with a value of 140. |
|
Octet 2 is the length of this attribute in multiples of 4 octets as specified in RFC 4187 [33]. |
|
Octet 3 is the short name length field and contains the length of the short name value field in octets. |
|
The short name value field starts at octet 4 and its length is indicated by the short name length field. The short name value field indicates the "abbreviated name of the network" that the network wishes the UE to associate with MCC and MNC in the realm of the NAI used during authentication. The structure of the short name value field is the same as the structure of the Network Name defined in 3GPP TS 24.008 [46] clause 10.5.3.5a except for the Network Name IEI and the Length of Network Name contents which are not included. |
|
The optional padding field starts after the last octet of the short name value field. Each octet of this field is set to zero by sending entity and ignored by receiving entity. |
8.2.6 Handling of the unknown protocol data
If the receiving entity receives an unknown value in a recognized skippable attribute in an EAP-AKA or EAP-AKA’ message, the receiving entity shall ignore the attribute and shall handle the rest of the message. The definition of skippable attribute see the RFC 4187 [33]. The receiving entity handling of the unrecognized skippable attribute is as specified in RFC 4187 [33].
8.2.7 Attributes for TWAN connection modes
8.2.7.1 AT_TWAN_CONN_MODE attribute
The AT_TWAN_CONN_MODE attribute is coded according to figure 8.2.7.1-1 and table 8.2.7.1-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute type = AT_TWAN_CONN_MODE |
octet 1 |
|||||||
|
Length |
octet 2 |
|||||||
|
Padding length |
octet 3 |
|||||||
|
Message |
octet 4 octet Y |
|||||||
|
Padding |
octet Y+1 octet Z |
|||||||
Figure 8.2.7.1-1: AT_TWAN_CONN_MODE attribute
Table 8.2.7.1-1: AT_TWAN_CONN_MODE attribute
|
Octet 1 indicates the type of attribute as AT_TWAN_CONN_MODE with a value of 144. This attribute is skippable. |
|
Octet 2 is the length of this attribute in multiples of 4 octets as specified in RFC 4187 [33]. |
|
Padding length field contains the length of the padding field. |
|
Message field is coded according to clause 8.1.4.1. The length of the message field is determined from the length field and the padding length field. |
|
Each octet of the padding field is set to zero by sending entity and ignored by receiving entity. |
8.2.8 Device Identity
8.2.8.1 AT_DEVICE_IDENTITY attribute
The AT_DEVICE_IDENTITY attribute is coded according to figure 8.2.8.1-1 and table 8.2.8.1-1.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
Attribute type = AT_DEVICE_IDENTITY |
octet 1 |
|||||||
|
Length |
octet 2 |
|||||||
|
Identity Type |
octet 3 |
|||||||
|
Identity Length |
octet 4 |
|||||||
|
Identity Value |
octet 5 octet n |
|||||||
|
Padding |
octet n+1 octet m |
|||||||
Figure 8.2.8.1-1: AT_DEVICE_IDENTITY attribute
Table 8.2.8.1-1: AT_DEVICE_IDENTITY attribute
|
Octet 1 indicates the type of attribute as AT_DEVICE_IDENTITY with a value of xxx. This attribute is skippable. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 2 is the length of this attribute in multiples of 4 octets as specified in RFC 4187 [33]. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 3 indicates the type of Device Identity.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 4 is Identity length field and contains the length of the Identity value in octets. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The Identity Value field starts at octet 5 and its length is indicated by the Identity length field. The Identity value field represents the device identity digits of the corresponding Identity type and is coded using BCD coding. The Identity Value field is optional. For Identity Type ‘IMEI’ and ‘IMEISV’, Identity value digits are coded based on the IMEI and IMEISV structure defined in 3GPP TS 23.003 [3]. IMEI is 15 BCD digits and IMEISV is 16 BCD digits. Both IMEI and IMEISV are TBCD encoded. Bits 5 to 8 of octet i+4 (where i represents the octet of the IMEI(SV) being encoded) encodes digit 2i, bits 1 to 4 of octet i+4 encodes digit 2i-1 (i.e the order of digits is swapped in each octet compared to the digit order defined in 3GPP TS 23.003 [2]). Digits are packed contiguously with no internal padding. For IMEI, bits 5 to 8 of the last octet shall be filled with an end mark coded as ‘1111’. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The optional padding field starts after the last octet of the Identity value field. Each octet of this field is set to zero by sending entity and ignored by receiving entity. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
8.2.9 IKEv2 Notify payloads
8.2.9.1 BACKOFF_TIMER Notify payload
The BACKOFF_TIMER Notify payload is used to indicate the value of the backoff timer. The BACKOFF_TIMER Notify payload type is 41041 (see clause 8.1.2.3). The length of the BACKOFF_TIMER Notify payload is 6 octets.
The BACKOFF_TIMER Notify payload is coded according to figure 8.2.9.1-1 and table 8.2.9.1-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3-4 |
|||||||
|
Length=1 |
5 |
|||||||
|
Backoff Timer Value |
6 |
|||||||
Figure 8.2.9.1-1: BACKOFF_TIMER Notify payload format
Table 8.2.9.1-1: BACKOFF_TIMER Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41041 to indicate the Backoff Timer. |
|
Octet 5 is the Length field. This field indicates the length in octets of the Backoff Timer Value field. This field is set to 1. |
|
Octet 6 is the Backoff Timer Value field. This field indicates the value of Backoff Timer. It is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the GPRS timer 3 information element defined in 3GPP TS 24.008 [46] clause 10.5.7.4a (Note 1). |
|
NOTE 1: The GPRS Timer 3 IEI field and the length of GPRS Timer 3 contents field of the GPRS timer 3 information element are not included in the value of the Backoff Timer. |
8.2.9.2 DEVICE_IDENTITY Notify payload
The DEVICE_IDENTITY Notify payload is used to indicate the device identity. The DEVICE_IDENTITY Notify payload type is 41101 (see clause 8.1.2.3).
The DEVICE_IDENTITY Notify payload is coded according to figure 8.2.2.9-1 and table 8.2.2.9-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3-4 |
|||||||
|
Length |
5-6 |
|||||||
|
Identity Type |
7 |
|||||||
|
Identity Value |
8-n |
|||||||
Figure 8.2.9.2-1: DEVICE_IDENTITY Notify payload format
Table 8.2.9.2-1: DEVICE_IDENTITY Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41101to indicate the DEVICE_IDENTITY. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 5 and Octet 6 is the Length field. This field indicates the combined length in octets of the Identity Type and Identity Value fields. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 7 is the Identity Type field. This field indicates the type of the device identity.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Octet 8-n is the Identity Value field indicating the value of the device identity. The Identity value field represents the device identity digits of the corresponding Identity type and is coded using BCD coding. The Identity Value field is optional. For Identity Type ‘IMEI’ and ‘IMEISV’, Identity value digits are coded based on the IMEI and IMEISV structure defined in 3GPP TS 23.003 [3]. IMEI is 15 BCD digits and IMEISV is 16 BCD digits. Both IMEI and IMEISV are TBCD encoded. Bits 5 to 8 of octet i+5 (where i represents the octet of the IMEI(SV) being encoded) encodes digit 2i, bits 1 to 4 of octet i+5 encodes digit 2i-1 (i.e the order of digits is swapped in each octet compared to the digit order defined in 3GPP TS 23.003 [2]). Digits are packed contiguously with no internal padding. For IMEI, bits 5 to 8 of the last octet shall be filled with an end mark coded as ‘1111’. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
8.2.9.3 NBIFOM_GENERIC_CONTAINER Notify payload
The NBIFOM_GENERIC_CONTAINER Notify payload is used to contain the NBIFOM parameters.
The NBIFOM_GENERIC_CONTAINER Notify payload is coded according to figure 8.2.9.3-1 and table 8.2.9.3-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 – 6 |
|||||||
|
NBIFOM container contents |
7 – x |
|||||||
Figure 8.2.9.3-1: NBIFOM_GENERIC_CONTAINER Notify payload
Table 8.2.9.3-1: NBIFOM_GENERIC_CONTAINER Notify payload
|
Octet 1 is defined in IETF RFC 7296 [28]. |
|
Octet 2 is the SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41288 to indicate the NBIFOM_GENERIC_CONTAINER. |
|
Octet 5 and octet 6 is the Length field. The Length field indicates the length in octets of the NBIFOM container contents field. |
|
Octet 7 to octet x is the NBIFOM container contents field containing the NBIFOM parameter list as defined in 3GPP TS 24.161 [69], clause 6.1. |
8.2.9.4 P-CSCF_RESELECTION_SUPPORT Notify payload
The P-CSCF_RESELECTION_SUPPORT Notify payload is used to indicate the support by the UE of the P-CSCF restoration extension for untrusted WLAN.
The P-CSCF_RESELECTION_SUPPORT Notify payload is coded according to figure 8.2.9.4-1 and table 8.2.9.4-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3-4 |
|||||||
Figure 8.2.9.4-1: P-CSCF_RESELECTION_SUPPORT Notify Payload format
Table 8.2.9.4-1: P-CSCF_RESELECTION_SUPPORT Notify Payload field values
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41304 to indicate the P-CSCF_RESELECTION_SUPPORT (see clause 8.1.2.3). |
8.2.9.5 PTI Notify payload
The PTI Notify payload is used to indicate that an INFORMATIONAL request message of an ePDG-initiated modification procedure is initiated by another INFORMATIONAL request message of an UE-initiated modification procedure.
The PTI Notify payload is coded according to figure 8.2.9.5-1 and table 8.2.9.5-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 – 6 |
|||||||
|
Related Message ID |
7 – 10 |
|||||||
Figure 8.2.9.5-1: PTI Notify payload
Table 8.2.9.5-1: PTI Notify payload
|
Octet 1 is defined in IETF RFC 7296 [28]. |
|
Octet 2 is the SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41501 (see clause 8.1.2.3) to indicate the PTI. |
|
Octet 5 and octet 6 is the Length field. The Length field is set to 4. |
|
Octet 7 to octet 10 is the Related Message ID field containing the Message ID field of the INFORMATIONAL request message of the UE-initiated modification procedure which initiated the ePDG-initiated modification procedure. |
8.2.9.6 REACTIVATION_REQUESTED_CAUSE Notify payload
The REACTIVATION_REQUESTED_CAUSE Notify payload is used to indicate the UE to re-establish the IPSec tunnel for the corresponding PDN connection after its release.
The REACTIVATION_REQUESTED_CAUSE Notify payload is coded according to figure 8.2.9.6-1 and table 8.2.9.6-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3-4 |
|||||||
Figure 8.2.9.6-1: REACTIVATION_REQUESTED_CAUSE Notify payload format
Table 8.2.9.6-1: REACTIVATION_REQUESTED_CAUSE Notify payload field values
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 40961 to indicate the REACTIVATION_REQUESTED_CAUSE (see clause 8.1.2.3). |
8.2.9.7 EMERGENCY_SUPPORT Notify payload
The EMERGENCY_SUPPORT Notify payload is used to indicate the ePDG support of emergency service.
The EMERGENCY_SUPPORT Notify payload is coded according to figure 8.2.9.7-1 and table 8.2.9.7-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3-4 |
|||||||
Figure 8.2.9.7-1: EMERGENCY_SUPPORT Notify Payload format
Table 8.2.9.7-1: EMERGENCY_SUPPORT Notify Payload field value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41112 to indicate the EMERGENCY_SUPPORT (see clause 8.1.2.3). |
8.2.9.8 EMERGENCY_CALL_NUMBERS Notify payload
The EMERGENCY_CALL_NUMBERS Notify payload is used:
a) by the ePDG to provide local emergency call numbers for use within the country indicated by the MCC information; and
b) by the UE to indicate support of retrieval of local emergency call numbers via IKEv2 procedures.
The EMERGENCY_CALL_NUMBERS Notify payload is coded according to figure 8.2.9.8-1 and table 8.2.9.8-1 with a minimum length of 4 octets and a maximum length of 55 octets.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
MCC information |
5 |
|||||||
|
6 |
||||||||
|
Length |
7 |
|||||||
|
Local emergency numbers |
8 – x |
|||||||
Figure 8.2.9.8-1: EMERGENCY_CALL_NUMBERS Notify payload
Table 8.2.9.8-1: EMERGENCY_CALL_NUMBERS Notify payload
|
Octet 1 is defined in IETF RFC 7296 [28]. |
|
Octet 2 is the SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 41134 to indicate the EMERGENCY_CALL_NUMBERS. |
|
Octet 5 to octet 6 contains the MCC information of the country for which the emergency numbers indicated in the local emergency numbers field are applicable. If the EMERGENCY_CALL_NUMBERS Notify payload is included in the IKE_AUTH response message, then the MCC information field shall be populated. |
|
Octet 7 is the Length field. The Length field indicates the length in octets of the Local emergency numbers field. |
|
Octet 8 to octet x is the Local emergency numbers field containing the emergency call numbers is in the same format as the Emergency Number List defined in clause 10.5.3.13 of 3GPP TS 24.008 [46], starting with octet 3. The MCC information field, length field and Local emergency numbers field are omitted when the UE sends the EMERGENCY_CALL_NUMBERS Notify payload to the network to indicate support of retrieval of local emergency call numbers. |
The format of the MCC information item is shown in figure 8.2.9.8-2. Table 8.2.9.8-2 shows the coding of the MCC in the MCC information item.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
|
MCC digit 2 |
MCC digit 1 |
5 |
|||||||
|
reserved |
MCC digit 3 |
6 |
|||||||
Figure 8.2.9.8-2: MCC information item
Table 8.2.9.8-2: MCC information item
|
MCC, Mobile country code (octet 5, octet 6 bits 1 to 4) The MCC field is coded as in ITU-T Rec. E212 [63], Annex A. Bits 5 to 8 of 6 shall be coded as "1111". Mobile equipment shall ignore bits 5 to 8 of octet 6. |
8.2.9.9 IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload
The IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload is used to indicate UE’s support of the IKEv2 multiple bearer PDN connectivity.
The IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify payload is coded according to figure 8.2.9.9-1 and table 8.2.9.9-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
Figure 8.2.9.9-1: IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify Payload format
Table 8.2.9.9-1: IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY Notify Payload field value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42011 to indicate the IKEV2_MULTIPLE_BEARER_PDN_CONNECTIVITY (see clause 8.1.2.3). |
8.2.9.10 EPS_QOS Notify payload
The EPS_QOS Notify payload is used to indicate EPS QoS.
The EPS_QOS Notify payload is coded according to figure 8.2.9.10-1 and table 8.2.9.10-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
EPS QoS Value |
6 – x |
|||||||
Figure 8.2.9.10-1: EPS_QOS Notify payload format
Table 8.2.9.10-1: EPS_QOS Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42014 to indicate the EPS_QOS (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the EPS QoS Value field. |
|
Octets 6 and later are the EPS QoS Value field. This field indicates the EPS QoS. It is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the EPS quality of service information element defined in 3GPP TS 24.301 [10] clause 9.9.4.3 (Note 1). |
|
NOTE 1: The EPS quality of service IEI field and the Length of EPS quality of service contents field of the EPS quality of service information element are not included in the value of the EPS QoS Value field. |
8.2.9.10A EXTENDED_EPS_QOS Notify payload
The EXTENDED_EPS_QOS Notify payload is used to indicate the extended EPS QoS.
The EXTENDED_EPS_QOS Notify payload is coded according to figure 8.2.9.10A-1 and table 8.2.9.10A-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
Extended EPS QoS Value |
6 – x |
|||||||
Figure 8.2.9.10A-1: EXTENDED_EPS_QOS Notify payload format
Table 8.2.9.10A-1: EXTENDED_EPS_QOS Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42015 to indicate the EXTENDED_EPS_QOS (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the Extended EPS QoS Value field. |
|
Octets 6 and later are the Extended EPS QoS Value field. This field indicates the extended EPS QoS. It is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the extended quality of service information element defined in 3GPP TS 24.301 [10] clause 9.9.4.30 (Note 1). |
|
NOTE 1: The Extended quality of service IEI field and the Length of extended quality of service contents field of the extended quality of service information element are not included in the value of the Extended EPS QoS Value field. |
8.2.9.11 TFT Notify payload
The TFT Notify payload is used to indicate TFT.
The TFT Notify payload is coded according to figure 8.2.9.11-1 and table 8.2.9.11-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
TFT Value |
6 – x |
|||||||
Figure 8.2.9.11-1: TFT Notify payload format
Table 8.2.9.11-1: TFT Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42017 to indicate the TFT (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the TFT Value field. |
|
Octets 6 and later are the TFT Value field. This field indicates the TFT. It is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the traffic flow template information element defined in 3GPP TS 24.00 [46] clause 10.5.6.12 (Note 1). |
|
NOTE 1: The Traffic flow template IEI field and the Length of traffic flow template IE field of the traffic flow template information element are not included in the value of the TFT Value field. |
8.2.9.12 MODIFIED_BEARER Notify payload
The MODIFIED_BEARER Notify payload is used to indicate ePDG’s ESP SPI of the modified child SA.
The MODIFIED_BEARER Notify payload is coded according to figure 8.2.9.12-1 and table 8.2.9.12-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Security Parameter Index |
5 – 8 |
|||||||
Figure 8.2.9.12-1: MODIFIED_BEARER Notify payload format
Table 8.2.9.12-1: MODIFIED_BEARER Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] and is set to 3 to indicate ESP. |
|
Octet 2 is SPI Size field. It is set to 4 and there is one Security Parameter Index field. |
|
Octet 3 to Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42020 to indicate the MODIFIED_BEARER (see clause 8.1.2.3). |
|
Octet 5 to Octet 8 is the Security Parameter Index field. The Security Parameter Index field contains the ePDG’s ESP SPI of the modified child SA. |
8.2.9.13 APN_AMBR Notify payload
The APN_AMBR Notify payload is used to indicate the APN-AMBR.
The APN_AMBR Notify payload is coded according to figure 8.2.9.13-1 and table 8.2.9.13-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
APN AMBR Value |
6 – x |
|||||||
Figure 8.2.9.13-1: APN_AMBR Notify payload format
Table 8.2.9.13-1: APN_AMBR Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42094 to indicate the APN_AMBR (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the APN AMBR Value field. |
|
Octets 6 and later are the APN AMBR Value field. This field indicates the APN-AMBR. It is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the APN aggregate maximum bit rate information element defined in 3GPP TS 24.301 [10] clause 9.9.4.2 (Note 1). |
|
NOTE 1: The APN aggregate maximum bit rate IEI field and the Length of APN aggregate maximum bit rate contents field of the APN aggregate maximum bit rate information element are not included in the value of the APN AMBR Value field. |
8.2.9.14 EXTENDED_APN_AMBR Notify payload
The EXTENDED_APN_AMBR Notify payload is used to indicate the extended APN-AMBR.
The EXTENDED_APN_AMBR Notify payload is coded according to figure 8.2.9.14-1 and table 8.2.9.14-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
Extended APN AMBR Value |
6 – x |
|||||||
Figure 8.2.9.14-1: EXTENDED_APN_AMBR Notify payload format
Table 8.2.9.14-1: EXTENDED_APN_AMBR Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28] |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 42095 to indicate the EXTENDED_APN_AMBR (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the Extended APN AMBR Value field. |
|
Octets 6 and later are the Extended APN AMBR Value field. This field indicates the extended APN-AMBR. It is coded as the value part (as specified in 3GPP TS 24.007 [48] for type 4 IE) of the extended APN aggregate maximum bit rate information element defined in 3GPP TS 24.301 [10] clause 9.9.4.29 (Note 1). |
|
NOTE 1: The Extended APN aggregate maximum bit rate IEI field and the Length of extended APN aggregate maximum bit rate contents of the extended APN aggregate maximum bit rate are not included in the value of the Extended APN AMBR Value field. |
8.2.9.15 N1_MODE_CAPABILITY Notify payload
The N1_MODE_CAPABILITY Notify payload is used to indicate support of N1 mode or N1 mode capability is disabled, and to indicate the PDU session ID allocated to the PDU session associated with the IKEv2 security association being established by the IKEv2 message carrying the N1_MODE_CAPABILITY Notify payload.
The N1_MODE_CAPABILITY Notify payload is coded according to figure 8.2.9.15-1 and table 8.2.9.15-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
PDU Session ID |
6 |
|||||||
Figure 8.2.9.15-1: N1_MODE_CAPABILITY Notify payload format
Table 8.2.9.15-1: N1_MODE_CAPABILITY Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28]. |
|
Octet 2 is SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 is the Notify Message Type field. The Notify Message Type field is set to value 51015 to indicate the N1_MODE_CAPABILITY (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the PDU Session ID field. |
|
Octets 6 is the PDU Session ID field. This field indicates the PDU session ID. It is coded as the PDU session identity information element defined in 3GPP TS 24.007 [48] clause 11.2.3.1b. |
8.2.9.16 N1_MODE_INFORMATION Notify payload
The N1_MODE_INFORMATION Notify payload is used to indicate the S-NSSAI for the PDU session associated with the IKEv2 security association established by the IKEv2 message carrying the N1_MODE_INFORMATION Notify payload.
The N1_MODE_INFORMATION Notify payload is coded according to figure 8.2.9.16-1 and table 8.2.9.16-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
S-NSSAI Value |
6 – x |
|||||||
Figure 8.2.9.16-1: N1_MODE_INFORMATION Notify payload format
Table 8.2.9.16-1: N1_MODE_INFORMATION Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28]. |
|
Octet 2 is the SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 are the Notify Message Type field. The Notify Message Type field is set to value 51115 to indicate the N1_MODE_INFORMATION (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the S-NSSAI Value field. |
|
Octets 6 and later are the S-NSSAI Value field. This field indicates the S-NSSAI value. It is coded as the value part of the S-NSSAI information element defined in 3GPP TS 24.501 [76] clause 9.11.2.8. |
8.2.9.17 N1_MODE_S_NSSAI_PLMN_ID Notify payload
The N1_MODE_S_NSSAI_PLMN_ID Notify payload is used to indicate the PLMN ID that the S-NSSAI relates to for the PDU session associated with the IKEv2 security association established by the IKEv2 message carrying the N1_MODE_S_NSSAI_PLMN_ID Notify payload.
The N1_MODE_S_NSSAI_PLMN_ID Notify payload is coded according to figure 8.2.9.17-1 and table 8.2.9.17-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Protocol ID |
1 |
|||||||
|
SPI Size |
2 |
|||||||
|
Notify Message Type |
3 – 4 |
|||||||
|
Length |
5 |
|||||||
|
S-NSSAI PLMN ID |
6 – 8 |
|||||||
Figure 8.2.9.17-1: N1_MODE_S_NSSAI_PLMN_ID Notify payload format
Table 8.2.9.17-1: N1_MODE_S_NSSAI_PLMN_ID Notify payload value
|
Octet 1 is defined in IETF RFC 7296 [28]. |
|
Octet 2 is the SPI Size field. It is set to 0 and there is no Security Parameter Index field. |
|
Octet 3 and Octet 4 are the Notify Message Type field. The Notify Message Type field is set to value 52216 to indicate the N1_MODE_S_NSSAI_PLMN_ID (see clause 8.1.2.3). |
|
Octet 5 is the Length field. This field indicates the length in octets of the S-NSSAI PLMN ID field. |
|
Octets 6, 7 and 8 are the S-NSSAI PLMN ID field. This field indicates the PLMN ID that the S-NSSAI relates to. It is coded as the value part of the PLMN identity of the CN operator information element defined in 3GPP TS 24.008 [46] clause 10.5.5.36. |
8.2.10 EAP-3GPP-LimitedService method
8.2.10.1 General
The messages of EAP-3GPP-LimitedService method are EAP requests and EAP responses as specified in IETF RFC 3748 [29] clause 4.1 and use coding of the expanded method type as described in IETF RFC 3748 [29] clause 5.7.
The sending entity shall set value of a spare bit to zero. The receiving entity shall ignore value of a spare bit.
8.2.10.2 Message format
8.2.10.2.1 EAP-Request/3GPP-LimitedService-Init-Info message
EAP-Request/3GPP-LimitedService-Init-Info message is coded as specified in figure 8.2.10.2.1-1 and table 8.2.10.2.1-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Code |
1 |
|||||||
|
Identifier |
2 |
|||||||
|
Length |
3 – 4 |
|||||||
|
Type |
5 |
|||||||
|
Vendor-Id |
6 – 8 |
|||||||
|
Vendor-Type |
9 – 12 |
|||||||
|
Message-Id |
13 |
|||||||
|
Spare |
14 |
|||||||
|
EAP-AKA attributes length |
15 – 16 |
|||||||
|
EAP-AKA attributes |
17 – n |
|||||||
|
Extensions |
n+1 – m |
|||||||
Figure 8.2.10.2.1-1: EAP-Request/3GPP-LimitedService-Init-Info message
Table 8.2.10.2.1-1: EAP-Request/3GPP-LimitedService-Init-Info message
|
Code field is set to 1 (decimal) as specified in IETF RFC 3748 [29] clause 4.1 and indicates request. |
|
Identifier field is set as specified in IETF RFC 3748 [29] clause 4.1. |
|
Length field is set as specified in IETF RFC 3748 [29] clause 4.1 and indicates the length of the EAP-Request/3GPP-LimitedService-Init-Info message in octets. |
|
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [29] clause 5.7 and indicates the expanded type. |
|
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
|
Vendor-Type field is set to EAP-3GPP-LimitedService method identifier of 2 (decimal) as specified in 3GPP TS 33.402 [15] annex C. |
|
Message-Id field is set to 3GPP-LimitedService-Init-Info-Id of 1 (decimal). |
|
Spare field consists of spare bits. |
|
EAP-AKA attributes length field indicates the length of EAP-AKA attributes field in octets. |
|
EAP-AKA attributes field contains attributes as specified in IETF RFC 4187 [33]. |
|
Extensions field is an optional field and consists of spare bits. |
8.2.10.2.2 EAP-Response/3GPP-LimitedService-Init-Info message
EAP-Response/3GPP-LimitedService-Init-Info message is coded as specified in figure 8.2.10.2.2-1 and table 8.2.10.2.2-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Code |
1 |
|||||||
|
Identifier |
2 |
|||||||
|
Length |
3 – 4 |
|||||||
|
Type |
5 |
|||||||
|
Vendor-Id |
6 – 8 |
|||||||
|
Vendor-Type |
9 – 12 |
|||||||
|
Message-Id |
13 |
|||||||
|
Spare |
14 |
|||||||
|
EAP-AKA attributes length |
15 – 16 |
|||||||
|
EAP-AKA attributes |
17 – n |
|||||||
|
Extensions |
n+1 – m |
|||||||
Figure 8.2.10.2.2-1: EAP-Response/3GPP-LimitedService-Init-Info message
Table 8.2.10.2.2-1: EAP-Response/3GPP-LimitedService-Init-Info message
|
Code field is set to 2 (decimal) as specified in IETF RFC 3748 [29] clause 4.1 and indicates response. |
|
Identifier field is set as specified in IETF RFC 3748 [29] clause 4.1. |
|
Length field is set as specified in IETF RFC 3748 [29] clause 4.1 and indicates the length of the EAP-Response/3GPP-LimitedService-Init-Info message in octets. |
|
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [29] clause 5.7 and indicates the expanded type. |
|
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
|
Vendor-Type field is set to EAP-3GPP-LimitedService method identifier of 2 (decimal) as specified in 3GPP TS 33.402 [15] annex C. |
|
Message-Id field is set to 3GPP-LimitedService-Init-Info-Id of 1 (decimal). |
|
Spare field consists of spare bits. |
|
EAP-AKA attributes length field indicates the length of EAP-AKA attributes field in octets. |
|
EAP-AKA attributes field contains attributes as specified in IETF RFC 4187 [33]. |
|
Extensions field is an optional field and consists of spare bits. |
8.2.10.2.3 EAP-Request/3GPP-LimitedService-Notif message
EAP-Request/3GPP-LimitedService-Notif message is coded as specified in figure 8.2.10.2.3-1 and table 8.2.10.2.3-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Code |
1 |
|||||||
|
Identifier |
2 |
|||||||
|
Length |
3 – 4 |
|||||||
|
Type |
5 |
|||||||
|
Vendor-Id |
6 – 8 |
|||||||
|
Vendor-Type |
9 – 12 |
|||||||
|
Message-Id |
13 |
|||||||
|
Spare |
14 |
|||||||
|
EAP-AKA attributes length |
15 – 16 |
|||||||
|
EAP-AKA attributes |
17 – n |
|||||||
|
Extensions |
n+1 – m |
|||||||
Figure 8.2.10.2.3-1: EAP-Request/3GPP-LimitedService-Notif message
Table 8.2.10.2.3-1: EAP-Request/3GPP-LimitedService-Notif message
|
Code field is set to 1 (decimal) as specified in IETF RFC 3748 [29] clause 4.1 and indicates request. |
|
Identifier field is set as specified in IETF RFC 3748 [29] clause 4.1. |
|
Length field is set as specified in IETF RFC 3748 [29] clause 4.1 and indicates the length of the EAP-Request/3GPP-LimitedService-Notif message in octets. |
|
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [29] clause 5.7 and indicates the expanded type. |
|
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
|
Vendor-Type field is set to EAP-3GPP-LimitedService method identifier of 2 (decimal) as specified in 3GPP TS 33.402 [15] annex C. |
|
Message-Id field is set to 3GPP-LimitedService-Notif-Id of 2 (decimal). |
|
Spare field consists of spare bits. |
|
EAP-AKA attribute length field indicates the length of EAP-AKA attributes field in octets. |
|
EAP-AKA attributes field contains attributes as specified in IETF RFC 4187 [33]. |
|
Extensions field is an optional field and consists of spare bits. |
8.2.10.2.4 EAP-Response/3GPP-LimitedService-Notif message
EAP-Response/3GPP-LimitedService-Notif message is coded as specified in figure 8.2.10.2.4-1 and table 8.2.10.2.4-1.
|
Bits |
||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
|
Code |
1 |
|||||||
|
Identifier |
2 |
|||||||
|
Length |
3 – 4 |
|||||||
|
Type |
5 |
|||||||
|
Vendor-Id |
6 – 8 |
|||||||
|
Vendor-Type |
9 – 12 |
|||||||
|
Message-Id |
13 |
|||||||
|
Extensions |
14 -m |
|||||||
Figure 8.2.10.2.4-1: EAP-Response/3GPP-LimitedService-Notif message
Table 8.2.10.2.4-1: EAP-Response/3GPP-LimitedService-Notif message
|
Code field is set to 2 (decimal) as specified in IETF RFC 3748 [29] clause 4.1 and indicates response. |
|
Identifier field is set as specified in IETF RFC 3748 [29] clause 4.1. |
|
Length field is set as specified in IETF RFC 3748 [29] clause 4.1 and indicates the length of the EAP-Response/3GPP-LimitedService-Notif message message in octets. |
|
Type field is set to 254 (decimal) as specified in IETF RFC 3748 [29] clause 5.7 and indicates the expanded type. |
|
Vendor-Id field is set to the 3GPP Vendor-Id of 10415 (decimal) registered with IANA under the SMI Private Enterprise Code registry. |
|
Vendor-Type field is set to EAP-3GPP-LimitedService method identifier of 2 (decimal) as specified in 3GPP TS 33.402 [15] annex C. |
|
Message-Id field is set to 3GPP-LimitedService-Notif-Id of 2 (decimal). |
|
Extensions field is an optional field and consists of spare bits. |
Annex A (informative):
Example signalling flows for inter-system change between 3GPP and non-3GPP systems using ANDSF