5 N32 Procedures

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

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

5.1 Introduction

The procedures on the N32 interface are split into two categories:

– Procedures that happen end to end between the SEPPs on the N32-c interface;

– Procedures that are used for the forwarding of messages on the service based interface between the NF service consumer and the NF service producer via the SEPP across the N32-f interface.

Table 5.1-1 summarizes the corresponding APIs defined for this specification.

Table 5.1-1: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
N32 Handshake	6.1	N32-c Handshake Service	TS29573_N32_Handshake.yaml	n32c-handshake	A.2
JOSE Protected Message Forwarding	6.2	N32-f Message Forwarding Service	TS29573_JOSEProtectedMessageForwarding.yaml	n32f-forward	A.3
Nsepp_Telescopic_FQDN_Mapping	6.3	SEPP Telescopic FQDN Mapping	TS29573_SeppTelescopicFqdnMapping.yaml	nsepp-telescopic	A.4

5.2 N32 Handshake Procedures (N32-c)

5.2.1 General

The N32 handshake procedure is used between the SEPPs in two PLMNs to mutually authenticate each other and negotiate the security mechanism to use over N32-f along with associated security configuration parameters.

A HTTP/2 connection shall be established between the initiating SEPP and the responding SEPP end to end over TLS. The following N32 handshake procedures are specified in the clauses below.

– Security Capability Negotiation Procedure

– Parameter Exchange Procedure

– N32-f Context Termination Procedure

– N32-f Error Reporting Procedure

5.2.2 Security Capability Negotiation Procedure

The initiating SEPP shall initiate a Security Capability Negotiation procedure towards the responding SEPP to agree on a security mechanism to use for protecting NF service related signalling over N32-f. An end to end TLS connection shall be setup between the SEPPs before the initiation of this procedure. This procedure may also be used to tear down the N32-f TLS connection if the remote SEPP indicated support of the feature NFTLST during the setup of the N32-c connection. The procedure is described in Figure 5.2.2-1 below.

Figure 5.2.2-1: Security Capability Negotiation Procedure

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecNegotiateReqData" IE carrying the following information:

– Supported security capabilities (i.e PRINS and/or TLS);

– Whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, if TLS security is supported;

– Sender PLMN ID(s) or SNPN ID(s);

– Target PLMN ID or SNPN ID;

– Purpose of the intended usage of N32 connection.

– The senderN32fFqdn IE, if TLS is present in the supportedSecCapabilityList IE, and the initiating SEPP wishes the responding SEPP to establish the N32-f connection towards a specific FQDN (of the initiating SEPP), if TLS is selected as the security option for N32.

– The senderN32fPort IE, if TLS is present in the supportedSecCapabilityList IE, and the initiating SEPP wishes the responding SEPP to establish the N32-f connection using a specific port number, if TLS is selected as the security option for N32.

If different PLMNs or SNPNs are represented by different PLMN IDs or SNPN IDs (respectively) supported by a SEPP, then the SEPP shall use separate N32-connections for each pair of local and remote PLMN or SNPN. Both SEPPs shall store the mapping between the N32 connections and their pair of PLMN IDs or SNPN IDs.

NOTE 1: If SEPPs support separate FQDN per PLMN or SNPN, then Target PLMN Id or Target SNPN Id is not required as target PLMN or SNPN can be selected by the FQDN.

To tear down the N32-f connection when negotiated security scheme is TLS, the "SecNegotiateReqData" IE shall contain:

– Supported security capability set to "NONE"

2a. On successful processing of the request, the responding SEPP shall respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains "SecNegotiateRspData" IE carrying the following information:

– Selected security capability (i.e PRINS or TLS);

– Whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, if TLS security is selected;

– Sender PLMN ID(s) or SNPN ID(s).

– Purpose of the accepted usage of N32 connection.

– The senderN32fFqdn IE, if TLS is present in the supportedSecCapabilityList IE, and the responding SEPP wishes the initiating SEPP to establish the N32-f connection towards a specific FQDN (of the responding SEPP), if TLS is selected as the security option for N32.

