Content for TS 23.502 Word version: 19.1.0

1… 4.2.2.2.2 4.2.2.2.3… 4.2.2.3… 4.2.3… 4.2.3.3 4.2.4… 4.2.6 4.2.7… 4.2.9… 4.2.11… 4.2.11.5… 4.3… 4.3.2.2.2 4.3.2.2.3… 4.3.3… 4.3.3.3 4.3.4… 4.3.4.3 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… 4.11.1.2.2 4.11.1.2.3 4.11.1.3… 4.11.1.3.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… 4.15.6.7… 4.15.6.13… 4.15.6.14… 4.15.9… 4.15.9.4… 4.15.13… 4.15.13.4… 4.16… 4.16.4… 4.16.8… 4.16.11… 4.16.14… 4.16.15… 4.17… 4.17.9… 4.18… 4.19… 4.22… 4.23… 4.23.7… 4.23.7.3.3 4.23.7.3.4… 4.23.9… 4.23.9.4… 4.23.11… 4.24… 4.25… 4.25.6… 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… G H…

D.1 Determination of UE presence in Area of Interest by AMF D.2 Determination of UE presence in Area of Interest by NG-RAN
...

A Drafting rules and conventions for NF services p. 866

A.1 General p. 866

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 p. 866

A.2.1 Service naming p. 866

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.

A.2.2 Service operation naming p. 866

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, Fig. A.2.2-1: Service Operation Naming and its Methods

Figure A.2.2-1: Service Operation Naming and its Methods

A.3 Representation in an information flow p. 867

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, Fig. A.3-1: Disaggregated representation of a NF service or service operation in information flows

Figure A.3-1: Disaggregated representation of a NF service or service operation in information flows

A.4 Reference to services and service operations in procedures p. 868

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)

A.5 Service and service operation description template p. 868

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

A.6 Design Guidelines for NF services p. 868

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 p. 868

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 Reusability p. 869

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.

A.6.3 Use Independent Management Schemes p. 869

The mechanisms for independent management schemes are not in scope of this specification.

B Drafting Rules for Information flows p. 870

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.

C Generating EPS PDN Connection parameters from 5G PDU Session parameters p. 871

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, otherwise 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.

D (Normative) UE Presence in Area of Interest p. 872

D.1 Determination of UE presence in Area of Interest by AMF p. 872

If the AMF has requested NG-RAN location reporting as specified in clause 4.10 for the Area Of Interest and UE is in CM-CONNECTED state, including RRC_CONNECTED and RRC_INACTIVE state, the AMF determines the UE presence in the Area of Interest as the reported value from the NG-RAN, as specified in clause D.2.

In the case the UE is served by a MBSR, the AMF may consider the additional ULI provided by the NG-RAN node (as defined in clause 5.35A.6 of TS 23.501) when determining the UE presence in Area of Interest.

If the AMF has requested N2 Notification as specified in clause 4.8.3, the AMF determines the UE presence in Area Of Interest as follows, taking N2 Notification from NG-RAN into consideration:

IN:
- if the UE is in CM-CONNECTED with RRC_CONNECTED state and if the last received User Location Information for the UE is inside the Area Of Interest service area; 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(s).
- if the UE is in CM-CONNECTED and if the UE is inside a Registration Area which is completely contained within the Area Of Interest.
OUT:
- if the UE is in CM-CONNECTED with RRC_CONNECTED state and if the last received User Location Information for the UE is outside the Area Of Interest; 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(s).
- if the UE is in CM-CONNECTED and 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 Area Of Interest service area is indicated as a RAN node identity, and the Parameter Type with value "RAN timing synchronization status change event" is included, and the UE has indicated a support for registration update procedure due to RAN timing synchronization status as described in clause 5.3.4.4 of TS 23.501 and the most recent N2 connection for the UE is via a RAN Node that is included in the Area Of Interest service area; or
- if the Parameter Type with value "Adjust AoI based on RA" is included and the UE is inside a Registration Area which contains at least one Tracking Area that is contained within the Area Of Interest; 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 and the Parameter Type with value "Adjust AoI based on RA" is not included; or
- if the Area Of Interest service area is indicated as a RAN node identity and the Parameter Type with value "RAN timing synchronization status change event" is included and the UE has indicated a support for registration update procedure due to RAN timing synchronization status as described in clause 5.3.4.4 of TS 23.501 and the most recent N2 connection for the UE is via a RAN Node that is not included in the Area Of Interest service area; 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.

D.2 Determination of UE presence in Area of Interest by NG-RAN p. 873

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