9 Northbound APIs related items

21.9163GPPRelease 16Release descriptionTS

9.1 Usage of CAPIF for xMB API

790019

Usage of CAPIF for xMB API

CAPIF4xMB

S4

SP-180031

Thorsten Lohmar, Ericsson LM

Summary based on the input provided by Ericsson in SP-181187.

The CAPIF4xMB work item resulted in the creation of the xMB specification in TS.26.348 [1]. This TS contains the reference point specification for the external interface towards content providers or other 3GPP defined API invokers.

3GPP SA4 aligned the xMB reference point to the Common API Framework (CAPIF) within the CAPIF4xMB work item targeting Release 16. The xMB reference point exists between Content Providers (as API invoker) and the BM-SC. An API invoker can be a 3rd party provider or other 3GPP defined services.

xMB offers a simple interface to control the MBMS delivery procedure and to ingest the data to be delivered via MBMS. The MBMS usage complexity, e.g. handling of packet losses, etc is handled by the BM-SC.

xMB offers control procedures for different session types, namely generic file delivery, application (timed file streaming like DASH over MBMS), streaming and transport-only (access to a plain IP multicast transport). The xMB reference point offers an extended set of control features for MC Services.

As part of the CAPIF4xMB work item, the xMB Stage 2 architecture and procedures are moved from TS 26.346 to a new TS 26.348, containing the xMB Stage 2 and necessary extensions for CAPIF. The new TS also contains more elaborative guidelines around the usage of the different xMB API features.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=790019

[1] TS 26.348, "Northbound Application Programming Interface (API) for Multimedia Broadcast/Multicast Service (MBMS) at the xMB reference point"

9.2 Enhancement of 3GPP Northbound APIs

840013

Enhancement of 3GPP Northbound APIs

eNAPIs

C3

CP-191233

Yali Yan, Huawei

The 3GPP Northbound APIs (i.e. SCEF Northbound APIs as defined in TS 29.122 [1], NEF Northbound APIs as defined in TS 29.522 [2], CAPIF APIs as defined in TS 29.222 [3] and xMB API as defined in TS 29.116 [4]) have been specified in Release 15 to enable third party Application Servers access the exposed 3GPP network services and capabilities in a secure and controlled manner.

In Release 16, further enhancements and changes to the 3GPP Northbound APIs (i.e. SCEF Northbound APIs, NEF Northbound APIs, CAPIF APIs and xMB API) are necessary. The enhancements specified by this Work Item are:

a) NEF/SCEF Northbound APIs registration with CAPIF Core Function in order to enable the discovery of the Northbound APIs by 3rd party Application Servers;

b) 3GPP Northbound APIs optimization;

c) Further handling of communication failure case, i.e.

– notification of resource allocation failure during procedures of setting up an AS session with required QoS;

– notification of unknown RDS port when the port numbers in MO/MT NIDD mismatch with the NIDD configuration;

d) HTTP-based protocol or OpenAPI file improvements to align with the handling of 5GC APIs, i.e.

– removal of duplicated OpenAPI definition;

– optionality of ProblemDetails;

– storage of YAML files;

– URI structure definition for N33 APIs, T8 APIs and CAPIF APIs;

– table update to align with the SBI template; and

e) Any other necessary improvements and changes missed in Release 15, i.e.

– support battery indication and traffic profile within the communication parameter set for CpProvisioning API;

– notification of the actually applied parameters (Maximum Detection Time, Maximum Latency and Maximum Response Time) in MonitoringEvent API and NpConfiguration API;

– support periodic reporting by MonitoringEvent API;

– support Loss_of_connectivity_notification feature in MonitoringEvent API;

– replace the reference IETF RFC 7159 with IETF RFC 8259;

– merge patch handling of HTTP PATCH operation;

– introduce Enhanced_event_report feature to support detailed event reporting requirement in CAPIF_Events API;

– correct the impacted specifications on other improvements or changes, i.e. attribute names, description of procedures, conditions of properties, syntax errors in OpenAPI file.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840013

[1] TS 29.122: "T8 reference point for northbound Application Programming Interfaces (APIs)".

