Content for TR 23.742 Word version: 16.0.0
1 Scope
2 References
3 Definitions and abbreviations
3.1 Definitions
3.3 Abbreviations
4 Architectural Requirements, Principles and Assumptions
4.1 Architectural Requirements
4.2 Architectural Principles
4.3 Architectural Assumptions
4.4 Service Definitions and Principles
...
...
1 Scope p. 9
This technical report studies and evaluates architecture enhancements on potential optimizations to the Release 15 Service-Based Architecture (SBA) in order to provide higher flexibility and better modularization of the 5G System for the easier definition of different network slices and to enable better re-use of the defined services. Moreover, the technical report considers mechanisms in order to better support automation and high reliability of network function service(s). The following aspects are covered:
- Optimizing the modularization of the system to improve its agility.
- Extending the service concept from 5GC control plane to the user plane function(s).
- Further improvements to service framework related aspects.
- Architectural support for highly reliable deployments, considering.
- Study backward and forward compatibility implications resulting from the above bullets.
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 23.501: "System Architecture for the 5G System; Stage 2".
[3]
TS 23.502: "Procedures for the 5G System; Stage 2".
[4]
TS 29.510: "5G System; Network function repository services; Stage 3".
[5]
TS 23.222: "Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2".
[6]
TS 29.531: "5G System; Network Slice Selection Services; Stage 3".
3 Definitions and abbreviations p. 9
3.1 Definitions p. 9
For the purposes of the present document, the terms and definitions given in TR 21.905 apply.
3.3 Abbreviations p. 9
4 Architectural Requirements, Principles and Assumptions p. 10
4.1 Architectural Requirements p. 10
Services shall be fully self-contained, reusable, and shall have independent life-cycle management (e.g. for scaling, healing, etc.).
The services deployed within a Network Slice shall be able to communicate efficiently with minimal information about the Network Slice configuration.
The service framework functionalities include service registration/discovery, communication between service instances and security functions.
The service framework:
- shall provide registration and discovery.
- shall enable efficient communication between service instances and allow distributed scaling.
- shall enable service communication within one slice, between slices, within one service framework, instance between different service framework instances and between different PLMNs with minimal impact to service.
- shall enable handling of failure scenarios with minimal impact to service.
- should enable protection of the system against signaling storms.
- should support protect the integrity and confidentiality of the communication.
- should provide the authentication and authorization to access the service.
4.2 Architectural Principles p. 10
- For interaction between UE/RAN and 5GC, the NF services interactions within 5GC have no impact on NG-RAN or UE, and 5GC interacts with UE and RAN via the specified Reference Point(s).
- For interaction between EPC and 5GC, the NF services interactions within 5GC have no impact on EPC network entities, and 5GC interacts with EPC network entities via the specified Reference Point(s).
- For interactions with the UPF, the NF services interactions within 5GC have no impact on the UP traffic processing model in UPF, including session level reporting by UPF. For all the session level reports, UPF shall report to SMF.
4.3 Architectural Assumptions p. 10
The assumption is that 5GS architecture supports cloud deployments (fully virtualized) and can make use of cloud operation mechanisms, e.g. auto-scaling, self-healing in line with e.g. ETSI NFV specifications.
The implementation architecture is outside of 3GPP SA WG2 scope. For example, how 3GPP NFs/NF Services are grouped into (VNFs) and how the resources for VNFs are managed is outside of 3GPP SA WG2 scope.
4.4 Service Definitions and Principles p. 11
The following principles are general principles for design of services. The Principles are work in progress and will be revisited and evaluated at future meetings. Compromises on some of the principles may be required when deciding how the architecture envolve in Rel-16.
- A service is designed to perform specific tasks, which are different from other services in the system.
- A service has a unique identification. Services that perform different tasks have a different identification.
- Service operations are the only way to communicate with a service.
- Within a given communication context, a service may take the role of either service consumer or service producer. A service consumer is unaware of any internals of the service producer and vice versa.
- A service is designed to operate on a specific set of data (data context, e.g. session data).
- A service instance is a software executable that implements a service. Each service instance needs to be uniquely identified.
- Service instances of the same service may share data via a shared storage resource.
- Not all the service instances of the same service need to have access to a single, shared instantiation of the data context. This may depend on the implemented data consistency model.
