Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.502  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   7…   7.3…   7.3A…   7.4…   7.6…   7.9…   7A…   8…   9…

 

8  Message transport procedures

8.1  General

In trusted and untrusted non-3GPP access, the UE establishes IKE SA and signalling IPsec SA i.e. the first child SA for NAS message exchange. Thereafter the UE establishes other child SAs for exchange of the user data packets. IPsec tunnel mode is employed for all the established child SAs including the first child SA for the signalling, to protect and encrypt the original IP user data packets, the original IP signalling packets and the port numbers used for communications of such IP packets. This clause is to list the parameters and the procedures for such IP tunneling mode of the signalling IPsec SA and the user data child SAs.
In wireline access, the 5G-RG establishes W-CP signalling connection as described in clause 7A. Thereafter the W-AGF serving the 5G-RG and the 5G-RG establish W-UP bearers for exchange of the user data packets as specified in subclause 4.4.2.2.
Up

8.2  Transport of NAS messages over control planeWord‑p. 57

8.2.1  General

In trusted and untrusted non-3GPP access, after the completion of IKE SA and establishment of signalling IPsec SA as specified in subclause 7.3 for untrusted non-3GPP access and subclause 7.3A for trusted non-3GPP access, the UE establishes with the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access a TCP connection for transport of NAS messages over the inner IP layer and the signalling IPsec SA as specified in subclause 8.2.3. Once the TCP connection for transport of NAS messages is established, the UE performs NAS procedures over the TCP connection for transport of NAS messages. All uplink and downlink NAS mobility management messages and NAS session management messages are relayed between the UE and the AMF via N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access using the TCP connection for transport of NAS messages as specified in subclause 8.2.4. Once the TCP connection is established and upon detection of a TCP connection failure, the UE and the N3IWF for untrusted non-3GPP access or the UE and the TNGF for trusted non-3GPP access re-establish the TCP connection as specified in subclause 8.2.3A. When the TCP connection for transport of NAS messages is no longer needed, the UE, the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access release the TCP connection as specified in subclause 8.2.5.
In wireline access, after completion of EAP-5G authentication as specified in clause 7A, all uplink and downlink NAS mobility management messages and NAS session management messages are relayed between the 5G-RG and the AMF via W-AGF serving the 5G-RG using the W-CP signalling connection without EAP-5G encapsulation. Transport using the W-CP signalling connection is out of scope of the present document.
Up

8.2.2  TCP packet encapsulation

If a TCP packet is transported between the UE and the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access, and:
a)
if the IKE_AUTH response message contained the INTERNAL_IP4_ADDRESS attribute and the NAS_IP4_ADDRESS notify payload, an inner IPv4 datagram shall be constructed where:
  1. the TCP packet shall be encapsulated in the inner IPv4 datagram with IPv4 header where:
    1. if the UE constructs the inner IPv4 datagram:
      • the source address field shall be set to the IPv4 address in the INTERNAL_IP4_ADDRESS attribute;
      • the destination address field shall be set to the IPv4 address in the NAS_IP4_ADDRESS notify payload; and
      • the destination port number shall be set to the NAS_TCP_PORT notify payload;
    2. if the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access constructs the inner IPv4 datagram:
      • the source address field shall be set to the IPv4 address in the NAS_IP4_ADDRESS notify payload;
      • the source port number shall be set to the NAS_TCP_PORT notify payload;
      • the destination address field shall be set to the IPv4 address in the INTERNAL_IP4_ADDRESS attribute; and
      • the destination port number shall be set to the UE's TCP port number; and
  2. the protocol field shall be set to 06H;
  3. the inner IPv4 datagram shall be protected employing the ESP protocol in tunnel mode as specified in RFC 4303 where:
    1. the SPI field in the ESP packet shall be set to the SPI of the signalling IPsec SA; and
    2. the next header field in the ESP packet shall be set to 04H; and
  4. the IP packet encapsulating the ESP protected inner IPv4 datagram shall be sent to the peer for the SPI of the signalling IPsec SA; or
b)
if the IKE_AUTH response message contained the INTERNAL_IP6_ADDRESS attribute and the NAS_IP6_ADDRESS notify payload, an inner IPv6 datagram shall be constructed where:
  1. the TCP packet shall be encapsulated in the inner IPv6 datagram with IPv6 header where:
    1. if the UE constructs the inner IPv6 datagram:
      • the source address field shall be set to the IPv6 address in the INTERNAL_IP6_ADDRESS attribute;
      • the source port number shall be set to the UE's TCP port number;
      • the destination address field shall be set to the IPv6 address in the NAS_IP6_ADDRESS notify payload; and
      • the destination port number shall be set to the NAS_TCP_PORT notify payload;
    2. if the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access constructs the inner IPv6 datagram:
      • the source address field shall be set to the IPv6 address in the NAS_IP6_ADDRESS notify payload;
      • the source port number shall be set to the NAS_TCP_PORT notify payload;
      • the destination address field shall be set to the IPv6 address in the INTERNAL_IP6_ADDRESS attribute; and
      • the destination port number shall be set to the UE's TCP port number; and
    3. the next header field shall be set to 06H;
  2. the inner IPv6 datagram shall be protected employing the ESP protocol in tunnel mode as specified in RFC 4303 where:
    1. the SPI field in the ESP packet shall be set to the SPI of the signalling IPsec SA; and
    2. the next header field in the ESP packet shall be set to 29H, and
  3. the IP packet encapsulating the ESP protected inner IPv6 datagram shall be sent to the peer for the SPI of the signalling IPsec SA.
