Content for TS 29.500 Word version: 18.4.0

1… 5… 5.2.3… 5.2.3.3… 5.2.4… 6… 6.3… 6.4… 6.5… 6.6… 6.7… 6.10… 6.10.3… 6.10.6… 6.10.11… 6.11… A B C D…

3.1 Definitions 3.2 Abbreviations 3.3 Special characters, operators and delimiters 3.3.1 General 3.3.2 ABNF operators 3.3.3 URI - reserved and special characters 3.3.4 SBI specific usage of delimiters 4.1 NF Services 4.2 Service Based Interfaces 4.3 NF Service Framework 4.3.1 General 4.3.2 NF Service Advertisement URI
...

1 Scope p. 9

The present document specifies the technical realization of the 5GC Service Based Architecture, protocols supported over the Service Based Interfaces, and the functionalities supported in the Service Based Architecture.

The service requirements for the 5G system are defined in TS 22.261. The system architecture requirements are defined in TS 23.501 and the procedures and flows in TS 23.502.

The design principles and documentation guidelines for 5GC SBI APIs are specified in TS 29.501.

2 References p. 9

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.261: "Service requirements for the 5G system; Stage 1".

[3]

TS 23.501: "System Architecture for the 5G System; Stage 2".

[4]

TS 23.502: "Procedures for the 5G System; Stage 2".

[5]

TS 29.501: "5G System; Principles and Guidelines for Services Definition; Stage 3".

[6]

RFC 793: "Transmission Control Protocol".

[7]

RFC 9113: "HTTP/2".

[8]

TS 29.510: "5G System; Network Function Repository Services; Stage 3".

[9]

OpenAPI: "OpenAPI Specification Version 3.0.0", https://spec.openapis.org/oas/v3.0.0.

[10]

RFC 8259: "The JavaScript Object Notation (JSON) Data Interchange Format".

[11]

RFC 9110: "HTTP Semantics".

[12] Void.

[13]

TS 29.571: "5G System; Common Data Types for Service Based Interfaces Stage 3".

[14]

RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".

[15]

TS 23.003: "Numbering, addressing and identification".

[16]

RFC 5681: "TCP Congestion Control".

[17]

TS 33.501: "Security Architecture and Procedures for 5G System".

[18]

IANA: "SMI Network Management Private Enterprise Codes", http://www.iana.org/assignments/enterprise-numbers.

[19]

RFC 7944: "Diameter Routing Message Priority".

[20]

RFC 9111: "HTTP Caching".

[21] Void.

[22]

RFC 6749: "The OAuth 2.0 Authorization Framework".

[23]

RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".

[24] Void.

[25]

RFC 7516: "JSON Web Encryption (JWE)".

[26]

RFC 7515: "JSON Web Signature (JWS)".

[27]

TS 29.573: "5G System: Public Land Mobile Network (PLMN) Interconnection; Stage 3".

[28]

TS 29.502: "5G System; Session Management Services; Stage 3".

[29]

TS 29.503: "5G System; Unified Data Management Services; Stage 3".

[30] Void.

[31]

TS 29.518: "5G System; Access and Mobility Management Services; Stage 3".

[32]

TS 29.531: "5G System; Network Slice Selection Services; Stage 3".

[33] Void.

[34]

RFC 1952: "GZIP file format specification version 4.3".

[35]

TS 29.525: "5G System; UE Policy Control Service; Stage 3".

[36]

RFC 3040: "Internet Web Replication and Caching Taxonomy".

[37]

RFC 5322: "Internet Message Format".

[38]

TS 23.527: "5G System; Restoration Procedures".

[39]

TS 29.303: "Domain Name System Procedures; Stage 3".

[40]

TS 29.515: "5G System; GMLC Services; Stage 3".

[41]

RFC 7519: "JSON Web Token (JWT)".

[42]

TS 32.291: "5G System; charging service; Stage 3".

[43]

RFC 5234: "Augmented BNF for Syntax Specifications: ABNF".

[44]

TS 29.526: "5G System; Network Slice-Specific Authentication and Authorization (NSSAA) Services; Stage 3".

[45]

TS 29.562: "5G System; Home Subscriber Server (HSS) Services for interworking with the IP Multimedia Subsystem (IMS); Stage 3".

[46]

