Patent Application
20250008372
In Fifth Generation (5G) network environments defined in accordance with the 3rd Generation Partnership Project (3GPP), a reduced capability (RedCap) new radio access type (RAT) associated with user equipment (UE) devices has been introduced. RedCap may support reduced bandwidth requirements for UE devices as compared to other types of RATs.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
Implementations described herein provide for dynamically switching types of data sessions for UE devices based on network load conditions. In one implementation, a UE device that can support both RedCap and Category M1 (Cat-M1) communications may dynamically switch between a RedCap data session and a Cat-M1 data session based on whether a network is congested and/or overloaded. For example, when a network is congested or overloaded with traffic, a network element may instruct a UE device to switch from a RedCap data session and re-register for a Cat-M1 data session. The CAT-M1 data session may allow a UE device to operate with lower bandwidth and/or data usage requirements than a RedCap data session. When the overload/congestion no longer exists, the network element may instruct the UE device to switch back to a RedCap data session. In this manner, a UE device data session may be dynamically controlled to assist in reducing network congestion/overloading. For example, a service provider may provide some communications services to a device already operating in accordance with a RedCap RAT by switching to a Cat-M1 data session, as opposed to denying all data services when a network is congested/overloaded. As a result, network usage may be reduced while the UE device is in a Cat-M1 mode. In addition, battery usage for a UE device may be less while in a Cat-M1 mode.
The term “network congestion” or “congestion” as used herein should be broadly construed to refer to a condition associated with a network in which a latency or delay associated with data transmissions is above a certain threshold and/or data collisions or interference is greater than a predetermined amount. The thresholds may be set by a service provider operating the network. The term “network overload” or “overload” as used herein should be broadly construed to refer to a level of traffic in a network or a portion of a network that is greater than a predetermined data traffic threshold, which may also be set by the service provider.
UE devices 110-1 and 110-N (referred to herein individually as UE device or UE 110, and collectively as UE devices or UEs 110) may include any computing device, such as a personal computer (PC), a laptop computer, a server, a tablet computer, a notebook, a Chromebook®, 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, any type of mobile computer device or system, a game playing device, a music playing device, a home appliance device, a home monitoring device, a virtualized system, a wearable device (e.g., a wrist watch, glasses, etc.), an Internet of Things (IoT) device, a Category M1 (Cat-M1) device, a machine type communication (MTC) device, etc., that includes communication functionality. In an exemplary implementation, some UE devices 110 may support both RedCap communications and Cat-M1 communications, as described in detail below.
UE device 110-1 may connect to access network 120 via wireless station 122-1 and UE device 110-N may connect to access network 120 via wireless station 122-N. UE devices 110 may also connect to other devices in environment 100 via other techniques, such as wired, wireless, optical connections or a combination of these techniques. UE device 110 and a person that may be associated with UE device 110 (e.g., the party holding or using UE device 110) may be referred to collectively as UE device 110 or UE 110 in the description below.
Access network 120, also referred to herein as radio access network (RAN) 120, may provide access to core network 130 for wireless devices, such as UE devices 110. Access network 120 may enable UE device 110 to connect to core network 130 for Internet access, non-Internet Protocol (IP) data delivery, cloud computing, mobile telephone service, Short Message Service (SMS) message service, Multimedia Message Service (MMS) message service, and/or other types of data services. Access network 120 may provide access to core network 130, a service or application layer network, a cloud network, a multi-access edge computing (MEC) network, a fog network, etc. Furthermore, access network 120 may enable a device in core network 130 to exchange data with UE device 110 using a non-IP data delivery method such as Data over Non-Access Stratum (DoNAS).
Access network 120 may also include a Fifth Generation (5G) access network or another advanced network, such as a Fourth Generation (4G) Long Term Evolution (LTE) access network. For example, access network 120 may include the functionality of a 5G network, such as 5G Radio Access Network (RAN) communicating via mmWave technology, a 5G RAN communicating via C-band technology or other types of 5G networks. Access network 120 may also include a 4G RAN.
Access network 120 may also include: support for advanced or massive multiple-input and multiple-output (MIMO) antenna configurations (e.g., an 8×8 antenna configuration, a 16×16 antenna configuration, a 256×256 antenna configuration, etc.); support for cooperative MIMO (CO-MIMO) configurations; support for carrier aggregation; relay stations; Heterogeneous Networks (HetNets) of overlapping small cells and macrocells; Self-Organizing Network (SON) functionality; machine type communication (MTC) functionality, such as 1.4 MHz wide enhanced MTC (eMTC) channels (also referred to as Cat-M1), Low Power Wide Area (LPWA) technology such as Narrow Band (NB) IoT (NB-IoT) technology, and/or other types of MTC technology; and/or other types of 5G functionality.
Wireless stations 122 (referred to collectively as wireless stations 122 and individually as wireless station 122) may be included in access network 120. Each wireless station 122 may service a number of UE devices 110 and/or other user devices when the particular UE device 110 is within radio frequency range of wireless station 122. In one implementation, wireless station 122 may include 5G base station (e.g., a next generation NodeB (gNB)) that includes one or more radio frequency (RF) transceivers. For example, wireless station 122 may include three RF transceivers and each RF transceiver may service a 120 degree sector of a 360 degree field of view. Each RF transceiver may include or be coupled to an antenna array. The antenna array may include an array of controllable antenna elements configured to send and receive 5G new radio (NR) wireless signals via one or more antenna beams. In other implementations, wireless station 122 may also include a 4G base station (e.g., an evolved NodeB (eNB)) or a 6G base station that communicates wirelessly with UE devices 110 located within the radio frequency range of wireless station 122.
Core network 130 may include one or more wired, wireless and/or optical networks that are capable of receiving and transmitting data, voice and/or video signals. In an exemplary implementation, core network 130 may be associated with a telecommunications service provider (e.g., a service provider providing cellular wireless communication services and wired communication services) and may manage communication sessions of UE devices 110 connecting to core network 130 via access network 120. Core network 130 may include one or multiple networks of different types and technologies. For example, core network 130 may be implemented to include a next generation core (NGC) network for a 5G network, an Evolved Packet Core (EPC) of an LTE or LTE Advanced network, a sixth generation (6G) network, and/or a legacy core network. Core network 130 may provide packet-switched services and wireless IP connectivity to various components in environment 100, such as UE devices 110, to provide, for example, data, voice, and/or multimedia services.
Core network 130 may include various network devices 140. Depending on the implementation, network devices 140 may include 5G core network components or network functions (NFs) (e.g., a User Plane Function (UPF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a Unified Data Management (UDM) function, a Unified Data Repository (UDR), a Policy Control Function (PCF), a network data analytics function (NWDAF), a Charging Function (CHF), a network exposure function (NEF), an application function (AF), etc.), 4G core network components (e.g., a Serving Gateway (SGW), a Packet data network Gateway (PGW), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), a Policy Charging and Rules Function (PCRF) etc.), or another type of core network components (e.g., future 6G network components). In other implementation, network devices 140 may include combined 4G and 5G functionality, such as a session management function with PGW-control plane (SMF+PGW−C) and a user plane function with PGW-user plane (UPF+PGW−U).
Data network 150 may include, for example, a packet data network. In an exemplary implementation, UE device 110 may connect to data network 150 via core network 130. Data network 150 may also include and/or be connected to a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an autonomous system (AS) on the Internet, an optical network, a cable television network, a satellite network, a wireless network, an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), an intranet, or a combination of networks.
The exemplary configuration illustrated in
Various functions are described below as being performed by particular components in environment 100. 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.
AMF 142 may perform registration management, connection management, reachability management, mobility management, lawful intercepts, Short Message Service (SMS) transport between UE device 110 and other network functions, session management messages transport between UE device 110 and an SMF (not shown), access authentication and authorization, location services management, functionality to support non-3GPP access networks, and/or other types of management processes. In exemplary implementations, AMF 142 may obtain information from other devices, such as NWDAF 144, to obtain network load information. AMF 142 may also obtain information from UDM/UDR 146 to determine whether a UE device 110 is a dual capability device, such as a device that supports both RedCap and Cat-M1 communications, as described in detail below.
NWDAF 144 may receive and/or collect analytics information associated with RAN 120 and/or core network 130. For example, NWDAF 144 may collect accessibility Key Performance Indicators (KPIs) (e.g., a Radio Resource Control (RRC) connection setup success rate, a Radio Access Bearer (RAB) success rate, etc.), retainability KPIs (e.g., a call drop rate, etc.), mobility KPIs (e.g., a handover success rate, etc.), service integrity KPIs (e.g., downlink average throughput, downlink maximum throughput, uplink average throughput, uplink maximum throughput, etc.), utilization KPIs (e.g., resource block utilization rate, transmission time interval (TTI), average processor load, etc.), availability KPIs (e.g., radio network unavailability rate, etc.), traffic KPIs (e.g., downlink traffic volume, uplink traffic volume, average number of users, maximum number of users, a number of voice bearers, a number of video bearers, etc.), response time KPIs (e.g., latency, packet arrival time, etc.), and/or other types of wireless network KPIs. NWDAF 144 may receive the KPIs from devices in RAN 120 and/or third party applications that monitor RAN 120 and/or core network 130. In an exemplary implementation, NWDAF 144 may continuously update the KPIs and provide network load information to AMF 142, as described in detail below.
UDM/UDR 146, shown as a single device in
Environment 100 illustrated in
Processor 320 may include one or more processors, microprocessors, or processing logic that may interpret and execute instructions. Memory 330 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 320. Memory 330 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 320. Memory 330 may further include a solid state drive (SSD). Memory 330 may also include a magnetic and/or optical recording medium (e.g., a hard disk) and its corresponding drive.
Input device 340 may include a mechanism that permits a user to input information, such as a keypad, a keyboard, a mouse, a pen, a microphone, a touch screen, voice recognition and/or biometric mechanisms, etc. Output device 350 may include a mechanism that outputs information to the user, including a display (e.g., a liquid crystal display (LCD)), a speaker, etc. In some implementations, device 300 may include a touch screen display may act as both an input device 240 and an output device 350.
Communication interface 360 may include one or more transceivers that device 300 uses to communicate with other devices via wired, wireless or optical mechanisms. For example, communication interface 360 may include one or more radio frequency (RF) transmitters, receivers and/or transceivers and one or more antennas for transmitting and receiving RF data. Communication interface 360 may also include a modem or an Ethernet interface to a LAN or other mechanisms for communicating with elements in a network.
In an exemplary implementation, device 300 performs operations in response to processor 320 executing sequences of instructions contained in a computer-readable medium, such as memory 330. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into memory 330 from another computer-readable medium (e.g., a hard disk drive (HDD), SSD, etc.), or from another device via communication interface 360. 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.
Assume that UE 110-1 transmits a registration request for a connection and wireless station 122-1 in RAN 120 receives the registration request (block 420;
AMF 142 may receive the registration request and perform authentication associated with registering UE 110-1. For example, AMF 142 may determine if UE 110-1 is authorized to establish a data session, such as whether UE 110-1 is associated with a subscriber to core network 130. For this example, assume that UE 110-1 is authenticated.
AMF 142 may also send a message to NWDAF 144 to obtain network loading information (block 430;
If, however, AMF 142 determines that the network is congested and/or or overloaded and that UE 110-1 is located in a RedCap UE service area (block 440-yes), AMF 142 may determine whether the subscriber profile of UE 110-1 indicates that UE 110-1 supports both RedCap and Cat-M1 communications (block 460).
For example, AMF 142 may access or send a request to UDM/UDR 146 to determine if the subscriber profile for UE 110-1 indicates that UE 110-1 supports both RedCap and Cat-M1 communications (
If AMF 142 determines that UE 110-1 supports RedCap, but does not support Cat-M1 communications (block 460-no), AMF 142 and/or other elements in core network 130 may establish, for example, a RedCap data session (block 470). For example, AMF 142 may transmit a registration accept message to UE 110-1 indicating that a RedCap data session will be established.
If, however, AMF 142 determines that UE 110-1 supports both RedCap and Cat-M1 communications (block 460-yes), AMF 142 may signal UE 110-1 to re-register as a Cat-M1 device (block 480;
AMF 142 may continue to monitor network load conditions. For example, AMF 142 may periodically signal NWDAF 144 (e.g., every hour or less, every two hours, every four hours, etc.) to obtain network loading information (
In this manner, AMF 142 may dynamically signal UE devices 110 to register using a first RAT, such as RedCap, and re-register using another RAT, such as Cat-M1, based on the network load conditions. In some implementations, AMF 142 may consider data usage by a UE 110 when determining whether to signal the UE 110 to re-register as a Cat-M1 device. For example, if the data usage of UE 110-1 is very low, AMF 142 may not instruct UE 110-1 to switch to a Cat-M1 data session when the network is congested and/or overloaded. By not switching a data session when data usage by a UE 110 is low, additional signaling may be reduced. For example, signaling associated with re-registering may be eliminated.
Implementations have been described above with respect to a UE device 110 registering for a data session as a RedCap device and core network elements dynamically changing the type of data session to a Cat-M1 data session based on network load conditions. In other implementations, core network elements may dynamically switch between other types of data sessions or RATs based on network load conditions, where a first type of data session has higher bandwidth and/or throughput requirements than a second type of data session.
In addition, in some situations, a wireless station 122, such as a gNB, may not support a Cat-M1 RAT. In such situations, an LTE device, such as a mobility management entity (MME) may interface with an eNB wireless station 122 to instruct a UE 110 to re-register as a Cat-M1 device.
Implementations described herein provide for dynamically switching types of data sessions for UE devices 110 based on network load conditions, such as switching from a RedCap data session to a Cat-M1 data session. In this manner, lower bandwidth and/or data usage requirements for a Cat-M1 data session may help reduce network loading when a network is congested or overloaded. In addition, switching to a Cat-M1 data session may reduce battery usage on a UE device 110. Further, by switching back to a RedCap data session based on monitored network load conditions, UE device 110 may obtain higher bandwidth services and/or data usage when network conditions are no longer overloaded/congested.
The foregoing description of example 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.
In addition, features have been described with respect to managing types of data sessions/RATs using elements in core network 130. In other implementations, similar processing may be performed in other portions of environment 100, such as in a Multi-access Edge Computing (MEC) platform located, for example, between access network 120 and core network 130. In still other implementations, a number of AMFs 142, NWDAFs 144 and UDM/UDRs 146 may be distributed in environment 100 to perform data session management.
Further, features have been described above with respect to an AMF 142 requesting information from a UDM/UDR 144 and/or NWDAF 146. In other implementations, AMF 142 may subscribe to event information, such as KPIs and/or other information from UDM/UDR 144 and/or NWDAF 146. In such implementations, AMF 142 may obtain the needed information without having to request such information.
Still further, while series of acts have been described with respect to
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.
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 may be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as may be appropriate for the situation and type of information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.
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.