[2] TS 29.522: "5G System; Network Exposure Function Northbound APIs; Stage 3".

[3] TS 29.222: "Common API Framework for 3GPP Northbound APIs".

[4] TS 29.116: "Representational state transfer over xMB reference point between content provider and BM-SC".

9.3 Enhancements for Common API Framework for 3GPP Northbound APIs

830069

Enhancements for Common API Framework for 3GPP Northbound APIs

eCAPIF

 

SP-181137

Basavaraj Pattan, Samsung

790022

Stage 2 for eCAPIF

eCAPIF

S6

SP-181137

Basavaraj Pattan, Samsung

830022

Security aspects of eCAPIF

eCAPIF

S3

SP-1901240

Rajavelsamy Rajadurai, Samsung

Summary based on the input provided by Samsung in SP-200851.

With the growing interest in 3GPP to develop northbound APIs, it is essential to define a common API framework. A common API framework within 3GPP will allow for a consistent development of northbound APIs across multiple working groups, i.e. when defining northbound APIs to abstract or expose the underlying 3GPP network capabilities to 3rd party applications. Intended users of CAPIF are third-party developers that may not be familiar with 3GPP networks and their underlying complexities.

In Release 15, the technical report TR 23.722 was provided to cover key issues, architecture requirements, functional architecture model, and corresponding solutions that are relevant to the definition of a common API framework applicable to any service APIs when used by northbound entities. Subsequently, still in Release 15, a stage-2 Common API Framework for 3GPP Northbound APIs (CAPIF) specification was developed in TS 23.222, based on the solutions and conclusions of TR 23.722. The work item summary for Release 15 CAPIF is available in TS 21.915 [1].

While a basic Common API Framework is made available in 3GPP Rel-15, there are several enhancements that are considered for developing eCAPIF in Rel-16 in TS 23.222 [2], and the key enhancements are listed as follows:

a. Architecture functional model to support multiple API providers (within and outside the PLMN trust domain) where CAPIF-3, CAPIF-4 and CAPIF-5 were enhanced as CAPIF-3e, CAPIF-4e and CAPIF-5e respectively to enable the API exposing function, the API publishing function and the API management function of the API provider domain within the 3rd party trust domain interaction with the CAPIF core function in the PLMN trust domain. Further, the API exposing function within the PLMN trust domain interacts with the API exposing function in the 3rd party trust domain via CAPIF-7e.

b. Architectural model for the CAPIF interconnection which allows API invokers of a CAPIF provider to utilize the service APIs from the 3rd party CAPIF provider where the designated CAPIF core function of the CAPIF provider A provides the information about the CAPIF instances and service APIs deployed by the CAPIF provider A to the designated CAPIF core function of the CAPIF provider B and vice versa over CAPIF-6e reference point.

c. Additional deployment models including distributed deployment of CAPIF considering PLMN trust domain and 3rd party trust domain, multiple CAPIF core functions that may be deployed within the PLMN trust domain.

d. The procedure to support API topology hiding by dynamically configuring the address of the AEF providing the Service API to the AEF entry point providing the topology hiding. The API publishing function and the API exposing function can be within PLMN trust domain or within 3rd party trust domain.

e. Procedures to support for CAPIF interconnenction including interconnection API publish request from CAPIF core function to CAPIF core function, service API discovery by the API invoker from multiple CCFs, service API discovery between multiple CCFs.

f. Procedures for updating the API invoker’s API list on the CAPIF core function.

g. Procedure for dynamically routing the service API invocation from the AEF acting as service communication entry point to the destination AEF for handling service API.

h. Procedure for registering API provider domain functions on the CAPIF core function and for updating the registration information of the API provider domain functions on the CAPIF core function.

i. Integrated deployment of 3GPP network exposure systems with the CAPIF – The SCEF and the NEF may be integrated with a single CAPIF core function to offer their respective service APIs to the API invokers. The following deployment model is possible for integrated deployment of the SCEF and the NEF with the CAPIF core function.

Security aspects of enhancements for Common API Framework for 3GPP Northbound APIs are specified in TS 33.122 [3].