– The senderN32fPort IE, if TLS is present in the supportedSecCapabilityList IE, and the responding SEPP wishes the initiating SEPP to establish the N32-f connection using a specific port number, if TLS is selected as the security option for N32.

NOTE 2: Same SEPP endpoints can serve all accepted purposes over the same N32-f connection established as the result of request/response messages.

The responding SEPP compares the initiating SEPP’s supported security capabilities to its own supported security capabilities and selects, based on its local policy, a security mechanism, which is supported by both the SEPPs. If the selected security capability indicates any other capability other than PRINS, then the HTTP/2 connection initiated between the two SEPPs for the N32 handshake procedures shall be terminated. The negotiated security capability shall be applicable on both the directions. If the selected security capability is PRINS, then the two SEPPs may decide to create (if not available) / maintain HTTP/2 connection(s) where each SEPP acts as a client towards the other (which acts as a server). This may be used for later signalling of N32-f error reporting procedure (see clause 5.2.5) and N32-f context termination procedure (see clause 5.2.4).

The SEPP shall select the PLMN or SNPN from the list of supported PLMN(s) or SNPN(s) based on the received Target PLMN ID or SNPN ID, or based on PLMN or SNPN specific FQDN used in the request, and provide the selected PLMN’s PLMN Id(s) in the plmnIdList or the selected SNPN’s SNPN Id(s) in the snpnIdList.

In case no purposes are exchanged, the receiving SEPP shall assume by default that purposes are for Roaming and inter-PLMN mobility as described in clause 6.1.5.3.9.

The initiating SEPP and/or responding SEPP may enable the establishment of an N32 connection for the purpose of Disaster Roaming only during disaster conditions.

When the request is for tearing down the existing N32-f TLS connection, the "SecNegotiateRspData" IE shall contain:

– Supported security capability set to "NONE"

and, subsequently, both SEPP shall terminate the N32-c and N32-f TLS connection.

If the initiating SEPP receives the senderN32fFqdn IE and/or the senderN32fPort IE from the responding SEPP and TLS is negotiated as the security option for N32-f, the initiating SEPP should establish the N32-f connection towards the responding SEPP using the received N32-f FQDN and/or the senderN32fPort IE, and vice-versa.

2b. On failure, the responding SEPP shall respond to the initiating SEPP with an appropriate 4xx/5xx status code as specified in clause 6.1.4.2.

Editor’s note: GSMA IR.67 does not document DNS procedures for resolving N32-f FQDNs. It is FFS whether N32-f FQDNs should be managed in GSMA DNS.

5.2.3 Parameter Exchange Procedure

5.2.3.1 General

The parameter exchange procedure shall be executed if the security capability negotiation procedure selected the security capability as PRINS. The parameter exchange procedure is performed to:

– Agree on a cipher suite to use for protecting NF service related signalling over N32-f; and

– Optionally, exchange the protection policies to use for protecting NF service related signalling over N32.

5.2.3.2 Parameter Exchange Procedure for Cipher Suite Negotiation

The parameter exchange procedure for cipher suite negotiation shall be performed after the security capability negotiation procedure if the selected security policy is PRINS. If there is a change in the cipher suite and the SEPP wants to renegotiate it, then the SEPP may reuse the parameter exchange procedure to override what was exchanged before.

The procedure is described in Figure 5.2.3.2-1 below.

Figure 5.2.3.2-1: Parameter Exchange Procedure for Cipher Suite Negotiation

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecParamExchReqData" IE carrying the following information

– Supported cipher suites;

The supported cipher suites shall be an ordered list with the cipher suites mandated by 3GPP TS 33.501 [6] appearing at the top of the list.

The initiating SEPP also provides a N32-f context identifier for the responding SEPP to use towards the initiating SEPP for subsequent JOSE Protected Message Forwarding procedures over N32-f (see clause 5.3.3) when the responding SEPP acts as the forwarding SEPP.

