18 Other system-wide Features

21.9163GPPRelease 16Release descriptionTS

18.1 Enablers for Network Automation Architecture for 5G

830047

Enablers for Network Automation for 5G

eNA

S2

SP-181123

Xiaobo Wu, Huawei Technologies

760047

Study of enablers for Network Automation for 5G

FS_eNA

S2

SP-180792

Xiaobo Wu, Huawei Technologies

820020

Stage 2 of eNA

eNA

S2

SP-181123

Xiaobo Wu, Huawei Technologies

830009

CT aspects of eNA

eNA

ct

CP-191111

Yali Yan, Huawei

830048

CT3 aspects of eNA

eNA

C3

CP-191111

Yali Yan, Huawei

830049

CT4 aspects of eNA

eNA

C4

CP-191111

Yali Yan, Huawei

Summary based on the input provided by Huawei in SP-200254.

In order to improve the NWDAF initiated in Rel 15, the eNA (Enablers for Network Automation for 5G) feature specifies the data collected by NWDAF and the NWDAF output (i.e. statistics and predictions) to support network automation.

The eNA feature includes:

– Architecture enhancements of 5G System to support network data analytics service

– A framework to enable data collection and provide analytics to consumers

– Extensions to existing Nnwdaf services to support the analytics that are required.

In addition, the eNA Work Item is applicable to the eV2XARC Work Item in which the V2X Application Server acting as an Application Function (AF) may consume relevant network data analytics provided by NWDAF for the purposes of adjustment of the application.

Main impacts on the system by the eNA Work Item are as follows:

– Non-roaming reference architecture for data analytics:

– Data Collection architecture from any NF:

Figure 1: Data Collection architecture from any NF

– Network Data Analytics Exposure architecture:

Figure 2: Network Data Analytics Exposure architecture

– General data collection procedures and network data analytics exposure procedures

– Collection method of data from 5G NFs, from AF via NEF and from OAM;

– Analytics exposure to the registered Consumer NF, when the NF is an AF located outside the MNO domain, analytics are provided via NEF.

– For each Analytics ID, the following was specified:

– General description;

– Input data consumed by NWDAF to derive the network data analytics;

– Output Analytics including details of the parameters;

– Procedure for NWDAF providing the network data analytics.

– Possible usage of analytics by some consumer NFs is defined for the following Analytics ID:

– Analytics ID = "Service experience"

– If the Consumer NF is PCF, the PCF may check the 5QI values assigned to the Application, and may use this as input to calculate and update the authorized QoS for a service data flow template.

– Analytics ID = "NF load information"

– If the Consumer NF is AMF, based on the SMF Load, AMF could select a suitable SMF during the PDU Session Establishment or Modification procedure.

– If the Consumer NF is SMF, based on the UPF Load, SMF could select a suitable UPF during the PDU Session Establishment or Modification procedure.

– Analytics ID = "Network Performance"

– If the Consumer NF is PCF, then PCF could help determine suitable background data transfer policies that fulfills Network Performance requirements t.

– Analytics ID = "UE mobility"

– If the Consumer NF is AMF, then AMF may use it to optimize the UE’s paging strategy or to learn expected UE behavior parameters for deriving appropriate MICO mode configuration.

– If the Consumer NF is SMF, based on the UE Moving Trajectory, the SMF could select a suitable UPF during the PDU Session Establishment or Modification procedure.

– If the Consumer NF is UDM, the UDM may store the UE Mobility analytics as the subscription data for the UE and provision it to the AMF to help monitoring the UE’s mobility behavior.

– Analytics ID = "UE Communication"

– If the Consumer NF is SMF, based on the UE Communication analytics, the SMF could select a suitable UPF during the PDU Session Establishment or Modification procedure.

– If the Consumer NF is UDM, the UDM may store the UE Communication analytics as the subscription data for the UE and provision it to the SMF to help monitoring the UE’s communication behavior.

– Analytics ID = "Abnormal behaviour"

