6.14 Indicating the purpose of Inter-PLMN signaling

29.5003GPP5G SystemRelease 17Stage 3Technical Realization of Service Based ArchitectureTS

6.14.1 General

The procedures defined in this clause provide means for two PLMNs to send/receive the purpose of inter-PLMN signaling. This can be used to help operators to avoid receiving any signaling from different operator without any relevant contract.

SEPP shall be preconfigured to understand the relationship with other PLMNs, e.g. roaming. The means on how to configure the relationship is outside the scope of the Release.

6.14.2 Inclusion of the intended purpose

An NF Consumer or SCP in case of model D may include in the HTTP request the intended purpose of the request that is targeted to PLMN different from the source PLMN, using 3gpp-Sbi-Interplmn-Purpose as defined in clause 5.2.3.3.11. The purposes shall be selected from the values specified in 3GPP TS 29.573 [27] clause 6.1.5.3.9. In addition, the any additional information may be associated for indicating the exact purpose.

6.14.3 Evaluating the intended purpose

When the SEPP receives request from NF consumer or SCP of the same network bound to another network (in case of cSEPP), or from the peer SEPP (in case of pSEPP), the SEPP shall evaluate the intended purpose of the signaling from the following information:

– Source PLMN;

– Target PLMN; and

– intended purpose in the received in the 3gpp-Sbi-Interplmn-Purpose header, if available

If the SEPP (i.e. cSEPP) receives request from NF consumer or SCP of the same network bound to another network including 3gpp-Sbi-Interplmn-Purpose header, the receiving SEPP shall compare the value received in the header with the preconfigued value of allowed intended purpose between the source and target PLMN.

If the SEPP (i.e. pSEPP) receives from the peer SEPP including 3gpp-Sbi-Interplmn-Purpose header, the receiving SEPP shall compare the value received in the header with the pre-negotiated value of allowed intended purpose between the source and target PLMN during Security Capability Negotiation procedure specified in 3GPP TS 29.573 [27].

The receiving SEPP shall:

– If the purpose in the 3gpp-Sbi-Interplmn-Purpose header matches with any one of the preconfigured purposes (for cSEPP) or pre-negotiated purposes (for pSEPP) as allowed by the receiving SEPP, then the receiving SEPP shall continue processing the request.

– Else, the receiving SEPP shall reject the message with 403 Forbidden with ProblemDetails REQUESTED_PURPOSE_NOT_ALLOWED as defined in Table 5.2.7.4-1.

EXAMPLE The following example describes how cSEPP and pSEPP evaluates and process with regards to the intended purposes.

a) cSEPP and pSEPP are configured with the allowed purpose =X, Y

– Case 1:
NFc/SCP sends the first message to cSEPP with purpose = X. In this case, cSEPP validate the message against the configured purpose and allow it. Using the N32 connection established between cSEPP and pSEPP for purpose = X , cSEPP deliver the message to pSEPP. Then only pSEPP checks the purpose=X over N32f with the pre-negotiated purpose.

– Case 2:
NFc/SCP sends a second message to cSEPP with the purpose=Z. Here, cSEPP rejects it on its own because it is not allowed purpose for cSEPP (configured).

b) cSEPP is configured with allowed purpose X, Y and pSEPP is configured with X, K

– Case 3:
NFc/SCP sends a second message to cSEPP with purpose =Y. In this case, cSEPP validates the message against the configured purpose and allow it. Then cSEPP will negotiate purpose=Y with pSEPP over N32-c and the negotiation will fail. Then cSEPP rejects the message.

If the SEPP receives request from NF consumer or SCP of the same network bound to another network (in case of cSEPP), or from the peer SEPP (in case of pSEPP) that does not include 3gpp-Sbi-Interplmn-Purpose header, the receiving SEPP shall by default consider this as roaming in order to allow backward compatibility for NF consumers not support the 3gpp-Sbi-Interplmn-Purpose header, and apply the policy accordingly. The purpose of transactions of AMFs or SMFs between two different VPLMNs, i.e. inter AMF or inter V-SMF signalling from VPLMN1 to VPLMN2 shall be considered as inter PLMN mobility.

Annex A (informative):
Client-side Adaptive Throttling for Overload Control