2a. On successful processing of the request, the responding SEPP shall respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains the following information

– Selected cipher suite

The responding SEPP compares the initiating SEPP’s supported cipher suites to its own supported cipher suites and selects, based on its local policy, a cipher suite, which is supported by both the SEPPs. The responding SEPP’s supported cipher suites shall be an ordered list with the cipher suites mandated by 3GPP TS 33.501 [6] appearing at the top of the list. The selected cipher suite is applicable for both the directions of communication between the SEPPs.

The responding SEPP also provides a N32-f context identifier for the initiating SEPP to use towards the responding SEPP for subsequent JOSE Protected Message Forwarding procedures over N32-f (see clause 5.3.3) when the initiating SEPP acts as the forwarding SEPP.

If the receiving SEPP already has a previously negotiated cipher suite, the SEPP shall overwrite it with the new one.

2b. On failure, the responding p-SEPP shall respond to the initiating SEPP with an appropriate 4xx/5xx status code as specified in clause 6.1.4.3. If the SEPP already has a previously negotiated cipher suite, the SEPP shall continue to use the same.

NOTE : If a SEPP already has a previously negotiated cipher suite and a new cipher suite is also received, the SEPP starts applying the new cipher suite immediately and also continues with the old cipher suite for a limited time period. This allows messages with old policies to be completed gracefully.

5.2.3.3 Parameter Exchange Procedure for Protection Policy Exchange

The parameter exchange procedure for protection policy exchange may be performed after the Parameter Exchange Procedure for Cipher Suite Negotiation (see clause 5.2.3.2). If a HTTP/2 connection does not exist towards the peer SEPP at the time of initiating this procedure, the HTTP/2 connection shall be established. If there is a change in the protection policy exchange and the SEPP wants to renegotiate it, then the SEPP may reuse the parameter exchange procedure for the protection policy exchange to override what was exchanged before. If the parameter exchange procedure for the protection policy exchange is not performed then the protection policies between the SEPP shall be exchanged out of bands.

The procedure is described in Figure 5.2.3.3-1 below.

Figure 5.2.3.3-1: Parameter Exchange Procedure for Protection Policy Exchange

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecParamExchReqData" IE carrying the following information

– Protection policy information

The protection policy information contains:

– API to IE mapping containing the mapping information of list of leaf IEs for each:

– Request/response and Subscribe / Unsubscribe service operation, identified by the API URI and method; and/or

– Callbacks (e.g Notification service operation), identified by the value of the 3GPP custom HTTP header "3gpp-Sbi-Callback" (see clause 5.2.3 of 3GPP TS 29.500 [4]).

– List of IE types that are to be protected across N32-f (i.e the data type encryption policy as specified in clause 13.2.3.2 of 3GPP TS 33.501 [6]); and

– Modification policy: Against each leaf IE in the API to IE mapping information, a boolean flag indicating whether that IE is allowed to be modified by an IPX on the side of the SEPP sending the protection policy information.

2a. On successful processing of the request, the responding SEPP shall respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains the following information

– Selected protection policy information

The Selected protection policy information contains the IEs allowed to be modified by an IPX on the side of the responding SEPP. If the responding SEPP connects to several IPXs, an isModifiable IE may be included to indicate an IE is allowed to be modified by all IPX(s) or an map type of isModifiableByIpx IE may be included to indicate an IE is allowed to be modified by an IPX identified by the key of ipxProviderId IE if this IE is allowed to be modified by some of (but not all) the IPX(s), as specified in clause 13.2.3.4 of 3GPP TS 33.501 [6].

The initiating SEPP shall store the modification policy which are sent from responding SEPP in selected protection policy information and the responding SEPP shall store the modification policy which are sent from the initiating SEPP in the protection policy information. The SEPP receving the subsequent message transfers over N32-f shall check whether the modifications performed by the IPXs were permitted by the respective modification policy.

