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 |