Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  17.2.1

Top   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.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.3.2.5…   4.15.4…   4.15.6.7…   4.15.7…   4.16…   4.16.4…   4.16.8…   4.16.11…   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…   5.2.18…   A…   E…   F…

 

A  Drafting rules and conventions for NF servicesWord‑p. 662

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 clause 4.2.5 of TS 23.501 for the list of service-based interfaces in the 5GS Architecture.
Example (illustrative): Namf_Registration.
Up

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:
Reproduction of 3GPP TS 23.502, Figure A.2.2-1: Service Operation Naming and its Methods
Up

A.3  Representation in an information flowWord‑p. 663

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.
Reproduction of 3GPP TS 23.502, Figure A.3-1: Disaggregated representation of a NF service or service operation in information flows
Up

A.4  Reference to services and service operations in proceduresWord‑p. 664

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.
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>.
Up

A.6  Design Guidelines for NF services

Clause 7.1.1 of TS 23.501 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. 665

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.
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. 666

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.
Up

C  Generating EPS PDN Connection parameters from 5G PDU Session parametersWord‑p. 667

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 SMF+PGW-C.
When the SMF+PGW-C is requested to set up/modify either a PDN connection or a PDU session supporting interworking between EPS and 5GS, the SMF+PGW-C generates the PDN Connection parameters from the PDU session parameters.
When the SMF+PGW-C 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 SMF+PGW-C. 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 SMF+PGW-C 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. 668

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
    • 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
    • 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