– If the Consumer NF is PCF, based on different Exception IDs in the analytics, the PCF could make different policies, depending on operator defined policies. Some examples are provided for illustration purposes such as the PCF may use "Unexpected UE location" as input to adjust the Service Area Restrictions, "Suspicion of DDoS attack" to request the SMF to terminate the PDU session, "Wrong destination address" to perform gating of a service data flow and "Unexpected long-live/large rate flows" to perform QoS related policies such as gating or policing. In another abnormal behavior example, the AMF based on “Ping-Pong UE” Exception ID, may adjust the UE registration area.

– Analytics ID = "User Data Congestion"

– If the Consumer NF is an AF interfacing through NEF, the NEF could provide the User Data Congestion analytics to the AF to help optimize the application information.

– Analytics ID = "QoS Sustainability"

– If the Consumer is V2X Application Server acting as an AF, the V2X Application Server can use this analytics for the purposes of adjustment of the application, e.g. adjust inter-vehicle gap, change video codec parameters, etc.

– NWDAF services to expose Network Data Analytics to the Consumer NFs are specified. Two models are defined:

– Subscribe-Notify model, i.e. Nnwdaf_AnalyticsSubscription_Subscribe / Nnwdaf_analyticsSubscription_Notify, to allow provide continuous data analytics exposure from NWDAF to the Consumer NF;

– Request-Response model, i.e. Nnwdaf_AnalyticsInfo_Request / Nnwdaf_AnalyticsInfo_Request response, to provide a one-time data analytics exposure response from the NWDAF to the requesting Consumer NF.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830047,760047,820020,830009,830048,830049

[1] TS 23.501: "System Architecture for the 5G System; Stage 2".

[2] TS 23.502: "Procedures for the 5G System; Stage 2".

[3] TS 23.503: "Policy and Charging Control Framework for the 5G System; Stage 2".

[4] TS 23.288: "Architecture enhancements for 5G System (5GS) to support network data analytics services".

[5] TS 28.550: "Management and orchestration; Performance assurance".

[6] TS 29.520: "5G System; Network Data Analytics Services; Stage 3".

[7] TS 29.517: "5G System; Application Function Event Exposure Service; Stage 3".

18.2 Provision of Access to Restricted Local Operator Services by Unauthenticated UEs

760003

Provision of Access to Restricted Local Operator Services by Unauthenticated UEs

PARLOS

 

SP-170449

Covell, Betsy Nokia

740002

Study on Stage 1 of PARLOS

FS_PARLOS

S1

SP-160904

Covell, Betsy

760046

Study on Stage 2 for PARLOS

FS_PARLOS_SA2

S2

SP-180501

