Downlink access control in 5G communications network

Embodiments are directed towards systems and methods for downlink access control in a communications network. An example method includes a base station receiving a request for downlink (DL) communication with a user equipment (UE), and the base station performing the following actions without communicating with the UE regarding the request for the DL communication: determining an unavailability of a resource required for the DL communication; responsive to the determined unavailability, sending a rejection of the request; determining an availability of the resource; and responsive to the determined availability, sending an indication of the availability of the resource required for the DL communication.

BACKGROUND

The advent and implementation of Fifth Generation (5G) wireless communication technology has resulted in faster speeds and increased bandwidth, but with the drawback of potentially overloading certain portions of the network in certain circumstances. It is with respect to these and other considerations that the embodiments described herein have been made.

BRIEF SUMMARY

The present disclosure relates generally to digital communications and, more particularly, to downlink access control within a 5G communications network.

Unified access control (UAC) is defined for 5G. Relevant details can be found, for example, from TS 23.501 5.2.5 (Access Control and Barring) and TS 38.413 (N2 interface). Typically, a base station (e.g., gNB) can broadcast barring information via system information block (SIB). For mobile originated call or other access request in the uplink (UL) direction, a user equipment (UE) applies UAC based on its access category and access identity, which can be pre-configured and/or provisioned from the 5G Core.

Overload control is also defined for 5G. Relevant details can be found, for example, from TS 23.501 5.19.5 (AMF Control of Overload). Typically, Access & Mobility Management Function (AMF) or Session Management Function (SMF) can indicate overload control information at various granularities such as data domains (e.g., via Data Network Name (DNN)) or network slices (e.g., via Single Network Slice Selection Assistance Information (S-NSSAI)). Based on the overload messages or indications, base stations (e.g., gNBs) can update the UAC. For example, if a particular network slice defined by an S-NSSAI is overloaded by the AMF then the related gNB can set corresponding barring information to bar the S-NSSAI. As such, base stations can bar mobile originated setup or other access requests from UEs (in UL direction) based on associated overload information.

Significant deficiencies exist in the current UAC, as it only applies to mobile originated setup (UL direction), but not to mobile terminated setup (DL direction). For example, Radio Access Network (RAN) node-based congestion is not reflected in the UAC mechanism for DL direction (e.g., based on paging). As another example, in Radio Resource Control-Inactive (RRC-Inactive) situations, data directly arrives at Central Unit User Plane (CU-UP) and needs proper congestion management.

To address at least these issues, embodiments of the presently disclosed technology include a mobile communications system, where a base station receives a request for DL communication with a UE. Without communicating with the UE regarding the request for the DL communication: the base station determines an unavailability of a resource required for the DL communication; responsive to the determined unavailability, the base station sends a rejection of the request for the DL communication; the base station determines an availability of the resource required for the DL communication; and responsive to the determined availability, the base station sends an indication of the availability of the resource required for the DL communication.

In some embodiments, the request for the DL communication is received from a network function in a 5G Core network. In some embodiments, the network function includes an AMF. In some embodiments, the request for the DL communication includes a paging request via N2 interface.

In some embodiments, the resource required for the DL communication includes a specific network slice. In some embodiments, the rejection of the request for the DL communication includes at least one of a duration indication or location indication associated with the unavailability.

In some embodiments, the base station receives another request for the DL communication with the UE, after the sending of the indication of the availability of the resource required for the DL communication. In some embodiments, the base station communicates with the UE regarding the other request for the downlink communication.

Embodiments of the presently disclosed technology also includes a mobile communications system, where a base station determines availability of a resource for DL communication with one or more UE, sends a notification of the determined availability, and receives a request for the DL communication with a UE, in accordance with the notification.

In some embodiments, the resource for the DL communication includes a specified network slice. In some embodiments, the notification includes at least one of a duration indication or location indication associated with the availability of the specified network slice. In some embodiments, the notification is sent to a network function in a 5G Core network.

In some embodiments, based on the interactions between Central Unit Control Plane (CU-CP) and CU-UP, CU-CP may reject RRC resume or otherwise manage congested resources (e.g., by not triggering a corresponding RAN paging) in a similar manner, for example, if received data is for a congested network slice or private network.

DETAILED DESCRIPTION

FIG.1illustrates an interaction diagram of a typical DL access management scenario.

As illustrated, a UE (e.g., a cellular telephone, tablet, laptop, Internet-of-Things (IoT) device, or other computing device that uses 5G wireless cellular telecommunication technology defined by standards set by 3GPP and International Telecommunications Union (ITU)) is in idle mode. A base station or RAN component (e.g., gNB, CU-CP, or the like) determines that the resource for a particular network slice (e.g., as identified by S-NSSAI A) is congested, and the corresponding gNB may have barred that slice for the UL direction. At AMF1, data notification has arrived for DL communication (e.g., to establish a Protocol Data Unit (PDU) session A, to activate an existing PDU session B, or the like) with the UE via the particular network slice (e.g., as identified by S-NSSAI A).