The SEPPs shall store the encryption policy in selected protection policy information and shall apply this policy for subsequent message transfers over N32-f. The encryption policy in selected protection policy is applicable for both the directions of communication between the SEPPs.

If the receiving SEPP already has a previously negotiated protection policy information, the SEPP shall overwrite it with the new one.

The HTTP/2 connection used for the N32 handshake procedures may be terminated after the completion of this procedure.

2b. On failure, the responding SEPP shall respond to the initiating SEPP with an appropriate 4xx/5xx status code as specified in clause 6.1.4.3. If the SEPP already has previously negotiated protection policy information, the SEPP shall continue to use the same.

An illustration of how the protection policy is stored and looked up in the SEPP is provided in figure 5.2.3.3-2

Figure 5.2.3.3-2: Protection Policy Storage and Lookup in SEPP

During the N32-f message forwarding, the SEPP looks at a HTTP request or response it receives from an NF service consumer or NF service producer and then uses the above tables to decide which IEs and headers in the message it shall cipher and integrity protect and which IEs it shall allow the IPXes to modify.

5.2.3.4 Parameter Exchange Procedure for Security Information list Exchange

The initiating SEPP shall initiate a Security Information list exchange procedure towards the responding SEPP to exchange the Security Information lists that contain information on IPX public keys or certificates that are needed to verify IPX modifications at the receiving SEPP as specified in clause 13.2.2.2 of 3GPP TS 33.501 [6]. If there is a change in the security information list and the SEPP wants to renegotiate it, then the SEPP may reuse the parameter exchange procedure for the security information list exchange to override what was exchanged before.

The procedure is described in Figure 5.2.3.4-1 below.

Figure 5.2.3.4-1: Parameter Exchange Procedure for Security Information List exchange

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecParamExchReqData" IE carrying the following information:

– IPX provider identifier connected to the initiating SEPP;

– List of raw public keys or certificates for that IPX.

2a. On successful processing of the request, the responding SEPP shall respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains the "SecParamExchRspData" IE carrying the following information:

– IPX provider identifier connected to the responding SEPP;

– List of raw public keys or certificates for that IPX.

If the receiving SEPP already has a previously negotiated security information list, the SEPP shall overwrite it with the new one.

2b. On failure, the responding SEPP shall respond to the initiating SEPP with an appropriate 4xx/5xx status code as specified in clause 6.1.4.3. If the SEPP already has previously negotiated security information list, the SEPP shall continue to use the same.

5.2.4 N32-f Context Termination Procedure

After the completion of the security capability negotiation procedure and/or the parameter exchange procedures, an N32-f context is established between the two SEPPs. The "n32fContextId" of each SEPP is provided to the other SEPP. This context identifier shall be stored in each SEPP until the context is explicitly terminated by the N32-f context termination procedure. The SEPP that is initiating the N32-f context termination procedure shall use the HTTP method POST on the URI: {apiRoot}/n32c-handshake/v1/n32f-terminate. If a HTTP/2 connection does not exist towards the receiving SEPP, a HTTP/2 connection shall be created before initiating this procedure. The procedure is shown below in Figure 5.2.4-1.

Figure 5.2.4-1: N32f Context Termination Procedure

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the N32-f context id information that is to be terminated.

2a. On success, the responding SEPP, shall:

– stop sending any further messages over the N32-f towards the initiating SEPP;

– once all the ongoing N32-f message exchanges with the initiating SEPP are completed or timed out, delete the N32-f context identified by the "n32fContextId" provided in the request.

The N32-f HTTP/2 connections from the responding SEPP shall not be deleted if they terminate at an IPX, since that HTTP/2 connection may carry traffic towards other PLMN SEPPs as well. The responding SEPP shall return the status code "200 OK" together with an N32ContextInfo payload body that carries the "n32fContextId" of the initiating SEPP that the responding SEPP has stored.

The initiating SEPP shall:

– stop sending any further messages over the N32-f towards the responding SEPP;

