4 General Description

29.5733GPP5G SystemPublic Land Mobile Network (PLMN) InterconnectionRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Introduction

This clause provides a general description of the interconnect interfaces used between the PLMNs and/or SNPNs for transporting the service based interface message exchanges.

4.2 N32 Interface

4.2.1 General

The N32 interface is used between SEPPs of different PLMNs for both roaming and PLMN interconnect scenarios.

The N32 interface may also be used between SEPPs from an SNPN and another SNPN or PLMN, for SNPN interconnect scenarios (e.g. for SNPN connectivity with a Credentials Holder network, see clause 5.30.2.9.3 of 3GPP TS 23.501 [2]). Unless specified otherwise, references to "PLMN" throughout this specification shall be substituted by "SNPN" for a SEPP that is deployed in an SNPN.

The SEPP that is on the NF service consumer side is called the c-SEPP and the SEPP that is on the NF service producer is called the p-SEPP. The NF service consumer or SCP may be configured with the c-SEPP or discover the c-SEPP by querying the NRF. The NF service producer or SCP may be configured with the p-SEPP or discover the p-SEPP by querying the NRF.

The N32 interface can be logically considered as 2 separate interfaces as given below.

– N32-c, a control plane interface between the SEPPs for performing initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding.

– N32-f, a forwarding interface between the SEPPs which is used for forwarding the communication between the NF service consumer and the NF service producer after applying application level security protection.

4.2.2 N32-c Interface

The following figure shows the scope of the N32-c interface.

Figure 4.2.2-1: N32-c Interface

The N32-c interface provides the following functionalities:

– Initial handshake procedure between the SEPP in PLMN A (called the initiating SEPP) and the SEPP in PLMN B (called the responding SEPP), that involves capability negotiation and parameter exchange as specified in 3GPP TS 33.501 [6].

4.2.3 N32-f Interface

The following figure shows the scope of the N32-f interface.

Figure 4.2.3-1: N32-f Interface

The N32-f interface shall be used to forward the HTTP/2 messages of the NF service producers and the NF service consumers in different PLMN, through the SEPPs of the respective PLMN. The application layer security protection functionality of the N32-f is used only if the PRotocol for N32 INterconnect Security (PRINS) is negotiated between the SEPPs using N32-c.

The N32-f interface provides the following application layer security protection functionalities:

– Message protection of the information exchanged between the NF service consumer and the NF service producer across PLMNs by applying application layer security mechanisms as specified in 3GPP TS 33.501 [6].

– Forwarding of the application layer protected message from a SEPP in one PLMN to a SEPP in another PLMN. Such forwarding may involve IPX providers on path.

– If IPX providers are on the path from SEPP in PLMN A to SEPP in PLMN B, the forwarding on the N32-f interface may involve the insertion of content modification instructions which the receiving SEPP applies after verifying the integrity of such modification instructions.

If TLS is the negotiated security policy between the SEPP, then the N32-f shall involve only the forwarding of the HTTP/2 messages of the NF service producers and the NF service consumers without any reformatting at the SEPPs and/or the IPXs.

4.3 Protocol Stack

4.3.1 General

The protocol stack for the N32 interface is shown below in Figure 4.3.1-1.

Figure 4.3.1-1: N32 Protocol Stack

The N32 interfaces (N32-c and N32-f) use HTTP/2 protocol (see clause 4.2.2 and 4.2.3, respectively) with JSON (see clause 4.2.4) as the application layer serialization protocol. For the security protection at the transport layer, the SEPPs shall support TLS as specified in clause 13.1.2 of 3GPP TS 33.501 [6].

For the N32-f interface, the application layer (i.e the JSON payload) encapsulates the complete HTTP/2 message between the NF service consumer and the NF service producer, by transforming the HTTP/2 headers and the body into specific JSON attributes as specified in clause 6.2. For the scenarios when there are IPX entities between SEPPs, see clause 4.3.2 for TLS/PRINS usage.

4.3.2 HTTP/2 Protocol

4.3.2.1 General

HTTP/2 as described in IETF RFC 7540 [7] shall be used for N32 interface.

4.3.2.2 HTTP standard headers