If the UE receives an IKE_AUTH response message containing both NAS_IP4_ADDRESS and NAS_IP6_ADDRESS notify payload, the UE:
  1. shall select and use either NAS_IP4_ADDRESS or NAS_IP6_ADDRESS;
  2. shall not switch between NAS_IP4_ADDRESS and NAS_IP6_ADDRESS for TCP packet transport during the lifetime of the IKE SA; and
  3. shall not switch between NAS_IP4_ADDRESS and NAS_IP6_ADDRESS when rekeying any child SA or IKE SA.
The ESP packet format is shown in figure 8.2.2-1 and figure 8.2.2-2:
Reproduction of 3GPP TS 24.502, Figure 8.2.2-1: ESP packet format for TCP packet (re-)establishing or releasing TCP connection
Up
Reproduction of 3GPP TS 24.502, Figure 8.2.2-2: ESP packet format for TCP packet encapsulating NAS message or partial NAS message
Up

8.2.3  Establishment of TCP connection for transport of NAS messagesWord‑p. 59
For transport of NAS messages, the UE shall initiate establishment of a TCP connection as defined in RFC 793. The UE and the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall construct and transport TCP packets according to subclause 8.2.2.

8.2.3A  Re-establishment of TCP connection for transport of NAS messages |R16|

The UE, the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access upon detection that the transport of a NAS message over the TCP connection is unsuccessful due to TCP connection failure, e.g. as indicated by the reception of a TCP error message, shall re-establish the TCP connection as defined in RFC 793. The UE and the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall construct and transport TCP packets according to subclause 8.2.2.
Up

8.2.4  Transport of NAS messages over TCP connection

In order to transport a NAS message over the untrusted non-3GPP access between the UE and the N3IWF or over the trusted non-3GPP access between the UE and the TNGF:
  1. the NAS message shall be framed in a NAS message envelope as defined in subclause 9.4;
  2. the NAS message envelope shall be transported as a payload of one or more TCP packets using the TCP connection; and
  3. the UE and the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall transport the one or more TCP packets encapsulating the NAS message envelope according to subclause 8.2.2.
Up

8.2.5  Release of TCP connection for transport of NAS messages

In order to release the TCP connection for transport of NAS messages, the UE, the N3IWF for untrusted non-3GPP access or the TNGF for trusted non-3GPP access shall initiate release of the TCP connection as defined in RFC 793. The UE, the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access shall construct and transport TCP packets according to subclause 8.2.2.
Up

8.3  Transport of messages over user planeWord‑p. 60

8.3.1  General

In trusted and untrusted non-3GPP access, after the completion of PDU session establishment via non-3GPP access, user plane IPsec SAs are established as specified in subclause 7.5. The UE is able to send and receive GRE encapsulated user data packets over non-3GPP access network via N3IWF in untrusted non-3GPP access and TNGF in trusted non-3GPP access. GRE encapsulation of user plane data packets is described in subclause 8.3.2.
In wireline access, after the completion of PDU session establishment via wireline access, one or more W-UP resources are established as specified in subclause 4.4.2.2. The 5G-RG is able to send and receive the user data packet, the QFI associated with the downlink user data packet, and RQI (in downlink direction only) via the selected W-UP resource and the W-AGF serving the 5G-RG as specified in subclause 4.4.2.2.
For an uplink user data packet associated with a PDU session ID and a QFI:
  1. if there is a user plane IPsec SA or a W-UP resource:
    1. associated with a PDU session ID matching the PDU session ID associated with the uplink user data packet; and
    2. associated with a QFI matching the QFI associated with the uplink user data packet;
      the UE or the 5G-RG shall select that user plane IPsec SA or that W-UP resource, respectively;
  2. otherwise, the UE or the 5G-RG shall select the user plane IPsec SA or the W-UP resource, respectively:
    1. associated with a PDU session ID matching the PDU session ID associated with the uplink user data packet; and
    2. associated with the indication that the child SA is the default child SA.
Up

8.3.2  Generic routing encapsulation (GRE)

If a user data packet message is transmitted over non-3GPP access between the UE and the N3IWF for untrusted non-3GPP access and the TNGF for the trusted non-3GPP access, the user data packet message shall be encapsulated as a GRE user data packet with a GRE header as specified in subclause 9.3.3. In the GRE encapsulated user data packet:
a0)
the protocol type field is set to zero;
a)
the payload packet field is set to the user data packet;
b)
the QFI field of the key field of the GRE header field is set to the QFI associated with the user data packet;
c)
if the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access:
  1. needs to send RQI for a downlink user data packet, the RQI field of the key field of the GRE header is set to "RQI is indicated" as defined in table 9.3.3-3; or
  2. does not need to send RQI for a downlink user data packet, the RQI field of the key field of the GRE header is set to "RQI is not indicated" as defined in table 9.3.3-3; and
