Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.502  Word version:   16.4.0

Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2…   4.3.2.2.2   4.3.2.2.3…   4.3.3   4.3.4   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2   4.11.3…   4.12…   4.12.6…   4.12a   4.12b   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24   4.25   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   A…   E…   F…

 

A  Drafting rules and conventions for NF servicesWord-p. 544
Drafting rules and conventions for NF services
A.1  General
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  Naming
A.2.1  Service 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.
A.2.2  Service operation naming
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[Create], Namf_Session_Registration[Delete]
In general, this operation naming structure for the given example is depicted in a tree-structure diagram:
Up
A.3  Representation in an information flowWord-p. 545
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.
Up
NOTE:
Depending on the information flow, the order of NF Producer and NF Consumer can be reversed.
A.4  Reference to services and service operations in proceduresWord-p. 546
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 (AMF)
Up
A.5  Service and service operation description template
The description of a service or service operation in this specification shall be done according to the following template.
NOTE:
The heading level should follow that of the actual clause where the service is specified.
X.x <Nnfname_ServiceName<_OperationName>>
X.x.1 Description
Service or \Service operation name: <Nnfname_ServiceName<_OperationName>>.
Description:
<short descriptive text>.
Known NF Consumers: <list of NFs>.
Inputs, Required:
<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.
Inputs, Optional:
<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.
Outputs, Required:
<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.
Outputs, Optional:
<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>.
NOTE:
This information flow can require invoking other services. In this case, the invoked services are represented as described in clause A.3.
Up
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.1  Self-Containment
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.2  ReusabilityWord-p. 547
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.
NOTE:
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 consideration.
Up
A.6.3  Use Independent Management Schemes
The mechanisms for independent management schemes are not in scope of this specification.
B  Drafting Rules for Information flowsWord-p. 548
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:
  1. 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.
  2. 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.
  3. 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.
NOTE:
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.
Up
C  Generating EPS PDN Connection parameters from 5G PDU Session parametersWord-p. 549
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 4.11.1.4.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.
Up
D (Normative)  UE Presence in Area of InterestWord-p. 550
D.1  Determination of UE presence in Area of Interest by AMF
If RRC Inactive state applies to NG-RAN and the AMF has requested NG-RAN location reporting for the Area Of Interest and UE is in CM-CONNECTED state, the AMF determines the UE presence of Area of Interest as the reported value from the NG-RAN.
If RRC Inactive state applies to NG-RAN and the AMF has requested N2 Notification, the AMF determines the UE presence in Area Of Interest as follows:
  • IN:
    • if the UE is inside the Area Of Interest service area and if the UE is in CM-CONNECTED with RRC Connected state; or
    • NOTE 1:
      The above is valid e.g. under the condition that Area Of Interest border coincides with NG-RAN node service area border or RAN Notification Area.
    • if the UE is inside a Registration Area which is contained within the Area Of Interest.
  • OUT:
    • if the UE is outside the Area Of Interest in CM-CONNECTED with RRC Connected state; or
    • NOTE 2:
      The above is valid e.g. under the condition that Area Of Interest border coincides with NG-RAN node service area border or RAN Notification Area.
    • if UE is inside a Registration Area which does not contain any part of Area Of Interest.
    • UNKNOWN:
    • if none of above conditions for IN or OUT is met.
Otherwise, AMF determines the UE presence of Area Of Interest as follows:
  • IN:
    • if the UE is inside the Area Of Interest service area and if the UE is in CM-CONNECTED state; or
    • if the UE is inside a Registration Area which is contained within the Area Of Interest.
  • OUT:
    • if the UE is outside the Area Of Interest in CM-CONNECTED; or
    • if UE is inside a Registration Area which does not contain any part of Area Of Interest.
    • UNKNOWN:
    • if none of above conditions for IN or OUT is met.
Up
D.2  Determination of UE presence in Area of Interest by NG-RAN
If the AMF has requested for the Area of Interest, NG-RAN determines the UE presence of Area Of Interest as follows:
  • IN:
    • if the UE is inside the Area Of Interest and the UE is in RRC Connected state; or
    • if the UE is inside an RNA which is contained within the Area Of Interest.
  • OUT:
    • if the UE is outside the Area Of Interest in RRC Connected state; or
    • if UE is inside an RNA which does not contain any part of Area Of Interest.
    • UNKNOWN:
    • if none of above conditions for IN or OUT is met.

Up   Top   ToC