Nokia (Nicolas Drevon

800035

Study on Security Aspects of PARLOS

FS_PARLOS_Sec

S3

SP-180442

Greg Schumacher, Sprint

760071

Stage 1 of PARLOS

PARLOS

S1

SP-170449

Covell, Betsy Nokia

810008

Stage 2 of PARLOS

PARLOS

S2

SP-180738

Nokia (Nicolas Drevon

830012

CT aspects of PARLOS

PARLOS

ct

CP-190197

Liu, Jennifer; Nokia

830062

CT1 aspects of PARLOS

PARLOS

C1

CP-190197

Liu, Jennifer; Nokia

830063

CT3 aspects of PARLOS

PARLOS

C3

CP-190197

Liu, Jennifer; Nokia

830064

CT4 aspects of PARLOS

PARLOS

C4

CP-190197

Liu, Jennifer; Nokia

830065

CT6 aspects of PARLOS

PARLOS

C6

CP-190197

Liu, Jennifer; Nokia

Summary based on the input provided by Nokia in SP-200215.

This WI adds requirements to enhance the 3GPP PS Domain to provide an optional capability to allow unauthenticated UE’s to access restricted local operator services based on operator policy and regional regulatory requirements. The requirements address identifying when restricted local operator services are available and enabling a UE to attach to a network for the purpose of accessing a restricted local operator service even if the UE is not able to be authenticated by the network. The requirements can be found in TS 22.101 [1], TS 22.115 [2], and TS 22.228 [3].

The PARLOS WI was driven primarily by FCC regulations for manual roaming as described in [4] and [5]. The ability to provide access to such local services has been available to U.S. operators on a proprietary basis. However, the wide deployment of LTE and corresponding introduction of VoLTE creates demand for a standardized mechanism to allow a UE to access these services such as manual roaming without necessarily being successfully authenticated for access. This optional functionality of supporting access to RLOS services to unauthenticated UEs can be deployed based on operator policy. The RLOS services themselves are out of scope of 3GPP. PARLOS is an LTE capability.

The PARLOS requirements provide for a network to inform UEs using a 3GPP access technology that RLOS services are available and to allow access to the RLOS services when requested by the UE without requiring successful authentication of the UE first. The services are provided in an isolated manner that prevents an unauthenticated UE from accessing any other service or functionality in the network. Additional requirements also provide for collection of charging information related to the use of RLOS services.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=760003,740002,760046,800035,760071,810008,830012,830062,830063,830064,830065

[1] TS 22.101 Requirements for access to restricted local operator services

[2] TS 22.115 Charging for restricted local operator services

[3] TS 22.228 Requirements for access to restricted local operator services

[4] Code of Federal Regulations (CFR) Title 47 Chapter 1 Subchapter B Part 20 Section 20.3

[5] Code of Federal Regulations (CFR) Title 47 Chapter 1 Subchapter B Part 20 Section 20.12 (Resale and Roaming)

18.3 Enhancing Topology of SMF and UPF in 5G Networks

820043

Enhancing Topology of SMF and UPF in 5G Networks

ETSUN

 

SP-181116

 Laurent Thiebaut (Nokia)

770039

Study on ETSUN

FS_ETSUN

S2

SP-180731

Laurent Thiebaut (Nokia)

820013

Stage 2 of ETSUN

ETSUN

S2

SP-181116

 

830002

CT aspects of ETSUN

ETSUN

ct

CP-190192

Landais, Bruno, Nokia

830055

CT3 aspects of ETSUN

ETSUN

C3

CP-190192

Landais, Bruno, Nokia

830056

CT4 aspects of ETSUN

ETSUN

C4

CP-190192

Landais, Bruno, Nokia

850024

Charging aspects of ETSUN

ETSUN

S5

SP-190880

Dong, Jia, China Mobile

Summary based on the input provided by Nokia in SP-200256.

Enhancing Topology of SMF and UPF in 5G Networks (ETSUN) has two goals:

1. Enable the 3GPP system to support deployments where a SMF is not able / allowed to control UPF(s) throughout the same PLMN.

– This is mostly meant for very big networks which are subdivided into geographical areas with each their own management;

– This relates with the addition of I-SMF in the architecture but defines also the possibility of changing the V-SMF in case of Home-Routing.

2. Enhance the capability of 5GS architecture for a UPF to be controlled by multiple SMF’s (and many UPF’s to be controlled by many SMFs) especially for the UE IP address / Prefix allocation

These features couldn’t be specified as part of 3GPP R15 Session Management due to lack of time.

Addition of I-SMF in the architecture

When a UE with an established PDU Session is not in a TA served by the SMF of this PDU Session, an intermediate SMF (called I-SMF) is inserted by the AMF in the signalling path of the PDU session to control the intermediate UPF (called I-UPF) terminating the N3 interface with the 5G Access Network.

Figure 1: Non-roaming architecture with I-SMF insertion to the PDU Session in reference point representation, with no UL-CL/BP

The I-SMF acts in a similar way than the V-SMF of a Home Routed PDU Session: as long as the UE remains in its own I-SMF service area, the I-SMF handles the transitions between User Plane Active and Inactive for the PDU session, the Hand-Over and controls the local UPF(s) with sometimes relaying of N4 commands received from the SMF. The SMF remains responsible of the interfaces with the PCF and the CHF, of the interface with the UDM and of the overall control of the PDU Session.

When the I-SMF is inserted into a PDU Session, the I-SMF provides to the SMF the list of DNAI it supports. Based on this information received from I-SMF and on PCC rules for the PDU Session, the SMF may provide the DNAI(s) of interest for local traffic steering to the I-SMF for this PDU Session. The I-SMF is thus responsible for the insertion, modification and removal of UPF(s) to ensure local traffic steering: the SMF does not need to know the mapping between DNAI(s) for local traffic offload and local UPF(s). Then the SMF provides N4 rules to the I-SMF for how the traffic for local offload shall be detected, enforced, monitored in UPF(s) controlled by the I-SMF.

When the UE moves out of the service area of the I-SMF, the I-SMF may be changed or the I-SMF is simply removed. Likewise, the V-SMF may be changed upon UE mobility in case of Home-Routing.

UE IP address / Prefix allocation

ETSUN adds the possibility for the SMF to defer to the UPF the UE IP address / Prefix allocation or to indicate to the DHCP/DN-AAA server the range (corresponding to the UPF) of IP address / Prefix to be allocated : this allows many SMF(s) to control the same UPF without having to synchronise or divide the UE IP address / Prefix space between these SMF(s).

Charging aspects (Summary provided by China Mobile in SP-200266)

SA2, CT3 and CT4 have studied the enhanced topology deployments of SMF and UPF in TR 23.726, TS 23.501 and 23.502. S5 WI ETSUN specify charging support for deployments topologies with specific SMF service areas to line up with the other NF interfaces.

Charing Stage 2 work on WI ETSUN for TS 32.255 [3]:

– Specify charging procedures and functionality enhancement for PDU sessions with Intermediate SMF (I-SMF) and anchor SMF (SMF), based on existing Nchf to SMF.

– Introduction of V-SMF change in Roaming HR principles and message flows.

– Enhance procedures for addition /change/removal of PSA for UL CL or BP controlled by I-SMF.

– Update charging procedures with I-SMF insertion/change/removal.

– Add I-SMF related triggers in SMF.

Charging Stage 3 work on WI ETSUN for 32.291 [4] and 32.298 [5]:

– Add relevant parameters in CHF-CDR to support I-SMF as serving network function.

– Add I-SMF related trigger, trigger types and data type.

– Update Nchf_ ConvergedCharging API.

References

For the addition of I-SMF in the architecture, ETSUN is mostly specified in TS 23.501 [1] clause 5.34 and in TS 23.502 [2] clause 4.23 (both clauses are dedicated to ETSUN).

For the aspects related with UE IP address allocation, ETSUN is mostly specified in a CR 0931/0954 (SP-190164) to TS 23.501 [1] clause 5.8.2.2.1.

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820043,770039,820013,830002,830055,830056,850024

[1] TS 23.501: "System Architecture for the 5G System; Stage 2".

[2] TS 23.502: "Procedures for the 5G System; Stage 2".

[3] TS 32.255: "5G data connectivity domain charging"

[4] TS 32.291: "5G system, charging service"

[5] TS 32.298: "Charging Data Record (CDR) parameter description"

18.4 Private and Non-Public Network Support for NG-RAN

830081

Private Network Support for NG-RAN

NG_RAN_PRN

R3

RP-200122

China Telecom

830181

Core part: Private Network Support for NG-RAN

NG_RAN_PRN-Core

R3

RP-200122

China Telecom

Summary based on the input provided by China Telecom in RP-200733.

This work item specifies the Private Network (i.e. Stand-alone Non-Public Network (NPN) and PLMN Integrated Non-Public Network) features for gNB with the following functionalities:

Support NPN functionality in NG-RAN:

– CAG/SNPN relevant parameter broadcast from SIB

– CAG/SNPN cell selection/reselection

– CAG/SNPN cell access control

– For CAG, in the case of Intra-RAT intra-system and inter-RAT intra-system, the connected mode mobility support

– The connected mode mobility support within SNPN

For CAG/SNPN, necessary modifications to NG-C and Xn interfaces to communicate the CAG-ID/NID related parameters to NG-RAN nodes, respectively: "Support CAG/SNPN functionality with CU-DU split" and "Support CAG/SNPN functionality with CP-UP split", if any.

The key functionalities of this work item include the following.

NPN relevant parameter broadcast from SIB

The NPN IDs (i.e. SNPNs (identified by PLMN ID + NID) and PNI-NPNs (identified by PLMN ID + CAG ID)) were introduced into SIB1 to indicate UEs whether a cell is an NPN cell. Up to 12 different SNPNs or PNI-NPNs or mixed networks can be broadcasted in a cell. SIB1 allows indication of TAC, RANAC, cell Identity per SNPN or per PNI-NPN.

The names of NPNs (HRNN) are broadcasted in SIB10 and the On-demand SI in connected is not supported for SIB10. The HRNN is associated with the Network ID implicitly. The SIB for HRNN shall have the same amount of HRNN elements as the number of CAGs and NIDs in SIB1.

New defined IE ‘manualCAGselectionAllowed-r16’ is used to indicate whether it is allowed users to manually select a CAG-ID supported by the CAG cell but outside the UE’s allowed CAG list.

Only cells supporting CAG(s), including CAG only cells and shared CAG cells, may be listed in the new CAG PCI lists, UE may use knowledge of the CAG PCIs to improve implementation dependent search procedures for CAGs.

NPN cell selection/reselection

NPN selection functions similar to normal PLMN selection, when a cell broadcasts any CAG IDs or NIDs, NPN-capable Rel-16 UE can treat the cell with cellReservedForOtherUse = true as a candidate cell during cell selection and cell reselection. UE AS reports the found NPN IDs to NAS. In case of manual selection, the human readable network name (if broadcasted) may also be provided from AS to NAS.

The UE shall scan all RF channels in the NR bands according to its capabilities to find available NPNs. On each carrier, the UE shall at least search for the strongest cell, read its system information and report available NPN identifiers together with their HRNN (if broadcast) to the NAS.

For a UE in NPN access mode, if the highest ranked cell or best cell according to absolute priority reselection rules is a cell which is not suitable for UE access, for licensed spectrum, the UE shall not consider this cell and other cells on the same frequency as candidates for reselection for a maximum of 300 seconds; for unlicensed spectrum, the UE shall not consider this cell as candidate for cell reselection but should continue to consider other cells on the same frequency for cell reselection.

The Rel-15 UEs and Non-NPN-capable Rel-16 UEs treat a cell with cellReservedForOtherUse=true as barred cell.

For Rel-16 and later NPN-capable UEs, if the npn-IdentityInfoList-r16 IE is present in CellAccessRelatedInfo and the cellReservedForOtherUse = true while, a cell is an NPN-only cell that is only available for normal service for NPNs’ subscriber.

All the R16 UEs will treat the cell as barred when the legacy IE cellReservedForOtherUse=True and this cell does not broadcast any CAG-IDs or NIDs.

For SNPN, Once the UE has selected an SNPN, cell selection/re-selection is only performed within the SNPN, i.e. a cell is only considered suitable if the broadcasted SNPN identifier matches the selected SNPN.

NPN cell access control

There is no preliminary access check for NPN cells in CONNECTED mode. For SNPN, the UAC parameters per SNPN are configured by reusing the existing uac-BarringPerPLMN-List, and for a PNI-NPN the UAC parameter set is selected based on the PLMN ID of PNI-NPNs. The current measurement reporting procedures is extended to include NPN information to support ANR.

During the access procedure, for SNPN, the SNPN ID is included in the RRCSetupComplete and Initial UE Message message, and for PNI-NPN the Allowed CAG list is provided to the gNB by the AMF. A single Cause “NPN access denied” will be sent to users when they fail to access NPN cells.

NPN relevant mobility support

At mobility, the source NG-RAN node knows the NPN information supported by the candidate target cells, the target RAN node needs to be informed of the serving SNPN ID or UE allowed CAG ID list which are included in the mobility restriction list. If the serving SNPN ID or UE allowed CAG ID list does not match any of the target cell supported list of SNPN IDs or CAG IDs, target RAN node shall fail the handover.

For mobility in inactive state, the last serving NG-RAN node performs access control check upon the reception of RETRIEVE UE CONTEXT REQUEST, the new NG-RAN node may perform access control check upon the reception of RETRIEVE UE CONTEXT RESPONSE which is implementation dependent.

NPN Support over NG/Xn

The list of supported SNPN IDs could be exchanged between NG-RAN node and AMF via NG setup and configuration update procedures while the list of cell supported SNPN IDs and CAG IDs could be exchanged via Xn setup and configuration update procedures.

NPN Support over F1/E1

Over F1, the list of supported SNPN IDs can be exchanged between DU and CU, the cell supported list of CAG IDs can be signaled from DU to CU. The NID as part of the UAC Assistance Information could be signalled from gNB-CU to gNB-DU. The gNB-DU is responsible for SIB10 encoding, valueTag and areaScope associated with SIB10, and need to signal the HRNN (SIB 10) to gNB-CD. The general cause value "NPN not supported" is introduced for interface related messages and the general cause value "NPN access denied” is introduced for UE-associated messages. Over E1, the list of SNPN IDs supported by CU-UP could be signalled to CU-CP.

NPN support for RAN sharing and Dual connectivity

If NR access is shared, system information broadcast in a shared cell indicates a TAC and a Cell Identity for each subset of PLMNs, PNI NPNs and SNPNs. NR access provides only one TAC and one Cell Identity per cell per PLMN, SNPN or PNI NPN. In Rel-16, a Cell Identity can only belong to one network type among PLMN, PNI-NPN or SNPN.

The NR-DC within a single SNPN or within PNI-NPN or across PLMN and PNI-NPN is supported, EN-DC is not supported for NPN.

Emergency Services

For SNPN, Emergency services are not supported.

For a CAG-only cell in PNI-NPN, if the cellReservedForOtherUse = false in gNB, the access attempts of Rel-15 UEs or Rel-16 non-NPN capable UEs for emergency services could be allowed; if the cellReservedForOtherUse = true, the access attempts of Rel-16 NPN capable UEs for emergency services could be allowed.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=830081,830181

18.5 Service-Based Architecture

18.5.1 Enhancements to the Service-Based 5G System Architecture

820045

Enhancements to the Service-Based 5G System Architecture

5G_eSBA

S2

SP-181125

 

790007

Study on Enhancements to the Service-Based 5G System Architecture

FS_eSBA

S2

SP-180231

Tao Sun (China Mobile)

820022

Stage 2 of 5G_eSBA

5G_eSBA

S2

SP-181125

Tao Sun (China Mobile)

830001

CT aspects of 5G_eSBA

5G_eSBA

ct

CP-190191

Song Yue (China Mobile)

830060

CT3 aspects of 5G_eSBA

5G_eSBA

C3

CP-190191

Song Yue (China Mobile)

830061

CT4 aspects of 5G_eSBA

5G_eSBA

C4

CP-190191

Song Yue (China Mobile)

780029

Study on Enhanced IMS to 5GC Integration

FS_eIMS5G

S2

SP-180736

Joul, Chris, T-Mobile USA

Summary based on the input provided by China Mobile in [SP-200776].

This WI enhances the service-based architecture of 5G system to improve the service framework and support high reliability. The main features introduced by the WI include:

1) support of indirect communication models of NF/NF Services via an intermediary function (Service Communication Proxy – SCP),

2) NF/NF service set enabling the grouping of equivalent NF instances/NF service instances. The NF/NF Services within a NF/NF Service set can share the same context data thus improving the resiliency for processing any transaction. and