– once all the ongoing N32-f message exchanges with the responding SEPP are completed or timed out, delete the local N32-f context identified by this "n32fContextId".

2b. On failure, the responding SEPP shall return an appropriate 4xx/5xx status code together with the "ProblemDetails" JSON body.

5.2.5 N32-f Error Reporting Procedure

When a SEPP is not able to process a message it received over the N32-f interface due to errors, the error information is conveyed to the sending SEPP by using the N32-f error reporting procedure over the N32-c interface. The SEPP that is initiating the N32-f error reporting procedure shall use the HTTP method POST on the URI: {apiRoot}/n32c-handshake/v1/n32f-error. If a HTTP/2 connection does not exist towards the receiving SEPP, a HTTP/2 connection shall be created before initiating this procedure. The procedure is shown below in Figure 5.2.5-1.

Figure 5.2.5-1: N32f Error Reporting Procedure

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the N32-f error information that is to be reported.

2a. On success, the responding SEPP, shall:

– log that the N32-f request / response message identified by the "n32fMessageId" is not processed by the receiving SEPP;

The responding SEPP shall return the status code "204 No Content".

2b. On failure, the responding SEPP shall return an appropriate 4xx/5xx status code together with the "ProblemDetails" JSON body.

5.3 JOSE Protected Message Forwarding Procedure on N32 (N32-f)

5.3.1 Introduction

The N32-f interface is used between two SEPPs for:

– The forwarding of JOSE protected HTTP/2 messages between the NF service consumer and the NF service producer across two PLMNs, when PRINS is the negotiated security policy. The message forwarding on N32-f shall be based on the negotiated security capability and the exchanged security parameters between the two SEPPs (see clause 5.2).

– Forwarding of the HTTP/2 messages between the NF service consumer and the NF service producer without any reformatting and application layer protection, when TLS is the negotiated security policy.

5.3.2 Use of Application Layer Security

5.3.2.1 General

If the negotiated security capability between the two SEPPs is PRINS, one or more HTTP/2 connections between the two SEPPs for the forwarding of JOSE protected message shall be established, which may involve IPX providers on path. The forwarding of messages over the N32-f interface involves the following steps at the sending SEPP:

1. Identification of the protection policy applicable for the API being invoked (i.e either a request/response NF service API or a subscribe/unsubscribe service API or a notification API).

2. Message reformatting as per the identified protection policy.

3. Forwarding of the reformatted message over the N32 interface.

The processing of a message received over the N32-f interface at the receiving IPX provider involves the following steps:

1. Apply the modifications in the "modificationsBlock" appended by the sending IPX provider as JSON patches in the DataToIntegrityProtectBlock (from the decoded "aad" part), if the "modificationsBlock" is received in the message.

2. Determine further modifications required based on modification policy and insert the modification entries in "modificationsBlock".

3. Forwarding the received message with the above inserted modification entries in "modificationsBlock" over the N32 interface.

The processing of a message received over the N32-f interface at the receiving SEPP involves the following steps.

1. Identify the N32-f context using the N32-f context Id received in the message.

2. Verify the integrity protection of the message using the keying material obtained from the TLS layer during the parameter exchange procedure for that N32-f context (see 3GPP TS 33.501 [6]). The TLS connection from which the keying material is obtained is the N32-c TLS connection used for the parameter exchange procedure.

3. Decrypt the ciphertext part of the received JWE message. Decode the "aad" part of the JWE message using BASE64URL decoding.

4. For each entry in the "modificationsBlock" of the received message:

– First verify the integity protection of that entry using the keying material applicable for the IPX that inserted that block (using the "identity" IE in the "modificationsBlock");

– Identify the modifications policy exchanged during the parameter exchange procedure with the sending SEPP if the IPX that inserted the modificationsBlock is from the sending SEPP side; else identify the modifications policy applicable for the IPX based on local configuration;

– Check if the inserted modifications are as per the identified modifications policy;