At102, the AMF1sends a DL communication request (e.g., a paging request via N2 interface) to the RAN component. The request can indicate the UE's identify, but may not include slice information (e.g., S-NSSAI).

At104, the RAN component relays, forwards, or otherwise causes the DL communication request to be communicated to the UE. For example, the RAN component can generate Uu paging message comprising multiple N2 paging messages.

At106, the UE and the RAN component establishes a communicative connection (e.g., an RRC connection).

At108, the RAN component initiates access with AMF1.

At110, in response, the AMF1initiates context setup with the RAN component for the particular slice (e.g., by indicating S-NSSAI A to the RAN component).

At112, the RAN component determines that the particular slice cannot be served due to congestion or barring information.

At114, the RAN component rejects the DL communication request and releases connection with AMF1due to insufficiency of the particular slice.

At116, the RAN component releases the connection with the UE, concurrently with or sequentially after114.

As can be seen, the typical DL access management is not able to properly address DL communication requests when related network resource is congested or otherwise unavailable. All or a majority of the interactions between AMF1and the RAN component and between the RAN component and the UE do not achieve any benefit to the mobile communications network. UE power and RAN resource are wasted, and AMF or other core network functions are not updated accordingly.

FIG.2illustrates an interaction diagram of an example implementation of reactive DL access management in accordance with some embodiments of the presently disclosed technology.

Similar to what is shown inFIG.1,FIG.2shows a UE in idle mode. gNB1(or other RAN component) determines that the resource for a particular network slice (e.g., as identified by S-NSSAI A) is congested, and may have barred that slice for the UL direction. At AMF1, data notification has arrived for DL communication (e.g., to establish a Protocol Data Unit (PDU) session A) with the UE via the particular network slice (e.g., as identified by S-NSSAI A). Illustratively, the data notification can be received from SMF1, another component of 5G Core network, or other third party system or service.

At202, the AMF1sends a DL communication request (e.g., a paging request via N2 interface) to gNB1. The request can indicate the UE's identify and also include information of the required or intended network resource (e.g., a particular network slice identified by S-NSSAI).

At204, the gNB1determines or confirms the unavailability of the network resource and does not relay, forward, or otherwise cause the DL communication request to be communicated to the UE; instead, gNB1sends a rejection of the request to the AMF1. The rejection (e.g., N2 paging reject) can indicate unavailability of one or more resources, period of time associated with the unavailability, a set of list of tracking areas (TAs) associated with the unavailability, combination of the same or the like.

At206, the AMF1processes and applies the rejection content. Illustratively, the AMF1can refrain from sending further DL communication requests (e.g., directed to the same UE or other UE) to gNB1that fall within the scope of resource unavailability indicated in the rejection.

At208, the AMF1sends further indication(s) of the resource unavailability to the SMF1, another component of the 5G Core network, or other third party system or service. The indication(s) can include the same or similar information as included in the rejection received from gNB1.

At210, the resource availability may have changed or otherwise differs from the rejection information sent to the AMF1at204, and gNB1can detect or otherwise determine availability of resources and send resource availability information to the AMF1. The resource availability information may or may not include the required or intended resource (e.g., the network slice identified by S-NSSAI A) as indicated in the DL communication request at202.

At212, the AMF1processes and further sends the resource availability information to the SMF1, another component of the 5G Core network, or other third party system or service.

Referring back to202, the AMF1can send the DL communication request (e.g., a paging request via N2 interface) to one or more other base stations (e.g., gNB2) or RAN components, where the required or intended network resource may be available. At block214, gNB2can further relay, forward, or otherwise cause the DL communication request to be communicated to the UE (e.g., via RRC paging).

As can be seen, the reactive DL access management is able to properly address DL communication requests when related network resource is congested or otherwise unavailable. The UE power and RAN resource are efficiently used, and AMF or other core network functions are timely updated to reflect network resource availability. In particular, in the reactive DL access management, the DL communication request includes information regarding the required or intended resource (e.g., N2 paging including an identification of the network slice required or intended), and gNB, CU-CP, or other RAN component can reject the DL communication request based on granular resource unavailability (e.g., rejecting incoming N2 paging per network slice).

Further, UAC can be extended to account for DL access by using the resource availability information, so a UE can de-prioritize camping to a cell in which both uplink and downlink are barred for the required or intended network resource (e.g., slice).

FIG.3illustrates a flow diagram of an example reactive DL access management process300, in accordance with some embodiments of the presently disclosed technology.