3) binding mechanism improves the flexibility and efficiency of the service based architecture by allowing the NF producer to dynamically indicate that the NF consumer, for a particular context, should be bound to an NF service instance, NF instance, NF service set or NF set for subsequent transaction depending on local policies or other criteria..

Architecture enhancement

The work has resulted in the definition of different communication models that NF and NF services can use to interact which each other via or not via a new NF named SCP as shown in the figure here below from TS 23.501 [1]

Figure 1: Communication models for NF/NF services interaction

Model A – Direct communication without NRF interaction: Neither NRF nor SCP are used. Consumers are configured with producers’ "NF profiles" and directly communicate with a producer of their choice.

Model B – Direct communication with NRF interaction: Consumers do discovery by querying the NRF. Based on the discovery result, the consumer does the selection. The consumer sends the request to the selected producer.

Model C – Indirect communication without delegated discovery: Consumers do discovery by querying the NRF. Based on discovery result, the consumer does the selection of an NF Set or a specific NF instance of NF instance set. The consumer sends the request to the SCP containing the address of the selected service producer pointing to a NF service instance or a set of NF service instances. The SCP routes the request to the selected NF service producer instance.

Model D – Indirect communication with delegated discovery: Consumers do not do any discovery or selection. The consumer adds any necessary discovery and selection parameters required to find a suitable producer to the service request. The SCP uses the request address and the discovery and selection parameters in the request message to route the request to a suitable producer instance. The SCP can perform discovery with an NRF and obtain a discovery result.

NF/NF Service set mechanism

The NF Set and NF Service Set concept has been defined by grouping equivalent control plane NFs into NF Set or grouping multiple NF Service instances into NF Service Set. The NF/NF Services within a NF/NF Service set can share the same context data.

When the NF producer instance is not available, another NF producer instance within the same NF Set is selected. When multiple NF Service instances within a NF Service Set are exposed to the NF Service consumer or SCP and the failure of NF Service instance is detected or notified by the NRF, the NF Service consumer or SCP selects another NF Service instance of the same NF Service Set within the NF instance, if available. Otherwise the NF Service consumer or SCP selects a different NF instance within the same NF Set.

Binding mechanism

A binding mechanism based on NF/NF Service set was introduced to improve the efficiency of the service-based architecture.

Binding is used to indicate suitable target NF producer instance(s) for NF service instance selection, reselection and routing of subsequent requests associated with a specific NF producer resource (context) and NF service. This allows the NF producer to indicate that the NF consumer, for a particular context, should be bound to an NF service instance, NF instance, NF service set or NF set depending on local policies and other criteria.

Binding is also used by the NF consumer to indicate suitable NF consumer instance(s) for notification target instance reselection and routing of subsequent notification requests associated with a specific notification subscription and for providing Binding Indication for service(s) that the NF consumer produces for the same data context and the NF service producer is subsequently likely to invoke.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820045,790007,820022,830001,830060,830061,780029

[1] TS 23.501: "System Architecture for the 5G System; Stage 2". Key reference sections: Clause 6.3.1, Clause 7.1, Annex E, Annex G.

[2] TS 23.502: "Procedures for the 5G System; Stage 2". Key reference sections: Clauses 4.17.9 – 4.17.12.

18.5.2 SBA aspects of enhanced IMS to 5GC integration

840062

SBA aspects of enhanced IMS to 5GC integration

eIMS5G_SBA

S2

SP-190181

T-Mobile USA, Christopher Joul

830028

Stage 2 of eIMS5G_SBA

eIMS5G_SBA

S2

SP-190181

T-Mobile USA, Christopher Joul

840006

CT aspects of eIMS5G_SBA

eIMS5G_SBA

ct

CP-191065

de Gregorio, Jesus. Ericsson

840063

CT3 aspects of eIMS5G_SBA

eIMS5G_SBA

C3

CP-191065

de Gregorio, Jesus. Ericsson

840064

CT4 aspects of eIMS5G_SBA

eIMS5G_SBA

C4

CP-191065

de Gregorio, Jesus. Ericsson

Summary based on the input provided by T-Mobile USA INC in SP-200808

In release 15 Service-Based interfaces were introduced between the functional elements of the new 5G core systems (5GC), however no changes were made to the IMS nodes that interact with the packet core, and so Diameter-based interfaces remained between IMS functions and the 5GC. It was therefore determined that the specification of Service-Based interfaces between the IMS core and the 5GC would enable more efficient implementations. However, to enable operators the flexibility in performing the transition to Service-Based Architecture (SBA), it was determined not to remove (at this time) the option to use Diameter for IMS services interworking with 5GC.

This work resulted in the specification of Service-Based architecture between the IMS and 5GC. The following summarizes the enhancements made:

The first major change to enable SBA was an update to the PCF and Npcf services to allow the IMS functions to use the N5 interface (instead of Rx) when communicating with the PCC functions for QOS interactions. This requires IMS functions to be upgraded to support the SBA procedures and protocols, as well as the SBA protocols themselves to be updated with IMS specific parameters (including IMS public and private identifiers). The IMS functions now use similar capabilities to other SBA functional entities to perform PCF discovery, avoiding the need for interworking to perform this. One added benefit of this is that a new option for P-CSCF discovery using the NRF is provided, this may allow for some network implementations to use a single discovery method (avoiding misalignment between different systems).

One area of significant change was to provide SBA capabilities to the IMS portion of the HSS, this introduces Nhss services to the SBA for IMS interactions with the HSS. Service-Based equivalents to the Cx and Sh interfaces (identified as the N70 and N71 interfaces) enable the CSCF and IMS-AS to use service-based interfaces for subscription and service interactions with the HSS. No changes are made to the non-IMS portions of the HSS so that existing LTE and UMTS packet cores can continue to interact with the HSS unchanged; this also allows for UDICOM implementations.

The last major change from the Diameter approach to the Service-Based approach was in the method of HSS discovery. To better align with the discovery of other 5GC functional elements, the NRF and the Nnrf protocols were updated, allowing the IMS functions to discover the correct HSS instance to use for the subscription of a specific subscriber. To enable implementations where the mapping between a subscriber identifier and the HSS instance is not stored in the NRF a new service was specified allowing the UDR to store this information and for the NRF to request the mapping. These enhancements can leverage the deployment implementation options introduced with eSBA (e.g. direct or indirect discovery methods) for proxy-based network routing.

As noted earlier, the option to utilize Diameter based interactions between IMS and 5GC was retained, to enable flexible transition to SBA.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840062,830028,840006,840063,840064

[1] TS 23.228 “IP Multimedia Subsystem (IMS); Stage 2”.

[2] TS 23.501: "System Architecture for the 5G System; Stage 2".

[3] TS 23.502: "Procedures for the 5G System (5GS); Stage 2".

[4] TS 23.503 “Policy and charging control framework for the 5G System (5GS); Stage 2”.

[5] TS 29.563 "Home Subscriber Server (HSS) services for interworking with Unified Data Management (UDM); Stage 3".

[6] TS 29.562 “5G System; Home Subscriber Server (HSS) services for interworking with the IP Multimedia Subsystem (IMS); Stage 3”.

[7] TS 29.510 “5G System; Network function repository services; Stage 3”.

[8] TS 29.513 “5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3”.

18.6 User data interworking, Coexistence and Migration

840065

User data interworking, Coexistence and Migration

UDICOM

S2

SP-190182

Alessio Casati, Nokia

800055

Study on UDICOM

FS_UDICoM

S2

SP-190148

Susana Sabater (Vodafone

830029

Stage 2 of UDICOM

UDICOM

S2

SP-190182

Alessio Casati, Nokia

840007

CT aspects of UDICOM

UDICOM

C4

CP-191066

Wiehe, Ulrich, Nokia

Summary based on the input provided by Nokia.

3GPP SA2 in Release 15 defined the unified data architecture based on UDR. The HSS+UDM were introduced in R15 for migration purposes (in TS 23.501, Section 5.17).

This WI standardises the interaction between UDM and HSS, when these are deployed separately, and coexistence of 5G and 4G subscription data permitting 5G migration towards the UDM/UDR architecture defined for 5GC.

Open interfaces are defined between UDM and HSS (NU1 interface) and HSS and UDR (NU2 interface) and in the figure here below from TS 23.632 [1]

Figure 1: Architecture for Direct UDM-HSS interworking in reference point representation

From a Service Based architecture standpoint, the new Nhss services have been added:

Figure 2: Architecture for Direct UDM-HSS interworking

The Nudr and Nudm services have been enhanced, also.

The Nhss service has been defined in TS 29.563[2] and the overall architecture and stage two is in TS 23.632. Both are under CT4 responsibility (see the CT WID in CP-193016[5]). TS 23.501[1] and TS 23.502[4] only provide minimal text on the stage two aspects and refer to the CT4 documents as necessary.

The work has no impact on the rest of the system as the interactions defined by this work remain confined between UDM, HSS and UDR (i.e. the deployment of UDICOM in a PLMN is transparent to the rest of the system, in that whether a combined UDM/HSS or a UDICOM enabled separate UDM and HSS are deployed in a PLMN is not detectable e.g. from a MME or a AMF)

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840065,800055,830029,840007

[1] TS 23.632 "Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services".

[2] TS 29.563 "Home Subscriber Server (HSS) services for interworking with Unified Data Management (UDM); Stage 3".

[3] TS 23.501: "System Architecture for the 5G System; Stage 2".

[4] TS 23.502: "Procedures for the 5G System (5GS); Stage 2".

[5] 3GPP CP-193016: "WID: User data interworking, Coexistence and Migration".