– Apply the modifications as a JSON patch in the DataToIntegrityProtectBlock (from the decoded "aad" part).

5. Form the original JSON request / response body from the decrypted ciphertext and the decoded integrity verified "aad" block possibly modified as described in step 4.

6. If the reconstructed HTTP message has a "Authorization" header, then the SEPP shall check whether the service consumer’s PLMN ID is present in the Bearer token contained in the Authorization header (see 3GPP TS 29.510 [18], clause 6.3.5.2.4) and if it matches with the "Remote PLMN ID" of the N32-f context. If they do not match, the SEPP shall respond to the sending SEPP with "403 Forbidden" status code with the application specific cause set as "PLMNID_MISMATCH".

NOTE 1: In this case, the N32-f Error Reporting procedure specified in clause 5.2.5 is not used since the processing of the complete N32-f message fails at the receiving SEPP.

NOTE 2: If the service consumer’s PLMN ID is present in the reconstructed HTTP message, then the receiving SEPP compares this with the sending SEPP’s PLMN ID, which is retrieved from N32f Context (see clause 5.9.3 in 3GPP TS 33.501 [6]). See the above step 6 for the receiving SEPP behaviour. If the service consumer’s PLMN ID is not present, the comparison is not done.

SEPPs and IPX should support gzip coding (see IETF RFC 1952 [23]) in HTTP requests and responses and indicate so in the Accept-Encoding header, as described in clause 6.9 of 3GPP TS 29.500 [4] and clause 6.2.2.2.3.

5.3.2.2 Protection Policy Lookup

When a SEPP receives a HTTP/2 request or response message intended to be routed towards another PLMN, the sending SEPP shall identify the protection policy as given below

1. Identify the target PLMN from the ":aurthority" part of the message using the format specified in clause 6.1.4.3 of 3GPP TS 29.500 [4].

2. Check if the incoming HTTP/2 message has the "3gpp-Sbi-Callback" header. When present, the SEPP shall select the data encryption and modification policy applicable for the specific notification type, identified by the value of the "3gpp-Sbi-Callback" header and the target PLMN, using the notification type list stored as specified in subclase 5.2.3.3.

3. Else, if it is a HTTP/2 request message, then from the ":authority" and ":path" part of the received HTTP/2 request message, form the API URI. For the identified PLMN, check if a protection policy exists for the API URI using the table stored as specified in clause 5.2.3.3.

4. Else, if it is a HTTP/2 response message, then based on the HTTP/2 stream ID on which the response is received, identify the corresponding request that was sent by the SEPP and the protection policy applicable for that request, as specified in step 3.

5. If an entry is not found, then it means that either the particular API has no protection policy exchanged.

Once a protection policy is identified, the SEPP shall apply the application layer security as per the identified protection policy.

5.3.2.3 Message Reformatting

A SEPP on the sending side PLMN applies message reformatting in the following cases:

– When it receives a HTTP/2 request message from an NF service consumer to a an NF service producer in another PLMN;

– When it receives a response HTTP/2 response message from an NF service producer to an NF service consumer in another PLMN.

– When it receives a HTTP/2 notification request message from an NF service producer to an NF service consumer in another PLMN;

– When it receives a HTTP/2 notification response message from an NF service consumer to an NF service producer in another PLMN

The SEPP shall reformat the HTTP/2 message by encapsulating the whole message into the body of a new HTTP POST message. The body of the HTTP POST request / response message shall contain the reformatted original HTTP/2 request/response message respectively. The HTTP POST request/response body shall be encoded as the "N32fReformattedReqMsg"/"N32fReformattedRspMsg" JSON bodies respectively, as specified in clause 6.2.5.

The "N32fReformattedReqMsg"/"N32fReformattedRspMsg" are structured as given below:

Figure 5.3.2.3-1 JSON representation of a reformatted HTTP message

The "cipherText" part of the reformatted message in FlatJweJson shall be prepared as given below

Figure 5.3.2.3-2 Transformation of HTTP Header and Payload to Encrypt into CipherText