TS 29.555: "5G System; 5G Direct Discovery Name Management Services; Stage 3".

[47]

RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".

[48]

RFC 1866: "Hypertext Markup Language - 2.0".

[49]

RFC 1738: "Uniform Resource Locators (URL)".

3 Definitions and abbreviations p. 11

3.1 Definitions p. 11

For the purposes of the present document, the terms and definitions given in TR 21.905, TS 23.501 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

Binding indication (consumer):

Binding can be used by the NF Service Consumer to indicate suitable NF Service Consumer instance(s) for notification target instance selection, reselection and routing of subsequent notification requests associated with a specific notification subscription. Binding indication needs to be stored by the NF Service Producer. Binding indication may also be used later if the NF Service Consumer starts acting as NF Service Producer, so that service requests can be sent to this NF Service Producer. See clauses 3.1 and 6.3.1.0 in TS 23.501. See also Routing binding indication.

Binding indication (producer):

Binding can be used to indicate suitable target NF Service Producer instance(s) for an NF service instance selection, reselection and routing of subsequent requests associated with a specific NF Service Producer resource (context) and NF service. Binding allows the NF Service Producer to indicate to the NF Service Consumer if a particular context should be bound to an NF service instance, NF instance, NF service set or NF set. Binding indication needs to be stored by the NF Service Consumer. See clauses 3.1 and 6.3.1.0 in TS 23.501. See also Routing binding indication.

Binding entity:

Either of the following identifiers: NF Service Instance, NF Service Set, NF Instance or an NF Set. The relation between these are explained below.

Binding entity ID:

An identification of a binding entity, i.e. NF Service Instance ID, NF Service Set ID, NF Instance ID or an NF set ID.

Binding level:

A parameter (bl) in "3gpp-Sbi-Routing-Binding" and "3gpp-Sbi-Binding" HTTP custom headers, which indicates the binding entity towards which a preferred binding exists (i.e. either to NF Service Instance, NF Service Set, NF Instance or an NF Set). Other binding entities in these headers, which do not correspond to the binding level indicate alternative binding entities that can be reselected and that share the same resource contexts (see Table 6.3.1.0-1 in TS 23.501).

Callback URI:

URI to be used by an NF Service Producer to send notification or callback requests.

Endpoint address:

An address in the format of an IP address, transport and port information, or FQDN, which is used to determine the host/authority part of the target URI. This Target URI is used to access an NF service (i.e. to invoke service operations) of an NF service producer or for notifications to an NF service consumer. See clauses 3.1 and 6.3.1.0 of TS 23.501.

NF Instance:

An identifiable instance of the NF. An NF Instance may provide services offered by one or more NF Service instances.

NF Service Instance:

An identifiable instance of the NF service.

NF Service Set:

A group of interchangeable NF service instances of the same service type within an NF instance. The NF service instances in the same NF Service Set have access to the same context data.

NF Set:

A group of interchangeable NF instances of the same type, supporting the same services and the same Network Slice(s). The NF instances in the same NF Set may be geographically distributed but have access to the same context data.

Notification endpoint:

Notification endpoint is a destination URI of the network entity where the notification is sent. See clause 6.3.1.0 in TS 23.501.

Routing binding indication:

Information included in a request or notification and that can be used by the SCP for discovery and associated selection to of a suitable target. See clauses 3.1, 6.3.1.0 and 7.1.2 in TS 23.501. Routing binding indication has similar syntax as a binding indication, but it has different purpose. Routing binding indication provides the receiver (i.e. SCP) with information enabling to route an HTTP request to an HTTP server that can serve the request. Routing binding indication is not stored by the receiver.

Routing binding indication:

3.2 Abbreviations p. 12

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

GZIP

GNU ZIP

LC-H

Load Control based on LCI Header

LCI

Load Control Information

MCX

Mission Critical Service

MPS

Multimedia Priority Service

OCI

Overload Control Information

OLC-H

Overload Control based on OCI Header

SCP

Service Communication Proxy

SEPP

Security and Edge Protection Proxy

SMP

SBI Message Priority

3.3 Special characters, operators and delimiters |R16| p. 12

3.3.1 General p. 12