d)
if the UE sends an uplink user data packet, the RQI field of the key field of the GRE header is set to "RQI is not indicated" as defined in table 9.3.3-3.
If the IKE_AUTH response message contains:
a)
the INTERNAL_IP4_ADDRESS attribute and the CREATE_CHILD_SA request message creating the user plane IPsec SA contains the UP_IP4_ADDRESS notify payload in subclause 7.5.4, an inner IPv4 datagram shall be constructed where:
  1. the GRE user data packet shall be encapsulated as the payload of the inner IPv4 datagram with IPv4 header where:
    1. if the UE constructs the inner IPv4 datagram, the source address field shall be set to the IPv4 address in the INTERNAL_IP4_ADDRESS attribute and the destination address field shall be set to the IPv4 address in the UP_IP4_ADDRESS notify payload;
    2. if the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access constructs the inner IPv4 datagram, the source address field shall be set to the IPv4 address in the UP_IP4_ADDRESS notify payload and the destination address field shall be set to the IPv4 address in the INTERNAL_IP4_ADDRESS attribute; and
    3. the protocol field shall be set to 2FH;
  2. the inner IPv4 datagram shall be protected employing the ESP protocol in tunnel mode as specified in RFC 4303 where:
    1. the SPI field in the ESP packet shall be set to the SPI of the user plane IPsec SA; and
    2. the next header field in the ESP packet shall be set to 04H,
    and the inner IPv4 datagram encapsulating the GRE encapsulated user data can be fragmented as described in RFC 791 before being protected by ESP protocol;
  3. if the DSCP field is associated with the user plane IPsec SA, the DSCP field as specified in RFC 2474 of the IP packet encapsulating the ESP protected inner IPv4 datagram shall be set to the value of the DSCP field included in the 5G_QOS_INFO Notify payload; and
  4. the IP packet encapsulating the ESP protected inner IPv4 datagram shall be sent to the peer for the SPI of the user plane IPsec SA; or
b)
the INTERNAL_IP6_ADDRESS attribute and the CREATE_CHILD_SA request message creating the user plane IPsec SA contains the UP_IP6_ADDRESS notify payload in subclause 7.5.4, an inner IPv6 datagram shall be constructed where:
  1. the GRE user data packet shall be encapsulated as the payload of the inner IPv6 datagram with IPv6 header where:
    1. if the UE constructs the inner IPv6 datagram, the source address field shall be set to the IPv6 address in the INTERNAL_IP6_ADDRESS attribute and the destination address field shall be set to the IPv6 address in the UP_IP6_ADDRESS notify payload;
    2. if the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access constructs the inner IPv6 datagram, the source address field shall be set to the IPv6 address in the UP_IP6_ADDRESS notify payload and the destination address field shall be set to the IPv6 address in the INTERNAL_IP6_ADDRESS attribute; and
    3. the next header field shall be set to 2FH;
  2. the inner IPv6 datagram shall be protected employing the ESP protocol in tunnel mode as specified in RFC 4303 where:
    1. the SPI field in the ESP packet shall be set to the SPI of the user plane IPsec SA; and
    2. the next header field in the ESP packet shall be set to 29H;
    and the inner IPv6 datagram encapsulating the GRE encapsulated user data can be fragmented as described in RFC 8200 before being protected by ESP protocol; and
  3. if the DSCP field is associated with the user plane IPsec SA, the DSCP field as specified in IETF RFC 2474 [26] of the IP packet encapsulating the ESP protected inner IPv6 datagram shall be set to the value of the DSCP field included in the 5G_QOS_INFO Notify payload; and
  4. theIP packet encapsulating the ESP protected inner IPv6 datagram shall be sent to the peer for the SPI of the user plane IPsec SA.
If a user data packet message is transmitted over non-3GPP access between the UE and the N3IWF for untrusted non-3GPP access and the TNGF for trusted non-3GPP access, the user data packet message shall be encapsulated in the payload of an inner IP datagram which is further encapsulated by ESP protocol in tunnel mode as specified in RFC 4303. In order to avoid any IP fragmentation by the sending entity over the non-3GPP access network, the maximum inner IP datagram length shall be set by the sending entity such that the length of the resulting outer IP datagram does not exceed the MTU of the non-3GPP access network. If the length of the user data packet message exceeds the payload size corresponding to the maximum inner IP datagram length and IP fragmentation is needed:
  1. the inner IP IPv4 datagram or inner IP IPv6 datagram shall be fragmented; and
  2. the IP packet encapsulating the ESP protected inner IPv4 datagram and the IP packet encapsulating the ESP protected inner IPv6 datagram shall not be fragmented.
Up


Up   Top   ToC