1. Based on the protection policy exchanged between the SEPPs, the sending SEPP prepares an input for the JWE ciphering and integrity protection as an array of arbitrary types in the "DataToIntegrityProtectAndCipher" block with each entry containing either a HTTP header value or the value of a JSON payload IE of the API message being reformatted. The index value "encBlockIdx" in the payload part of DataToIntegrityProtectBlock shall point to the index of a header value or IE value in this input array.

2. The input block is fed into an encryption function along with the other required inputs for JWE as specified in IETF RFC 7516 [14].

3. The encryption function outputs the cipher text information. This cipher text is then subjected to BASE64URL transformation as specified in IETF RFC 4648 [15] clause 5.

4. The output of the BASE64URL transform is them encoded as the ciphertext part of FlatJweJson IE specified in clause 6.2.5.2.11.

5.3.2.4 Message Forwarding to Peer SEPP

Once a SEPP reformats the HTTP/2 message into the "N32ReformattedReqMsg"/"N32ReformattedRspMsg" JSON object as specified in clause 5.3.2, the SEPP forwards the message to the receiving SEPP by invoking a HTTP POST method as shown in figure 5.3.2.4-1 below.

Figure 5.3.2.4-1 Message Forwarding between SEPP on N32-f

1. The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "N32ReformattedReqMsg" IE carrying the reformatted HTTP/2 message. The request message shall contain the "n32fContextId" information provided by the responding SEPP to the initiating SEPP earlier during the parameter exchange procedure (see clause 5.2.3). The responding SEPP shall use the "n32fContextId" information to:

– Locate the agreed cipher suite and protection policy;

– Locate the n32ContextId to be used in the response.

If the HTTP request/response message to be forwarded over N32-f includes an 3gpp-Sbi-Message-Priority header, the initiating/responding SEPP should additionally insert a 3gpp-Sbi-Message-Priority header in the N32-f message with the same contents as the 3gpp-Sbi-Message-Priority header encoded within the "N32ReformattedReqMsg"/ N32ReformattedRspMsg IE respectively.

NOTE 1: Replicating the information in a N32-f message header enables the receiving SEPP to determine the priority of the forwarded HTTP request/response without having to parse the N32-f message payload.

The HTTP request payload may be compressed hop by hop over N32-f, if the initiating SEPP or IPX and its next hop (IPX or SEPP) support gzip coding (see IETF RFC 1952 [23]).

2a. On successful processing of the request, the responding SEPP shall:

– decompress the N32-f HTTP request payload, if it is compressed;

– reconstruct the HTTP/2 message towards the NF service producer;

– compress the reconstructed HTTP request if the reconstructed HTTP payload contains a Content-Encoding header indicating gzip compression;

– forward the reconstructed HTTP/2 message to the NF service producer;

– wait for the response from the NF service producer; and then

– once the response from the NF service producer is received, respond to the initiating SEPP with a "200 OK" status code and a POST response body that contains the "N32ReformattedRspMsg". The "N32ReformattedRspMsg" shall contain the reformatted HTTP response message from the responding PLMN. The response message shall contain the "n32fContextId" information provided by the initiating SEPP to the responding SEPP earlier during the parameter exchange procedure (see clause 5.2.3).

NOTE 2: For unsuccessful processing of the request with "PLMNID_MISMATCH", see clause 5.3.2.1.

The responding SEPP shall be able to map the response received from the NF service producer to the HTTP/2 stream ID for the corresponding response it needs to generate towards the initiating SEPP. The HTTP/2 stream ID and the HTTP/2 connection information on either side shall be used to derive this mapping.

The HTTP response payload may be compressed hop by hop over N32-f, if the responding SEPP or IPX and its next hop (IPX or SEPP) support gzip coding (see IETF RFC 1952 [23]).