At block302, the process300includes a base station (or other RAN component) receiving a request for DL communication with a UE. Without communicating with the UE regarding the request for the DL communication, the base station (or other RAN component) performs the following actions of the process300.

At block304, the process300includes determining an unavailability of a resource required for the DL communication.

At block306, the process300includes, responsive to the determined unavailability, sending a rejection of the request for the DL communication.

At block308, the process300includes determining an availability of the resource required for the DL communication.

At block310, the process300includes, responsive to the determined availability, sending an indication of the availability of the resource required for the DL communication.

As described above,FIG.2provides an implementation example of the process300. The request for the DL communication can be received from a network function in a 5G Core network. The rejection of the request for the DL communication can include at least one of a duration indication or location indication associated with the unavailability. The base station (or other RAN component) can receive another request for the DL communication with the UE, after the sending of the indication of the availability of the resource required for the DL communication. The base station can communicate with the UE regarding the other request for the downlink communication.

FIG.4illustrates an interaction diagram of an example implementation of proactive DL access management in accordance with some embodiments of the presently disclosed technology.

FIG.4shows a UE in idle mode. A gNB (or other RAN component) determines that the resource for a particular network slice (e.g., as identified by S-NSSAI A) is congested, and may have barred that slice for the UL direction and also for the DL direction.

At402, the gNB determines availability and/or unavailability of network resource(s) useful for DL communications and sends a notification to AMF1. The notification (e.g., via N2 interface) can indicate identification of one or more resources (e.g., network slice(s) as identified by S-NSSAI(s)), period of time associated with the availability and/or unavailability, a set of list of tracking areas (TAs) associated with the availability and/or unavailability.

At404, the AMF1can acknowledge receiving the notification by sending a notification response back to the gNB.

At406, the AMF1can process the notification and send an indication of resource unavailability to SMF1, another component of 5G Core network, or other third party system or service. Illustratively, the indication of resource unavailability can be based on the content of the notification and include identification of one or more resources (e.g., network slice(s) as identified by S-NSSAI(s)), period of time associated with their unavailability, a set of list of tracking areas (TAs) associated with their unavailability. Illustratively, the AMF1can also refrain from sending DL communication requests (e.g., directed to the same UE or other UE) to the gNB that fall outside the scope of resource availability indicated in the notification.

At408, the AMF1can process the notification and indicate availability of resource(s) to SMF1, another component of 5G Core network, or other third party system or service, allowing them to send DL communication request(s) to the AMF1that require or intend to use such resource(s).

At410, the gNB can broadcast barring information for the DL direction via one or more broadcasting channels. For example, the gNB can generate and send SIB that includes barring information for DL direction (or both UL and DL directions), associated time information, or the like.

At412, one or more UEs can determine that DL direction is barred for certain network resource or service (e.g., a particular slice as identified by S-NSSAI) and deprioritize camping to a cell served by the gNB.

At414, one or more UEs can determine camping onto a cell based, at least in part, on resource (e.g., slice) priority, user priority, or the like.

As can be seen, the proactive DL access management is able to properly address network resource availability and facilitate DL communication requests. The UE power and RAN resource are efficiently used, and AMF or other core network functions are timely updated to reflect network resource availability. In particular, in the proactive DL access management, if a gNB, CU-CP, or other RAN component detects congestion or otherwise determines availability of network resource(s) (e.g., one or more particular slices), it can proactively notify an AMF or other systems or services. Further, UAC can be extended to account for DL access by using the resource availability information for the DL direction, for example, based on broadcast from a gNB.

FIG.5illustrates a flow diagram of an example proactive DL access management process500, in accordance with some embodiments of the presently disclosed technology.

At block502, the process500includes a base station (or other RAN component) determining availability of a resource for DL communication with one or more UE.

At block504, the process500includes the base station sending a notification of the determined availability.

At block506, the process500includes the base station receiving a request for the DL communication with a UE, in accordance with the notification.

As described above,FIG.4provides an implementation example of the process500. The notification can include at least one of a duration indication or location indication associated with the availability of a specified network slice. The notification can be sent to a network function in a 5G Core network.

Those skilled in the art will appreciate that the various operations depicted viaFIGS.2-5, as well as those described elsewhere herein, may be altered in a variety of ways. For example, the particular order of the operations may be rearranged; some operations may be performed in parallel; shown operations may be omitted, or other operations may be included; a shown operation may be divided into one or more component operations, or multiple shown operations may be combined into a single operation, etc.

FIG.6is a block diagram illustrating elements of an example computing device600utilized in accordance with some embodiments of the techniques described herein. Illustratively, the computing device600corresponds to a base station (e.g., gNB) or other RAN component, a UE, a component of 5G Core network, or at least a part thereof.