This clause contains an example algorithm to make an NF Service Consumer adjust the traffic rate sent to an NF Service Producer based on the number of received "rejects" of HTTP requests with a status code "503 Service Unavailable", or requests that have timed-out and the response was never received. This algorithm is described in the book "Betsy Beyer, et al; Google: Site Reliability Engineering" (https://landing.google.com/sre/book.html), clause 21, "Handling Overload".

NOTE: The reference link provided to the book can change and hence the name of the book is expected to be used for referring to the latest edition.

Each client (NF Service Consumer) keeps track of the following counters during a certain time window:

– Requests: The number of requests that the client (NF Service Consumer) needs to handle. Under normal operation (no overload), all these requests are sent to the server (NF Service Producer). Under an overload situation, part of these requests are locally rejected by the client (and not sent to the server), and the rest of the requests are sent to the server.

– Accepts: The number of requests accepted by the server (i.e., requests for which a response has been effectively received at the client, with a status code other than "503 Service Unavailable").

When there is no server overload, these values are equal.

When there is an overload status in the server, the rate between "Accepts" and "Requests" decreases progressively. When this rate falls below a certain point (given by an algorithm parameter named "K"), the client shall start dropping some requests locally and not send them to the server.

The local rejection of requests can be done by calculating a "Client request rejection probability", as:

So, for example, assuming that the K parameter is set at 1.5:

– if the server accepts >67% of the traffic, and rejects <33% of the traffic, the client does not take any throttling action, and keeps sending to the server all the traffic it has available for processing

– if, during a first time-window, the server accepts, e.g., only 60% of the requests, and rejects 40% due to overload, the application of this algorithm implies that the client must drop locally 10% of the requests (probabilistically), and only send to the server the remainder 90% of its traffic.

– if, during a second time-window, the client keeps the same amount of available traffic to handle, but the server continues rejecting requests with same rate as before (40%) of the received requests, the application of the algorithm again, results in increasing the drop rate to 14.5%, and sending to the server only 85.5% of the available traffic.

The value of the parameter K, along with the size of the time window during which the total number of "requests" and "accepts" is accounted for, has a fundamental role on how the algorithm behaves. If K is higher, the algorithm is more "permissive", and the client does not start dropping requests locally until the rejection rate is higher (e.g., >50%, for K = 2); if K is lower, the algorithm is more "aggressive", and the client starts dropping requests sooner (e.g., K = 1.1 implies to start dropping requests as soon as the server rejects >10% of the requests).

Annex B (normative):
3gpp-Sbi-Callback Types

This annex specifies allowed 3GPP SBI callback type values for the "3gpp-Sbi-Callback" HTTP custom header specified in clause 5.2.3.2.3.

Table B-1 contains a non-exhaustive list of callbacks that are invoked in the 5GS.

Table B-1: Non-exhaustive list of values for the "3gpp-Sbi-Callback" Custom HTTP Header

Value for "3gpp-Sbi-Callback" Custom HTTP Header

Reference

"Nsmf_PDUSession_Update"

3GPP TS 29.502 [28], Clause 5.2.2.8.3.2, 5.2.2.8.3.3, 5.2.2.8.3.4 and 5.2.2.8.3.5.

"Nsmf_PDUSession_StatusNotify"

3GPP TS 29.502 [28], Clause 5.2.2.10.

"Nudm_SDM_Notification"

3GPP TS 29.503 [29], Clause 6.1.5.2

"Nudm_UECM_DeregistrationNotification"

3GPP TS 29.503 [29], Clause 6.2.5.2

"Nudm_UECM_PCSCFRestorationNotification"

3GPP TS 29.503 [29], Clause 6.2.5.3

"Nnrf_NFManagement_NFStatusNotify"

3GPP TS 29.510 [8], Clause 6.1.5.2.

"Namf_EventExposure_Notify"

3GPP TS 29.518 [31], Clause 6.2.5.2.

"Npcf_UEPolicyControl_UpdateNotify"

3GPP TS 29.525 [35], Clauses 4.2.4, 5.5.2 and 5.5.3.

"Nnssf_NSSAIAvailability_Notification"

3GPP TS 29.531 [32], Clause 6.2.5.2

"Namf_Communication_AMFStatusChangeNotify"

3GPP TS 29.518 [31], Clause 6.1.5.2.

"Ngmlc_Location_EventNotify"

3GPP TS 29.515 [40], Clause 6.1.4.2.

"Nchf_ConvergedCharging_Notify"

3GPP TS 32.291 [42], Clause 6.1.5.2

"Nnssaaf_NSSAA_ReAuthentication"

3GPP TS 29.526 [44], Clause 6.1.5.2.

"Nnssaaf_NSSAA_Revocation"

3GPP TS 29.526 [44], Clause 6.1.5.3.

"N5g-ddnmf_Discovery_MonitorUpdateResult"

3GPP TS 29.555 [46], Clause 6.1.5.2.

"N5g-ddnmf_Discovery_MatchInformation"

3GPP TS 29.555 [46], Clause 6.1.5.3.

For notification and callback service operations (used across PLMNs or within a PLMN) that are not part of TableB.1, the value of the header shall be constructed as follows:

"<API name taken from the heading of the relevant annex A.x as defined in the corresponding 3GPP TS of that API>_<name of the callback service operation in the corresponding OpenAPI specification file>"

EXAMPLE: Nsmf_PDUSession_smContextStatusNotification (for the Notify SM Context Status service operation)

where the "smContextStatusNotification" correspond to:

callbacks:

smContextStatusNotification:

‘{$request.body#/smContextStatusUri}’:

NOTE: Several values in Table B-1 do not comply with the construction rule for the "3gpp-Sbi-Callback" HTTP header described in this clause; in those cases, the values explicitly included in Table B-1 take precedence over the construction rule.

Annex C (informative):
Internal NF Routing of HTTP Requests

The internal details of the architecture of a Network Function instance is out of the scope of 3GPP and are entirely implementation-specific. This annex describes how an instance of an NF Service Producer can route internally HTTP requests received on a given Service-Based Interface.

Figure C-1 illustrates an example component architecture where incoming HTTP requests are received and processed in a component named as "Ingress Proxy" module and route them to the appropriate computing resource in the NF.

Figure C-1: Internal message routing inside NF Service Producer

The Ingress Proxy may parse any of the different components in the HTTP request, but typically it may parse the path of the URI (i.e. the :path pseudo-header in the HTTP/2 request). Parsing of other component in the request message, such as the HTTP body, is also possible but it is not desirable as it requires the parsing of the entire body (i.e. a JSON document) which is a much more computing-intensive task.

The path component of the URI contains the service name of the requested SBA service, so frequently the routing is done based on this component.

It is also frequent to inspect other components of the path (i.e. path segments), to do a more fine-grained routing and direct requests done on a specific HTTP resource(s) towards a given computing resource(s).

It can be noted that the path components used to determine the target computing resource typically do not need to be statically defined but are frequently defined in terms of "variables", or placeholders, similarly to how they are defined in the OpenAPI specification language (a mechanism usually known as "path templating"). See: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#path-templating

Annex D (informative):
Change history

Change history

Date

Meeting

TDoc

CR

Rev

Cat

Subject/Comment

New version

2017-10

CT4#80

C4-175246

TR skeleton

0.1.0

2017-10

CT4#80

C4-175390

Implementation of pCRs agreed at CT4#80.

0.2.0

2017-12

CT4#81

C4-176433

Implementation of pCRs agreed at CT4#81.

0.3.0

2018-01

CT4#82

C4-181387

Implementation of pCRs agreed at CT4#82.

0.4.0

2018-03

CT4#83

C4-182430

Implementation of pCRs agreed at CT4#83.

0.5.0

2018-03

CT#79

CP-180028

Presented for information

1.0.0

2018-04

CT4#84

C4-183512

Implementation of pCRs agreed at CT4#84.

1.1.0

2018-05

CT4#85

C4-184617

Implementation of pCRs agreed at CT4#85. The following pCRs are implemented. C4-184589, C4-184580, C4-184347, C4-184590, C4-184338, C4-184591, C4-184349, C4-184490, C4-184350, C4-184579, C4-184577 and C4-184498.

1.2.0

2018-06

CT#80

CP-181098

Presented for approval

2.0.0

2018-06

CT#80

Apprvoed in CT#80

15.0.0

2018-09

CT#81

CP-182053

0001

4

F

OAuth2.0 Clarifications

15.1.0

2018-09

CT#81

CP-182053

0002

2

B

Specifying N32 Aspects

15.1.0

2018-09

CT#81

CP-182053

0003

1

F

Determination of SBI message priorities

15.1.0

2018-09

CT#81

CP-182053

0004

5

F

Stateless AMF support

15.1.0

2018-09

CT#81

CP-182053

0005

F

Support of status code "501 Not implemented"

15.1.0

2018-09

CT#81

CP-182053

0006

2

B

Default port number

15.1.0

2018-12

CT#82

CP-183011

0009

3

F

Keep-alive on idle HTTP connections

15.2.0

2018-12

CT#82

CP-183011

0010

1

F

Stream Concurrency for overload control

15.2.0

2018-12

CT#82

CP-183011

0011

1

F

Update of missing status code 429

15.2.0

2018-12

CT#82

CP-183011

0012

1

F

Correction of the entity upon which content encoding is performed

15.2.0

2018-12

CT#82

CP-183011

0013

2

F

Custom header for notifications

15.2.0

2018-12

CT#82

CP-183011

0014

3

F

Routing across PLMN

15.2.0

2018-12

CT#82

CP-183011

0015

F

HTTP status code "406 Not Acceptable"

15.2.0

2018-12

CT#82

CP-183011

0016

1

F

Support of HTTP status code "414 URI Too Long"

15.2.0

2018-12

CT#82

CP-183011

0018

F

HTTP status code "414 URI Too Long" on PUT method

15.2.0

2018-12

CT#82

CP-183011

0020

1

F

Correction of Stream Priority in HTTP/2 Server Behaviour

15.2.0

2018-12

CT#82

CP-183194

0022

2

F

Change 403 to mandatory and clarify conditional headers

15.2.0

2018-12

Change history annex number corected

15.2.1

2019-03

CT#83

CP-190016

0023

1

F

Extensibility mechanism for Query parameters

15.3.0

2019-03

CT#83

CP-190016

0024

1

F

Bearer Tokens

15.3.0

2019-03

CT#83

CP-190016

0025

1

F

Handling of Incorrect IEs

15.3.0

2019-03

CT#83

CP-190016

0026

2

F

Clarification on Handling of Incorrect Optional IEs

15.3.0

2019-03

CT#83

CP-190016

0027

F

Status Codes

15.3.0

2019-06

CT#84

CP-191027

0030

1

F

Content-encodings supported in HTTP requests

15.4.0

2019-06

CT#84

CP-191027

0031

3

F

Missing Application Error Codes

15.4.0

2019-06

CT#84

CP-191027

0032

2

F

Correction on Feature Negotiation

15.4.0

2019-06

CT#84

CP-191027

0037

1

F

Allowed values of 3gpp-Sbi-Callback header field

15.4.0

2019-06

CT#84

CP-191027

0038

1

F

Adding the Control Plane interfaces that support service based interface

15.4.0

2019-06

CT#84

CP-191055

0033

1

B

Support of Indirect Communication (General)

16.0.0

2019-06

CT#84

CP-191055

0034

2

B

Support of Indirect Communication (Routing to SCP)

16.0.0

2019-06

CT#84

CP-191055

0035

1

B

Support of Indirect Communication (NF discovery and selection)

16.0.0

2019-06

CT#84

CP-191057

0036

2

B

Partially implemented PATCH

16.0.0

2019-09

CT#85

CP-192194

0040

2

B

Support of stateless NFs

16.1.0

2019-09

CT#85

CP-192194

0041

1

B

Routing mechanisms for Indirect Communication

16.1.0

2019-09

CT#85

CP-192194

0042

1

B

Routing extensions for Indirect Communication

16.1.0

2019-09

CT#85

CP-192194

0043

B

Authority and/or deployment-specific string in apiRoot of resource URI for Indirect Communication

16.1.0

2019-09

CT#85

CP-192194

0044

1

B

NF / NF service instance selection for Indirect Communication without Delegated Discovery

16.1.0

2019-09

CT#85

CP-192194

0045

B

Feature negotiation for Indirect Communication with Delegated Discovery

16.1.0

2019-09

CT#85

CP-192194

0053

2

B

Routing for indirect Communication with HTTP between NFs and SCP

16.1.0

2019-09

CT#85

CP-192123

0046

B

Timestamp in HTTP messages

16.1.0

2019-09

CT#85

CP-19212

0047

1

B

Handling of timed out requests

16.1.0

2019-09

CT#85

CP-19212

0049

1

B

Indicating partially implemented PATCH

16.1.0

2019-09

CT#85

CP-19212

0052

2

F

Adding the Control Plane interfaces that support service based interface

16.1.0

2019-12

CT#86

CP-193036

0059

1

F

Load Info used for Load Control

16.2.0

2019-12

CT#86

CP-193036

0062

F

Informative description of internal NF routing of HTTP messages

16.2.0

2019-12

CT#86

CP-193057

0039

5

B

16.2.0

2019-12

CT#86

CP-193057

0056

2

B

Routing of Indirect Communication with TLS between NFs and SCP

16.2.0

2019-12

CT#86

CP-193057

0057

2

B

Routing of Indirect Communication without TLS between NFs and SCP

16.2.0

2019-12

CT#86

CP-193057

0060

3

B

Conveyance of Delegated Discovery Parameters in HTTP/2 Headers

16.2.0

2019-12

CT#86

CP-193057

0064

1

B

Binding indication for subscribe/notify

16.2.0

2019-12

CT#86

CP-193057

0065

B

General Introduction for Delegated Discovery

16.2.0

2019-12

CT#86

CP-193057

0067

1

B

Handling of relative URIs with indirect communication

16.2.0

2019-12

CT#86

CP-193057

0068

2

B

Use of 3gpp-Sbi-Target-apiRoot header in HTTP requests from NFs to SEPP

16.2.0

2019-12

CT#86

CP-193057

0069

2

B

Returning NF Producer ID to NF Consumer when using Delegated Discovery

16.2.0

2019-12

CT#86

CP-193057

0066

1

B

Handling of default notification subscriptions with Delegated Discovery

16.2.0

2019-12

CT#86

CP-193063

0063

1

F

Clarification of Cause MANDATORY_IE_INCORRECT

16.2.0

2020-01

6.10.7 was removed (same as 6.10.2A0

16.2.1

2020-03

CT#87e

CP-200025

0074

6

B

16.3.0

2020-03

CT#87e

CP-200025

0081

6

B

16.3.0

2020-03

CT#87e

CP-200016

0085

2

F

Security requirements for Indirect Communication

16.3.0

2020-03

CT#87e

CP-200016

0086

3

F

Corrections to routing mechanism with TLS between NF and SCP

16.3.0

2020-03

CT#87e

CP-200016

0087

4

F

Binding procedures

16.3.0

2020-03

CT#87e

CP-200016

0088

3

F

Notifications sent with indirect communication

16.3.0

2020-03

CT#87e

CP-200016

0089

4

F

Handling of Discovery headers not supported by the SCP

16.3.0

2020-03

CT#87e

CP-200016

0091

2

F

16.3.0

2020-03

CT#87e

CP-200016

0095

2

F

Indirect Communication Configuration Fixes With or Without TLS

16.3.0

2020-03

CT#87e

CP-200016

0096

1

B

Stateless Network Functions

16.3.0

2020-03

CT#87e

CP-200016

0097

2

F

NF set / NF service set usage in Indirect Communication models

16.3.0

2020-03

CT#87e

CP-200016

0100

F

Complement to 3gpp-Sbi-Callback Types in Annex B

16.3.0

2020-03

CT#87e

CP-200020

0090

2

B

Failover cause

16.3.0

2020-03

CT#87e

CP-200020

0098

1

B

Usage of compression for HTTP responses

16.3.0

2020-03

CT#87e

CP-200039

0092

2

D

16.3.0

2020-06

CT#88e

CP-201030

0104

2

F

16.4.0

2020-06

CT#88e

CP-201030

0106

1

F

16.4.0

2020-06

CT#88e

CP-201030

0107

F

ABNF definition of 3gpp-Sbi-Target-apiRoot header

16.4.0

2020-06

CT#88e

CP-201030

0108

1

F

Error handling for indirect communications

16.4.0

2020-06

CT#88e

CP-201030

0113

1

B

Populating Recovery Information in the Binding Indication

16.4.0

2020-06

CT#88e

CP-201030

0114

1

B

Binding Indication sent from a Service Consumer

16.4.0

2020-06

CT#88e

CP-201030

0118

F

Binding indications / headers

16.4.0

2020-06

CT#88e

CP-201030

0119

1

F

HTTP redirection for indirect communication

16.4.0

2020-06

CT#88e

CP-201030

0121

3

F

Clarifications for scenarios with more than one SCP

16.4.0

2020-06

CT#88e

CP-201030

0124

2

F

16.4.0

2020-06

CT#88e

CP-201030

0127

2

F

16.4.0

2020-06

CT#88e

CP-201030

0128

F

16.4.0

2020-06

CT#88e

CP-201030

0134

F

Clarifications of Binding concepts

16.4.0

2020-06

CT#88e

CP-201030

0135

1

B

Client credentials assertion and authentication

16.4.0

2020-06

CT#88e

CP-201030

0136

F

URI used in communications after an NF Service Producer change

16.4.0

2020-06

CT#88e

CP-201030

0137

F

Discovery parameters

16.4.0

2020-06

CT#88e

CP-201030

0138

F

Support of Nchf_ConvergedCharging_Notify in 3gpp-Sbi-Callback

16.4.0

2020-06

CT#88e

CP-201030

0139

1

F

Complete the description of custom headers

16.4.0

2020-06

CT#88e

CP-201039

0109

1

B

Scope of OCI signalled by an NF service consumer

16.4.0

2020-06

CT#88e

CP-201039

0110

1

B

Load and Overload Control for Indirect Communications

16.4.0

2020-06

CT#88e

CP-201039

0111

1

B

S-NSSAI/DNN based Load/Overload Control

16.4.0

2020-06

CT#88e

CP-201039

0112

1

Handling of multiple LCI/OCIs with different scopes

16.4.0

2020-06

CT#88e

CP-201039

0116

1

F

The Overload Control clarification when OCI sent from a Service Consumer

16.4.0

2020-06

CT#88e

CP-201071

0122

2

F

Failure detection on idle HTTP connections by NFs acting as HTTP/2 server

16.4.0

2020-06

CT#88e

CP-201071

0142

1

F

16.4.0

2020-06

CT#88e

CP-201034

0120

1

B

Resource-Level Authorization

16.4.0

2020-06

CT#88e

CP-201034

0123

2

F

16.4.0

2020-06

CT#88e

CP-201034

0140

1

F

HTTP Connection management and HTTP Retry

16.4.0

2020-06

CT#88e

CP-201034

0141

1

B

Definition of error "RESOURCE_CONTEXT_NOT_FOUND"

16.4.0

2020-06

CT#88e

CP-201047

0132

B

16.4.0

2020-09

CT#89e

CP-202119

0148

1

F

Custom headers related to indirect communication

16.5.0

2020-09

CT#89e

CP-202119

0150

1

F

TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f

16.5.0

2020-09

CT#89e

CP-202119

0151

1

F

Determining the NF Service Producer Identity without support of binding procedures

16.5.0

2020-09

CT#89e

CP-202119

0152

1

F

Clarifications for Indirect Communications

16.5.0

2020-09

CT#89e

CP-202119

0153

F

Incorrect references and editorial errors

16.5.0

2020-09

CT#89e

CP-202119

0154

F

Sending the NRF API URIs to the SCP for indirect communication

16.5.0

2020-09

CT#89e

CP-202119

0157

F

Discovery Headers

16.5.0

2020-09

CT#89e

CP-202119

0158

1

F

Reselection with indirect communication

16.5.0

2020-09

CT#89e

CP-202119

0159

2

F

API Root Change Handling

16.5.0

2020-09

CT#89e

CP-202119

0160

2

F

Notification Binding for Default Subscription

16.5.0

2020-09

CT#89e

CP-202119

0161

1

F

Notification for Default Subscriptions

16.5.0

2020-09

CT#89e

CP-202117

0156

F

3gpp-Sbi-Oci and 3gpp-Sbi-Lci headers

16.5.0

2020-09

CT#89e

CP-202110

0163

2

F

Corrections on expressions based on ABNF

16.5.0

2020-09

CT#89e

CP-202121

0144

1

D

17.0.0

2020-09

CT#89e

CP-202121

0145

D

17.0.0

2020-12

CT#90e

CP-203054

0171

A

Service access authorization for indirect communication with delegated discovery

17.1.0

2020-12

CT#90e

CP-203054

0173

1

A

NF instance selection in SCP for Indirect Communication mode C

17.1.0

2020-12

CT#90e

CP-203054

0175

2

A

Essential Clarification on the Default Notification with indirect communication

17.1.0

2020-12

CT#90e

CP-203054

0177

1

A

Reporting NF is not reachable

17.1.0

2020-12

CT#90e

CP-203054

0181

1

A

Update a binding indication

17.1.0

2020-12

CT#90e

CP-203060

0168

2

F

17.1.0

2020-12

CT#90e

CP-203054

0183

1

A

Binding indication with the scope set to other service

17.1.0

2020-12

CT#90e

CP-203054

0185

1

A

NF instance reselection and use of location

17.1.0

2020-12

CT#90e

CP-203054

0191

1

A

Handling of binding on behalf of another NF

17.1.0

2020-12

CT#90e

CP-203054

0193

1

A

Binding Indication for Backup AMF

17.1.0

2020-12

CT#90e

CP-203054

0197

A

Target NF (service) instance ID in HTTP 307/308 response

17.1.0

2020-12

CT#90e

CP-203054

0198

1

A

17.1.0

2020-12

CT#90e

CP-203048

0195

2

B

Max SCP Hops

17.1.0

2020-12

CT#90e

CP-203061

0167

1

F

17.1.0

2020-12

CT#90e

CP-203061

0179

1

F

Direct retrying with another SCP

17.1.0

2020-12

CT#90e

CP-203064

0169

B

SBI correlation info header

17.1.0

2020-12

CT#90e

CP-203064

0186

1

C

Too Many Requests

17.1.0

2020-12

CT#90e

CP-203064

0187

F

Resolution of FQDN in Callback URIs

17.1.0

2020-12

CT#90e

CP-203064

0189

4

B

Asserted PLMN-ID Header

17.1.0

2021-03

CT#91e

CP-210037

0202

A

with Delegated Discovery

17.2.0

2021-03

CT#91e

CP-210037

0204

A

without Delegated Discovery

17.2.0

2021-03

CT#91e

CP-210037

0206

A

Error handling when SCP receives "401 Unauthorized" or "403 Forbidden" from NFp

17.2.0

2021-03

CT#91e

CP-210037

0208

1

A

Error handling when the SCP fails to obtain an access token

17.2.0

2021-03

CT#91e

CP-210037

0210

1

A

Rejection response upon Client credentials assertion verification failure

17.2.0

2021-03

CT#91e

CP-210037

0212

1

A

Scope parameter in notification and callback responses

17.2.0

2021-03

CT#91e

CP-210037

0214

1

A

User-Agent header

17.2.0

2021-03

CT#91e

CP-210037

0218

1

A

Essential Correction for interpretation of NF change

17.2.0

2021-03

CT#91e

CP-210037

0228

1

A

Signaling Primary or Secondary CHF instance ID in service response with Model D

17.2.0

2021-03

CT#91e

CP-210037

0233

1

A

used by SCP/SEPP

17.2.0

2021-03

CT#91e

CP-210043

0222

A

Essential Correction to Causes NF_FAILOVER and NF_SERVICE_FAILOVER

17.2.0

2021-03

CT#91e

CP-210043

0223

1

A

ABNF Definition of 3GPP Custom Headers

17.2.0

2021-03

CT#91e

CP-210058

0225

A

Correction to API Prefix

17.2.0

2021-03

CT#91e

CP-210021

0215

2

B

Update Binding Indication for multiple resource contexts

17.2.0

2021-03

CT#91e

CP-210021

0226

F

Corrections to the description of the 3gpp-Sbi-discovery custom headers

17.2.0

2021-03

CT#91e

CP-210021

0235

1

F

Usage of Via header

17.2.0

2021-03

CT#91e

CP-210021

0236

1

F

Overload Control based on HTTP status codes

17.2.0

2021-03

CT#91e

CP-210021

0237

D

Editorial Corrections

17.2.0

2021-03

CT#91e

CP-210034

0229

F

Text style correction

17.2.0

2021-06

CT#92e

CP-211059

0242

A

Correction to binding procedures

17.3.0

2021-06

CT#92e

CP-211059

0257

A

SCP Redirect

17.3.0

2021-06

CT#92e

CP-211059

0263

1

A

Requirements supported for Indirect Communication without Delegated Discovery

17.3.0

2021-06

CT#92e

CP-211059

0264

1

A

Sending requests taking the binding level into account

17.3.0

2021-06

CT#92e

CP-211065

0255

A

Match check between Token and CCA

17.3.0

2021-06

CT#92e

CP-211028

0238

1

F

New header for requests sent to an (alternate) NF and overload control

17.3.0

2021-06

CT#92e

CP-211028

0239

2

B

Enhancement of the supported communication options discovery

17.3.0

2021-06

CT#92e

CP-211028

0245

1

F

3GPP SBI Callback in Notification

17.3.0

2021-06

CT#92e

CP-211028

0247

1

F

Clarification on NF Service Advertisement URI

17.3.0

2021-06

CT#92e

CP-211028

0248

1

F

ing

17.3.0

2021-06

CT#92e

CP-211028

0249

1

B

Load control and overload control for SEPP

17.3.0

2021-06

CT#92e

CP-211028

0253

1

Passing the NF Group ID to the NF service consumer for Indirect communication

17.3.0

2021-06

CT#92e

CP-211028

0258

F

Incorrect CR implementation

17.3.0

2021-06

CT#92e

CP-211028

0260

F

Implementation errors

17.3.0

2021-06

CT#92e

CP-211028

0261

F

Service specific support of 409 status code for HTTP GET method

17.3.0

2021-06

CT#92e

CP-211028

0266

2

F

Consumer Information for Direct Notification Report

17.3.0

2021-06

CT#92e

CP-211039

0267

B

N5g-ddnmf Discovery Notifications

17.3.0

2021-06

CT#92e

CP-211046

0252

1

F

Error handling for encBlockIndex

17.3.0

2021-06

CT#92e

CP-211059

0250

F

OpenAPI Reference

17.3.0

2021-09

CT#93e

CP-212060

0272

1

A

Discovery headers in service request with binding information

17.4.0

2021-09

CT#93e

CP-212026

0268

F

Correct the examples of 3gpp-Sbi-Routing-Binding and 3gpp-Sbi-Binding

17.4.0

2021-09

CT#93e

CP-212026

0269

1

F

SCP response in NRF error scenarios

17.4.0

2021-09

CT#93e

CP-212026

0270

F

Via header encoding

17.4.0

2021-09

CT#93e

CP-212026

0274

B

Feature Negotiation for Default Subscription

17.4.0

2021-09

CT#93e

CP-212026

0275

1

F

NRF Uri for Callbacks

17.4.0

2021-09

CT#93e

CP-212055

0273

F

Correction on 3gpp-Sbi-Callback

17.4.0

2021-12

CT#94e

CP-213088

0293

A

Handling of 3gpp-Sbi-Sender-Timestamp and 3gpp-Sbi-Max-Rsp-Time in SEPP

17.5.0

2021-12

CT#94e

CP-213088

0295

1

A

Correction to HTTP status code 307 and 308

17.5.0

2021-12

CT#94e

CP-213086

0240

4

B

Indicating in error responses whether a request was retransmitted by SCP

17.5.0

2021-12

CT#94e

CP-213086

0283

1

B

3GPP SBI Response Information

17.5.0

2021-12

CT#94e

CP-213086

0284

1

B

NF Peer Informaiton

17.5.0

2021-12

CT#94e

CP-213086

0285

1

F

Multiple UE identities in 3gpp-Sbi-Correlation-Info HTTP header

17.5.0

2021-12

CT#94e

CP-213086

0286

1

F

Invalid characters in headers using tchar common component in ABNF syntax

17.5.0

2021-12

CT#94e

CP-213086

0288

F

NF Producer information sent to NF Consumer when using Delegated Discovery

17.5.0

2021-12

CT#94e

CP-213085

0276

1

F

Mandating SCPs to support NF reselection for Model C/D delegated discovery

17.5.0

2021-12

CT#94e

CP-213085

0277

1

B

Indicating possible use of OAuth2 authorization in 3gpp-Sbi-Nrf-Uri header

17.5.0

2021-12

CT#94e

CP-213085

0280

1

F

3gpp-Sbi-Correlation-Info in Indrect Communication with or without Delegated Discovery

17.5.0

2021-12

CT#94e

CP-213085

0281

1

F

Correction on 3gpp-Sbi-Callback

17.5.0

2021-12

CT#94e

CP-213105

0278

1

B

SBI message priority for MPS

17.5.0

2021-12

CT#94e

CP-213093

0287

1

F

Notifying different NF Service consumer instance sharing same authority

17.5.0

2021-12

CT#94e

CP-213087

0289

1

B

New application errors to indicate Congestion per service

17.5.0

2021-12

CT#94e

CP-213087

0290

1

F

NF_FAILOVER and NF_SERVICE_FAILOVER from NF service consumer

17.5.0

2021-12

CT#94e

CP-213087

0297

2

F

Event subscriptions with Inter PLMN and Intra PLMN callback URIs

17.5.0

2022-03

CT#95e

CP-220069

0300

2

A

3gpp-Sbi-Discovery-service-names header

17.6.0

2022-03

CT#95e

CP-220069

0309

A

ABNF correction for binding header

17.6.0

2022-03

CT#95e

CP-220069

0315

A

ABNF definition of the 3gpp-Sbi-Target-Nf-Id header

17.6.0

2022-03

CT#95e

CP-220069

0322

A

Correction on Pseudo-header Setting

17.6.0

2022-03

CT#95e

CP-220023

0298

1

F

Static Authorization

17.6.0

2022-03

CT#95e

CP-220023

0302

1

B

3gpp-Sbi-NF-Peer-Info header field

17.6.0

2022-03

CT#95e

CP-220023

0304

F

HTTP Client Behaviour

17.6.0

2022-03

CT#95e

CP-220023

0305

1

B

Group Binding for NF (Service) Levels

17.6.0

2022-03

CT#95e

CP-220023

0306

1

B

Other-service Scope support to PDU Session resource for NIDD

17.6.0

2022-03

CT#95e

CP-220023

0307

F

Producer ID for Indirect Communication without Delegated Discovery

17.6.0

2022-03

CT#95e

CP-220024

0303

1

B

Avoidance of (re)selection of the target NF for Indirect Communication

17.6.0

2022-03

CT#95e

CP-220024

0316

F

NF Type in User-Agent

17.6.0

2022-03

CT#95e

CP-220024

0323

F

Corrections to the examples on API URI

17.6.0

2022-03

CT#95e

CP-220024

0325

1

B

Retry with an Idempotency key for non-idempotent methods

17.6.0

2022-03

CT#95e

CP-220025

0312

1

F

S-NSSAI encoding in the 3gpp-Sbi-Lci and 3gpp-Sbi-Oci headers’ examples

17.6.0

2022-03

CT#95e

CP-220025

0317

1

B

URL Encoding

17.6.0

2022-03

CT#95e

CP-220025

0326

3

B

Usage indication over N32-f

17.6.0

2022-03

CT#95e

CP-220090

0301

F

Editorial corrections

17.6.0

2022-03

CT#95e

CP-220092

0299

1

F

OpenAPI definition of 3gpp-Sbi-Discovery headers

17.6.0

2022-03

CT#95e

CP-220092

0310

F

ABNF correction for max forwarding header

17.6.0

2022-03

CT#95e

CP-220092

0311

F

SEPP Error Correction

17.6.0

2022-06

CT#96

CP-221027

0327

F

Corrections to Parameter Name in 3gpp-Sbi-Routing-Binding

17.7.0

2022-06

CT#96

CP-221027

0329

F

3gpp-Sbi-Request-Info

17.7.0

2022-06

CT#96

CP-221028

0335

F

Access Token reuse in indirect communication with delegated discovery

17.7.0

2022-06

CT#96

CP-221028

0330

2

F

New values for the 3gpp-Sbi-Callback HTTP custom header

17.7.0

2022-06

CT#96

CP-221045

0328

F

Style correction

17.7.0

2022-06

CT#96

CP-221045

0333

2

F

Removing misplaced string

17.7.0

2022-06

CT#96

CP-221045

0334

F

Target NF type in notification request for NF service consumer reselection by SCP

17.7.0

2022-09

CT#97e

CP-222026

0337

2

F

URL Encoding of data

17.8.0

2022-09

CT#97e

CP-222026

0344

1

F

Binding Indication for the resource bound to a specific NF service instance

17.8.0

2022-09

CT#97e

CP-222026

0345

1

F

Originating network ID

17.8.0

2022-09

CT#97e

CP-222026

0352

1

F

Removal of Editor’s NOTE

17.8.0

2022-09

CT#97e

CP-222026

0353

1

F

Usage of 3gpp-Sbi-NF-Peer-Info HTTP header

17.8.0

2022-09

CT#97e

CP-222045

0340

1

F

Load and Overload Control Information of an NF service instance

17.8.0

2022-09

CT#97e

CP-222045

0346

F

Correct the order of parameters in 3gpp-Sbi-Producer-Id

17.8.0

2022-09

CT#97e

CP-222046

0341

1

A

Redirection to an SCP or SEPP

17.8.0

2022-09

CT#97e

CP-222053

0349

1

F

NF Producer Id for Resource Creation

17.8.0

2022-09

CT#97e

CP-222059

0351

1

A

API version in URI setting in indirect communication

17.8.0

2022-09

CT#97e

CP-222061

0348

1

A

Essential Correction on Headers in Indirect Communication

17.8.0

2022-12

CT#98e

CP-223041

0358

F

Incomplete implementation of CR 29.500 #0353

17.9.0

2022-12

CT#98e

CP-223041

0363

3

F

Identifying the entity inserting 3gpp-Sbi-Originating-Network-Id

17.9.0