The HTTP request standard headers and the HTTP response standard headers that shall be supported on the N32 interface are defined in Table 4.2.2.2-1 and in Table 4.2.2.2-2 respectively.

Table 4.3.2.2-1: Mandatory to support HTTP request standard headers

Name	Reference	Description
Accept	IETF RFC 7231 [9]	This header is used to specify response media types that are acceptable.
Accept-Encoding	IETF RFC 7231 [9]	This header may be used to indicate what response content-encodings (e.g gzip) are acceptable in the response.
Content-Length	IETF RFC 7230 [10]	This header is used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type	IETF RFC 7231 [9]	This header is used to indicate the media type of the associated representation.
Via	IETF RFC 7230 [10]	This header is used to indicate the intermediate proxies in the service request path. Please refer to clause 6.10.8 of 3GPP TS 29.500 [4] for encoding of the via header

Table 4.3.2.2-2: Mandatory to support HTTP response standard headers

Name	Reference	Description
Content-Length	IETF RFC 7230 [10]	This header may be used to provide the anticipated size, as a decimal number of octets, for a potential payload body.
Content-Type	IETF RFC 7231 [9]	This header shall be used to indicate the media type of the associated representation.
Content-Encoding	IETF RFC 7231 [9]	This header may be used in some responses to indicate to the HTTP/2 client the content encodings (e.g gzip) applied to the response body beyond those inherent in the media type.
Via	IETF RFC 7230 [10]	This header is used to indicate the intermediate proxies in the service response path. Please refer to clause 6.10.8 of 3GPP TS 29.500 [4] for encoding of the via header.
Server	IETF RFC 7231 [9]	This header is used to indicate the originator of an HTTP error response.

4.3.2.3 HTTP custom headers

The HTTP custom headers specified in clause 5.2.3 of 3GPP TS 29.500 [4] shall be supported on the N32 interface.

4.3.2.4 HTTP/2 connection management

Each SEPP initiates HTTP/2 connections towards its peer SEPP for the following purposes

– N32-c interface

– N32-f interface

The scope of the HTTP/2 connection used for the N32-c interface is short-lived. Once the initial handshake is completed the connection is torn down as specified in 3GPP TS 33.501 [6]. The HTTP/2 connection used for N32-c is end to end between the SEPPs and does not involve an IPX to intercept the HTTP/2 connection, though an IPX may be involved for IP level routing.

The scope of the HTTP/2 connection used for the N32-f interface is long-lived. The N32-f HTTP/2 connection at a SEPP can be:

– Case A: Towards a SEPP of another PLMN without involving any IPX intermediaries or involving IPX intermediaries where IPX does not require modification or observation of the information; or

– Case B: Towards a SEPP of another PLMN via IPX where IPX requires modification or observation of the information. In this case, the HTTP/2 connection from a SEPP terminates at the next hop IPX with the IPX acting as a HTTP proxy.

For the N32-f interface the HTTP/2 connection management requirements specified in clause 5.2.6 of 3GPP TS 29.500 [4] shall be applicable. The URI scheme used for the N32-f JOSE protected message forwarding API shall be "http". If confidentiality protection of all IEs for the N32-f JOSE protected message forwarding procedure is required, then:

– For case A, the security between the SEPPs shall be ensured by means of an IPSec or TLS connection;

– For case B, hop-by-hop security between the SEPP and the IPXs should be established on N32-f. This hop-by-hop security shall be established using an IPSec or TLS connection.

4.3.3 Transport Protocol

The Transmission Control Protocol as described in IETF RFC 793 [11] shall be used as transport protocol as required by HTTP/2 (see IETF RFC 7540 [7]).

When there is no IPX between the SEPPs or IPX(s) are offering only IP routing service without modification or observation of the content, TLS shall be used for security protection (see clause 13.1.2 of 3GPP TS 33.501 [6]). When there is IPX between the SEPPs and IPX requires modification or observation of the content, TLS or NDS/IP should be used for security protection as specified in clause 13.1.2 of 3GPP TS 33.501 [6].

NOTE: When using TCP as the transport protocol, an HTTP/2 connection is mapped to a TCP connection.

4.3.4 Serialization Protocol

The JavaScript Object Notation (JSON) format as described in IETF RFC 8259 [8] shall be used as the serialization protocol.