In some embodiments, one or more general purpose or special purpose computing systems or devices may be used to implement the computing device600. In addition, in some embodiments, the computing device600may include one or more distinct computing systems or devices, and may span distributed locations. Furthermore, each block shown inFIG.6may represent one or more such blocks as appropriate to a specific embodiment or may be combined with other blocks. Also, the downlink (DL) manager622may be implemented in software, hardware, firmware, or in some combination to achieve the capabilities described herein.

As shown, the computing device600includes a computer memory (“memory”)601, a display602(including, but not limited to a light emitting diode (LED) panel, cathode ray tube (CRT) display, liquid crystal display (LCD), touch screen display, projector, etc.), one or more Central Processing Units (“CPU”) or other processors603, Input/Output (“I/O”) devices604(e.g., keyboard, mouse, RF or infrared receiver, universal serial bus (USB) ports, High-Definition Multimedia Interface (HDMI) ports, other communication ports, and the like), other computer-readable media605, network connections606, a power source (or interface to a power source)607. The DL access manager622is shown residing in memory601. In other embodiments, some portion of the contents and some, or all, of the components of the DL access manager622may be stored on and/or transmitted over the other computer-readable media605. The components of the computing device600and DL access manager622can execute on one or more processors603and implement applicable functions described herein. In some embodiments, the DL access manager622may operate as, be part of, or work in conjunction and/or cooperation with other software applications stored in memory601or on various other computing devices. In some embodiments, the DL access manager622also facilitates communication with peripheral devices via the I/O devices604, or with another device or system via the network connections606.

The one or more DL access modules624is configured to perform actions related, directly or indirectly, to downlink access control as described herein. In some embodiments, the DL access module(s)624stores, retrieves, or otherwise accesses at least some downlink access related data on some portion of the DL access data storage616or other data storage internal or external to the computing device600. In various embodiments, at least some of the DL access modules624may be implemented in software or hardware.

Other code or programs630(e.g., further data processing modules, communication modules, a Web server, and the like), and potentially other data repositories, such as data repository620for storing other data, may also reside in the memory601, and can execute on one or more processors603. Of note, one or more of the components inFIG.6may or may not be present in any specific implementation. For example, some embodiments may not provide other computer readable media605or a display602.

In some embodiments, the computing device600and DL access manager622include API(s) that provides programmatic access to add, remove, or change one or more functions of the computing device600. In some embodiments, components/modules of the computing device600and DL access manager622are implemented using standard programming techniques. For example, the DL access manager622may be implemented as an executable running on the processor(s)603, along with one or more static or dynamic libraries. In other embodiments, the computing device600and DL access manager622may be implemented as instructions processed by a virtual machine that executes as one of the other programs630. In general, a range of programming languages known in the art may be employed for implementing such example embodiments, including representative implementations of various programming language paradigms, including but not limited to, object-oriented (e.g., Java, C++, C#, Visual Basic.NET, Smalltalk, and the like), functional (e.g., ML, Lisp, Scheme, and the like), procedural (e.g., C, Pascal, Ada, Modula, and the like), scripting (e.g., Perl, Ruby, Python, JavaScript, VBScript, and the like), or declarative (e.g., SQL, Prolog, and the like).

In a software or firmware implementation, instructions stored in a memory configure, when executed, one or more processors of the computing device600to perform the functions of the DL access manager622. In some embodiments, instructions cause the one or more processors603or some other processor(s), such as an I/O controller/processor, to perform at least some functions described herein.

In addition, programming interfaces to the data stored as part of the computing device600and DL access manager622, can be available by standard mechanisms such as through C, C++, C#, and Java APIs; libraries for accessing files, databases, or other data repositories; scripting languages such as XML; or Web servers, FTP servers, NFS file servers, or other types of servers providing access to stored data. The DL access data storage616and data repository620may be implemented as one or more database systems, file systems, or any other technique for storing such information, or any combination of the above, including implementations using distributed computing techniques.

Furthermore, in some embodiments, some or all of the components of the computing device600and DL access manager622may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to one or more application-specific integrated circuits (“ASICs”), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field-programmable gate arrays (“FPGAs”), complex programmable logic devices (“CPLDs”), and the like. Some or all of the system components and/or data structures may also be stored as contents (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., as a hard disk; a memory; a computer network, cellular wireless network or other data transmission medium; or a portable media article to be read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) so as to enable or configure the computer-readable medium and/or one or more associated computing systems or devices to execute or otherwise use, or provide the contents to perform, at least some of the described techniques.

The various embodiments described above can be combined to provide further embodiments. All of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet are incorporated herein by reference, in their entirety. In cases where the present patent application conflicts with an application or other document incorporated herein by reference, the present application controls. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.