A number of characters have special meaning and are used as delimiters in this document and also in other stage 3 SBI specifications. Below clauses specify the usage of a selected set of the special characters. Full set of these special characters are specified in the respective IETF specifications.

3.3.2 ABNF operators p. 12

Operator. The forward slash character separates alternatives. See Section 3.2 in RFC 5234.

Operator. The number sign character allows for compact definition of comma-separated lists, similar to the "*" operator. See Section 2.1 in RFC 9110.

Special character. The equal sign character separates an ABNF rule name from the rule elements. See Section 2.2 in RFC 5234.

[ ]

Operator. The square bracket characters enclose an optional element sequence. See Section 3.8 in RFC 5234.

< >

Special characters. The angle bracket characters typically enclose an ABNF rule element (they are optional). See Section 2.1 in RFC 5234.

Operator. The star character precedes an element and indicates the elements repetition. See Section 3.6 in RFC 5234.

;

Operator. Semicolon character indicates the start of a comment that continues to the end of line. See Section 3.9 in RFC 5234.

3.3.3 URI - reserved and special characters p. 12

Special characters that are used as delimiters in URI syntax have somewhat different purpose from the same characters when used by ABNF syntax. See clause 3.3.3 in TS 29.501.

3.3.4 SBI specific usage of delimiters p. 12

See clause 3.3.4 in TS 29.501.

4 Service Based Architecture Overview p. 13

4.1 NF Services p. 13

TS 23.501 defines the 5G System Architecture as a Service Based Architecture, i.e. a system architecture in which the system functionality is achieved by a set of NFs providing services to other authorized NFs to access their services.

Control Plane (CP) Network Functions in the 5G System architecture shall be based on the service based architecture.

A NF service is one type of capability exposed by a NF (NF Service Producer) to other authorized NF (NF Service Consumer) through a service based interface. A NF service may support one or more NF service operation(s). See clause 7 of TS 23.501.

Network Functions may offer different functionalities and thus different NF services. Each of the NF services offered by a Network Function shall be self-contained, acted upon and managed independently from other NF services offered by the same Network Function (e.g. for scaling, healing).

4.2 Service Based Interfaces p. 13

A service based interface represents how the set of services is provided or exposed by a given NF. This is the interface where the NF service operations are invoked.

The service based Control Plane interfaces within the 5G Core Network are specified in TS 23.501.

4.3 NF Service Framework p. 13

4.3.1 General p. 13

The Service Based Architecture shall support the NF Service Framework that enable the use of NF services as specified in clause 7.1 of TS 23.501.

The NF Service Framework includes the following mechanisms:

NF service registration and de-registration: to make the NRF aware of the available NF instances and supported services (see clause 7.1.5 of TS 23.501);
NF service discovery: to enable a NF Service Consumer to discover NF Service Producer instance(s) which provide the expected NF service(s) (see clause 7.1.3 of TS 23.501);
NF service authorization: to ensure the NF Service Consumer is authorized to access the NF service provided by the NF Service Producer (see clause 7.1.4 of TS 23.501);
Inter service communication: NF Service Consumers and NF Service Producers may communicate directly or indirectly via a Service Communication Proxy (SCP). Whether a NF uses Direct Communication or Indirect Communication via an SCP is based on configuration of the NF.

The stage 3 procedures for NF service registration and de-registration, NF service discovery and NF service authorization are defined in TS 29.510.

4.3.2 NF Service Advertisement URI p. 13

When invoking a service operation of a NF Service Producer that use HTTP methods with a message body (i.e. PUT, POST and PATCH), the NF Service Consumer may provide NF Service Advertisement URI(s) in the service operation request, based on operator policy, if it expects that the NF Service Producer may subsequently consume NF service(s) which the NF Service Consumer can provide (as a NF Service Producer).

When receiving NF Service Advertisement URI(s) in a service operation request, the NF Service Producer may store and use the Service Advertisement URI(s) to discover NF services produced by the NF Service Consumer in subsequent procedures, based on operator policy.

The NF Service Advertisement URI identifies the nfInstance resource(s) in the NRF which are registered by NF Service Producer(s).

An example of NF Service Advertisement URI could be represented as:

"{apiRoot}/nnrf-disc/nf-instances?nfInstanceId={nfInstanceId}".

When applicable, the NF Service Advertisement URI(s) shall be carried in HTTP message body.