US20200196373A1 - System and method of radio resource management for radio access networks - Google Patents
System and method of radio resource management for radio access networks Download PDFInfo
- Publication number
- US20200196373A1 US20200196373A1 US16/220,627 US201816220627A US2020196373A1 US 20200196373 A1 US20200196373 A1 US 20200196373A1 US 201816220627 A US201816220627 A US 201816220627A US 2020196373 A1 US2020196373 A1 US 2020196373A1
- Authority
- US
- United States
- Prior art keywords
- rrc
- ran
- state
- network
- access
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 23
- 230000011664 signaling Effects 0.000 claims abstract description 9
- 238000004891 communication Methods 0.000 claims description 17
- 230000007704 transition Effects 0.000 claims description 15
- 230000004044 response Effects 0.000 claims description 13
- 230000006870 function Effects 0.000 claims description 12
- 238000012913 prioritisation Methods 0.000 claims description 8
- 230000014759 maintenance of location Effects 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000005457 optimization Methods 0.000 description 3
- 230000007774 longterm Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012806 monitoring device Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 210000000707 wrist Anatomy 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/27—Transitions between radio resource control [RRC] states
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2458—Modification of priorities while in transit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
- H04L47/6275—Queue scheduling characterised by scheduling criteria for service slots or service orders based on priority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
-
- H04W72/1247—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/50—Allocation or scheduling criteria for wireless resources
- H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
- H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/25—Maintenance of established connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
- H04W76/38—Connection release triggered by timers
Definitions
- Radio access networks operated by wireless network providers provide shared, finite radio resources that are generally accessible to user devices via the air interface.
- RANs are susceptible to congestion and/or overload when the maximum number of radio links, i.e., signaling radio bearer (SRB) resources, have been established and/or the limited available bandwidth has been allocated to connected, Radio Resource Control (RRC) active user devices, i.e., data radio bearer (DRB) resources.
- RRC Radio Resource Control
- DRB Radio Resource Control
- eNB evolved NodeB
- gNB next generation NodeB
- the eNB/gNB must support services designated as high priority, such as public safety and emergency communications users, etc.
- the RAN cannot simply rely on the Access Class information provided by the UE as being legitimate in determining a prioritization level associated with any given access request.
- FIG. 1 is a diagram illustrating possible RRC states of user devices with respect to a RAN in accordance with an exemplary implementation
- FIG. 2 illustrates an exemplary environment in which systems and methods described herein may be implemented
- FIG. 3 illustrates an exemplary configuration of components implemented in a portion of the network of FIG. 2 ;
- FIG. 4 illustrates an exemplary configuration of logic components included in one or more of the devices of FIG. 2 and FIG. 3 ;
- FIG. 5 illustrates an exemplary configuration of logic components implemented by one of the devices of FIG. 2 ;
- FIGS. 6, 8, and 9 are flow diagrams illustrating processing associated with radio resource management in accordance with an exemplary implementation.
- FIG. 7 is a signal flow diagram associated with the processing of FIGS. 6, 8, and 9 .
- Implementations described herein relate to controlling prioritized access to RAN resources.
- prioritized access is controlled in a prescribed manner that provides a technological improvement over the current state of the art in scheduling of RAN resources in a congested/overloaded RAN, and thereby advantageously conserves bandwidth and reduces messaging traffic in the RAN.
- Preemption and admission priority are some of the mechanisms available to RANs to enforce access prioritization during congestion/overload.
- RANs may use allocation and retention priority (ARP) information for a user device requesting prioritized access to deny/grant the request.
- ARP allocation and retention priority
- the RAN must first set up signaling radio bearers (SRBs) to the user device, and then request the information from the core network responsive to each initiation of an RRC connection during congestion/overload in the RAN.
- SRBs signaling radio bearers
- Radio resource management has a number of technological disadvantages. For example, if the RAN is SRB congested, the RAN is not able to allocate SRB resources to the user device and may reject the access attempt without first identifying the prioritized access that may be due the user device. On the other hand, if SRB resources are available and are allocated by the RAN, these resources will be wasted in situations where the RAN ultimately determines that prioritized access is not due. Also, signaling communications with the core network creates additional network traffic in an already congested/overloaded RAN, and adds unnecessary delay to the response. Further, reserving RAN resources in advance of receiving actual requests will result in less than optimal use of the resources available. Implementations described herein provide technological solutions and efficiencies over the above-mentioned technological challenges.
- 3rd Generation Partnership Project (3GPP) standards for Fifth Generation (5G) define RRC states/transitions 100 for user equipment (UE) with respect to a RAN.
- UE user equipment
- 3GPP 3rd Generation Partnership Project
- 5G Fifth Generation
- 3GPP 3rd Generation Partnership Project
- 5G 5G standards introduce a third state, RRC (connected) inactive state 130 , to reduce the control plane latency.
- periods of inactivity in the RRC connected state result in the RRC session being suspended and the user device being transitioned to the RRC inactive state, in which the user device is still registered and connected to the RAN, unlike the idle state where the user device is disconnected and deregistered from the RAN.
- Fourth Generation (4G) networks supports a similar approach as part of User Plane Optimization. RRC states and/or transitions other than what are depicted in FIG. 1 are possible.
- Implementations described herein include the technological solution of the RAN storing user device context even when the user device is not in the RRC connected state 520 . That is, when an RRC session for the user device is suspended as described in more detail below, and the user device is placed in the RRC inactive state 530 , the RAN may store the context information obtained from the core network. At this point, should the user device resume activity in the RRC session, the RAN may use the context information to determine whether the inactive user device is due prioritized access when the RAN is under congested/overload conditions. In this manner, prioritized network access can be effectively controlled using a less resource-intensive process than currently practiced.
- FIG. 2 is a block diagram of an exemplary environment 200 in which systems and methods described herein may be implemented.
- Environment 200 may include user equipment (UE) 210 - 1 through 210 -N, service provider 230 , and network 240 .
- UE user equipment
- UEs 210 - 1 through 210 -N may include a mobile device, such as wireless or cellular telephone device (e.g., a conventional cell phone with data processing capabilities), a smart phone, a personal digital assistant (PDA) that can include a radiotelephone, etc.
- a mobile device such as wireless or cellular telephone device (e.g., a conventional cell phone with data processing capabilities), a smart phone, a personal digital assistant (PDA) that can include a radiotelephone, etc.
- PDA personal digital assistant
- UEs 210 may also include any type of mobile computer device or system, such as a personal computer (PC), a laptop, a tablet computer, a notebook, a netbook, a wearable computer (e.g., a wrist watch, eyeglasses, etc.), a game playing device, a music playing device, a home appliance device, a home monitoring device, etc., that may include communication functionality.
- UEs 210 may further include Internet of things (IoT) devices, such as narrow band IoT devices operating in accordance with the 3GPP standard, devices employing machine-to-machine (M2M) communication, such as Machine-Type Communication (MTC), a type of M2M communication standard developed by the 3GPP.
- IoT Internet of things
- M2M machine-to-machine
- MTC Machine-Type Communication
- UEs 210 may connect to network 240 via an air interface and to other devices in environment 200 (e.g., service provider 230 ) via any conventional technique, such as wired, wireless, optical connections or a combination of these techniques.
- UE 210 and the entity associated with UE 210 e.g., the user of UE 210
- Service provider 230 may include one or more computer devices and systems associated with providing wireless services via network 240 .
- service provider 230 may be an entity associated with operating network 240 .
- Service provider 230 may maintain information regarding service plans for large numbers of users (also referred to herein as customers or subscribers) and manage network resource usage by the users.
- service provider 230 may store user profiles that include subscription priority associated with each UE 210 . The subscription priority may enable the RAN to selectively provide prioritized access to network resources in congested/overloaded conditions.
- Service provider 230 may communicate with elements of network 240 to selectively provide prioritized access to network resources, as described in more detail below.
- Network 240 may include one or more wired, wireless and/or optical networks that are capable of receiving and transmitting data, voice and/or video signals.
- network 140 may include one or more public switched telephone networks (PSTNs) or other type of switched network.
- PSTNs public switched telephone networks
- Network 240 may also include one or more wireless networks and may include a number of transmission towers for receiving wireless signals and forwarding the wireless signals toward the intended destination.
- Network 240 may further include one or more satellite networks, one or more packet switched networks, such as an Internet protocol (IP) based network, a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a long term evolution (LTE) network, a 4G network, a next generation, e.g., (5G) network, a WiFi network, a Bluetooth network, an intranet, the Internet, or another type of network that is capable of transmitting data.
- IP Internet protocol
- LAN local area network
- WAN wide area network
- PAN personal area network
- LTE long term evolution
- 4G 4G network
- 5G next generation
- Wireless Fidelity Wireless Fidelity
- IP Internet protocol
- IP Internet protocol
- FIG. 2 The exemplary configuration illustrated in FIG. 2 is provided for simplicity. It should be understood that a typical environment 200 may include more or fewer devices than illustrated in FIG. 2 .
- environment 200 may include a large number (e.g., thousands or more) of UEs 210 and multiple service providers 230 .
- network 240 may include additional elements, such as eNBs, gNBs, base stations, switches, gateways, routers, monitoring devices, etc., that aid in routing data and determining whether to grant/deny prioritized access to network resources, as described in detail below.
- various functions are described below as being performed by particular components in environment 200 .
- various functions described as being performed by one device may be performed by another device or multiple other devices, and/or various functions described as being performed by multiple devices may be combined and performed by a single device.
- FIG. 3 is an exemplary block diagram illustrating a portion of network 240 .
- network 240 is a long term evolution (LTE) network.
- LTE long term evolution
- network 240 may be a 4G network implementing User Plane Optimization developed by the 3GPP. It should be understood, however, that embodiments described herein may operate in other types of wireless networks.
- network 240 may be a next generation network, such as a 5G network, which includes a new radio core network (NG Core).
- NG Core new radio core network
- Network 240 may include an evolved packet core (ePC) connected to an evolved Node B (eNB) 320 , mobile management entity (MME) 330 , serving gateway (SGW) 340 , packet gateway (PGW) 350 , home subscriber server (HSS) 360 and policy charging rules function (PCRF) 370 .
- eNB 320 may be part of an evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (eUTRAN).
- network 240 may include a 5G network and include a NextGen core (5GC) connected to a next generation NodeB (gNB).
- 5GC NextGen core
- gNB next generation NodeB
- eNB 320 may include one or more devices and other components having functionality that allow UEs 210 to wirelessly connect to network 240 .
- eNB 320 may be associated with one or more cells/sectors.
- each cell or sector in network 240 may include one or more radio frequency (RF) transceivers pointed in a particular direction.
- RF radio frequency
- eNB 320 may instead be a gNB associated with one or more cells/sectors.
- MME 330 may include one or more devices that implement control plane processing for network 240 .
- MME 330 may implement tracking and paging procedures for UEs 210 , may activate and deactivate bearers for UEs 210 , may authenticate respective users of UEs 210 , and may interface with non-LTE radio access networks.
- the core network e.g., 5GC
- AMF access and mobility management function
- a bearer may represent a logical channel with particular quality of service (QoS) requirements, and can be used in some embodiments to control packet flows as described herein.
- MME 330 may also select a particular SGW 340 for a particular UE 210 .
- MME 330 may interface with other MME devices (not shown) in network 240 and may send and receive information associated with UEs 210 , which may allow one MME 330 to take over control plane processing of UEs 210 serviced by another MME 330 , if the other MME 330 becomes unavailable.
- SGW 340 may provide an access point to and from UEs 210 , may handle forwarding of data packets for UEs 210 , and may act as a local anchor point during handover procedures between eNBs 320 .
- SGW 340 may interface with PGW 350 .
- PGW 350 may function as a gateway to a core network, such as a wide area network (WAN) (not shown) that allows delivery of Internet protocol (IP) services to UEs 210 .
- WAN wide area network
- HSS 360 may store information associated with UEs 210 and/or information associated with users of UEs 210 .
- HSS 360 may store user profiles that include authentication and access authorization information.
- Each user/subscription profile may include a list of UEs 210 associated with the subscriptions as well as an indication of which UEs 210 are active (e.g., authorized to connect to network 240 ).
- HSS 360 may also store profile information corresponding to modes or categories of use for UEs 210 , and ARP parameters associated with the modes or categories of use, as described in detail below.
- the core network e.g., 5GC
- UDM unified data management
- PCRF 370 may implement policy charging and rule functions, such as providing quality of service (QoS) requirements, bandwidth and/or charges for a particular service for UEs 210 .
- PCRF 370 may determine how a certain service data flow will be treated, and may ensure that user plane traffic mapping and treatment is in accordance with a user's subscription profile.
- QoS quality of service
- network 240 may include fewer components, different components, differently arranged components, or additional components than depicted in FIG. 3 .
- network 240 may include a large number of eNBs 320 , MMEs 330 , SGWs 340 , PGWs 350 , HSSs 360 , and PCRFs 370 .
- one or more components of network 240 may perform functions described as being performed by one or more other components.
- FIG. 4 illustrates an exemplary configuration of UE 210 .
- Other devices in environment 200 such as service provider 230 may be configured in a similar manner.
- devices in network 240 such as eNB 320 , MME 330 , SGW 340 , PGW 350 , HSS 360 , and PCRF 370 may be configured in a similar manner.
- UE 210 may include bus 410 , processor 420 , memory 430 , input device 440 , output device 450 , and communication interface 460 .
- Bus 410 may include a path that permits communication among the elements of UE 210 .
- Processor 420 may include one or more processors, microprocessors, or processing logic that may interpret and execute instructions.
- Memory 430 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 420 .
- Memory 430 may also include a read only memory (ROM) device or another type of static storage device that may store static information and instructions for use by processor 420 .
- Memory 430 may further include a solid state drive (SDD).
- SDD solid state drive
- Memory 430 may also include a magnetic and/or optical recording medium (e.g., a hard disk) and its corresponding drive.
- Input device 440 may include a mechanism that permits a user to input information to UE 210 , such as a keyboard, a keypad, a mouse, a pen, a microphone, a touch screen, voice recognition and/or biometric mechanisms, etc.
- Output device 450 may include a mechanism that outputs information to the user, including a display (e.g., a liquid crystal display (LCD)), a printer, a speaker, etc.
- a touch screen display may act as both an input device and an output device.
- Communication interface 460 may include one or more transceivers that UE 210 (service provider 230 or devices in network 240 ) uses to communicate with other devices via wired, wireless, or optical mechanisms.
- communication interface 460 may include one or more radio frequency (RF) transmitters, receivers and/or transceivers and one or more antennas for transmitting and receiving RF data via network 240 .
- Communication interface 460 may also include a modem or an Ethernet interface to a LAN or other mechanisms for communicating with elements in a network, such as network 240 or another network.
- RF radio frequency
- UE 210 (service provider 230 or devices in network 240 ) may include more or fewer devices than illustrated in FIG. 4 .
- UE 210 (or other devices in environment 200 ) performs operations in response to processor 420 executing sequences of instructions contained in a computer-readable medium, such as memory 430 .
- a computer-readable medium may be defined as a physical or logical memory device.
- the software instructions may be read into memory 430 from another computer-readable medium (e.g., a hard disk drive (HDD), SSD, etc.), or from another device via communication interface 460 .
- HDD hard disk drive
- SSD etc.
- hard-wired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the implementations described herein.
- implementations described herein are not limited to any specific combination of hardware circuitry and software.
- FIG. 5 is an exemplary functional block diagram of components implemented in eNB 320 .
- all or some of the components illustrated in FIG. 5 may be implemented by processor 420 executing software instructions stored in memory 430 .
- eNB 320 may include UE monitoring/state logic 510 , network monitoring logic 520 , UE scheduling logic 530 , database 540 , and communication logic 550 .
- these components or a portion of these components may be located externally with respect to eNB 220 , such as within one or more elements of network 240 (e.g., HSS 360 ) and/or service provider 230 .
- the components illustrated in FIG. 5 may be implemented in a 5G network, such as within a gNB.
- UE monitoring/state logic 510 may include a state machine that defines state transitions for an RRC connected (active) state, an RRC (connected) inactive state, and an RRC idle (disconnected) state for a radio communication session of UE 210 via eNB 320 .
- UE monitoring/state logic 510 may include timing logic to monitor periods of session inactivity for UE 210 operating in the RRC connected state with eNB 320 .
- UE monitoring/state logic 510 may suspend the RRC connection to UE 210 , and transition UE 210 to the RRC inactive state (e.g., state 130 , FIG. 1 ). From the RRC inactive state, UE monitoring/state logic 410 may transition UE 210 to either the RRC idle state (e.g., state 110 ) or back to the RRC connected state (e.g., state 120 ).
- a predetermined threshold period e.g., N seconds, where Nis any positive integer
- the timing logic may determine that the period of inactivity for the session exceeds another threshold period, and UE monitoring/state logic 510 may transition UE 210 to the RRC idle state based on the inactivity.
- the timing logic may detect session activity that occurs prior to the other predetermined threshold period, and UE monitoring/state logic 510 may transition UE 210 to the RRC connected state based on the detected session activity.
- Network monitoring logic 520 may include logic to determine parameters associated with the RAN, such as the capacity of the RAN, whether the RAN is overloaded, lightly loaded, etc.
- Network monitoring logic 520 may determine congestion and/or overload conditions, for example, when the maximum number of radio links (e.g., established signaling radio bearers) at eNB 320 have been established and/or the limited available bandwidth has been allocated by eNB 320 to RRC connected UEs 210 (e.g., established data radio bearers).
- radio links e.g., established signaling radio bearers
- UE scheduling logic 530 may use the network loading information from network monitoring logic 520 to determine whether idle/disconnected UEs 210 can be granted access (e.g., prioritized access or normal access) to RAN resources.
- UE scheduling logic 530 may, in response to an RRC request received during congested/overload conditions at eNB 320 , use allocation and retention priority (ARP) parameter values associated with idle/disconnected UE 210 to deny/grant the RRC request.
- ARP allocation and retention priority
- UE scheduling logic 430 may determine to deny/grant the RRC request based on preemption capability information (PCI) and a priority level (PL) associated with idle/disconnected UE 210 , and/or based on preemption vulnerability information (PVI) and the PL associated with one or more UE 210 in a connected state or an inactive state in the RAN.
- PCI preemption capability information
- PL priority level
- PVI preemption vulnerability information
- UE scheduling logic 530 may use context for UE 210 , which is retrieved from database 540 as described in more detail below.
- Database 540 may include one or more data storage devices that store one or more databases of information associated with network 240 .
- eNB 320 may retrieve from the service provider's core network, initial context setup information including ARP parameter values, as well as subscription priority information for each UE 210 .
- database 540 stores ARP and subscription priority information for each UE 210 that includes a non-zero PCI value and/or a PL above a threshold value.
- the stored information for UE 210 may be used by UE scheduling logic 530 in a congested/overload state of eNB 320 , to determine whether an RRC request from UE 210 that has moved to an idle state, should be granted or denied.
- Communication logic 550 may include logic to allow eNB 320 to communicate with other devices in environment 200 , such as elements of network 240 .
- communication logic 550 may receive user profile information (ARP parameters, subscription priority, etc.) from MME 330 and/or other devices in network 240 , as described above.
- FIG. 5 shows exemplary components of eNB 320
- eNB 320 may include fewer components, different components, differently arranged components, or additional components than depicted in FIG. 5 .
- functions described as being performed by one of the components in FIG. 5 may alternatively be performed by another one or more of the components of eNB 320 and/or network 240 .
- FIGS. 6, 8, and 9 are flow diagrams illustrating processing associated with UE 210 accessing network 240 .
- the flow diagrams of FIGS. 6, 8, and 9 are described in conjunction with the signal flow diagram of FIG. 7 .
- Processing may begin with UE 210 accessing network 240 and attempting to setup a network session via a RAN (block 610 ).
- UE 210 may transmit an RRC Connection Request message to eNB 320 ( FIG. 7, 710 ).
- the RRC Connection Request message may include information elements corresponding to the identity of UE 210 , including, for example, an access class.
- eNB 320 has determined that the RAN is not in a congested/overload state (i.e., detected normal traffic conditions).
- eNB 320 may receive the Connection Request message and transmit an RRC Connection Setup message to UE 210 ( FIG. 7, 715 ).
- UE 210 Upon receiving RRC Connection Setup message, assume that UE 210 responds by sending an RRC Setup Complete message to eNB 320 , indicating that the RRC Connection Setup is complete, and thereby signaling radio bearer (SRB) resources are allocated to UE 210 by eNB 320 (block 620 , FIG. 7, 720 ).
- SRB radio bearer
- UE 210 may transmit an 51 Application Protocol (AP) Initial UE message, via eNB 320 , which includes a non-access stratum (NAS) Attach Request to MME 330 (block 630 ; FIG. 7, 730 ).
- MME 330 receives the Attach Request and sends an update location request message to HSS 360 ( FIG. 7, 740 ).
- HSS 360 may then update the location associated with UE 210 , transmit the Update Location Response to MME 330 , and in create data radio bearers (DRBs) ( FIG. 7, 745 ).
- the Update Location Response may include subscriber profile data and an International Mobile Subscriber Identity (IMSI) group ID.
- IMSI International Mobile Subscriber Identity
- the subscriber profile data includes information provided by PCRF 370 via HSS 360 and identifies a subscription priority with respect to prioritized access to network 240 , and may indicate that the RRC inactive state is to be enabled for UE 210 .
- MME 330 may receive the Update Location Response and send an Initial Context Setup Attach Accept message to eNB 320 ( FIG. 7, 750 ), which may then be forwarded to UE 210 (as shown by the dotted line in FIG. 7 ).
- DRB resources may be allocated to UE 210 , and UE 210 may then transmit data via network 240 using the DRB resources during a data session (block 630 ; FIG. 7, 752 ).
- UE 210 may use IP multimedia core network subsystem (IMS) services via the RRC connection.
- IMS IP multimedia core network subsystem
- eNB 220 may determine whether the subscriber profile data allows UE 220 to be placed in the RRC inactive state (block 625 ). If eNB 220 determines that UE 210 is allowed to enter the RRC inactive state (block 625 —YES), then eNB 220 may store the context information for UE 210 (block 630 ). Alternatively, if eNB 220 determines that UE 210 is not allowed to enter the RRC inactive state (block 625 —NO), then the context information for UE 210 may not be stored by eNB 220 .
- eNB 320 monitors the network session for activity (blocks 635 , 650 ; FIG. 7, 755 ). eNB 320 determines whether a period of inactivity exceeds a predetermined threshold amount of time (blocks 640 , 655 ). When eNB 320 detects additional session activity before the period of session inactivity exceeds the threshold (block 640 —NO or block 655 —NO), the process may return to block 635 or block 650 , and UE 210 may remain in the RRC connected state.
- eNB 320 places UE 210 in the RRC inactive state (block 645 ; FIG. 7, 757 ).
- eNB 320 places UE 210 in the RRC idle state (block 660 )
- eNB 320 may use Context information to determine whether UE 210 is eligible for prioritized access. eNB 320 may also store the Context information, including the ARP parameter values and/or the subscription priority information, based on eNB 320 determining that UE 210 is eligible for prioritized access to the RAN. Prioritized access may be determined from ARP values and/or subscription priority values that exceed a threshold value(s). Alternatively, eNB 320 may not store Context information for UE 210 when UE 210 is not eligible for prioritized access, i.e., the ARP values and/or subscription priority values do not exceed the threshold value(s). For example, if UE 210 has a PCI value of 0 (i.e., UE 210 is not capable of preemption) instead of 1, the Context information may not be stored for UE 210 by eNB 320 .
- PCI value i.e., UE 210 is not capable of preemption
- eNB 320 detects congestion and/or overload conditions in the RAN (block 810 ; FIG. 7, 759 ). Alternatively, the congestion/overload determination may be made at any time, for example, after the attach accept 750 . Assume further that UE 210 , while in the inactive state and before transition to an idle state, sends an RRC Resume Request message to eNB 320 (block 820 ; FIG. 7, 760 ). For example, UE 210 may send the request within an amount of time that is less than a threshold of inactive time for being placed in an RRC idle state, i.e., disconnected.
- eNB 320 receives the RRC Resume Request message and determines whether, in view of the congestion/overload state of the RAN, eNB 320 is to preempt one or more other bearers and transition UE 210 from the RRC inactive state to the RRC connected state (block 830 ; FIG. 7, 770 ). In making the determination, eNB 320 uses the Context information for UE 210 that is stored by eNB 320 . For example, eNB 320 may identify the ARP parameter values and/or the subscription priority information associated with UE 210 .
- eNB 320 may determine that the ARP parameter values for UE 210 , associated with a public safety agency, include a PCI value of 1, and a PL value that is between 1-14 (where a PL value of 1 is the highest priority and a PL value of 15 is the lowest priority).
- bearers i.e., UEs 210 in a connected, RRC active state on the RAN
- eNB 320 may preempt the identified bearer(s) to enable UE 110 to access the RAN, i.e., transition from the inactive state to the connected, RRC active state. For example, eNB 320 may preempt the identified bearer(s) in any number of ways, including disconnecting the bearer, modifying (e.g., degrading) the connection, directing handover to another eNB 320 , or any other form of preempting the bearer to prioritize access to the RAN by UE 210 .
- eNB 320 may deny the RRC Resume Request (block 840 ) and may transmit a reject response to UE 210 (block 850 ).
- eNB 320 provides an RRC Resume message to UE 210 and the identified low priority bearer(s) is preempted (block 860 ; FIG. 7, 780 ).
- UE 210 may receive the RRC Resume message and transmit an RRC Resume Complete message ( FIG. 7, 790 ) to eNB 320 .
- one or more SRBs are allocated between eNB 320 and UE 210 and UE 210 transitions to the RRC active state (block 870 ).
- eNB 320 may detect congestion and/or overload conditions in the RAN (block 900 ; FIG. 7, 759 ). eNB may receive an RRC connection request from UE 210 (block 910 ), substantially as described above with respect to FIG. 7, 780 . In response, eNB 320 may allocate an SRB and perform RRC connection setup and the RRC connection completed substantially as described above with respect to FIG. 7, 715, 720 . eNB 320 may exchange messages with the core network to perform initial context setup and receive ARP data and subscriber priority information for UE 210 substantially as described above with respect to FIGS. 7, 730, 740, 745, and 750 .
- eNB 320 determines whether, in view of the congestion/overload state of the RAN, eNB 320 is to preempt one or more other bearers and transition UE 210 from the RRC inactive state to the RRC connected state (block 950 ; FIG. 7, 770 ). In making the determination, eNB 320 uses the Context information for UE 210 that is received from the core network. If eNB 320 determines that UE 210 is not eligible to preempt any existing bearer in the RAN, the RRC connection is releases or redirected (block 960 ), for example, to another eNB, i.e., handover to another cell, and the SRB is torn down. If eNB 210 determines that UE 210 is eligible to preempt a low priority UE 210 , eNB 320 may preempt the existing bearer in the RAN (block 970 ).
- eNB 320 may use subscription priority information stored by eNB 320 , which was provided by, for example, PCRF 370 during initial RRC connection establishment.
- the subscription priority information may be used, for example, to verify an Access Class claimed by UE 210 .
- Implementations described herein provide for controlling prioritized access to network resources in a RAN based on access point name (APN)-level data and/or UE-level prioritization information stored at the RAN.
- APN access point name
- the RAN may avoid overloading the RAN with SRB creation and network traffic in prioritized connection determinations. This in turn results in less network congestion and increased network capacity.
- Controlling prioritized accesses also helps protect a network from intentional or improper use of prioritized network access requests that can limit other devices' ability to access the network.
- utilization of UE Context stored in the RAN as part of RRC inactive/User Plane Optimization state to apply prioritization and preemption during RRC Connection establishment may reduce delay and increase the accuracy of prioritization decisions.
- the Resume Request may include Access Class information for UE 210 .
- eNB 320 may use the Context, the subscription information for example, to verify the identified Access Class associated with UE 210 .
- logic may include hardware, such as one or more processors, microprocessor, application specific integrated circuits, field programmable gate arrays or other processing logic, software, or a combination of hardware and software.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- Radio access networks (RANs) operated by wireless network providers provide shared, finite radio resources that are generally accessible to user devices via the air interface. RANs are susceptible to congestion and/or overload when the maximum number of radio links, i.e., signaling radio bearer (SRB) resources, have been established and/or the limited available bandwidth has been allocated to connected, Radio Resource Control (RRC) active user devices, i.e., data radio bearer (DRB) resources. During congestion/overload conditions in the RAN, when RRC protocol Connection Request messages are received from additional user devices seeking access, via an evolved NodeB (eNB) or a next generation NodeB (gNB), the eNB/gNB must support services designated as high priority, such as public safety and emergency communications users, etc. However, the RAN cannot simply rely on the Access Class information provided by the UE as being legitimate in determining a prioritization level associated with any given access request.
-
FIG. 1 is a diagram illustrating possible RRC states of user devices with respect to a RAN in accordance with an exemplary implementation; -
FIG. 2 illustrates an exemplary environment in which systems and methods described herein may be implemented; -
FIG. 3 illustrates an exemplary configuration of components implemented in a portion of the network ofFIG. 2 ; -
FIG. 4 illustrates an exemplary configuration of logic components included in one or more of the devices ofFIG. 2 andFIG. 3 ; -
FIG. 5 illustrates an exemplary configuration of logic components implemented by one of the devices ofFIG. 2 ; -
FIGS. 6, 8, and 9 are flow diagrams illustrating processing associated with radio resource management in accordance with an exemplary implementation; and -
FIG. 7 is a signal flow diagram associated with the processing ofFIGS. 6, 8, and 9 . - The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.
- Implementations described herein relate to controlling prioritized access to RAN resources. In an exemplary implementation, prioritized access is controlled in a prescribed manner that provides a technological improvement over the current state of the art in scheduling of RAN resources in a congested/overloaded RAN, and thereby advantageously conserves bandwidth and reduces messaging traffic in the RAN.
- Preemption and admission priority are some of the mechanisms available to RANs to enforce access prioritization during congestion/overload. For example, RANs may use allocation and retention priority (ARP) information for a user device requesting prioritized access to deny/grant the request. Currently, because such information is not stored by RANs, the RAN must first set up signaling radio bearers (SRBs) to the user device, and then request the information from the core network responsive to each initiation of an RRC connection during congestion/overload in the RAN.
- Current radio resource management has a number of technological disadvantages. For example, if the RAN is SRB congested, the RAN is not able to allocate SRB resources to the user device and may reject the access attempt without first identifying the prioritized access that may be due the user device. On the other hand, if SRB resources are available and are allocated by the RAN, these resources will be wasted in situations where the RAN ultimately determines that prioritized access is not due. Also, signaling communications with the core network creates additional network traffic in an already congested/overloaded RAN, and adds unnecessary delay to the response. Further, reserving RAN resources in advance of receiving actual requests will result in less than optimal use of the resources available. Implementations described herein provide technological solutions and efficiencies over the above-mentioned technological challenges.
- Referring to
FIG. 1 , 3rd Generation Partnership Project (3GPP) standards for Fifth Generation (5G) define RRC states/transitions 100 for user equipment (UE) with respect to a RAN. At power up, a user device may be unregistered with the RAN, and may assume an RRC idle ordisconnected state 110. The user device may, upon attachment and registration via an RRC connection, transition to an RRC connected (active)state 120. 5G standards introduce a third state, RRC (connected)inactive state 130, to reduce the control plane latency. For example, periods of inactivity in the RRC connected state result in the RRC session being suspended and the user device being transitioned to the RRC inactive state, in which the user device is still registered and connected to the RAN, unlike the idle state where the user device is disconnected and deregistered from the RAN. Fourth Generation (4G) networks supports a similar approach as part of User Plane Optimization. RRC states and/or transitions other than what are depicted inFIG. 1 are possible. - Implementations described herein include the technological solution of the RAN storing user device context even when the user device is not in the RRC connected state 520. That is, when an RRC session for the user device is suspended as described in more detail below, and the user device is placed in the RRC
inactive state 530, the RAN may store the context information obtained from the core network. At this point, should the user device resume activity in the RRC session, the RAN may use the context information to determine whether the inactive user device is due prioritized access when the RAN is under congested/overload conditions. In this manner, prioritized network access can be effectively controlled using a less resource-intensive process than currently practiced. -
FIG. 2 is a block diagram of anexemplary environment 200 in which systems and methods described herein may be implemented.Environment 200 may include user equipment (UE) 210-1 through 210-N,service provider 230, andnetwork 240. - UEs 210-1 through 210-N (individually referred to as UE 210-x, UE 210 or UE
device 210, and collectively as UEs 210 or UE devices 210) may include a mobile device, such as wireless or cellular telephone device (e.g., a conventional cell phone with data processing capabilities), a smart phone, a personal digital assistant (PDA) that can include a radiotelephone, etc. UEs 210 may also include any type of mobile computer device or system, such as a personal computer (PC), a laptop, a tablet computer, a notebook, a netbook, a wearable computer (e.g., a wrist watch, eyeglasses, etc.), a game playing device, a music playing device, a home appliance device, a home monitoring device, etc., that may include communication functionality. UEs 210 may further include Internet of things (IoT) devices, such as narrow band IoT devices operating in accordance with the 3GPP standard, devices employing machine-to-machine (M2M) communication, such as Machine-Type Communication (MTC), a type of M2M communication standard developed by the 3GPP. - UEs 210 may connect to
network 240 via an air interface and to other devices in environment 200 (e.g., service provider 230) via any conventional technique, such as wired, wireless, optical connections or a combination of these techniques. UE 210 and the entity associated with UE 210 (e.g., the user of UE 210) may be referred to collectively as UE 210 in the description below. -
Service provider 230 may include one or more computer devices and systems associated with providing wireless services vianetwork 240. For example,service provider 230 may be an entity associated withoperating network 240.Service provider 230 may maintain information regarding service plans for large numbers of users (also referred to herein as customers or subscribers) and manage network resource usage by the users. For example,service provider 230 may store user profiles that include subscription priority associated with each UE 210. The subscription priority may enable the RAN to selectively provide prioritized access to network resources in congested/overloaded conditions.Service provider 230 may communicate with elements ofnetwork 240 to selectively provide prioritized access to network resources, as described in more detail below. -
Network 240 may include one or more wired, wireless and/or optical networks that are capable of receiving and transmitting data, voice and/or video signals. For example, network 140 may include one or more public switched telephone networks (PSTNs) or other type of switched network. Network 240 may also include one or more wireless networks and may include a number of transmission towers for receiving wireless signals and forwarding the wireless signals toward the intended destination. Network 240 may further include one or more satellite networks, one or more packet switched networks, such as an Internet protocol (IP) based network, a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a long term evolution (LTE) network, a 4G network, a next generation, e.g., (5G) network, a WiFi network, a Bluetooth network, an intranet, the Internet, or another type of network that is capable of transmitting data. Network 240 provides wireless packet-switched services and wireless Internet protocol (IP) connectivity to UEs 210 to provide, for example, data, voice, and/or multimedia services. - The exemplary configuration illustrated in
FIG. 2 is provided for simplicity. It should be understood that atypical environment 200 may include more or fewer devices than illustrated inFIG. 2 . For example,environment 200 may include a large number (e.g., thousands or more) of UEs 210 andmultiple service providers 230. In addition,network 240 may include additional elements, such as eNBs, gNBs, base stations, switches, gateways, routers, monitoring devices, etc., that aid in routing data and determining whether to grant/deny prioritized access to network resources, as described in detail below. - In addition, various functions are described below as being performed by particular components in
environment 200. In other implementations, various functions described as being performed by one device may be performed by another device or multiple other devices, and/or various functions described as being performed by multiple devices may be combined and performed by a single device. -
FIG. 3 is an exemplary block diagram illustrating a portion ofnetwork 240. In the implementation depicted inFIG. 3 ,network 240 is a long term evolution (LTE) network. For example,network 240 may be a 4G network implementing User Plane Optimization developed by the 3GPP. It should be understood, however, that embodiments described herein may operate in other types of wireless networks. For example,network 240 may be a next generation network, such as a 5G network, which includes a new radio core network (NG Core). -
Network 240 may include an evolved packet core (ePC) connected to an evolved Node B (eNB) 320, mobile management entity (MME) 330, serving gateway (SGW) 340, packet gateway (PGW) 350, home subscriber server (HSS) 360 and policy charging rules function (PCRF) 370.eNB 320 may be part of an evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (eUTRAN). In one embodiment,network 240 may include a 5G network and include a NextGen core (5GC) connected to a next generation NodeB (gNB). -
eNB 320 may include one or more devices and other components having functionality that allowUEs 210 to wirelessly connect tonetwork 240.eNB 320 may be associated with one or more cells/sectors. For example, each cell or sector innetwork 240 may include one or more radio frequency (RF) transceivers pointed in a particular direction. Alternatively, wherenetwork 240 is a 5G network,eNB 320 may instead be a gNB associated with one or more cells/sectors. -
eNB 320 may interface withMME 330.MME 330 may include one or more devices that implement control plane processing fornetwork 240. For example,MME 330 may implement tracking and paging procedures forUEs 210, may activate and deactivate bearers forUEs 210, may authenticate respective users ofUEs 210, and may interface with non-LTE radio access networks. Alternatively toMME 330, the core network (e.g., 5GC) may include an access and mobility management function (AMF) device. - A bearer may represent a logical channel with particular quality of service (QoS) requirements, and can be used in some embodiments to control packet flows as described herein.
MME 330 may also select aparticular SGW 340 for aparticular UE 210.MME 330 may interface with other MME devices (not shown) innetwork 240 and may send and receive information associated withUEs 210, which may allow oneMME 330 to take over control plane processing ofUEs 210 serviced by anotherMME 330, if theother MME 330 becomes unavailable. -
SGW 340 may provide an access point to and fromUEs 210, may handle forwarding of data packets forUEs 210, and may act as a local anchor point during handover procedures betweeneNBs 320.SGW 340 may interface withPGW 350.PGW 350 may function as a gateway to a core network, such as a wide area network (WAN) (not shown) that allows delivery of Internet protocol (IP) services toUEs 210. -
HSS 360 may store information associated withUEs 210 and/or information associated with users ofUEs 210. For example,HSS 360 may store user profiles that include authentication and access authorization information. Each user/subscription profile may include a list ofUEs 210 associated with the subscriptions as well as an indication of whichUEs 210 are active (e.g., authorized to connect to network 240).HSS 360 may also store profile information corresponding to modes or categories of use forUEs 210, and ARP parameters associated with the modes or categories of use, as described in detail below. Alternatively toHSS 360, the core network (e.g., 5GC) may include a unified data management (UDM) device. -
PCRF 370 may implement policy charging and rule functions, such as providing quality of service (QoS) requirements, bandwidth and/or charges for a particular service forUEs 210.PCRF 370 may determine how a certain service data flow will be treated, and may ensure that user plane traffic mapping and treatment is in accordance with a user's subscription profile. - Although
FIG. 3 shows exemplary components ofnetwork 240, in other implementations,network 240 may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 3 . For example,network 240 may include a large number ofeNBs 320,MMEs 330,SGWs 340,PGWs 350,HSSs 360, andPCRFs 370. Additionally, or alternatively, one or more components ofnetwork 240 may perform functions described as being performed by one or more other components. -
FIG. 4 illustrates an exemplary configuration ofUE 210. Other devices inenvironment 200, such asservice provider 230 may be configured in a similar manner. In addition, in some implementations, devices innetwork 240, such aseNB 320,MME 330,SGW 340,PGW 350,HSS 360, andPCRF 370 may be configured in a similar manner. Referring toFIG. 4 ,UE 210 may includebus 410,processor 420,memory 430,input device 440,output device 450, andcommunication interface 460.Bus 410 may include a path that permits communication among the elements ofUE 210. -
Processor 420 may include one or more processors, microprocessors, or processing logic that may interpret and execute instructions.Memory 430 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution byprocessor 420.Memory 430 may also include a read only memory (ROM) device or another type of static storage device that may store static information and instructions for use byprocessor 420.Memory 430 may further include a solid state drive (SDD).Memory 430 may also include a magnetic and/or optical recording medium (e.g., a hard disk) and its corresponding drive. -
Input device 440 may include a mechanism that permits a user to input information toUE 210, such as a keyboard, a keypad, a mouse, a pen, a microphone, a touch screen, voice recognition and/or biometric mechanisms, etc.Output device 450 may include a mechanism that outputs information to the user, including a display (e.g., a liquid crystal display (LCD)), a printer, a speaker, etc. In some implementations, a touch screen display may act as both an input device and an output device. -
Communication interface 460 may include one or more transceivers that UE 210 (service provider 230 or devices in network 240) uses to communicate with other devices via wired, wireless, or optical mechanisms. For example,communication interface 460 may include one or more radio frequency (RF) transmitters, receivers and/or transceivers and one or more antennas for transmitting and receiving RF data vianetwork 240.Communication interface 460 may also include a modem or an Ethernet interface to a LAN or other mechanisms for communicating with elements in a network, such asnetwork 240 or another network. - The exemplary configuration illustrated in
FIG. 4 is provided for simplicity. It should be understood that UE 210 (service provider 230 or devices in network 240) may include more or fewer devices than illustrated inFIG. 4 . In an exemplary implementation, UE 210 (or other devices in environment 200) performs operations in response toprocessor 420 executing sequences of instructions contained in a computer-readable medium, such asmemory 430. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read intomemory 430 from another computer-readable medium (e.g., a hard disk drive (HDD), SSD, etc.), or from another device viacommunication interface 460. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the implementations described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. -
FIG. 5 is an exemplary functional block diagram of components implemented ineNB 320. In an exemplary implementation, all or some of the components illustrated inFIG. 5 may be implemented byprocessor 420 executing software instructions stored inmemory 430. -
eNB 320 may include UE monitoring/state logic 510, network monitoring logic 520,UE scheduling logic 530,database 540, andcommunication logic 550. In alternative implementations, these components or a portion of these components may be located externally with respect to eNB 220, such as within one or more elements of network 240 (e.g., HSS 360) and/orservice provider 230. In addition, in other implementations, the components illustrated inFIG. 5 may be implemented in a 5G network, such as within a gNB. - UE monitoring/
state logic 510 may include a state machine that defines state transitions for an RRC connected (active) state, an RRC (connected) inactive state, and an RRC idle (disconnected) state for a radio communication session ofUE 210 viaeNB 320. In one example embodiment, UE monitoring/state logic 510 may include timing logic to monitor periods of session inactivity forUE 210 operating in the RRC connected state witheNB 320. When the timing logic determines that a period of inactivity exceeds a predetermined threshold period (e.g., N seconds, where Nis any positive integer), UE monitoring/state logic 510 may suspend the RRC connection toUE 210, andtransition UE 210 to the RRC inactive state (e.g.,state 130,FIG. 1 ). From the RRC inactive state, UE monitoring/state logic 410 may transitionUE 210 to either the RRC idle state (e.g., state 110) or back to the RRC connected state (e.g., state 120). For example, the timing logic may determine that the period of inactivity for the session exceeds another threshold period, and UE monitoring/state logic 510 may transitionUE 210 to the RRC idle state based on the inactivity. Alternatively, or additionally, the timing logic may detect session activity that occurs prior to the other predetermined threshold period, and UE monitoring/state logic 510 may transitionUE 210 to the RRC connected state based on the detected session activity. - Network monitoring logic 520 may include logic to determine parameters associated with the RAN, such as the capacity of the RAN, whether the RAN is overloaded, lightly loaded, etc. Network monitoring logic 520 may determine congestion and/or overload conditions, for example, when the maximum number of radio links (e.g., established signaling radio bearers) at
eNB 320 have been established and/or the limited available bandwidth has been allocated byeNB 320 to RRC connected UEs 210 (e.g., established data radio bearers). -
UE scheduling logic 530 may use the network loading information from network monitoring logic 520 to determine whether idle/disconnectedUEs 210 can be granted access (e.g., prioritized access or normal access) to RAN resources. In one implementation,UE scheduling logic 530 may, in response to an RRC request received during congested/overload conditions ateNB 320, use allocation and retention priority (ARP) parameter values associated with idle/disconnected UE 210 to deny/grant the RRC request. For example,UE scheduling logic 430 may determine to deny/grant the RRC request based on preemption capability information (PCI) and a priority level (PL) associated with idle/disconnected UE 210, and/or based on preemption vulnerability information (PVI) and the PL associated with one ormore UE 210 in a connected state or an inactive state in the RAN. In one implementation,UE scheduling logic 530 may use context forUE 210, which is retrieved fromdatabase 540 as described in more detail below. -
Database 540 may include one or more data storage devices that store one or more databases of information associated withnetwork 240. For example, as described above,eNB 320 may retrieve from the service provider's core network, initial context setup information including ARP parameter values, as well as subscription priority information for eachUE 210. In one embodiment,database 540 stores ARP and subscription priority information for eachUE 210 that includes a non-zero PCI value and/or a PL above a threshold value. The stored information forUE 210 may be used byUE scheduling logic 530 in a congested/overload state ofeNB 320, to determine whether an RRC request fromUE 210 that has moved to an idle state, should be granted or denied. -
Communication logic 550 may include logic to alloweNB 320 to communicate with other devices inenvironment 200, such as elements ofnetwork 240. For example,communication logic 550 may receive user profile information (ARP parameters, subscription priority, etc.) fromMME 330 and/or other devices innetwork 240, as described above. - Although
FIG. 5 shows exemplary components ofeNB 320, in other implementations,eNB 320 may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 5 . In addition, functions described as being performed by one of the components inFIG. 5 may alternatively be performed by another one or more of the components ofeNB 320 and/ornetwork 240. -
FIGS. 6, 8, and 9 are flow diagrams illustrating processing associated withUE 210 accessingnetwork 240. The flow diagrams ofFIGS. 6, 8, and 9 are described in conjunction with the signal flow diagram ofFIG. 7 . - Processing may begin with
UE 210 accessingnetwork 240 and attempting to setup a network session via a RAN (block 610). For example,UE 210 may transmit an RRC Connection Request message to eNB 320 (FIG. 7, 710 ). The RRC Connection Request message may include information elements corresponding to the identity ofUE 210, including, for example, an access class. Assume thateNB 320 has determined that the RAN is not in a congested/overload state (i.e., detected normal traffic conditions).eNB 320 may receive the Connection Request message and transmit an RRC Connection Setup message to UE 210 (FIG. 7, 715 ). Upon receiving RRC Connection Setup message, assume thatUE 210 responds by sending an RRC Setup Complete message toeNB 320, indicating that the RRC Connection Setup is complete, and thereby signaling radio bearer (SRB) resources are allocated toUE 210 by eNB 320 (block 620,FIG. 7, 720 ). - Once the RRC is setup,
UE 210 may transmit an 51 Application Protocol (AP) Initial UE message, viaeNB 320, which includes a non-access stratum (NAS) Attach Request to MME 330 (block 630;FIG. 7, 730 ).MME 330 receives the Attach Request and sends an update location request message to HSS 360 (FIG. 7, 740 ).HSS 360 may then update the location associated withUE 210, transmit the Update Location Response toMME 330, and in create data radio bearers (DRBs) (FIG. 7, 745 ). The Update Location Response may include subscriber profile data and an International Mobile Subscriber Identity (IMSI) group ID. In accordance with an exemplary implementation, the subscriber profile data includes information provided byPCRF 370 viaHSS 360 and identifies a subscription priority with respect to prioritized access tonetwork 240, and may indicate that the RRC inactive state is to be enabled forUE 210. -
MME 330 may receive the Update Location Response and send an Initial Context Setup Attach Accept message to eNB 320 (FIG. 7, 750 ), which may then be forwarded to UE 210 (as shown by the dotted line inFIG. 7 ). DRB resources may be allocated toUE 210, andUE 210 may then transmit data vianetwork 240 using the DRB resources during a data session (block 630;FIG. 7, 752 ). For example,UE 210 may use IP multimedia core network subsystem (IMS) services via the RRC connection. - eNB 220 may determine whether the subscriber profile data allows UE 220 to be placed in the RRC inactive state (block 625). If eNB 220 determines that
UE 210 is allowed to enter the RRC inactive state (block 625—YES), then eNB 220 may store the context information for UE 210 (block 630). Alternatively, if eNB 220 determines thatUE 210 is not allowed to enter the RRC inactive state (block 625—NO), then the context information forUE 210 may not be stored by eNB 220. - In either case,
eNB 320 monitors the network session for activity (blocks FIG. 7, 755 ).eNB 320 determines whether a period of inactivity exceeds a predetermined threshold amount of time (blocks 640, 655). WheneNB 320 detects additional session activity before the period of session inactivity exceeds the threshold (block 640—NO or block 655—NO), the process may return to block 635 or block 650, andUE 210 may remain in the RRC connected state. ForUE 210 that may be placed in the RRC inactive state, when the period of session inactivity exceeds the threshold (block 640—YES), according to the Context information forUE 210,eNB 320places UE 210 in the RRC inactive state (block 645;FIG. 7, 757 ). Alternatively, forUE 210 that cannot be placed in the RRC inactive state, when the period of session inactivity exceeds the threshold (block 655—YES),eNB 320places UE 210 in the RRC idle state (block 660) - In one embodiment,
eNB 320 may use Context information to determine whetherUE 210 is eligible for prioritized access.eNB 320 may also store the Context information, including the ARP parameter values and/or the subscription priority information, based oneNB 320 determining thatUE 210 is eligible for prioritized access to the RAN. Prioritized access may be determined from ARP values and/or subscription priority values that exceed a threshold value(s). Alternatively,eNB 320 may not store Context information forUE 210 whenUE 210 is not eligible for prioritized access, i.e., the ARP values and/or subscription priority values do not exceed the threshold value(s). For example, ifUE 210 has a PCI value of 0 (i.e.,UE 210 is not capable of preemption) instead of 1, the Context information may not be stored forUE 210 byeNB 320. - Referring to
FIG. 8 , assume that whileUE 210 is in the RRC inactive state,eNB 320 detects congestion and/or overload conditions in the RAN (block 810;FIG. 7, 759 ). Alternatively, the congestion/overload determination may be made at any time, for example, after the attach accept 750. Assume further thatUE 210, while in the inactive state and before transition to an idle state, sends an RRC Resume Request message to eNB 320 (block 820;FIG. 7, 760 ). For example,UE 210 may send the request within an amount of time that is less than a threshold of inactive time for being placed in an RRC idle state, i.e., disconnected. -
eNB 320 receives the RRC Resume Request message and determines whether, in view of the congestion/overload state of the RAN,eNB 320 is to preempt one or more other bearers andtransition UE 210 from the RRC inactive state to the RRC connected state (block 830;FIG. 7, 770 ). In making the determination,eNB 320 uses the Context information forUE 210 that is stored byeNB 320. For example,eNB 320 may identify the ARP parameter values and/or the subscription priority information associated withUE 210. For example,eNB 320 may determine that the ARP parameter values forUE 210, associated with a public safety agency, include a PCI value of 1, and a PL value that is between 1-14 (where a PL value of 1 is the highest priority and a PL value of 15 is the lowest priority). eNB 220 may identify one or more bearers (i.e.,UEs 210 in a connected, RRC active state on the RAN), which are susceptible to preemption (i.e., PVI=1) and that have a PL value that is inferior (i.e., PL=2-15) to that ofUE 210.eNB 320 may preempt the identified bearer(s) to enableUE 110 to access the RAN, i.e., transition from the inactive state to the connected, RRC active state. For example,eNB 320 may preempt the identified bearer(s) in any number of ways, including disconnecting the bearer, modifying (e.g., degrading) the connection, directing handover to anothereNB 320, or any other form of preempting the bearer to prioritize access to the RAN byUE 210. - Based on the results of the preemption decision, if
eNB 320 decides thatUE 210 is to be denied prioritized access (block 830—NO),eNB 320 may deny the RRC Resume Request (block 840) and may transmit a reject response to UE 210 (block 850). When the preemption decision is thatUE 210 is to be granted prioritized access (block 830—YES),eNB 320 provides an RRC Resume message toUE 210 and the identified low priority bearer(s) is preempted (block 860;FIG. 7, 780 ).UE 210 may receive the RRC Resume message and transmit an RRC Resume Complete message (FIG. 7, 790 ) toeNB 320. At this point, one or more SRBs are allocated betweeneNB 320 andUE 210 andUE 210 transitions to the RRC active state (block 870). - Alternatively, for
UE 210 that transitioned to the RRC idle state inblock 660,eNB 320 may detect congestion and/or overload conditions in the RAN (block 900;FIG. 7, 759 ). eNB may receive an RRC connection request from UE 210 (block 910), substantially as described above with respect toFIG. 7, 780 . In response,eNB 320 may allocate an SRB and perform RRC connection setup and the RRC connection completed substantially as described above with respect toFIG. 7, 715, 720 .eNB 320 may exchange messages with the core network to perform initial context setup and receive ARP data and subscriber priority information forUE 210 substantially as described above with respect toFIGS. 7, 730, 740, 745, and 750 . -
eNB 320 determines whether, in view of the congestion/overload state of the RAN,eNB 320 is to preempt one or more other bearers andtransition UE 210 from the RRC inactive state to the RRC connected state (block 950;FIG. 7, 770 ). In making the determination,eNB 320 uses the Context information forUE 210 that is received from the core network. IfeNB 320 determines thatUE 210 is not eligible to preempt any existing bearer in the RAN, the RRC connection is releases or redirected (block 960), for example, to another eNB, i.e., handover to another cell, and the SRB is torn down. IfeNB 210 determines thatUE 210 is eligible to preempt alow priority UE 210,eNB 320 may preempt the existing bearer in the RAN (block970). - In the examples above, it was assumed that
UE 210, after being connected toeNB 320, had activated other services that resulted in the creation of one or more DRBs, and thus the Context information included ARP parameter values (that were later used to determine access prioritization). However, inother instances UE 210 may not activate services that require DRB creation and thus the Context information may not include any ARP parameter values. In this scenario, when a resume request is received fromUE 210 from the RRC inactive state,eNB 320 may use subscription priority information stored byeNB 320, which was provided by, for example,PCRF 370 during initial RRC connection establishment. The subscription priority information may be used, for example, to verify an Access Class claimed byUE 210. - Implementations described herein provide for controlling prioritized access to network resources in a RAN based on access point name (APN)-level data and/or UE-level prioritization information stored at the RAN. By controlling prioritized access to RAN resources, the RAN may avoid overloading the RAN with SRB creation and network traffic in prioritized connection determinations. This in turn results in less network congestion and increased network capacity. Controlling prioritized accesses also helps protect a network from intentional or improper use of prioritized network access requests that can limit other devices' ability to access the network. In addition, utilization of UE Context stored in the RAN as part of RRC inactive/User Plane Optimization state to apply prioritization and preemption during RRC Connection establishment may reduce delay and increase the accuracy of prioritization decisions.
- In some implementations, the Resume Request may include Access Class information for
UE 210.eNB 320 may use the Context, the subscription information for example, to verify the identified Access Class associated withUE 210. - The foregoing description of exemplary implementations provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the embodiments.
- Lastly, while series of acts have been described with respect to
FIGS. 6, 8, and 9 , and signal flows with respect toFIG. 7 , the order of the acts and signal flows may be different in other implementations. Moreover, non-dependent acts may be implemented in parallel. - It will be apparent that various features described above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement the various features is not limiting. Thus, the operation and behavior of the features were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the various features based on the description herein.
- Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as one or more processors, microprocessor, application specific integrated circuits, field programmable gate arrays or other processing logic, software, or a combination of hardware and software.
- In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.
- No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
- To the extent the aforementioned embodiments collect, store, or employ personal information of individuals, it should be understood that such information shall be collected, stored, and used in accordance with all applicable laws concerning protection of personal information. Additionally, the collection, storage, and use of such information can be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as can be appropriate for the situation and type of information. Storage and use of personal information can be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.
Claims (20)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/220,627 US10694573B1 (en) | 2018-12-14 | 2018-12-14 | System and method of radio resource management for radio access networks |
US16/876,339 US11234287B2 (en) | 2018-12-14 | 2020-05-18 | System and method of radio resource management for radio access networks |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/220,627 US10694573B1 (en) | 2018-12-14 | 2018-12-14 | System and method of radio resource management for radio access networks |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/876,339 Continuation US11234287B2 (en) | 2018-12-14 | 2020-05-18 | System and method of radio resource management for radio access networks |
Publications (2)
Publication Number | Publication Date |
---|---|
US20200196373A1 true US20200196373A1 (en) | 2020-06-18 |
US10694573B1 US10694573B1 (en) | 2020-06-23 |
Family
ID=71071974
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/220,627 Active US10694573B1 (en) | 2018-12-14 | 2018-12-14 | System and method of radio resource management for radio access networks |
US16/876,339 Active 2039-03-04 US11234287B2 (en) | 2018-12-14 | 2020-05-18 | System and method of radio resource management for radio access networks |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/876,339 Active 2039-03-04 US11234287B2 (en) | 2018-12-14 | 2020-05-18 | System and method of radio resource management for radio access networks |
Country Status (1)
Country | Link |
---|---|
US (2) | US10694573B1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2023045839A1 (en) * | 2021-09-22 | 2023-03-30 | 维沃移动通信有限公司 | Communication method and apparatus, core network device and communication device |
GB2625132A (en) * | 2022-12-08 | 2024-06-12 | Nokia Solutions & Networks Oy | Admission control enhancement for prioritized users |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2513311B (en) * | 2013-04-22 | 2020-05-27 | Sony Corp | Communications device and method |
US9805479B2 (en) * | 2013-11-11 | 2017-10-31 | Amazon Technologies, Inc. | Session idle optimization for streaming server |
US10129802B2 (en) * | 2013-12-06 | 2018-11-13 | Idac Holdings, Inc. | Layered connectivity in wireless systems |
WO2017061643A1 (en) * | 2015-10-06 | 2017-04-13 | 엘지전자(주) | Method and device for transmitting/receiving data to/from base station in wireless communication system |
US10887834B2 (en) * | 2016-05-12 | 2021-01-05 | Samsung Electronics Co., Ltd. | Method and device for saving power for terminal |
US10666383B2 (en) * | 2016-10-07 | 2020-05-26 | Htc Corporation | Device and method of performing codec rate adaptation in a wireless communication system |
US10728927B2 (en) * | 2016-11-11 | 2020-07-28 | FG Innovation Company Limited | Data packet delivery in RRC inactive state |
US10314005B2 (en) * | 2017-02-10 | 2019-06-04 | Samsung Electronics Co., Ltd. | Method and apparatus for inactive mode operation in wireless communication system |
-
2018
- 2018-12-14 US US16/220,627 patent/US10694573B1/en active Active
-
2020
- 2020-05-18 US US16/876,339 patent/US11234287B2/en active Active
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2023045839A1 (en) * | 2021-09-22 | 2023-03-30 | 维沃移动通信有限公司 | Communication method and apparatus, core network device and communication device |
GB2625132A (en) * | 2022-12-08 | 2024-06-12 | Nokia Solutions & Networks Oy | Admission control enhancement for prioritized users |
Also Published As
Publication number | Publication date |
---|---|
US10694573B1 (en) | 2020-06-23 |
US20200281041A1 (en) | 2020-09-03 |
US11234287B2 (en) | 2022-01-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR102096258B1 (en) | Granular network access control and methods therof | |
US9277559B2 (en) | Sharing radio resources among devices of different device classes | |
US9516652B2 (en) | Pre-emption and resource allocation prioritization for D2D communications | |
US10057805B2 (en) | Use of traffic load reduction indicator for facilitating mobility management entity overload control function | |
US20160050587A1 (en) | Proactive network congestion mitigation | |
US20220264444A1 (en) | Session Management for A Network Slice | |
US10045355B2 (en) | Preemption policy for a base station operating in closed subscriber group hybrid mode | |
JP5805909B2 (en) | Extended access control by network control for multi-service user devices | |
US9578507B2 (en) | Managing hidden security features in user equipment | |
EP3251321B1 (en) | Method and nodes for handling a user equipment's access to a mobile communications network | |
US10159033B2 (en) | System and method for controlling usage of priority access in networks | |
EP2997761B1 (en) | A node and a method for small data communications | |
US10039154B2 (en) | Node and method for establishing an inactivity timer in a wireless network | |
US11234287B2 (en) | System and method of radio resource management for radio access networks | |
US9491596B2 (en) | Prioritized push-to-talk session using quality of service (QoS) over an internet protocol multimedia subsystem (IMS) | |
US20180234824A1 (en) | Access control and scheduling mechanism for mtc devices | |
CN111919501A (en) | Dedicated bearer management | |
US20150351027A1 (en) | Dynamic activation and deactivation of access points | |
US20140323146A1 (en) | Apparatuses and Methods For Reducing Location Update Signaling Between Network Nodes of a Mobile Communication Network | |
US9930563B2 (en) | Providing a quality-of-service-based service from a cellular network via a wireless sharing device | |
JP6125585B2 (en) | Extended access control by network control for multi-service user devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PATIL, SUDHAKAR REDDY;SAGHIR, AMIR;JAGER, FRANK;SIGNING DATES FROM 20181210 TO 20181214;REEL/FRAME:047781/0028 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |