Presented herein are techniques that provide for defining an interface between one or more local network slice admission control functions (NSACFs) and a global or primary NSACF.  Various techniques presented herein can help to report local events to a global NSACF and may also be useful for restoration procedures when a local NSACF restarts.  Thus, techniques proposed herein can facilitate improved slice admission and control procedures over existing standards-based solutions

Parikh, Dishant

Shekhar, Ravi

English

Technical Disclosure Common

Technical Disclosure Commons Defensive Publications Series March 2023 DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND A GLOBAL NSACF FOR EFFICIENT ADMISSION CONTROL Ravi Shekhar Dishant Parikh Follow this and additional works at: https://www.tdcommons.org/dpubs_series Recommended Citation Shekhar, Ravi and Parikh, Dishant, "DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND A GLOBAL NSACF FOR EFFICIENT ADMISSION CONTROL", Technical Disclosure Commons, (March 29, 2023) https://www.tdcommons.org/dpubs_series/5764 This work is licensed under a Creative Commons Attribution 4.0 License. This Article is brought to you for free and open access by Technical Disclosure Commons. It has been accepted for inclusion in Defensive Publications Series by an authorized administrator of Technical Disclosure Commons.  1 6854 DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND A GLOBAL NSACF FOR EFFICIENT ADMISSION CONTROL  AUTHORS:   Ravi Shekhar Dishant Parikh   ABSTRACT Presented herein are techniques that provide for defining an interface between one or more local network slice admission control functions (NSACFs) and a global or primary NSACF.  Various techniques presented herein can help to report local events to a global NSACF and may also be useful for restoration procedures when a local NSACF restarts.  Thus, techniques proposed herein can facilitate improved slice admission and control procedures over existing standards-based solutions.  DETAILED DESCRIPTION A network slice coverage area is defined in Release 17 (R17 or Rel. 17) of Third Generation Partnership Project (3GPP) standards in which slice coverage may be limited to a few tracking area (TA) boundaries, which may require network operators to deploy multiple slices to increase slice coverage. Such slice coverage area features can also impact the number network slice admission control function (NSACF) nodes needed to serve slices, as more NSACF nodes may be needed in order to facilitate local slice admission control. Such a local NSACF also has to interface with global or primary NSACF, which maintains a global view of network slice operations. Figure 1, below, illustrates example details associated with the proposed 3GPP architecture. 2Shekhar and Parikh: DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND APublished by Technical Disclosure Commons, 2023 2 6854  Figure 1: Local-Global NSACF Architecture  For one network slice, typically identified using a single-network slice selection assistance information (S-NSSAI) identifier, there is only one configured global maximum allowed number value for NSAC. As illustrated in Figure 1, it is possible in some scenarios that more than one service area is associated with one S-NSSAI, for example, for a public land mobile network (PLMN) that is split into multiple service areas. Such scenarios can impact different network use cases, as there will be more than one NSACF handling a given UE’s slice admission control request. Thus, in some scenarios slice admission control requests can be handled using multiple NSACFs deployed within one PLMN such that, for each service area, one NSACF or NSACF set can be used for slice admission control.  Each service area level local NSACF will receive a number of allowed UEs or a PDU session count the from primary NSACF. The allocated quota between the local NSACFs and the primary NSACF can be regularly synced. As the current architecture illustrated in Figure 1 is a proposed architecture for 3GPP standards, the architecture may continue to evolve as part of Release 18 studies and various gaps are still present in the current architecture, as follows: 1) There is no defined interface between primary NSACF and local NSACF; 2) There is no way to discover the primary NSACF; and 3Defensive Publications Series, Art. 5764 [2023]https://www.tdcommons.org/dpubs_series/5764 3 6854 3) There is no defined method for data reconciliation and restoration at the primary NSACF. In a scenario involving a primary NSACF being impacted and recovering after a failover, there is currently no defined mechanism defined that can facilitate updating the primary NSACF with the latest information regarding the number of allocated UEs in respective slices.  Additionally, there are two approaches to the NSACF architecture that are under discussion in 3GPP, a centralized approach and distributed approach. Although the overall distributed architecture may be introduced in 3GPP standards operational/implementation details for successfully deploying such an architecture the details are missing from standards for both centralized and distributed approach. Further, the actual breakup between primary and secondary NSCAF is not defined, as service-based architecture (SBA) aspects are still under discussion. Further, important features regarding data reconciliation at the time of recovery of a primary NSACF are also missing from standards, which are very important to achieving successful deployment of such an architecture. In order to address such gaps in the current local-global NSACF architecture, techniques proposed herein augment the distributed approach involving one global NSCAF (name primary NSCAF) and one or more local NSCAF(s) (servicing a local service area).  Specifically, this submission proposes a service-based interface (SBI) through which a primary NSACF can be discovered by a local NSACF and both can exchange information using a Hypertext Transfer Protocol (HTTP) version 2.0 (HTTP/2.0) interface.   The SBI between a primary NSACF and one or more local NSACFs can be used for various purposes, such as: 1) Registration – each local NSACF can register itself with a primary NSACF and subscribe to event notifications; 2) Information Push/Pull – Get and Update Application Programming Interfaces (APIs) can be implemented between local NSACF(s) and a primary NSACF to facilitate information exchange among the local/primary NSACFs; and 3) Event Notification.  4Shekhar and Parikh: DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND APublished by Technical Disclosure Commons, 2023 4 6854 During operation, each local NSCAF can provide admission control for a local serving area and report the events to the primary NSCAF. The primary NSCAF can also pull information from all local NSCAFs in order to obtain a global view of all the slices deployed. Existing Network Repository Function (NRF) operations can be leveraged such that primary NSACF and secondary (local) NSCAF become consumer and producer respectively. Both NSCAFs can register with the NRF and let primary NSCAF subscribe for the event notifications from secondary (local) NSCAF(s).  The primary NSCAF is effectively a master NSCAF that can decide the policy for all the local NSCAFs based on the current Key Performance Indicators (KPIs) that the primary NSACF gathers at the global level.  Thus, the data set of the secondary (local) NSACF(s) will be a small subset of the data set of the primary NSCAF. Further, Figure 2, below, illustrates an example procedure that may be utilized to facilitate primary NSACF restoration.   Figure 2: Primary NSACF Restoration Procedure  5Defensive Publications Series, Art. 5764 [2023]https://www.tdcommons.org/dpubs_series/5764 5 6854 As noted above, after the primary NSACF is negatively impacted (e.g., goes down) and later recovers, it needs to reconcile the allowed UEs/PDUs counts for each slice. Such reconciliation will help the primary NSACF efficiently serve subsequent requests from  local NSACF(s) for allocating quota and allowing UEs and PDU sessions within each service area for respective S-NSSAI.  As shown above in Figure 2, the primary NSACF can collect various data from each local NSACF through a request/response mechanism to reconcile such data. As shown in Figure 3, below, the primary NSCAF will also have an Operations, Administration, and Maintenance (OAM) interface through which a mobile network operator can provision policy at the global level and/or local level. Local policies can be pushed down from the primary NSACF to the local NSCAF(s) in each respective serving area via a 'Nxx' SBI interface in which the 'xx' SBI interface number will be decided by 3GPP.  Likewise, all local KPIs/event/alarms can be reported to the primary NSCAF from all the local NSCAF(s) via the Nxx SBI interface.  Figure 3: Hierarchical NSCAF Architecture with OAM Integration  6Shekhar and Parikh: DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND APublished by Technical Disclosure Commons, 2023 6 6854 Accordingly, techniques are presented herein that provide for defining an interface between one or more local NSACFs and a primary or global NSACF.  The techniques and procedures presented herein can help to report local events to the primary NSACF and may also be useful for restoration procedures when a local and/or the primary NSACF restarts.  Thus, techniques proposed herein can facilitate improved slice admission and control procedures over existing standards-based solutions.     7Defensive Publications Series, Art. 5764 [2023]https://www.tdcommons.org/dpubs_series/5764

DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND A GLOBAL NSACF FOR EFFICIENT ADMISSION CONTROL

https://www.tdcommons.org/cgi/viewcontent.cgi?article=6871&context=dpubs_series

DEFINING PROCEDURES AND AN INTERFACE BETWEEN A LOCAL NSACF AND A GLOBAL NSACF FOR EFFICIENT ADMISSION CONTROL

Abstract

Similar works

Full text

Available Versions

Technical Disclosure Common