Stage 3 normative work to support enhancements for Common API Framework for 3GPP Northbound APIs including the OpenAPI specifications made by CT3 working group is specified in TS 29.222 [4].

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830069,790022,830022

[1] TS 21.915: "Release 15 Description; Summary of Rel-15 Work Items".

[1] TS 23.222: "Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2".

[2] TS 33.122: "Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs".

[3] TS 29.222: "Common API Framework for 3GPP Northbound APIs".

9.4 Service Enabler Architecture Layer for Verticals

850048

Service Enabler Architecture Layer for Verticals (SEAL)

SEAL

SP-181141

Basavaraj (Basu) Pattan, Samsung

820027

Stage 2 of SEAL

SEAL

S6

SP-181141

Basavaraj (Basu) Pattan, Samsung

850019

Security aspects of SEAL

SEAL

S3

SP-190901

Rajavelsamy Rajadurai, Samsung

850006

CT aspects of SEAL

SEAL

CT

CP-192255

Sapan Shah, Samsung Electronics

850049

CT1 aspects of SEAL

SEAL

C1

CP-192255

Sapan Shah, Samsung Electronics

850050

CT3 aspects of SEAL

SEAL

C3

CP-192255

Sapan Shah, Samsung Electronics

Summary based on the input provided by Samsung in SP-200852.

3GPP SA6 specified application layer standards for mission critical services and application layer support for V2X. While developing mission critical services, some core set of capabilities (e.g. group management, configuration management, identity management, key management, location management) were identified to be common across MCPTT, MCData and MCVideo services, leading to a separate Common Functional Architecture (CFA) specification. It was identified that V2X applications will also require a similar common set of application layer capabilities as specified in TS 23.286.

Specifying such common capabilities for V2X, independent from those that are defined in existing mission critical specifications could lead to fragmented capabilities and deployments. This approach results in consuming significant development time and delays in timely adoption of 3GPP technologies.

Therefore, a set of common capabilities that can be utilized by V2X applications and potentially by multiple vertical industry applications is developed as service enabler architecture layer (SEAL) over 3GPP networks in TS 23.434 [1].

The Stage-2 SEAL in TS 23.434 specifes the following:

1) The architecture requirements for SEAL services.

2) The functional model for SEAL is organized into generic SEAL service functional model and specific SEAL service functional models. The generic SEAL service functional model will be used as the reference model for the specific SEAL service functional models. The generic functional model (represented using reference point and service based interface) for SEAL service is in the figure below:

In the vertical application layer, the VAL client communicates with the VAL server over VAL-UU reference point. VAL-UU supports both unicast and multicast delivery modes.

The SEAL functional entities on the UE and the server are grouped into SEAL client(s) and SEAL server(s) respectively. The SEAL consists of a common set of services (e.g. group management, location management) and reference points. The SEAL offers its services to the vertical application layer (VAL).

The SEAL client(s) communicates with the SEAL server(s) over the SEAL-UU reference points. SEAL-UU supports both unicast and multicast delivery modes. The SEAL client(s) provides the service enabler layer support functions to the VAL client(s) over SEAL-C reference points. The VAL server(s) communicate with the SEAL server(s) over the SEAL-S reference points. The SEAL server(s) may communicate with the underlying 3GPP network systems using the respective 3GPP interfaces specified by the 3GPP network system.

3) The functional model for interconnection between SEAL servers to support distributed SEAL server deployments, the SEAL server interacts with another SEAL server for the same SEAL service over SEAL-E reference point as shown in the figure below:

4) The functional model for inter-service communication between SEAL servers to support the SEAL server interaction with another SEAL server for inter-service communication over SEAL-X reference point is shown in the figure below:

5) The functional architecture of each SEAL service listed below and corresponding functional entities and reference points along with the procedures and information flows, northbound APIs to expose the SEAL services to the vertical applications in compliance with CAPIF for each SEAL service is listed below:

– Group management (GM): The vertical application specific group communication is one of the essential feature in any vertical application. To enable group communication, each vertical application needs to create and manage the group, group specific policies and group members. The group management service, as provided by SEAL, supports group management operations (i.e. Create, Read, Update, Delete and Notify) by the authorized users or VAL servers. It also supports merging of multiple groups into single group where all the group members of the constituent groups are also members of the merged group.