2b. On failure or unsuccessful processing of the request, the responding SEPP shall respond to the initiating SEPP with an appropriate 4xx/5xx status code, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application error as specified in clause 6.2.4.2. The "cause" attribute shall be set to "UNSPECIFIED", if the responding SEPP fails to process the reconstructed message, and the error is reported by N32f error reporting procedure as specified in clause 5.2.5.

5.3.3 Message Forwarding to Peer SEPP when TLS is used

When the negotiated security policy between the SEPPs is TLS, then the procedures described in clause 5.3.2 shall not be applied. Messages shall be forwarded to the peer SEPP as specified in clause 6.1.4.3.4 of 3GPP TS 29.500 [4].

5.3.4 JOSE Protected Forwarding Options

The JOSE Protected Forwarding Options is used by the sending SEPP or IPX to discover the communication options supported by its next hop (IPX or SEPP) for N32-f message processing.

Figure 5.3.4-1: Procedure for the discovery of communication options supported by the next hop

1. The sending SEPP or IPX shall send an OPTIONS request to discover the communication options supported by its next hop (IPX or SEPP) for N32-f message processing.

2. If the request is accepted, the next hop (IPX or SEPP) shall respond with the status code 204 No Content and include an Accept-Encoding header (as described in IETF RFC 7694 [24]).

On failure, the next hop shall return one of the HTTP status code listed in Table 6.2.4.3.2.1-3.

5.4 Nsepp_Telescopic_FQDN_Mapping Service

5.4.1 General

The Nsepp_Telescopic_FQDN_Mapping service is used between any Network Function and the SEPPs in the same PLMN, if TLS protection between the Network Function and the SEPP relies on using telescopic FQDN. See clause 28.5.2 of 3GPP TS 23.003 [19] and clause 6.1.4.3 of 3GPP TS 29.500 [4]) for the definition and use of Telescopic FQDN.

5.4.2 Foreign FQDN to Telescopic FQDN Mapping Procedure

This procedure is initiated by an NF Service Consumer (typically an NRF or an NSSF) that needs to interact with a NF in a foreign PLMN (typically the corresponding NRF or NSSF), and to do so, it needs to build a telescopic FQDN of said NF (i.e. concatenation of the FQDN of the foreign FQDN, and the FQDN of the local SEPP), and then the resulting telescopic FQDN needs to be "flattened" (i.e. the FQDN of the NF in the foreign PLMN needs to be converted to a singel label). The procedure is described in Figure 5.4.2-1 below.

Figure 5.4.2-1: Foreign FQDN to Telescopic FQDN Mapping Procedure

1. The NF Service Consumer issues an HTTP GET request towards the local SEPP with a query parameter "foreign-fqdn" containing the FQDN of the NF in the foreign PLMN, that needs to be transformed into a flattened telescopic FQDN.

2a. On successful processing of the request, the responding SEPP shall respond to the NF Service Consumer with a "200 OK" status code and a response body that contains a JSON object of type "TelescopicMapping", containing as attributes the label to be used as first label in the telescopic FQDN, and the domain of the local SEPP to be appended after such first label. The resulting FQDN shall be used by the NF Consumer to setup a TLS session terminated in the local SEPP, where the SEPP shall present a server certificate with a wildcard domain matching the returned telescopic FQDN.

5.4.3 Telescopic FQDN to Foreign FQDN Mapping Procedure

This procedure is initiated by an NF Service Consumer (typically another SEPP) that has received a service request with an unknown first label of a telescopic FQDN. Typically, this SEPP may interact with other SEPPs in the same PLMN in order to determine if there is an existing mapping for a given label to an FQDN of a foreign FQDN; this procedure is only expected to be used when multiple SEPPs are deployed in a PLMN. The procedure is described in Figure 5.4.3-1 below.

Figure 5.4.3-1: Foreign FQDN to Telescopic FQDN Mapping Procedure

1. The NF Service Consumer issues an HTTP GET request towards another SEPP with a query parameter "telescopic-label" containing the first label of a given telescopic FQDN, whose mapping towards an FQDN of an NF in a foreign PLMN needs to be verified.