This informative Annex provides drafting rules and conventions followed in this technical specification (and TS 23.501
) for the definition of NF services offered over the service-based interfaces.
A.2.1 Service naming
A.3 Representation in an information flow Word-p. 545
A.2.2 Service operation naming
Each NF service provided by a service-based interface shall be named and referred to according to the following nomenclature:
Nnfname_ServiceName, where Nnfname is the service-based interface where the NF service is invoked. See TS 23.501, clause 4.2.6 for the list of service-based interfaces in the 5GS Architecture.
Example (illustrative): Namf_Registration
If a service contains multiple independent operations, each operation shall be named and referred to according to the following nomenclature:
Nnfname_ServiceName_ServiceOperation[Method], where the ServiceName represents the actual NF service. The ServiceOperation itself defines the available service functionality which can be addressed by a specific operation. The Method(s) is/are the action(s), how the ServiceOperation can be used. It can be created, read, updated or deleted.
Example (illustrative): Namf_Session_Registration
In general, this operation naming structure for the given example is depicted in a tree-structure diagram:
Invoking a service or service operation within an information flow is represented using a disaggregated representation (see figure A.3-1).
The disaggregated representations on figure A.3-1 shall be used as follows:
The <step> represents the actual step number in the information flow e.g. "7.".
Representation a) shall be used when the step is required.
Representation b) shall be used when the step is optional or conditional.
A.4 Reference to services and service operations in procedures Word-p. 546
Depending on the information flow, the order of NF Producer and NF Consumer can be reversed.
A.5 Service and service operation description template
Whenever a procedure needs to refer to the service or service operation of a service-based interface, the naming in clause A.2
shall be used, using italic font. Unless otherwise obvious in the text, the NF Consumer of the service or service operation shall be indicated within parenthesis after the service or service operation name.
<Nnfname_ServiceName<_OperationName>> (<NF Name Consumer>)
Example: e.g. Namf_Registration_RelocationRequest
The description of a service or service operation in this specification shall be done according to the following template.
The heading level should follow that of the actual clause where the service is specified.
Service or \Service operation name: <Nnfname_ServiceName
<short descriptive text>.
Known NF Consumers: <list of NFs>.
<list of parameters> -- Parameters required from NF Consumer for successful completion of the service or service operation. Parameters required for the operation of the underlying protocol shall not be listed.
<list of parameters> -- Additional parameters that may be provided by NF Consumer for execution of the service or service operation. Parameters required for the operation of the underlying protocol shall not be listed.
<list of parameters>, < Nnfname_ServiceNameX<_OperationNameY >>, <Other> -- Parameters provided to NF Consumer and/or service triggered upon successful completion of the service and/or other (e.g. procedure triggered). Parameters required for the operation of the underlying protocol shall not be listed.
<list of parameters> -- Additional parameters provided to NF Consumer upon successful completion of the service or service operation. Parameters required for the operation of the underlying protocol shall not be listed.
X.x.2 Service/service operation information flow
<Information flow of the service or service operation offered by NF Producer to NF Consumer over the NF Producer service-based interface>.
This information flow can require invoking other services. In this case, the invoked services are represented as described in clause A.3
A.6 Design Guidelines for NF services
TS 23.501, clause 7.1.1
defines the criteria for defining the NF services. The following clauses identify the design guidelines that shall be considered for identifying the NF services.
A.6.2 Reusability Word-p. 547
The following design guidelines are used for identifying self-contained NF services.
Each NF service operates on its own set of context(s). A context refers to a state or a software resource or an internal data storage. The NF service operations can create, read, update or delete the context(s).
Any direct access of a context(s) owned by a NF service is be made by the service operations of that NF service. Services provided by the same NF can communicate internally within the NF.
A.6.3 Use Independent Management Schemes
The following design guidelines are used for specifying NF services to be reusable.
NF service operations are specified such that other NF can potentially invoke them in future, if required.
The service operations may be usable in multiple system procedures specified in clause 4 of this specification.
Using clause 4 of the current document, the system procedures in which the NF service operations can be used are considered, and based on that the parameters for the NF service operations are clearly listed.
It is possible that, when mapping an end to end call flow to service based architecture, one step in the call flow may map to multiple NF service operation invocations. This specification clearly identifies each NF service operation invocation in the call flow. Protocol optimization of multiple NF service operation invocations are left for TS 29.500
The mechanisms for independent management schemes are not in scope of this specification.
Drafting Rules for Information flows
The following drafting rules are recommended for information flows specified in this specification in order to ensure that the Control Plane network functions can be supported with service based interfaces:
Information flows should describe the end to end functionality. NF services in clause 5 shall only be derived from the information flows in clause 4.
Information flows should strive to use type of interactions such as REQUEST/RESPONSE (e.g. location request, location response), SUBSCRIBE/NOTIFY between Core CP NFs. Any other type of interactions described should have justifications for its use.
Information flows should also ensure readability thus the semantics of the REQUEST/RESPONSE should still be maintained (for instance, we need to indicate PDU Session request, PDU Session response and Subscribe for UE location reporting/Notify UE location reporting) for readers and developers to understand the need for a certain transaction.
As stated in TS 23.501
, service based interface is not supported for N1, N2, N4. Thus, the rules are not meant for those interfaces.
Generating EPS PDN Connection parameters from 5G PDU Session parameters
This annex specifies how to generate the EPS PDN connection parameters from the 5G PDU Session parameters in PGW-C+SMF.
When the PGW-C+SMF is requested to set up/modify either a PDN connection or a PDU session supporting interworking between EPS and 5GS, the PGW-C+SMF generates the PDN Connection parameters from the PDU session parameters.
When the PGW-C+SMF generates the PDN Connection parameters based on the PDU Session parameters, the following rules hold:
PDN type: the PDN type is set to IPv4, IPv6 or IPv4v6 if the PDU Session Type is IPv4, IPv6 or IPv4v6, respectively. The PDN Type is set to Ethernet if the MME, SGW and UE support Ethernet PDN Type, otherwsie the PDN type is set to Non-IP for Ethernet and Unstructured PDU Session Types
EPS bearer ID: the EBI is requested from the AMF during the establishment of a QoS Flow as described in clause 22.214.171.124.1 for PDU Sessions supporting interworking between EPS and 5GS. The EBI is obtained from MME during the establishment of an EPS Bearer (that is triggered by an establishment of a QoS Flow) as defined in TS 23.401 for PDN Connections hosted by PGW-C+SMF. The association between EBI and QoS Flow is stored by the SMF.
APN-AMBR: APN-AMBR is set according to operator policy (e.g. taking the Session AMBR into account).
EPS QoS parameters (including ARP, QCI, GBR and MBR):
If QoS Flow is mapped to one EPS bearer, ARP, GBR and MBR of the EPS Bearer is set to the ARP, GFBR and MFBR of the corresponding QoS Flow, respectively. For standardized 5QIs, the QCI is one to one mapped to the 5QI. For non-standardized 5QIs, the PGW-C+SMF derives the QCI based on the 5QI and operator policy.
A GBR QoS Flow is mapped 1 to 1 to a GBR dedicated EPS Bearer if an EBI has been assigned. After mobility to EPS traffic flows corresponding to GBR QoS Flow for which no EBI has been assigned will continue flowing on the default EPS bearer if it does not have assigned TFT.
If multiple QoS Flows are mapped to one EPS bearer, the EPS bearer parameters are set based on operator policy, e.g. EPS bearer QoS parameters are set according to the highest QoS of all mapped QoS Flows.
After mobility to EPS traffic flows corresponding to Non-GBR QoS Flows for which no EBI has been assigned will continue flowing on the default EPS Bearer if it does not have assigned TFT.