– Location management (LM): Managing VAL user’s location information is a service that is required by multiple vertical specific applications. The location management service, as provided by SEAL, supports sharing location data between client and server for vertical application usage. It also provides support to request for on-demand location reporting by client and location reporting based on configurable triggers. The service also enables VAL servers to query location of any user as well as sharing the network location information obtained from the 3GPP network systems to the vertical applications.

– Configuration management (CM): Most of the vertical applications need to create and maintain configurations. Further, they need to provide the initial configuration to all its users and need to notify as soon as there is any change in configuration. The configuration management service, as provided by SEAL, supports creating and managing UE configuration and user profile configuration for the vertical applications. It also supports subscribe-notify mechanism so that the VAL users can subscribe to any change in configurations.

– Network resource management (NRM): Many vertical applications require managing different radio bearers and switching among them. The network resource management service, as provided by SEAL, supports establishing and modifying unicast and/or multicast bearers. It also supports announcements for multicast bearers and switching from unicast to multicast bearers and vice versa.

– Key management (KM): The security of sensitive data and user’s information is important aspect for every vertical application. The key management service, as provided by SEAL, supports generation and secure distribution of encryption keys to VAL users.

– Identity management (IM): The identity management service, as provided by SEAL, supports VAL user’s authentication and authorization framework. As per the defined framework, each VAL user sends authentication request using SEAL Identity Management Client (SIM-C) and once the user authentication is successful, the VAL user can request for access-token. The SEAL Identity Management Server (SIM-S) creates the access token, which is opaque to the VAL clients. The access token contains VAL user’s identity. The VAL user presents the access token to VAL server to access VAL service. The VAL server authorizes the VAL user after verifying the validity of the access token.

6) Specifying various deployment models of SEAL services: The SEAL server(s) may be deployed either in the PLMN operator domain or deployed in the VAL service provider domain. The SEAL server(s) connects with the 3GPP network system in one or more PLMN operator domain. The SEAL server(s) may be supporting multiple VAL servers.

7) Service-based interface representation of the functional model for SEAL services as shown in the figure below:

The SEAL function(s) exhibit the service-based interfaces, which are used for providing and consuming SEAL services. The service APIs are specified for each SEAL function enabled over the service-based interface. The service-based interfaces of specific SEAL services are specified in TS 23.434. All the interactions with SEAL are governed based on the reference point interactions of the functional models specified in subclause 6 of TS 23.434. VAL function represents the functionalities of the VAL server.

The service APIs offered by the SEAL function(s) are published and discovered on the CAPIF core function as specified in TS 23.222 [9].

8) SEAL functional model mapping with Common functional architecture (CFA).

Security aspects of 3GPP support for service enabler architecture layer (SEAL) are specified in TS 33.434 [2].

Stage 3 normative work to service enabler architecture layer (SEAL) are specified in TS 24.544 [3], TS 24.545 [4], TS 24.546 [5], TS 24.547 [6], TS 24.548 [7] and TS 29.549 [6].

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=850048,820027,850019,850006,850049,850050

[1] TS 23.434: "Service Enabler Architecture Layer for Verticals; Functional architecture and information flows".

[2] TS 33.434: "Security aspects of Service Enabler Architecture Layer (SEAL) for verticals".

[3] TS 24.544: "Group Management – SEAL; Protocol specification".

[4] TS 24.545: "Location Management – SEAL; Protocol specification".

[5] TS 24.546: "Configuration management – SEAL; Protocol specification".

[6] TS 24.547: "Identity management – SEAL; Protocol specification".

[7] TS 24.548: "Network Resource Management – SEAL; Protocol specification".

[8] TS 29.549: "SEAL; Application Programming Interface (API) specification".

[9] TS 23.222: "Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2 ".

9.5 Other APIs-related items

See also:

Cellular IoT support and evolution for the 5G System

Business Role Models for Network Slicing

Enhancing Topology of SMF and UPF in 5G Networks

MBMS APIs for Mission Critical Services