Mobility signaling load reduction

Abstract

The present invention discloses mobility signaling load reduction. Methods, systems, and devices can help reduce the signaling load that occurs based on paging and handover. Methods, systems, and devices can be based on UE status, radio access network registration area (RRA) or tracking / paging areas with different architectural approaches (e.g., hierarchical or distributed), dynamic RRA management, radio access network-based paging, and radio access network-based user equipment (UE) mobility management.

Description

[0001] This application is a divisional application of the invention patent application with application date of April 20, 2017, application number 201780037883.5, and invention name “Mobility Signaling Load Reduction”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 325,450, filed on April 20, 2016, entitled “Mobility Signaling Load Reduction,” the contents of which are incorporated herein by reference. Background Art

[0004] RRC protocol status : In LTE, the terminal can be in two different states, such as Figure 1 As shown in, RRC_CONNECTED and RRC_IDLE.

[0005] In RRC_CONNECTED, an RRC context exists. The cell to which the UE belongs is known, and the identity of the UE (Cell Radio Network Temporary Identifier (C-RNTI)) for signaling purposes between the UE and the network has been configured. RRC_CONNECTED is intended for data transmission to / from the UE.

[0006] In RRC_IDLE, there is no RRC context in the Radio Access Network (RAN) and the UE does not belong to a specific cell. No data transmission occurs in RRC_IDLE. A UE in RRC_IDLE monitors the paging channel to detect incoming calls and changes to system information. Discontinuous Reception (DRX) is used to save UE power. When moving to RRC_CONNECTED, an RRC context needs to be established in both the RAN and the UE.

[0007] Figure 2 An overview of the RRC states in E-UTRA is provided, wherein the mobility support between E-UTRAN, UTRAN and GERAN is illustrated.

[0008] UE mobility states (3GPP TS 36.304 User Equipment (UE) procedures in idle mode (Release 13) .V13.0.0): In addition to the normal mobility state, the high mobility and medium mobility states may be applied if the parameters (TCRmax, NCR_H, NCR_M and TCRmaxHyst) are sent in the system information broadcast of the serving cell. NOTE: These states should be considered as sub-states related to mobility in the RRC_IDLE state. NCR M specifies the maximum number of cell reselections to enter the medium mobility state. NCR_H specifies the maximum number of cell reselections to enter the high mobility state. TCRmax specifies the duration for evaluating the allowed large number of cell reselections. TCRmaxHyst specifies an additional time period before the UE can enter the normal mobility state.

[0009] The state detection criteria include a medium mobility state criterion or a high mobility state criterion. Medium mobility state criterion: if the number of cell reselections during the time period TCRmax exceeds NCR M but does not exceed NCR_H. High mobility state criterion: if the number of cell reselections during the time period TCRmax exceeds NCR_H. If the same cell is reselected after another reselection, the UE does not count consecutive reselections between the same two cells into the mobility state detection criteria.

[0010] State Transition: The UE shall: 1) enter the High Mobility State if criteria for a High Mobility State are detected; or 2) enter the Medium Mobility State if criteria for a Medium Mobility State are detected; or 3) enter the Normal Mobility State if criteria for a Medium or High Mobility State are not detected during the time period TCRmaxHyst.

[0011] NAS Protocol Details of the NAS protocol for LTE are described in 3GPP TS 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 13), V13.6.1 and 3GPP TS 24.302 Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3 (Release 13), V13.5.0. An overview is provided below.

[0012] The Non-Access Stratum (NAS) forms the highest layer of the control plane between the UE and the MME at the radio interface over the reference point Uu. The main functions of the protocols that are part of the NAS are: supporting the mobility of the User Equipment (UE); and supporting the session management procedures that establish and maintain the IP connection between the UE and the Packet Data Network Gateway (PDN GW).

[0013] Likewise, NAS consists of two separate protocols carried over direct signaling transport between the UE and, for example, the MME in the core network (CN). The content of the NAS layer protocols is invisible to the Radio Access Network (RAN) nodes (e.g., eNodeB), and the RAN nodes are not involved in these transactions by any other means except transporting messages and providing some additional transport layer indications and messages in some cases. The NAS layer protocols include EPS Mobility Management (EMM) and EPS Session Management (ESM).

[0014] EPS Mobility Management (EMM): The EMM protocol is responsible for handling UE mobility within the system. The EMM protocol includes functionality for attaching to and detaching from a network and performing location updates between the two. This is called Tracking Area Update (TAU) and occurs in idle mode. Note that switching in connected mode is handled by lower layer protocols, but the EMM layer does include functionality for reactivating the UE from idle mode. The UE-initiated situation is called a service request, while paging represents a network-initiated situation. Authentication and protection of the UE identity, i.e., assigning a temporary identity (Globally Unique Temporary UE Identity (GUTI)) to the UE is also part of the EMM layer as well as controlling NAS layer security functions, performing encryption and integrity protection. Examples of EMM procedures include: an attach procedure (for registration), a detach procedure, a service request procedure, a tracking area update procedure, a connection suspension, a connection recovery procedure, and a UE reachability procedure. NAS security is an additional function that NAS provides services to the NAS protocol, for example, integrity protection and encryption of NAS signaling messages.

[0015] EPS Session Management (ESM): This protocol can be used to handle bearer management between the UE and the MME and is also used for E-UTRAN bearer management procedures. Note that if the bearer context is already available in the network and the E-UTRAN procedures can be run immediately, the ESM procedures are not intended to be used. This would be the case, for example, when the UE has already been signaled using the operator-attached application function in the network and the relevant information has been made available through the PCRF.

[0016] exist Figure 3 The overall Evolved Packet System control plane protocol stack is depicted in FIG.

[0017] Used for the connection between EPS mobility management and EPS session management protocols: During the EPS attach procedure, the network may activate the default EPS bearer context (i.e., if the UE requested a PDN connection in the attach request). In addition, the network may activate one or more dedicated EPS bearer contexts in parallel for PDN connections of IP PDN type. To this end, an EPS session management message for the default EPS bearer context activation is transmitted in an information element in the EPS mobility management message. In this case, the UE and the network perform the attach procedure, the default EPS bearer context activation procedure, and the dedicated EPS bearer context activation procedure in parallel. The UE and the network complete the combined default EPS bearer context activation procedure and the attach procedure before completing the dedicated EPS bearer context activation procedure. The success of the attach procedure depends on the success of the default EPS bearer context activation procedure. If the attach procedure fails, the ESM procedure will also fail. In addition to the attach procedure and the service request procedure, the MME will also suspend the transmission of ESM messages during the EMM procedure. During the service request procedure, the MME will also suspend the transmission of ESM messages. In addition to the attach procedure, the UE will also suspend the transmission of ESM messages during the EMM procedure.

[0018] NAS protocol status :exist Figure 4 The main states of the EMM sublayer in the UE are shown in FIG. Figure 5 The diagram shows the EMM sublayer status in the MME. Figure 6 The ESM sublayer status in the UE is shown in FIG. Figure 7 The ESM sublayer status in MME is shown in FIG.

[0019] Cell selection and reselection : Section 5.2 of 3GPP TS 36.304 describes the cell selection and reselection procedures performed by the UE in RRC_IDLE. Figure 8 is a high-level flow chart illustrating the cell selection and reselection process performed by the UE in RRC_IDLE. This process is entered whenever a new PLMN is selected or if a suitable cell cannot be found after exiting RRC_CONNECTED. After selecting a cell, the UE camps on the cell and performs the tasks defined in sections 5.2.6 or 5.2.9 of 3GPP TS 36.304, depending on whether the UE is already camped on a suitable cell or an acceptable cell, respectively. As defined in section 5.2.3.2 of 3GPP TS 36.304, while the UE camps on a cell, the UE periodically searches for a better cell according to the cell reselection criteria.

[0020] The cell reselection evaluation procedure is performed according to an internal UE trigger or when the information about the BCCH used for the cell reselection evaluation procedure has been modified. After reselecting a cell, the UE in RRC_IDLE needs to apply the system information acquisition procedure as defined in section 5.2.3 of 3GPP TS 36.331 to obtain the system information of the new serving cell.

[0021] IMT 2020 : It is envisioned that IMT in 2020 and beyond will extend and support a wide range of use cases and applications that will continue to exceed the current IMT. In addition, a wide range of capabilities will be closely integrated with these different expected use cases and applications of IMT in 2020 and beyond. The use case range of IMT in 2020 and beyond includes eMBB, URLLC, mMTC, and NEO.

[0022] eMBB (enhanced mobile broadband)

[0023] Macro cells and small cells

[0024] ●1 ms latency (air interface)

[0025] ● Spectrum assigned under WRC-15 will result in up to 8 Gbps of additional throughput

[0026] ●Support high mobility

[0027] URLLC (Ultra-Reliable Low-Latency Communications)

[0028] Low to medium data rates (50 kilobits per second to 10 megabits per second)

[0029] ●<1ms air interface latency

[0030] ● 9.999 percent reliability and availability

[0031] ●Low connection establishment latency

[0032] ●0 to 500 km / h mobility

[0033] mMTC (massive machine type communications)

[0034] Low data rates (1 to 100 kbps)

[0035] ●High density of devices (up to 200,000 per square kilometer)

[0036] ●Delay: A few seconds to a few hours

[0037] ●Low power: up to 15 years battery life ●Asynchronous access

[0038] Network Operations (NEO) addresses topics such as network slicing, routing, migration and interworking, energy conservation, etc.

[0039] The following deployment scenarios are considered primarily for eMBB (see 3GPP TR 38.913 Study on scenarios and requirements for next generation access technologies; (Release 14), VO.2.0). Deployment scenarios for mMTC and URLLC are still under study; however, the following eMBB deployment scenarios may also be applicable to mMTC and URLLC. For eMBB, the following five deployment scenarios are being considered: indoor hotspot, dense urban, rural, urban macrocell, and high-speed.

[0040] Indoor hotspot: This deployment scenario focuses on smaller coverage of each site / TRP (transmission and reception point) and high user throughput or user density in buildings. The key features of this deployment scenario are high capacity, high user density and consistent user experience indoors.

[0041] Dense Urban: The dense urban micro-cell deployment scenario focuses on macro TRPs with or without micro TRPs and high user density and traffic loads in city centers and dense urban areas. The key features of this deployment scenario are high traffic load, outdoor and outdoor-to-indoor coverage.

[0042] Rural: This deployment scenario focuses on larger and continuous coverage. The key feature of this scenario is continuous large-area coverage that supports high-speed vehicles.

[0043] Urban macrocell: The urban macrocell deployment scenario focuses on large cells and continuous coverage. The key feature of this scenario is continuous and ubiquitous coverage in urban areas.

[0044] High speed: After 2020, there will be a growing demand for mobile services in vehicles, trains and even airplanes. While some services are a natural evolution of existing services (navigation, entertainment, etc.), some others represent entirely new scenarios, such as broadband communication services on commercial aircraft (e.g., via an onboard hub). The degree of mobility required will depend on the specific use case, with speeds greater than 500 km / h.

[0045] In addition, the following deployment scenarios have been identified specifically for the mMTC use case: Massively Connected Urban Coverage. Massively Connected Urban Coverage: The Massively Connected Urban Coverage scenario focuses on large cells and continuous coverage to provide mMTC. The key features of this scenario are continuous and ubiquitous coverage in urban areas with a very high connection density of mMTC devices. This deployment scenario is used to evaluate the KPI of connection density.

[0046] In addition, the following deployment scenarios have been identified for the UR / LL use case: Highway scenario and Urban Grid for connected cars. Highway scenario: The highway deployment scenario focuses on the scenario of vehicles traveling at high speed on highways. The main KPI evaluated in this scenario is reliability / availability at high speed / high mobility (and therefore, frequent handover operations).

[0047] Urban Grid for Connected Cars: Urban macrocell deployment scenario focuses on the scenario of highly densely deployed vehicles in urban areas. Urban macrocell deployment scenario can cover the scenario of highways introduced into the urban grid. The main KPIs evaluated in this scenario are reliability / availability / latency in high network load and high UE density scenarios.

[0048] Examples of mMTC applications : First example - Lightweight device: Lightweight device - a very simple device, e.g. no IMS client (5.1.2.1 of 3GPP TR 22.861), the device could be: For example, a smart meter. It records electricity usage, provides detailed usage reports that allow customers to rate by time of day, and provides a larger complete report to the power company every month. The power company deploys a large number of these smart meters in an apartment building, one per apartment.

[0049] Second Example—Video Surveillance with Variable Data Size: The application here is video surveillance with variable data size (5.1.2.2 of 3GPP TR 22.861). A video recorder is installed and activated on the street. The video recorder includes a camera, some onboard processing power, and the ability to send information to the traffic police. The camera records continuous video, storing the content for a period of time. The device periodically sends status updates to the traffic police indicating that traffic is proceeding smoothly.

[0050] When an accident occurs at an intersection, the device begins sending high-quality video of the accident and the ensuing traffic jam to traffic police.

[0051] Note: The network will need to be flexible to always provide efficient service to the device, regardless of whether a small or large amount of data is sent in a given transmission. An efficient system can minimize the negative impact on the battery life of the device and minimize the use of signaling resources. The same device will need to establish a connection when a large amount of data (e.g., video) needs to be transmitted.

[0052] Third Example—Warehouse Application (5.2.3.1 of 3GPP TR 22.861, Feasibility Study of New Services and Market Technology Enablement Approaches for Massive Internet of Things; Phase 1 (Release 14), V1.0.0): In this application, the coverage area is limited. Most likely, the IoT devices in a given deployment are owned by the same physical device which will range from very simple limited functionality devices to very complex sophisticated computing platforms. At the lower end of the device functionality spectrum, not all such devices may use IMS and may not need to be equipped with an IMS client, but due to sensor deployment configuration, it will still be desirable to remotely activate such devices.

[0053] Examples of UR / LL applications : First example - Industrial process control (3GPP TR 22.862 5.1.2.2): Process automation requires communication for monitoring and open-loop control applications, field-level process monitoring and tracking operations within industrial plants. Fig. 9 As depicted in Figure 1, a large number of sensors (approximately 10,000) distributed in accordance with the factory forward measurement data process the controller periodically or on an event-driven basis. This use case requires support for a large number of sensor devices (10,000) per factory and highly reliable transmission (packet loss rate <10 to 5). Further, since most sensor devices are battery powered, the target battery life is several years while providing measurement updates every few seconds, so power consumption is critical. A typical process control application supports downstream and upstream flows consisting of separate transactions between the process controller and the sensor / actuator. The process controller resides in an in-plant network. The network is interconnected via a base station with a wireless (mesh) network hosting the sensor / actuator devices. Typically, each transaction uses less than 100 bytes. For service flows initiated by the controller and the sensor / actuator, upstream and downstream transactions usually occur asynchronously.

[0054] Second example - local UAV collaboration and connectivity (3GPP TR 22.862, 5.1.2.4): Fig.10 As illustrated in FIG, unmanned aerial vehicles (UAVs) can collaborate to act as a network of mobile sensors and actuators to perform tasks in uncertain and dynamic environments when controlled by a single user. When a group of drones are deployed, the accuracy of the sensing task is improved because there are multiple vantage points using multiple sensors. Examples of uses for deploying a group of drones include: searching for intruders or suspects, continuously monitoring natural disasters, performing autonomous mapping, and collaboratively manipulating objects (e.g., picking up corners of a network), depicting how communication occurs in UAV local vehicle collaboration and connectivity. Both node-to-node and UAV-to-mobile network links are required.

[0055] Examples of eMBB applications: First example - office scenario with high data rate applications (5.1.2 of 3GPP TR 22.862): In an office scenario requiring high data rates, users use real-time video conferencing and frequently upload and download data from the company's servers, and the sizes of the servers vary. Productivity depends on the efficiency of the system response time and reliability. Depending on the time of day (e.g., morning, evening, weekdays vs. weekends, etc.) and location (e.g., shopping mall, city center street), users expect to upload and download multimedia traffic to the Internet and conduct D2D communications.

[0056] Second example - office scenario with higher connection density (5.2.1 of 3GPP TR 22.862): This series covers scenarios with system requirements for data that carry a large amount of data traffic (traffic density) or a large number of connections (connection density) per area. A typical scenario enables users to upload and download very large amounts of data from a server, handle high-resolution real-time video conferencing, etc., while the end users can be indoors or outdoors and in densely populated areas, but do not require high mobility (i.e., up to 60 km / h in a city vehicle). In hotspot scenarios with high user density, there is a large volume and high capacity of multimedia traffic uploaded and downloaded to the Internet, depending on the time of day (e.g., morning, evening, weekdays vs. weekends, etc.) and location (e.g., pedestrians in a shopping mall, city center street, stadium, users on a bus in a dense city center). Users can be indoors or outdoors. At the same time, when users are indoors, the vehicle is stationary or moving; however, when users are outdoors, the vehicle can move slowly up to 60 km / h. Mobile broadband scenarios should be provided even when the terminal enters areas with high traffic density.

[0057] 5G Requirements : 3GPP TR 38.913 defines the scenarios and requirements for next generation access technologies. The following is an excerpt from the Key Performance Indicators (KPI) section of 3GPP TR 38.913 that imposes new requirements related to the topic of optical signaling connections.

[0058] 7.17 Connection density and the need to reduce potential signaling storms: Connection density refers to the total number of devices per unit area (per square kilometer) that meet a specific QoS. The QoS qualification should take into account the amount of data or access requests generated in a time t_gen that can be sent or received with a probability of x percent in a given time t_sendrx. In an urban environment, the connection density target should be 1,000,000 devices / square kilometer. 3GPP should develop standards to achieve the required connection density with high connection efficiency (measured as the number of devices supported per TRP per unit frequency resource)

[0059] 7.4 Control Plane Latency: Control plane latency is the time to move from a battery efficient state (e.g., IDLE) to the start of continuous data transmission (e.g., ACTIVE). The target for control plane latency should be [10 milliseconds].

[0060] 7.11 UE Battery Life: The UE battery life can be assessed by measuring the battery life of the UE without the need for recharging. For mMTC, the UE battery life in extreme coverage will be based on a mobile originated data transmission activity consisting of [200 bytes] UL per day followed by [20 bytes] DL from [tbd] dB MCL, assuming a stored energy capacity of [5 Wh]. The target for UE battery life should be [10 years].

[0061] 7.19 Network Energy Efficiency: The capability is to minimize RAN energy consumption while providing better regional traffic capacity. The baseline qualitative KPI and quantitative KPI is FFS.

[0062] 7.1 Peak data rate: The peak data rate is the highest theoretical data rate of data bits received assuming error-free conditions assignable to a single mobile station when all assignable radio resources for the corresponding link direction are utilized (i.e., excluding radio resources used for physical layer synchronization, reference signals or pilots, guard bands and guard times). For the downlink, the target for the peak data rate should be [20 Gbits per second] and for the uplink, it should be [10 Gbits per second].

[0063] Network Slicing : Fig.11 A high-level illustration of the concept of network slicing is provided. A network slice consists of a set of logical network functions that support the communication service requirements of (multiple) specific use cases. It should be possible to steer terminals to a selected slice in a way that meets operator or user needs (e.g. based on subscription or terminal type). Network slicing primarily aims to partition the core network, but does not exclude that the Radio Access Network (RAN) may require specific functions to support multiple slices or even partition resources for different network slices. See 3GPP TR 22.89—Feasibility study on new service and market technology implementation approaches (smarter); Phase 1 (Release 14) V-1.1.0. (example).

[0064] Potential network slicing service requirements defined in 3GPP TR 22.891: 1) The 3GPP system should allow operators to compose network slices, i.e., independent sets of network functions (e.g., possibly from different vendors) and parameter configurations, for example, for hosting multiple enterprises or mobile virtual network operators (MVNOs); 2) Operators should be able to dynamically create network slices to form complete, autonomous and fully operational networks customized to meet different market scenarios; 3) The 3GPP system should be able to identify certain terminals and subscribers to be associated with a specific network slice; 4) The 3GPP system should be able to enable UEs to obtain services through a specific network slice, for example based on subscription or terminal type.

[0065] Potential network slicing operational requirements defined in 3GPP TR 22.891 include:

[0066] ● Operators should be able to create and manage network slices that meet the required standards for different market scenarios.

[0067] ● Operators should be able to operate different network slices in parallel with isolation, for example, preventing data communications in one slice from negatively impacting services in other slices.

[0068] ●The 3GPP system should have the ability to comply with service-specific security assurance requirements within a single network slice rather than the entire network.

[0069] ●The 3GPP system should have the capability to provide a level of isolation between network slices, which would limit potential network attacks to a single network slice.

[0070] ● Operators should be able to authorize third parties to create and manage network slice configurations (e.g., scale slices) via appropriate application programming interfaces (APIs) within the limits set by the network operator.

[0071] ●The 3GPP system should support the resilience of network slices in terms of capacity without affecting the services of that slice or other slices.

[0072] ●The 3GPP system should be able to change slices with minimal impact on ongoing subscriber services served by other slices, i.e., adding new network slices, removing existing network slices, or updating network slice functionality or configuration.

[0073] ●The 3GPP system should be able to support end-to-end (E2E) (e.g., RAN, Core Network (CN)) resource management for network slices.

[0074] Proposal for small data transfers :As in Fig.12As shown in, the RRC inactive state and the RRC connected state have been proposed in S2-161323. In S2-161324, as shown in Fig.13 A mobility framework is proposed as shown in the figure.

[0075] Relationship of requirements to current state of technology :The current design for LTE (Release 12) is not efficient in transitioning to the RRC-CONNECTED state so that small amounts of data can be transmitted, or is not efficient in scalability for supporting a large number of devices that typically generate small amounts of data. For frequent small burst transmissions, the device wakes up every few minutes and sends data. For normal procedures, the UE will need to follow the RACH procedure and then establish signaling radio bearers (through the RRC connection establishment procedure) and data radio bearers (through the RRC connection reconfiguration procedure). As in Fig.14 As shown in the overall conventional process diagram in Figure 2, the signaling overhead is large when only a small amount of data is considered to be transmitted in the uplink. This situation is expected to be the worst depending on the different use cases and traffic profiles of the 5G system.

[0076] One of the key issues identified in the Release 13 study project obtained in 3GPP TR 23.720 is: supporting infrequent, small data transmissions for cellular IoT. This key issue aims to provide solutions that support efficient handling of infrequent, small data transmissions to enable ultra-low complexity, power-constrained, and low data rate 'Internet of Things' devices (referred to as CIoT devices). In 5G systems, the number of these devices is expected to increase exponentially, but the data size of each device and each data transmission event will remain small. The infrequent, small data traffic characteristics of MTC applications (as described in Annex E of 3GPP TR 45.820 Cellular System Support for Ultra-Low Complexity and Low Throughput Internet of Things (CIoT) (Release 13), V13.1.0) can lead to inefficient use of resources in 3GPP systems. Another key issue identified in the study of 3GPP TR 23.720 on architectural enhancements for cellular IoT V13.0.0 is: providing effective support for tracking devices by using small data transmissions for cellular IoT. This key problem aims to support solutions for ultra-low complexity, power-constrained, and low data rate 'Internet of Things' devices (referred to as CIoT devices) by efficiently processing tracking devices using small data transmissions. It should be noted that excessive signaling also causes additional latency and additional power consumption.

[0077] Release 13 LTE has specified two solutions to further reduce the signaling overhead for small data transmissions. One solution, known as the Control Plane (CP) solution (Solution 2 in 3GPP TR 23.720), transmits user data between the UE and the core network as NAS Protocol Data Units (PDUs). The second solution (Solution 18 in 3GPP GP 23.720) allows the RRC connection to be suspended and resumed at a later time; minimizing the need to go through the full signaling process of IDLE to CONNECTED state transition. This solution is applicable to both normal LTE UEs and IOT UEs, and is based on enhancements to the IDLE state so that the RRC connection can be resumed, while avoiding the need to establish the RRC connection again when the UE returns from IDLE, assuming that most of the time, the UE returns to a node with a stored RRC context. In Fig.15 and Fig.16 The process is illustrated in FIG.

[0078] These version 13 solutions are still not optimal and have many drawbacks:

[0079] ●After suspending the RRC connection,

[0080] o The UE transitions to NAS EMC-IDLE state and therefore no longer has a NAS signaling connection. The S1 connection is also released. This means that overhead is signaled over the air, between the Radio Access Network (RAN) and the Core Network (CN), and within the CN (e.g., between the MME and SGW and between the SGW and PGW) when the RRC connection is restored.

[0081] ○ The UE also transitions to the RRC-IDLE state and is assumed to perform a complete random access procedure before the RRC connection is restored. It is still necessary to exchange RRC Connection Resumption / RRC Connection Resumption Complete messages with the eNB to restore the RRC connection.

[0082] o Storing only partial access stratum (AS) context which will incur additional signaling overhead to reconfigure the UE after RRC recovery.

[0083] ○ Storing AS context in eNB and non-access stratum context in core network (MME, SGW and PGW) implies increasing storage capacity on both radio access network and core network. Due to the expected density of one million mMTC devices per square kilometer, the number of devices in suspended RRC-CONNECTED state per core network node (e.g., MME) and per cell is expected to be quite large in 5G system compared to existing LTE system, even assuming dense deployment of cells and core network nodes, since there are non-negligible CapEx and OpEx deployment costs for operators. In the context of 5G system, a solution that relies mainly on context storage of a large number of devices in the network may not be cost-effective.

[0084] ○ Support for mobility is limited, i.e. UE context retrieval is only possible if the X2 interface between the source eNB and the target eNB is available. If no X2 interface is available, the signaling radio bearers (SRBs) and data radio bearers (DRBs) have to be reestablished by using conventional procedures. Furthermore, the context stored in the source eNB or even in the core network nodes has to be cleared by some proprietary implementation means.

[0085] ● For the first access or any time the UE does not have a stored context, the traditional RRC connection establishment procedure (request / response) is assumed to be used. It should also be noted that the traditional RRC connection establishment procedure is a unicast transmission based procedure. All of this leads to scalability issues in the context of large-scale mMTC deployment scenarios expected for 5G systems.

[0086] ● This solution does not allow for effective control of UE state transitions by the RAN (e.g., eNB) and does not take into account traffic mix and UE mobility due to UE tracking based on NAS Tracking Area (TA) and UE paging based on NASDRX configuration. This solution suffers from the same limitations as the existing approach in previous 3GPP releases, where controlling UE state transitions between idle mode and connected mode is based on the use of inactivity timers in the eNB. In this approach, the eNB monitors traffic activity by a proprietary approach. When there is no traffic activity according to the proprietary configuration and threshold settings for traffic activity detection, the eNB makes a request to the core network, specifically, the eNB releases the S1 signaling connection. The eNB also releases the RRC signaling connection. The MME and UE also release the NAS signaling connection. The effectiveness of this approach depends on the eNB's ability to clearly configure traffic activity detection and set the inactivity timer to the correct value taking into account various factors such as traffic type, UE mobility level, target user experience level, etc. In addition, in an ideal solution, the inactivity timer value should be adjusted dynamically. It has been observed in LTE networks that the inactivity timer is often configured to be quite short (as low as 10 to 20 seconds), which results in a large number of transitions from RRC_IDLE to RRC_CONNECTED. Considering that most RRC connections in LTE transfer less than 1 kilobyte of data and then move back to RRC_IDLE, this state transition is quite expensive in terms of signaling. Likewise, the non-optimal configuration of Release 13 NB-IOT solutions will limit the applicability of these solutions, and even the limited expected signaling overhead reduction achieved using this solution may not be achieved.

[0087] Next generation wireless communication systems are expected to support a variety of use cases, from fully mobile devices to stationary IOT or fixed wireless broadband devices, with different requirements. The traffic patterns associated with many use cases are expected to consist of short or long bursts of data traffic, with different waiting period lengths between the bursts of data traffic.

[0088] The shortcomings of the Release 13 NB-IOT solution listed above highlight the need for further enhancements to the handling of small and infrequent data transmissions, not only for stationary NB-IoT / mMTC devices, but for all UEs that are mobile. More specifically: 1) The current signaling overhead for small and infrequent data transmissions is still too high and needs to be further reduced to meet the 5G requirements of reduced signaling storms and 3 times higher spectrum efficiency than Advanced IMT; 2) The increased storage for AS and NAS contexts in the network implies increased network CapEx and OpEx, which negatively impacts the requirements to minimize 5G network deployment and operating costs; 3) Excessive signaling also causes additional latency. The current RRC connection establishment latency (i.e., 120 ms for mobile originated calls and 280 ms for mobile terminated calls, see RP-160301) still needs to be further reduced to improve the end-user experience and meet the 5G requirements on control plane latency, which may be 10 ms or less for some use cases (e.g., ultra-reliable and low latency applications); and 4) Excessive signaling will also result in additional UE power consumption and additional network capacity consumption, and will negatively impact the system's ability to meet the 10-year UE battery lifetime requirement defined in Section 7.11 of 3GPP TR 38.913 and the network energy efficiency requirements defined in Section 7.19 of GPP TR 38.913.

[0089] New proposals for enhancements to small data transfer handling are emerging, specifically aimed at further reducing signaling overhead and addressing the shortcomings of the Release 13 NB-IOT solution identified above. Various high-level solution ideas have been proposed in the context of 5G discussions, for example, in 3GPP System Aspects Working Group 2 (SA WG2 or simply SA2), high-level ideas proposed for further exploration include: 1) Further reduction of NAS signaling and signaling to the CN over the S1 interface due to mobility and idle / active transitions by further developing the following ideas: a) Reuse of the Release 13 suspend / resume solution, where the UE context is stored when the UE is in RRC_IDLE or a new RRC-CONNECTED state based on UE controlled mobility is created, but hiding such suspend / resume state or any such new intermediate state from the core network; b) RAN initiated paging messages; and c) Use of anchor / gateway functionality in the RAN to allow context acquisition when cell reselection and data re-forwarding are performed. Other ideas include: 2) further enhancements to allow the RAN to select the best parameters, such as flexibility for the RAN to control UE-specific tracking areas that may be different from core network-based tracking areas; and 3) further enhancements to allow the RAN to select the best parameters, such as flexibility for the RAN to adjust DRX parameters applicable to lightly connected states (e.g., UE-controlled mobility connection states), for example, allowing the RAN to optimize DRX by taking into account the UE's current data QoS requirements. Summary of the invention

[0090] Disclosed herein are methods, systems, and apparatus that can help reduce the signaling load that may occur based on paging and handover. Specifically, disclosed herein are new UE states, radio access network registration areas (RRAs) or tracking / paging areas with different architectural approaches (e.g., hierarchical and distributed), dynamic RRA management, radio access network-based paging, and radio access network-based user equipment (UE) mobility management.

[0091] The purpose of providing this summary is to introduce a selection of concepts in a simplified form, which are further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to addressing any or all disadvantages mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0093] Figure 1 An exemplary RRC protocol state machine is illustrated;

[0094] Figure 2 illustrates exemplary E-UTRA states and inter-RAT mobility procedures;

[0095] Figure 3 An exemplary control plane protocol stack in EPS is illustrated;

[0096] Figure 4 illustrates an exemplary EMM main state in a UE;

[0097] Figure 5 illustrates exemplary EMM main states in an MME;

[0098] Figure 6 illustrates exemplary ESM sublayer states (overview) of EPS bearer context handling in a UE;

[0099] Figure 7 illustrates an exemplary ESM sublayer state (overview) of EPS bearer context processing in a network;

[0100] Figure 8 An exemplary flow chart of cell selection and reselection processing in RRC_IDLE is illustrated;

[0101] Fig. 9 illustrates an exemplary communication path for a service flow between a process controller and a sensor / actuator device;

[0102] Fig.10 An exemplary UAV communication path is illustrated;

[0103] Fig.11 illustrates an exemplary network slicing concept;

[0104] Fig.12 An exemplary RRC idle state, RRC inactive state, and RRC connected state are illustrated;

[0105] Fig.13 illustrates exemplary UE controlled mobility in RRC connected state;

[0106] Fig.14 An exemplary conventional process for SRB and DRB setup is illustrated;

[0107] Fig.15 An exemplary suspension of an RRC connection is illustrated;

[0108] Fig.16 illustrates an exemplary resumption of a previously suspended RRC connection (MO case);

[0109] Fig.17illustrates exemplary RRC signaling statistics collected in several live LTE networks (RP-160301);

[0110] Fig.18A illustrates exemplary new UE states and state transitions;

[0111] Fig.18B An exemplary method for a new UE state is illustrated;

[0112] Fig.19 illustrates an exemplary layered architecture without RRA overlap;

[0113] Fig. 20 illustrates an exemplary layered architecture with RRA overlap;

[0114] Fig.21 An exemplary distributed architecture without RRA overlap is illustrated;

[0115] Fig. 22 illustrates an exemplary dynamic RRA management—creating an RRA;

[0116] Fig.23 An exemplary dynamic RRA management—RRA removal is illustrated;

[0117] Fig.24 An exemplary radio access network based paging is illustrated;

[0118] Fig.25 illustrates an exemplary SRRAN initiated handover within an RRA;

[0119] Fig.26 An exemplary UE-initiated handover on RRA is illustrated;

[0120] Fig.27A An example communication system is illustrated;

[0121] Fig.27B is a block diagram of an example device or apparatus configured for wireless communications, such as, for example, a wireless transmit / receive unit (WTRU);

[0122] Fig.27C is a system diagram of a first example radio access network (RAN) and core network;

[0123] Fig.27D is a system diagram of a second example radio access network (RAN) and core network;

[0124] Fig.27E is a system diagram of a third example radio access network (RAN) and core network;

[0125] Fig.27Fis a block diagram of an exemplary computing system that may embody one or more devices in a communication network, such as certain nodes or functional entities in a RAN, a core network, a public switched telephone network (PSTN), the Internet, or other networks.

[0126] Fig.28 Exemplary displays (eg, graphical user interfaces) that may be generated based on methods and systems for mobility signaling load reduction are illustrated. DETAILED DESCRIPTION

[0127] As discussed in the background, solutions for reducing RRC connection establishment and subsequent RRC reconfiguration signaling load have been proposed in LTE Release 13 in the context of NB-IOT (e.g., Solution 2 and Solution 18), but more efficient solutions are desired. Reducing the signaling load related to mobility, as discussed herein (e.g., paging and handover), among others, can help implement a 5G system that meets the desired requirements (such as, despite a significant increase in connection density, reduced signaling load, very low control plane latency, extended UE battery life, or increased network energy) to minimize CapEx and OpEx.

[0128] Fig.17 The diagram illustrates RRC signaling statistics collected in an LTE network. As shown, wedge 201, which is an RRC connection establishment, corresponds to a signaling load of 51.4 percent. While wedge 202 (paging) accounts for 26.8 percent of the signaling, wedge 203 (handover) accounts for 12.9 percent of the signaling, and wedge 204 (other) accounts for 8.9 percent of the signaling. The present invention discloses methods, systems, and devices that can help reduce the signaling load that may occur based on paging and handover. Specifically, the present invention discloses new UE states, radio access network registration areas (RRAs) or tracking / paging areas with different architectural approaches (e.g., hierarchical and distributed), dynamic RRA management, radio access network-based paging, and radio access network-based user equipment (UE) mobility management. Dynamic RRA management can include RRA creation initiated by the network or mobile management entity (MME) or RRA removal initiated by the network or MME. Radio access network based paging may include core network information paging, emergency message broadcast paging, downlink (DL) UE emergency message paging, or DL ​​UE data paging. Finally, radio access network based UE mobility management may include handover initiated by the serving RRA node (SRRAN) within its RRA or handover initiated by the UE on the RRA in a local area.

[0129] New UE states and state transitions for the Radio Resource Control (RRC) protocol are discussed below. As discussed below, the term "Data Radio Bearer (DRB)" is used in a broader sense to refer to the data path in the user plane, such as, at the IP flow level. Similarly, the term "Signaling Radio Bearer (SRB)" is used to refer to the signaling path in the control plane. In addition, it is expected that the target scenario will involve a certain level of mobility, or the UE will be at the cell edge, with a certain level of variability in the received signal level, and therefore, the UE can perform cell reselection to a more suitable cell. The new states discussed in this article can be defined as UE optical signaling connection or UE operation in connectionless mode. A framework for distributed UE location registration areas between the core network and the RAN is proposed.

[0130] Fig.18A New UE states and state transitions are illustrated. In the RRC_IDLE state 210, the UE monitors neighboring cells, performs cell reselection based on thresholds broadcast by the NW, monitors paging messages and system information broadcasts. In the RRC_IDLE state 210, there is no uplink user data transmission, and the UE can perform discontinuous reception (DRX) in the downlink. In the RRC_IDLE state 210, the radio access network may not know the UE location, however, at the core network tracking area or location registration area level (for example, when the UE can be reached through the core network), the core network may know the UE location.

[0131] The device may be configured not to perform paging monitoring during the RRC_IDLE state 210. For example, a device (e.g., an mMTC device) having only mobile origination (MO) call capability may be configured not to perform paging monitoring. Similarly, if MT calls are expected to occur rarely (e.g., a device that expects to receive at most one MT call within a few days (e.g., a week, a month, or a longer period of time)), a device having only mobile termination (MT) call capability may be configured not to perform paging monitoring. Instead, the device may be configured to query the network. This may be considered as reverse paging, in which the UE (e.g., UE 228 or UE 229) pages the network for potential waiting messages in the NW. The device queries the network for potential waiting messages. Such queries may be periodic, according to a configurable period. The UE may perform reverse paging by using an optical signaling connection to transition to a defined connection mode or state in which communication with the network can be performed. Alternatively, the UE may perform reverse paging at the physical layer level by using a physical channel signal defined for reverse paging. This physical channel can follow the unlicensed communication model. The UE can perform carrier sensing or listen before talking to obtain access to the reverse paging unlicensed physical channel. Once the network is paged, the network can decide to order the UE to switch from idle mode to connected mode. Alternatively, the UE can remain in idle mode. After transmitting the reverse paging message, the UE can enter the reverse paging monitoring mode or the sub-state of the RRC_IDLE state 210, in which the UE monitors the network response within a configurable or predefined or specified time amount. If no network response is received, the UE ends the NW response monitoring and remains in the RRC_IDLE state 210. The response to the reverse paging signal can also be carried on the reverse paging physical channel. The UE monitors this channel to obtain the network response to the earlier reverse paging message sent by the UE. This device behavior under the RRC_IDLE state 210 can also be specified as a function of the device category.

[0132] The device may also be configured not to monitor system information broadcasts under RRC-IDLE. The behavior may also be specified as a function of the device class or as a result of device capabilities known to the network or, for example, exchanged between the UE and the network in a previous session. As discussed herein, a device that does not monitor system information obtains a very small set of basic system information. If the UE transitions to a connected state, once the device accesses the network, the device may obtain other system information required for normal operation (e.g., device operation in one mode). Alternatively, there may be a system information update schedule known to the UE (e.g., a date for system information update by the network). Such information may be provided to the UE in advance. The network may use an over-the-air (OTA) pre-setting method to pre-set the system information update schedule on the UE. Alternatively, an operator or service provider may store such information about the UE's USIM / UICC, for example, in a factory before the user takes possession of the UE. In this case, the UE may not monitor system information. The UE may use a system information schedule to determine whether the UE should read system information (e.g., basic system information) before accessing the network or whether the UE uses system information that has already been stored. The NW may also signal system information only according to a predefined schedule.

[0133] The RRC_IDLE state 210 may be mapped to a NAS idle state (e.g., ECM_IDLE). In some instances where the UE is reconfigured to RRC_IDLE 210 without the core network knowing, the RRC_IDLE state 210 may be mapped to the ECM_CONNECTED state or an equivalent 5G NAS state.

[0134] The RRC_Grant_Less state 212 is a connected state. In the first scenario, there is an RRC context, but there is no signaling connection (dedicated or public), no resources are assigned for it, there is no data radio bearer (DRB) connection, and in this state, the DRB cannot be established. The RRC_GRANT_LESS state 212 is similar to the RRC_IDLE state 210 in the sense that it has the attributes of the above-mentioned RRC_IDLE state 210. The difference from the RRC_IDLE state is that for the RRC_GRANT_LESS state 212, there can be unlicensed uplink data transmission. The UE location can also be known at the radio access network registration area (RRA) or routing area level. In addition, the UE location can also be known at the RRA anchor node level, which is discussed in more detail below. This latest attribute minimizes the paging signaling load. It should be noted that paging is the second contributor to the signaling load in existing advanced LTE / LTE networks. In an alternative example, the UE location can also be known to the radio access network at the cell level. For example, the UE may be configured with or provided with a threshold value related to a mobility metric or a speed metric. A mobility metric may include information such as the number of cell reselections that occurred during a specified time period, while a "speed metric" is primarily based on the speed or acceleration of the UE. Another mobility metric may include the number of handovers that occurred during a specified time period. This metric may be applicable to UEs in a connected state, while the count of cell reselections will be applicable to UEs in an idle or inactive state. A speed metric may be used, and the speed metric includes the distance traveled per time unit (e.g., miles / hour, kilometers / hour) and acceleration (i.e., the rate of change of the device speed). The UE uses this threshold to determine the UE mobility level (e.g., mobility state) and whether the UE should perform a location update after a cell change or after an RRA change. For example, the UE may be configured with or provided with a mobility state parameter similar to that used in an advanced LTE / LTE network (see background technology). The mobility state definition may be further extended to include stationary mobility (e.g., no mobility) or nomadic mobility (e.g., can change position at a certain time, but is stationary most of the time). In an exemplary configuration, if the UE is in a high mobility state or a medium mobility state, the UE may perform a location update in the RRC_Grant_Less state 212 that is sent to the RAN (e.g., eNodeB or other base station) only after the UE detects a change in the RRA. The mobility is based on UE controlled mobility. In another exemplary configuration, if the UE is in a low mobility state (e.g., stationary or nomadic), the UE may perform a location update in the RRC_GRANT_LESS state 212 after performing a cell reselection. The mobility is based on UE controlled mobility.

[0135] Fig.18B An exemplary method for a new UE state is illustrated. Note that this is an example of a state transition or state disclosed herein, such as, Fig.18A In step 1, a UE (e.g., UE 228) may detect a change associated with the user equipment, which may include a change in a radio access network registration area of ​​the user equipment or a change in a mobility metric reaching a threshold. In step 2, in response to detecting the change associated with the user equipment in step 1, a location update is performed on the user equipment. In step 3, the UE may provide a location update to a base station (e.g., eNB 227) through an unlicensed channel.

[0136] In the second scenario regarding the RRC_GRANT_LESS state 212, there is an RRC context and there is an RRC signaling connection (common channel, shared channel, or dedicated channel), but there is no DRB connection. The UE location is known in the radio access network at the cell level and therefore the UE performs a location update to the RAN after cell reselection. This state is a connected state. This state is similar to the UMTS / HSPA CELL_FACH state, but one difference is that user data transmission is unauthorized.

[0137] In the RRC_GRANT_LESS state 212, a physical channel or transport channel for unlicensed data transmission may be specified (e.g., assigned). The UE may perform carrier sensing or listen before talk to obtain access to the reverse paging unlicensed physical channel. The signaling connection may be released by the network, or may be implicitly released by both the network and the UE. However, the UE context may be retained in both the UE and the network. The UE may be configured to remain in this situation in the RRC_GRANT_LESS state 212.

[0138] The RRC_GRANT_LESS state 212 may be mapped to NAS ECM_CONNECTED or an equivalent 5G NAS state. In this state, the UE may be paged. Similarly, as described in the case of the RRC_IDLE mode state 210, the UE may be configured to perform reverse paging only to the radio access network. If the UE is configured with reverse paging capability, the UE may perform reverse paging.

[0139] The RRC_CONNECTION_LESS state 214 is similar to the RRC_GRANT_LESS state 212, but the RRC_CONNECTION_LESS state 214 maps to a grant-based connectionless physical channel for data transmission in uplink and downlink.

[0140] The RRC_Connection_Less state 214 is a connected state. In the first scenario, there is an RRC context and a signaling connection, but there is no DRB connection, and in this state, no data radio bearer can be established. The UE location is known at the cell level within the radio access network and therefore, the UE performs a location update to the RAN after cell reselection. The RRC_Connection_Less state 214 is similar to the UMTS / HSPA CELL_FACH state. The difference is that in the case of the RRC_Connection_Less state, there is no data radio bearer (DRB) connection to a pre-established data path on a common or shared transport channel or a common or shared physical channel. Upper layer data (e.g., application data) is carried on a signaling radio bearer (SRB) mapped to a connectionless physical channel. It should be noted that when the SRB carries upper layer data (e.g., application data), the SRB may be mapped to a different type of physical channel having different physical layer properties (e.g., bandwidth, modulation scheme, channel coding, waveform, physical layer resource location, transport block size, error correction, etc.) than the physical layer properties of the physical channel used when the SRB does not carry upper layer data (e.g., application data). The signaling connection may be released by the network, or may be implicitly released by both the network and the UE. However, the UE context may be retained in both the UE and the network. The UE may be configured to remain in the RRC_Connection_Less state 214 in this case, which is discussed below.

[0141] In the second scenario regarding the RRC_Connection_Less state 214, there is an RRC context, but there is no signaling connection, there is no data radio bearer connection, and in this state, a data radio bearer cannot be established. In this state, data transmission is not possible. This RRC connectionless state in which there is an RRC context but there is no signaling connection, there is no data radio bearer connection, and a data radio bearer cannot be established in this state can be considered as a substate of the RRC_Connection_Less state. Before the UE exchanges data with the network, the UE transitions to one of the other RRC connection states (for example, the RRC_Grant_Less state, or the above-mentioned RRC_Connection_Less state substate that may have a signaling radio bearer). The UE location can also be known at the radio access network registration (RRA) level or the routing area level. In addition, the UE location can also be known at the RRA anchor node level. This latest attribute minimizes the paging signaling load. It should be noted that, as in Fig.17 As shown in , paging is the second contributor to signaling load in existing advanced LTE / LTE networks. In an alternative scenario to this scenario, the UE location may also be known to the radio access network at the cell level. For example, the UE may be configured with or provided with a threshold value related to a mobility metric or a speed metric (as discussed herein). The UE uses such a threshold value to decide the UE mobility (state) level and whether the UE should perform a location update when a cell change occurs or when an RRA change occurs. For example, the UE may be configured with or provided with a mobility state parameter similar to the mobility state parameter used in the advanced LTE / LTE network (see background technology). The mobility state definition may be further extended to include stationary mobility (e.g., no mobility) or nomadic mobility (e.g., may change location at a certain time, but is stationary most of the time). In an exemplary configuration, if the UE is in a high mobility state or a medium mobility state, the UE may perform a location update to the RAN (e.g., eNodeB) when an RRA change is detected in the RRC_Connection_Less state 214. Mobility is based on UE controlled mobility. In another exemplary configuration, if the UE is in a low mobility state (eg, stationary or nomadic), the UE may perform location update after cell reselection in the RRC_Connection_Less state 214. Mobility is based on UE controlled mobility.

[0142] The RRC_Connection_Less state 214 may be mapped to NAS ECM_CONNECTED or an equivalent 5G NAS state (eg, when there is an RRC signaling connection). The RRC_Connection_Less state 214 may also be mapped to NAS ECM_IDLE or a 5G NAS equivalent (eg, when there is no RRC signaling connection).

[0143] In this state, the UE may be paged. Likewise, as described in the case of the RRC_IDLE state 210, the UE may be configured only for reverse paging to the radio access network. If the UE is configured with reverse paging capability, the UE may perform reverse paging.

[0144] The RRC_CONNECTED_UE_Controlled_Mobility state 216 is similar to the RRC_Connection_Less state 214 in the sense that it has similar properties to the RRC_Connection_Less case (i.e., sub-states) in which there is an RRC signaling connection (i.e., signaling radio bearers (SRBs)). The difference from the RRC_Connection_Less state 214 is that for the RRC_CONNECTED_UE_Controlled_Mobility state 216, data radio bearers (DRBs) may be established in support of data transmission between the UE and the network. The UE location is known at the cell level. The UE may also be configured such that the UE location is known at the RAN Registration Area (RRA) level or at the RRA anchor node level. The mobility is UE controlled mobility, for example, after cell reselection, the UE performs a location registration update to the radio access network. This state may be mapped to a physical channel having physical layer properties (e.g., bandwidth, modulation scheme, channel coding, waveform, physical layer resource location, transport block size, error correction, etc.) that are different from the properties of the physical channel used in other RRC states. The physical channel properties may also be specific to the usage scenario, for example, mMTC specific physical channels vs. UR / LL physical channels vs. eMBB physical channels. This state may be further divided into sub-states based on the usage scenario (e.g., mMTC, UR / LL, or eMBB). The RRC_CONNECTED_UE_Controlled_Mobility state 216 may be mapped to NAS ECM_CONNECTED or an equivalent 5G NAS state. In this state, the UE may be paged, for example, to wake the UE from DRX mode. The UE may be configured with or provided with thresholds related to mobility metrics or speed metrics (as discussed herein). The UE uses such thresholds to decide the UE mobility (state) level and whether the UE should perform a location update when a cell change occurs or when an RRA change occurs. For example, the UE may be configured with or provided with mobility state parameters similar to those used in LTE-Advanced / LTE networks (see Background). The mobility state definition may be further extended to include stationary mobility (e.g., no mobility), nomadic mobility (e.g., may change location at a certain time, but is stationary most of the time). When the UE is in the RRC_CONNECTED_UE_Controlled_Mobility state at the RRC protocol level, the UE may be in the ECM_CONNECTED state at the NAS protocol level.In an exemplary configuration, if the UE is in a high mobility state or a medium mobility state, then in the RRC_CONNECTED_UE_Controlled_Mobility state 216, the UE may perform a location update to the RAN (e.g., eNodeB) upon detecting an RRA change. The mobility is based on UE controlled mobility. In another exemplary configuration, if the UE is in a low mobility state (stationary or nomadic), then in the RRC_CONNECTED_UE_Controlled_Mobility state 216, the UE may perform a location update after performing a cell reselection. The mobility is based on UE controlled mobility.

[0145] The RRC_Connected_NW_Controlled_Mobility state 218 is similar to the RRC_Connected_UE_Controlled_mobility state 216. The difference is that in the RRC_Connected_NW_Controlled_Mobility state 218, the network controls the UE mobility. The UE location is known at the cell level. The UE is configured with mobility-related measurements reported to the network (e.g., thresholds related to mobility metrics or speed metrics as discussed herein). The network can use the measurement reports to make handover decisions and reconfigure the UE with communication resources in the newly selected target cell. This state can be mapped to a physical channel with physical layer attributes (e.g., bandwidth, modulation scheme, channel coding, waveform, physical layer resource location, transport block size, error correction, etc.) that are different from the attributes of the physical channel used in other RRC states. The physical channel attributes can also be specific to the usage scenario, for example, mMTC-specific physical channels and UR / LL physical channels and eMBB physical channels. This state can be further divided into sub-states based on usage scenarios (e.g., mMTC, UR / LL, or eMBB). This state may be mapped to NAS ECM_CONNECTED or an equivalent 5G NAS state. In this state, the UE may be paged, for example, to wake up the UE from DRX mode.

[0146] Continue to refer to Fig.18A ,Should Fig.18A The new UE states and state transitions are shown below. Fig.18A An example trigger for the state transitions shown in Figure .

[0147] The following are example triggers for RRC_IDLE state 210 to RRC_Grant_Less state 212: 1) The RRC establishment cause is an "emergency" call or the UE is configured to access the network using unauthorized access when the establishment cause is "emergency"; 2) The RRC establishment cause is "high priority access" or the UE is configured to access the network using unauthorized access when the establishment cause is "highPriorityAcess"; 3) The RRC establishment cause is mo_signaling or the UE is configured to access the network using unauthorized access when the establishment cause is "mo_signaling"; 4) The RRC establishment cause is "delay tolerant access" or the UE is configured to access the network in connectionless mode when the establishment cause is "delay tolerant access"; 5) The establishment cause is access configuration or a network slice specified to use unauthorized operation; 6) The establishment cause is set to access configuration or a usage scenario (e.g., UR / LL) or application specified to use an unauthorized operation mode; 7) Utilization indicates that the connection operation mode should be based on an unauthorized NW (e.g., eNode B) a mobile terminated (MT) call; 8) the access reason is reverse paging, i.e., the UE wants to page the network; 9) the access reason is optical connection; or 10) the NW configures the UE into an unlicensed operation mode with unlicensed operation resources during the RRC connection establishment procedure.

[0148] The following are example triggers for the RRC_IDLE state 210 to the RRC_Connection_Less state 214: 1) The RRC establishment cause is an "emergency" call or the UE is configured to access the network using a connectionless access when the establishment cause is "emergency"; 2) The RRC establishment cause is "high priority access" or the UE is configured to access the network using a connectionless access when the establishment cause is "highPriorityAcess"; 3) The RRC establishment cause is mo_signaling or the UE is configured to access the network using a connectionless access when the establishment cause is "mo_signaling"; 4) The RRC establishment cause is "delay tolerant access" or the UE is configured to access the network in a connectionless operation mode when the establishment cause is "delay tolerant access"; 5) The establishment cause is an access configuration or a network slice specified to use a connectionless operation mode; 6) The establishment cause is set to an access configuration or a usage scenario (e.g., UR / LL) or application specified to use an unauthorized operation mode; 7) Using an NW (e.g., eNode B) that indicates that the connection operation mode should be connectionless. B) a mobile terminated (MT) call; 8) the access reason is reverse paging, i.e., the UE wants to page the network; 9) the access reason is optical connection; or 10) the NW configures the UE into a connectionless operation mode with only connectionless resources during the RRC connection establishment procedure.

[0149] With reference to the transition from the RRC_IDLE state 210 to the RRC_Connected_UE_Controlled_Mobility state 216, in an example, the NW may have configured the UE to the RRC_Connected_UE_Controlled_Mobility state 216 with transport and physical channel resources for this state during the RRC connection establishment procedure. The NW may determine to place the UE in the RRC_Connected_UE_Controlled_Mobility state 216 based on a mobility state report from the UE (e.g., as part of a connection establishment complete message from the UE). Likewise, the NW may determine to place the UE in the RRC_Connected_UE_Controlled_Mobility state 216 based on an establishment cause included in an RRC connection establishment request message from the UE. Other example triggers for the RRC_IDLE state 210 to the RRC_Connected_UE_Controlled_Mobility state 216 may include: 1) the establishment cause is set to the access configuration or the network slice specified to use the RRC_Connected_UE_Controlled_Mobility state 216; or 2) the establishment cause is set to the access configuration or the usage scenario (e.g., UR / LL) or application specified to use the RRC_Connected_UE_Controlled_Mobility state 216.

[0150] With reference to the transition from the RRC_IDLE state 210 to the RRC_Connected_NW_Controlled_Mobility state 218, the NW may have configured the UE in the RRC_Connected_NW_Controlled_Mobility state 218 with transport and physical channel resources for this state during the RRC connection establishment procedure. The NW may determine to place the UE in the RRC_Connected_NW_Controlled_Mobility state 218 based on a mobility state report from the UE (e.g., as part of a connection establishment complete message from the UE). Likewise, the NW may determine to place the UE in the RRC_Connected_NW_Controlled_Mobility state 218 based on an establishment cause included in an RRC connection establishment request message from the UE. Other example triggers for the RRC_IDLE state 210 to the RRC_Connected_NW_Controlled_Mobility state 218 may include: 1) the establishment cause is set to the access configuration or the network slice specified to use the RRC_Connected_NW_Controlled_Mobility state 218; or 2) the establishment cause is set to the access configuration or the usage scenario (e.g., UR / LL) or application specified to use the RRC_Connected_NW_Controlled_Mobility state 218.

[0151] Transitioning back to the RRC_IDLE state 210 is discussed below. The network (e.g., eNodeB or equivalent 5G RAN node) may reconfigure the UE to the RRC_IDLE state from any connected state. The UE may also autonomously transition to the RRC_IDLE state from any connected state. The network may trigger a transition to the RRC_IDLE state using an inactivity timer specific to an application, traffic profile, or use case (e.g., an mMTC application or UR / LL application or eMBB). Similarly, the UE may autonomously trigger a transition to the RRC_IDLE state using an inactivity timer specific to an application, traffic profile, or use case (e.g., an mMTC application or UR / LL application or eMBB).

[0152] When the network (e.g., eNodeB or equivalent 5G RAN node) reconfigures the UE to RRC_IDLE state 210, the network may decide not to notify the core network. In this case, the UE may be in RRC_IDLE state 210, but in NAS, the UE is in a fully connected state (e.g., ECM_CONNECTED state or equivalent 5G NAS state) with a signaling connection between the RAN and the core network (e.g., an S1 signaling connection in a signaling connection for an equivalent interface between a 5G radio access network and a 5G core network). This may also mean that RRC_IDLE may be mapped to ECM_CONNECTED state or equivalent 5G NAS state.

[0153] Referring to the RRC_Grant_Less state 212 to the RRC_Connection_Less state 214, when the UE is in the RRC_Grant_Less state 212, the network (e.g., an eNB or an equivalent 5G RAN node) may decide to reconfigure the UE with transport channels and physical channel resources used in the connectionless operation mode. After successfully reconfiguring these resources, the UE transitions from the RRC_Grant_Less state 212 to the RRC_Connection_Less state 214. Example triggers in the network for reconfiguring the UE from the RRC_Grant_Less state 212 to the RRC_Connection_Less state 214 may include the following: 1) adding a service that requires transport channels or physical channel resources used in the connectionless operation mode; or 2) a measurement value (e.g., a data volume report) from the UE or other device has met the conditions set in the network for the network (e.g., eNodeB) to reconfigure the UE to the RRC_Connection_Less state 214 (e.g., the data volume is above a threshold).

[0154] The transition from the RRC_Grant_less state 212 to the RRC_CONNECTED_UE_Controlled_Mobility 216 may follow similar rules as the transition from the RRC_Grant_less state 212 to the RRC_Connection_Less state 214. For example, while the UE is in the RRC_Grant_Less state 212, the network (e.g., an eNB or equivalent 5G RAN node) may decide to reconfigure the UE with the transport channel and physical channel resources used in the RRC_CONNECTED_UE_Controlled_Mobility state 216. After successfully reconfiguring these resources, the UE transitions from the RRC_Grant_Less state 212 to the RRC_CONNECTED_UE_Controlled_Mobility state 216.

[0155] The transition from the RRC_Grant_less state 212 to the RRC_CONNECTED_NW_Controlled_Mobility state 218 may follow similar rules as the transition from the RRC_Grant_less state 212 to the RRC_Connection_Less state 214. For example, while the UE is in the RRC_Grant_Less state 212, the network (e.g., an eNB or equivalent 5G RAN node) may decide to reconfigure the UE with the transport channel and physical channel resources used in the RRC_CONNECTED_NW_Controlled_Mobility state 218. After successfully reconfiguring these resources, the UE transitions from the RRC_Grant_Less state 212 to the RRC_CONNECTED_NW_Controlled_Mobility state 218.

[0156] Referring to the transition from the RRC_Connection_Less state 214 to the RRC_Grant_Less state 212, when the UE is in the RRC_Connection_Less state 214, the network (e.g., eNB or equivalent 5G RAN node) may decide to reconfigure the UE with transport channels and physical channel resources used in the unlicensed operation mode. After successfully reconfiguring these resources, the UE transitions from the RRC_Connection_Less state 214 to the RRC_Grant_Less state 212. Example triggers in the network for reconfiguring the UE from the RRC_Connection_Less state 214 to the RRC_Grant_Less state 212 may include the following: 1) services that require transport channels or physical channel resources used in the RRC_Connection_Less operating mode are removed, and the remaining services only require transport channels or physical channel resources used in the RRC_Grant_Less state; or 2) measurement values ​​(e.g., data volume reports) from the UE or other devices have met the conditions set in the network for the network (e.g., eNodeB) to reconfigure the UE to the RRC_Connection_Less state 214 (e.g., the data volume is below a threshold).

[0157] The transition from the RRC_CONNECTED_UE_Controlled_Mobility state 216 to the RRC_Grant_Less state 212 follows similar rules as the transition from the RRC_Connection_Less state 214 to the RRC_Grant_Less 212. For example, when the UE is in the RRC_CONNECTED_UE_Controlled_Mobility state 216, the network (e.g., eNB or equivalent 5G RAN node) may decide to reconfigure the UE with transport channel and physical channel resources used in the unlicensed operation mode. After successfully reconfiguring these resources, the UE transitions from the RRC_CONNECTED_UE_Controlled_Mobility state 216 to the RRC_Grant_Less state 212.

[0158] The transition from the RRC_CONNECTED_NW_Controlled_Mobility state 218 to the RRC_Grant_Less state 212 follows similar rules as the transition from the RRC_Connection_Less state 214 to the RRC_Grant_Less 212. For example, when the UE is in the RRC_CONNECTED_NW_Controlled_Mobility state 218, the network (e.g., eNB or equivalent 5G RAN node) may decide to reconfigure the UE with transport channel and physical channel resources used in the unlicensed operation mode. After successfully reconfiguring these resources, the UE transitions from the RRC_CONNECTED_NW_Controlled_Mobility state 218 to the RRC_Grant_Less state 212.

[0159] With reference to the transition from the RRC_CONNECTED_UE_Controlled_Mobility state 216 to the RRC_CONNECTED_NW_Controlled_Mobility state 218, while the UE is in the RRC_CONNECTED_UE_Controlled_Mobility state 216, the network (e.g., an eNB or equivalent 5G RAN node) may decide to reconfigure the UE with transport channel and physical channel resources used in the RRC_CONNECTED_NW_Controlled_Mobility state 218 mode of operation. Upon successful reconfiguration of these resources, the UE transitions from the RRC_CONNECTED_UE_Controlled_Mobility state 216 to the RRC_CONNECTED_NW_Controlled_Mobility state 218. The UE may provide the network with recommendations regarding mobility history, mobility states, measurements of traffic patterns, the length of time the UE desires to remain in connected mode, or a preference for transitioning to the RRC_CONNECTED_NW_Controlled_Mobility state.

[0160] With reference to the transition from the RRC_CONNECTED_NW_Controlled_Mobility state 218 to the RRC_CONNECTED_UE_Controlled_Mobility state 216, while the UE is in the RRC_CONNECTED_NW_Controlled_Mobility state 218, the network (e.g., an eNB or equivalent 5G RAN node) may decide to reconfigure the UE with transport channel and physical channel resources used in the RRC_CONNECTED_UE_Controlled_Mobility state 216 mode of operation. Upon successful reconfiguration of these resources, the UE transitions from the RRC_CONNECTED_NW_Controlled_Mobility state 218 to the RRC_CONNECTED_UE_Controlled_Mobility state 216. The UE may provide the network with recommendations regarding mobility history, mobility states, measurements of traffic patterns, the length of time the UE desires to remain in connected mode, or a preference for transitioning to the RRC_CONNECTED_NW_Controlled_Mobility state 218.

[0161] exist Fig.18A The states depicted in and discussed herein may be configured by the network (e.g., taking into account the use case or application being served by the UE). The network (e.g., an eNB or 5G radio access network equivalent node) may utilize the states described in Fig.18A 214. For example, for UR / LL applications, the UE may be configured with only two states, such as the RRC_Grant_Less state 212 and the RRC_CONNECTED state 214. In the example, the UE may not be configured with the RRC_IDLE state 210. Similarly, for some mMTC applications, for example, when the device is stationary or nomadic, the UE may be configured with only the RRC_IDLE state 210 and the RRC_Connection_Less state 214.

[0162] This article is expected to be mix and match Fig.18A Many states are not required or can be combined with other states. For example, the features of the RRC_Grant_Less state 212 can be combined with the RRC_Connection_less state 214 or the RRC_Connected_UE_Control_Mobility state 216. The steps and scenarios associated with each state as disclosed below can be skipped or combined. Figure 22 to Figure 26 Provided may include and as described herein Fig.18AThe state provided in the method associates one or more states and steps.

[0163] The following discloses a mobility management mechanism. The disclosed mobility management considers radio access network based tracking area control and supports paging procedures for reducing mobility related signaling or messages. For example, radio access network registration area (RRA), dynamic RRA management, RAN based paging, and radio access network based mobility management.

[0164] The following is a diagram of the architecture disclosed (such as Fig.19 , Fig. 20 ,and Fig.21 ) is a defined term or logical entity for RRA used in the LTE / LTE network. A Radio Access Network (RANW) is a radio network that provides a connection between a UE and a Core Network (CN), such as an LTE RAN, a WiFi radio network, etc. A RANW Registration Area (RRA) is a radio access network registration area used as a location tracking area at the RANW level. An RRA may include one or more radio access networks, such as one or more eNBs in an LTE system or an access point (AP) in a WiFi system. For example, in an LTE system, the location tracking area of ​​an MME may be divided into multiple RRAs that are locally controlled and managed by the corresponding eNBs.

[0165] The RRA anchor point (RRAaP) serves as a radio access network that interfaces with the core network (CN), other radio access networks, and UEs. It plays the role of a registrar for RANW registration and therefore, it also plays the role of tracking the location (e.g., reachability status) of the UE in the local radio access area and managing the mobility of the UE locally. An exemplary RRAaP may be an eNB in ​​an LTE system or an AP controller in a WiFi system.

[0166] The Serving RRA Node (SRRAN) serves as a presence point for the UE to the core network (CN) (e.g., an entity with which the UE makes an RRC connection when in the RRC_Idle state), and provides a specific physical connection via signaling or provides (multiple) data channels or logical connections via a relationship or context between the UE and the RANW. Each UE has a connection or context with the RANW represented by the SRRAN. The SRRAN may be an RRAaP, i.e., a RANW registrar for UEs in its RRA, responsible for tracking the location of the UE and local mobility management. An exemplary SRRAN may be an eNB in ​​an LTE system or an AP or AP controller in a WiFi system.

[0167] The drift RRA node (DRRAN) is used as a substitute RRA node for the serving RRA node to act as a temporary presence of the UE to the core network (CN) (e.g., an entity to which the UE is switched when in the RRC_Connected state 114), and provides a specific physical connection via signaling or (multiple) data channels. Each UE has a DRRAN connected to the RANW represented by the DRRAN. The DRRAN can be the RRAaP that the UE is accessing in the substitute RRA. An exemplary DRRAN can be an eNB in ​​an LTE system or an AP or AP controller in a WiFi system.

[0168] Fig.19 , Fig. 20 ,and Fig.21 is an exemplary deployment of RRAaP, SRRAN and DRRAN in an LTE system. Note that the same mechanism is also applicable to non-LTE systems or LTE and non-LTE integrated systems.

[0169] Fig.19 An exemplary layered architecture without RRA overlap is illustrated.As shown, MME 221 may be connected to several radio access network nodes, such as eNB 222, eNB 223, eNB 224, eNB 225, eNB 226, and eNB 226. The mobile tracking / paging area 220 of the core network mobility controller (e.g., MME 221) can be divided into multiple radio access network level tracking / paging areas - RANW registration areas, for example, eNB 222 and eNB 223 tracking / paging areas RRA 230 and RRA 231 in the LTE system, respectively, and the eNB 222 and eNB 223 tracking / paging areas RRA 230 and RRA 231 are controlled and managed by the RRA anchor point (RRAaP) or RANW registrar (e.g., in the LTE system, eNB 222 acts as the RRAaP of RRA 230, and eNB 223 acts as the RRAaP of RRA 231).

[0170] In each RRA, there may be one or more radio access nodes (e.g., eNBs in an LTE system) as serving RRA nodes (e.g., eNB 222 that is also RRAaP or eNB 226 in RRA 231) or drift RRA nodes (e.g., eNB 224 in RRA 230 or eNB 225 also in RRA 230).

[0171] As illustrated in the LTE system, each RRAaP may have the following interfaces: 1) an interface with the core network, such as shown between eNB 222 or eNB 223 and MME / SGW, for example, an S1 class or S1 enhanced interface S1′; 2) an interface with other RRAaPs, such as shown between eNB 222 or eNB 223, for example, an X2 class or an X2 enhanced interface X2′; 3) an interface with the SRRAN and DRRAN within its RRA, such as shown between eNB 222 and eNB 224 and eNB 225, respectively, in RRA 230 or between eNB 223 and eNB 226 and eNB 227, respectively, in RRA 231, for example, an X2 class or an X2 enhanced interface X2′; and 4) an interface with the UE within its RRA, such as shown between UE 228 and the eNB as an RRAaP in RRA 230. 222, for example, is a Uu class or Uu enhanced interface Uu'.

[0172] As illustrated in the LTE system, each SRRAN or DRRAN may have the following interfaces: 1) an interface with the core network, such as shown between the eNB 224 as DRRAN in the RRA 230 and the MME / SGW 221 or between the eNB 226 as SRRAN in the RRA 231 and the MME / SGW 221, for example, an S1-type or S1-enhanced interface S1′; 2) an interface with other SRRANs or DRRANs, such as shown between the eNB 222 as RRAaP / SRRAN and the eNB 224 as DRRAN in the RRA 230 or between the eNB 226 as SRRAN and the eNB 225 as DRRAN on the RRA 231 and the RRA 230, for example, an X2-type or X2-enhanced interface X2′; and 3) an interface with the UE within its RRA, such as shown between the UE 229 and the eNB 226 as SRRAN in the RRA 231. 226, for example, a Uu class or Uu enhanced interface Uu'.

[0173] Fig. 20 The diagram is similar to that described above except that there is an overlap area between adjacent RRAs (e.g., RRA 230 and RRA 231 overlap on eNB 225). Fig.19 Another similar hierarchical structure. In this scenario, both RRAaPs may have interfaces with SRRAN or DRRAN in the overlapping area, for example, eNB 222 RRAaP and eNB 223 RRAaP respectively have XT interfaces with eNB 225.

[0174] exist Fig.21, where the tracking / paging areas of the MME of the core network mobility controller (e.g., the tracking / paging areas of the MME in an LTE system) are distributed among all radio access network nodes controlled and managed by the RRA anchor points in the LTE system (e.g., eNB 242 and eNB 246 as RRAaPs of RRA 250 and RRA 251, respectively). The tracking / paging areas of each node (e.g., eNB 243, 244, 245, and 247) will exist in the RRA anchor points in the LTE system. Fig.21 In the distributed architecture shown in Fig.21 Not shown in the figure due to limited space.

[0175] RRAs may be configured via system configuration or updates. However, RRAs may also be dynamically created, updated, or removed based on the status and capabilities of the core network and radio access network. For example, new RRAs may be created or removed based on traffic loading, event scheduling, system storage or computing capabilities, service requirements, etc. Another example is the creation or removal of new RRAs due to network or RAN slicing.

[0176] Described below Fig.18B and Figure 22 to Figure 26 The method for interaction between devices / apparatuses in a communication network is illustrated. It should be understood that the execution of Fig.18B and Figure 22 to Figure 26 The entities of the steps illustrated in the figure are executable according to the device or computer system (such as in Fig.27B and Fig.27F A logical entity implemented in the form of software (i.e., computer executable instructions) stored in a memory of a communication device (such as those systems illustrated in FIG. 1 ) and executed on a processor of the device or computer system. That is, the communication device (such as a communication device) may be stored in a memory of the communication device (such as a communication device) or a computer system .... Fig.27B and Fig.27F The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system illustrated in FIG. Fig.18B and Figure 22 to Figure 26 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the device perform Fig.18B and Figure 22 to Figure 26 It should also be understood that the steps illustrated in the figure can be performed by the communication circuit system of the device under the control of the processor of the device and the computer executable instructions (e.g., software) executed by it. Fig.18B and Figure 22 to Figure 26 In the example, according to the further details below about the interaction of the device, Fig. 22 The RRAaP 262 can reside in Fig.27ABase station 114a in Fig.27C Node B 140A in Fig.27D eNode-B 160a in, or Fig.27E On the base station 180c in Fig. 22 The MME 264 (RAN slice controller) in Fig.27D Considering the exemplary methods disclosed herein (e.g., Fig.18B and Figure 22 to Figure 26 ) to skip steps, combine steps, or add steps.

[0177] In the context of creating an RRA Fig. 22 and for the removal of RRA Fig.23 The diagram shows the layered architecture ( Fig.19 is an example of dynamic RRA management. The dynamic RRA management can be initiated by the application function, network controller, or MME in the LTE system based on application / service requirements, network traffic, network slices, mobility management status, etc. Fig. 22 and Fig.23 An example is shown in the figure. Fig. 22 and Fig.23 Following a similar process as shown in the figure, the creation or removal of RRA can also be initiated through SRRAN or DRRAN based on the traffic, mobility management, RAN slicing, etc. of the radio access network.

[0178] The following discusses Fig. 22 Additional details. Fig. 22 An exemplary method for dynamic RRA management associated with creating an RRA is illustrated. The proposed network may include nodes (eg, eNBs) such as SRRAN 260 (which may be a DRRAN), SRRAN 261 (which may be a DRRAN), RRAaP 262, and RRAaP 263. Fig. 22MME 264 (e.g., RAN slice controller) and HSS 265 (e.g., AF or network controller) may also be included. In step 270, SRRAN 260 and SRRAN 261 may be established, which are in RRA1 under RRAaP 262. RRAap_new 263 may be under MME 264, but not in RRA1 under RRAaP 262. In step 271, HSS 265 may send an MM request or create RAN slice request. In step 272, MME 264 may determine to create a new RRA and select RRAaP_new 263. In step 273, MME sends an RRA create request using the RRAaP 262 context. In step 274, RRAaP_new 263 creates RRA2. In step 275, RRAaP_new 263 sends an RRA create response using the RRA2 context. Block 266 (step 276) or block 267 (step 277) may occur. In step 276, RRAaP_new 263 may send an RRA update request using the RRA2 and SRRAN 261 contexts. Alternatively, in step 277, MME 264 may send an RRA update request using the RRA2 and SRRAN 261 contexts.

[0179] Continue to refer to Fig. 22, in step 278, an RRA update request with RRA2 context may be sent by RRAP 262. Block 268 (steps 279 to 281) or block 269 (steps 287 to 289) may occur. In step 279, SRRAN 261 may send an RRA update request with SRRAN 261 context. In step 280, RRAaP_new 263 may update RRA2. In step 281, RRAaP_new 263 may send an RRA update response with RRA2 context. In step 282, an RRA update response may be sent by SRRAN 261. In step 283, RRAaP 262 may update RRA1. Step 284 or step 285 may occur. In step 284, an RRA update response may be sent to RRAaP_new 263. In step 285, an RRA update response may be sent to MME 264. Regarding optional block 269, in step 286, RRAP 262 may send SRRAN 261 information to RRAaP_new 263. In step 287, RRAaP_new 263 may send an RRA update request using the RRA2 context. In step 288, SRRAN 261 may send an RRA update response. In step 289, RRAaP_new 263 may update RRA2. In step 290, MME 264 may send a create response or a create slice response to HSS 265.

[0180] Fig.23 Dynamic RRA management is illustrated - removing the RRA. In addition to the optional steps in block 318 (steps 304 to 308) and block 319 (steps 311 to 316), steps 301 to 316 may be used.

[0181] Fig.24 An exemplary method for radio access network based paging is illustrated, which can reduce unnecessary paging messages that are commonly performed in some systems (such as LTE). Fig.19 The architecture of Fig.24 As in Fig.24 The method shown in is also applicable to Fig. 20 and Fig.21 The other architecture shown in FIG. 1 has the following differences: 1) as in Fig. 20 As shown in FIG, for SRRAN or DRRN in the overlapping area, it is necessary to use the mobility context of the UE (such as location, reachability status, etc.) to update two RRAaPs (for example, eNB 225 updates both eNB 222 and eNB 223 via the X2' interface.); 2) as shown in FIG. Fig.21As shown in the figure, SRRAN or DRRN (i.e., as separate RRAaPs, respectively) needs to exchange the mobility context of the UE (such as location, reachability status, etc.), for example, eNB 242 to eNB 247 respectively update the mobility context of the UE via the X2' interface, but the paging area can be reduced to the radio access node area (e.g., the smallest RRA).

[0182] Fig.24 The method is illustrated in which multiple UEs may communicate with the network. Consider one or more UEs connected to the network. RRAaP1 (i.e., eNB 222 in this example) provides RRA / RRC paging (e.g., system information) to UE 1. RRAaP 2 (i.e., eNB 223 in this example) provides RRA / RRC paging (e.g., system information) to UE 2. UE 1 provides measurement reports (e.g., + location, speed, etc.) to RRAaP1. UE 2 provides measurement reports (e.g., + location, speed, etc.) to RRAaP2. RRAaP1 may update RRA 230, update UE 228 context, and updating UE 228 context may include: updating UE 228 reachability status. In step 323, RRAaP 1 may update the RRA 1 list, update UE 1 context, or update UE 1 reachability status. RRAaP 2 may update an RRA 2 list (e.g., a list of UEs in an RRA managed by the RRAaP), update a UE 2 context, or update a UE 2 reachability state. Different RRAaPs (e.g., RRAaP 1, RRAaP 2, RRAaP3), SRRAN, or DRRAN may exchange the mobility context of the UE via an X2' interface. The mobility context may be exchanged between different nodes so that the network knows where the node is located if the network needs to page the node. If the location is not known, the network will have to page the UE in all nodes. Exchanging mobility context may also be used to trigger dynamic updates to the RRA based on the UE location or trajectory. This may be limited to RRAaPs connected via an X2 / X2 enhanced interface.

[0183] Continue to refer to Fig.24, one or more messages may be sent to the MME in block 221. For example, the MME receives an indication that DL data needs to be transmitted, which causes the MME to page UE 1. Or the MME may receive a DL emergency message for UE 1 from an Sx server, or a DL emergency broadcast message from a Sy server. Based on S1 AP paging, one or more messages or CN update information may be sent to RRAaP 1, RRAaP 2, or RRAaP 3. As part of this step, an S1AP paging request is sent to a node that may be able to reach the UE. RRAaP 1 may determine whether core network (CN) information, emergency broadcast, or DL ​​UE data or emergency message has reached UE 1. Similarly, RRAaP 1 may determine whether UE 1 is in its RRA1. RRAaP 1 may send a paging message to a UE in its RRA. In this example, only UE 1 is shown as being in its RRA. Likewise, RRAaP 2 may determine whether core network (CN) information, emergency broadcasts, or DL ​​UE data or emergency messages have reached UE 2. Likewise, RRAaP 2 may determine whether UE 2 is in its RRA 2. RRAaP 2 may send a paging message to all UEs in its RRA. In this example, only UE 2 is in its RRA. RRA / RRC paging by RRAaP 1 may include CN update information, emergency broadcasts, or DL ​​UE 1 data or emergency messages. RRA / RRC paging by RRAaP 2 may include CN update information, emergency broadcasts, or DL ​​UE 2 data or emergency messages. UE 1 may determine whether it needs to pass the paging content to a higher layer. UE 2 may determine whether it needs to pass the paging content to a higher layer. RRAaP 2 may forward a DL paging for another UE (not shown) to RRAaP 3 where the other UE is located.

[0184] exist Fig.25 and Fig.26 The figure shows the mobility management based on the radio access network. Figure 22 to Figure 26 In the method flow, we can consider Fig.18B and the accompanying description. Fig.19 and Fig. 20 To obtain information about Fig.25 and Fig.26 Another perspective on the method. Fig.25An exemplary RRAaP / SRRAN initiated handover within an RRA is illustrated. UE 1 may determine a measurement value. UE 1 may send the measurement value to RRAaP 1. Based on the measurement value, DRRAN 1 may be selected for handover of UE 1. RRAaP 1 sends a handover request to DRRAN 1 based on the selection. DRRAN 1 sends a handover response to RRAaP 1. UE 1, RRAaP 1, and DRRAN 1 perform a handover procedure. RRAaP 1 updates the context of UE 1. RRAaP 1 and RRAaP 2 may exchange reachability of UEs (which may include UE 1).

[0185] Fig.26 An example method of UE mobility management controlled by the UE while on an RRA in a local area is illustrated. Fig.26 An exemplary UE-initiated handover on RRA is illustrated. UE 2 may exit sleep mode and listen to PBCH for system information. SRRAN 2 and RRAaP 2 may not be able to reach UE 2, respectively. UE 2 may be out of range of SRRAN 2 and RRAaP 2, or may block signals from these nodes. Since high frequencies are expected to be used for certain deployments, blocking is expected to be more problematic for NR. DRRAN 2 sends system information to UE 2, which is received by UE 2. The three steps after exiting sleep mode may occur at nearly the same time. UE 2 selects DRRAN 2 based on the received system information. UE 2 sends an attach request to DRRAN 2 based on the determined selection. The attach request may include RRAaP 2 or SRRAN 2 information. In response to the attach request, DRRAN 2 sends an attach response that may include RRAaP 2 or DRRAN 2 information. DRRAN 2 may forward context information of RRAaP 2, SRRAN 2, or UE 2 to RRAaP 1. RRAaP 1 may update its UE 2 reachability status based on the information. RRAaP 1 may forward the SRRAN 2 or UE 2 context information to RRAaP 2. RRAaP 2 may update its UE 2 reachability status based on the information. UE 2 context information may be forwarded from RRAAP 2 to SRRAN 2. Accordingly, SRRAN 2 may update its UE 2 context information based on the received information.

[0186] The above switching mechanism also applies to Fig.21The distributed architecture illustrated in FIG. 1 is taken as an example of the following handover scenario. For a fully distributed network of radio access nodes (e.g., a mesh network of LTE eNBs or WiFi APs), mobility can be handled between the two radio access nodes (e.g., between the two eNBs via an X2' interface in an LTE system) via a direct interface between the two radio access nodes using UE mobility context (such as location, reachability status, etc.) exchanged through an interface between the radio access nodes. For a partially distributed network of radio access nodes (e.g., a partial mesh network of LTE eNBs or WiFi APs), there may or may not be a direct interface between a pair of radio access nodes. Mobility can be handled between a pair of radio access nodes having a direct interface therebetween in the same manner as described above.

[0187] Continuing with reference to the handover of radio access nodes and the local distributed network, as illustrated below, mobility may be handled differently between a pair of radio access nodes that do not have a direct interface therebetween. In a first example, if there is a third radio access node that has a direct interface with the pair of radio access nodes, respectively, the handover may be performed via the third node through the direct interface of the third node with the pair of radio access nodes, respectively. Thus, the third node acts as a relay for the handover process and supports the exchange of UE mobility contexts, such as location, reachability status, etc., through its interface between the pair of radio access nodes, respectively. In a second example, if there is no third radio access node that has a direct interface with the pair of radio access nodes, respectively, the handover may be performed via the mobility controller of the core network through the direct interface of the pair of radio access nodes, respectively, via the mobility controller of the core network, for example, the MME in an LTE system, via the S1' interface with the pair of eNBs, respectively. Thus, the core network manages the handover process and supports the exchange of UE mobility contexts, such as location, reachability status, etc., through its interface between the pair of radio access nodes, respectively.

[0188] In the present disclosure, 5G, 5G system, NexGen, and next generation system are used interchangeably. Moreover, in the present disclosure, the term "Node B" or "eNode B" or 5G RAN node is used to generally represent a 5G radio access network node, which may be located in the control plane, or in the user plane, and may be located in a centralized location (e.g., a data center, a cloud, i.e., a central controller or central unit supporting virtualization), or may be located at the edge of the RAN as a distributed RAN unit, for example, a transmission reception point (TRP) with RAN functions is located at the edge of the RAN. Similarly, with respect to a 5G network control entity or control unit located in the control plane, the term "MME" or "5G CN control node" is generally used. With respect to a 5G core network gateway or user data processing unit located in the data plane or user plane, the term "S-GW", "P-GW", or a 5G core network equivalent node is used.

[0189] Device is used herein as a general series name for communication devices including UE. Terms such as "device", "device configured for wireless or wired communication", "device" and "UE" are used interchangeably herein. For the purpose of this application, the method applicable to the device can be applied to the UE. Architecturally, the UE includes a USIM (User Service Identity Module), a mobile termination (MT) that performs radio transmission, and related functions and a terminal equipment (TE) (e.g., a laptop computer) including an end-to-end application and a keyboard. For example, if a user interface (such as a graphical user interface or a voice recognition interface, etc.) is not required, some devices may not have a TE.

[0190] Basic system information as discussed herein is system information that a UE must read before being able to access the network and, for example, perform a random access procedure and establish an RRC (Radio Resource Control) signaling connection. With respect to existing 4G LTE systems, such basic system information includes information captured in a master information block (MIB), a system information block (SIB) type 1, SIB types 2 to SIB types 8 (depending on support for the radio access technology (RAT) involved), and SIB type 17 (depending on support for RAN-assisted WLAN interworking). The MIB includes, for example, information about downlink cell bandwidth and system frame number. SIB type 1 may include information about whether the UE is allowed to camp on a cell. SIB type 2 includes information that the UE needs in order to be able to access a cell. SIB type 3 includes information related to cell reselection. SIB4 to SIB8 include information related to neighboring SIBs.

[0191] Unlicensed uplink data transmission as discussed herein means that when transmitting uplink user data from a UE to a network, the UE does not need to first request communication resources (e.g., in the frequency domain and time domain in the network) from the network (e.g., an eNB or 5G RAN node equivalent) or wait for the network to assign communication resources to the UE before the UE accesses the system and sends user data in the uplink direction.

[0192] In summary, distributed mobility management and UE states and state transitions for implementing lightweight signaling for data transmission are disclosed. A radio access registration area (RRA) and logical entities (e.g., RRA anchor point (RRAaP), serving RRA node (SRRAN), drift RRA node (DRRAN)) for implementing RAN-based tracking area control are disclosed. A mechanism can trigger a report location update to make the location of the UE known at the RRA, RRA anchor point or cell level. The mechanism can perform dynamic RRA management based on the status and capabilities of the core network and the radio access network. RAN-based UE reachability management and RRA anchor node-based paging mechanisms can reduce TAUs and brute force TA-wide paging. An enhanced RRA-based RAN-controlled mobility management process can implement SRRAN-initiated handovers within RRAs and UE-initiated handovers on RRAs.

[0193] In further summary, with respect to distributed mobility management and UE states and state transitions, the RRC_IDLE state can be enhanced to support reverse paging, in which the UE pages the network to obtain potential waiting messages in the network. The RRC_Grant_Less state, in which SRBs or DRBs have not been established but uplink data transmission is possible, can use unlicensed physical channels. The RRC_Connection_Less state, in which upper layer data (e.g., user application data) is carried on SRBs, can be mapped to connectionless physical channels. The RRC_CONNECTED_UE_Controlled_Mobility state can implement UE-controlled mobility via cell reselection. The new RRC_CONNECTED_NW_Controlled_Mobility state can implement network-controlled mobility based on measurement reports from the UE. The establishment cause can cause a transition from the RRC_IDLE state to an appropriate new state when a connection is established.

[0194] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including: radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. The latest radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and advanced LTE standards. 3GPP has begun to work on the standardization of the next generation of cellular technology, called New Radio (NR), which is also referred to as "5G". It is expected that the 3GPP NR standard development includes the definition of the next generation radio access technology (new RAT), which is expected to include providing new flexible radio access below 6 GHz and providing new ultra-mobile broadband radio access above 6 GHz. It is expected that the flexible radio access consists of a new non-backward compatible radio access below 6 GHz in the new spectrum, and it is expected that the flexible radio access includes different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra Mobile Broadband is expected to include centimeter wave and millimeter wave spectrum that will provide opportunities for ultra mobile broadband access (e.g., indoor applications and hotspots). Specifically, ultra mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz, with centimeter wave and millimeter wave specific design optimizations. NR devices can be base stations, UEs, or other devices disclosed herein.

[0195] 3GPP has identified a variety of use cases that NR is expected to support, giving rise to various user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, 50 megabits per second and above everywhere, ultra-low-cost broadband access, in-vehicle mobile broadband), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automatic emergency calling, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality, to name a few. All of these use cases and others are considered in this article.

[0196] Fig.27A Methods and apparatus (such as those described and claimed herein) that may embody mobility signaling load reduction are illustrated. FIG. 18B to FIG. 2610. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (generally or collectively, the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d may be referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it is to be understood that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although in Fig.27A , Fig.27B , Fig.27C , Fig.27D ,and Fig.27E Each WTRU 102a, 102b, 102c, 102d, 102e is depicted as a handheld wireless communication device, but it should be understood that, depending on the various use cases considered for 5G wireless communications, each WTRU may include or be embodied in any type of device or apparatus configured to transmit and / or receive wireless signals, including: by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, a truck, a train, or an airplane, etc.).

[0197] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b and / or TRPs (transmission and reception points) 119a, 119b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one WTRU 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one WTRU 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it is to be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0198] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. As disclosed herein, the base station 114a may be configured to transmit and / or receive wireless signals in a specific geographic area, which may be referred to as a cell (not shown) of a method and system for reducing mobility signaling load. The base station 114b may be configured to transmit or receive wired or wireless signals in a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in an example, the base station 114a may include three transceivers, e.g., one transceiver for each sector of the cell. In an example, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0199] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0200] The base station 114b can communicate with one or more of the RRHs 118a, 118b and / or the TRPs 119a, 119b via a wired or air interface 115b / 116b / 117b, which can be any suitable wired communication link (e.g., cable, optical fiber, etc.) or a wireless communication link (e.g., radio frequency (RF), microwave, infrared light (IR), ultraviolet light (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b can be established by using any suitable radio access technology (RAT).

[0201] The RRHs 118a, 118b and / or the TRPs 119a, 119b may communicate with one or more of the WTRUs 102c, 102d via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0202] More specifically, as mentioned above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and the TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a wireless technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0203] In an example, the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and TRPs 119a, 119b and WTRUs 102c, 102d in the base station 114a and RAN 103b / 104b / 105b may implement a wireless technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A). In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology.

[0204] In an example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and the TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0205] As disclosed herein, the base station 114c in Figure 27 can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area (such as a business location, a residence, a vehicle, a campus, etc.) to implement methods and systems for reducing mobility signaling load. In an example, the base station 114c and the WTRU 102e can implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an example, the base station 114c and the WTRU 102d can implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In another example, the base station 114c and the WTRU 102e can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a micro cell or a femto cell. As in Fig.27A As shown in FIG. 1 , base station 114 b may have a direct connection to the Internet 110. Therefore, base station 114 c may not need to access the Internet 110 via core network 106 / 107 / 109.

[0206] The RAN 103 / 104 / 105 or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or voice over Internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0207] Although not shown in Figure 27, it will be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may employ an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0208] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may use the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0209] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.27A The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and the base station 114c, which may employ an IEEE 802 radio technology.

[0210] Fig.27B is a block diagram of an example device or apparatus (e.g., WTRU 102) configured for wireless communication according to the examples described herein. Fig.27B27 , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the example. Moreover, the example contemplates that the base stations 114a and 114b and / or nodes of the base stations 114a and 114b may represent, such as but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home evolved Node B (HeNB), a Home evolved Node B gateway, and a proxy node, among others, may include some or all of the elements depicted in FIG. 27 and described herein.

[0211] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.27B The processor 118 and the transceiver 120 are depicted as separate components, but it is to be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0212] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in an example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an example, the transmit / receive element 122 may be configured to transmit and / or receive RF signals. Fig.27ANot shown, but to be appreciated, the RAN 103 / 104 / 105 and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

[0213] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may use the same RAT as the RAN 103 / 104 / 105 or a different RAT.

[0214] As disclosed herein, some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links to implement methods and systems for mobility signaling load reduction. Fig.27A The WTRU 102c shown in FIG. 1 may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and a base station 114b, which may employ an IEEE 802 radio technology.

[0215] Fig.27B is a block diagram of an example device or apparatus (such as, for example, a WTRU 102 (eg, UE 229 or UE 228)) configured for wireless communication in accordance with the methods and systems for mobility signaling load reduction as disclosed herein. Fig.27BAs shown in the example WTRU 102, the example WTRU 102 may include: a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is to be understood that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with the example. Moreover, the examples herein contemplate that the base stations 114a and 114b and / or nodes of the base stations 114a and 114b may represent: such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home evolved Node B (HeNB), a Home evolved Node B gateway, and a proxy node, among others, may be included in Fig.27B Some or all of the elements depicted in the and may be exemplary embodiments of implementing the disclosed systems and methods for mobility signaling load reduction described herein.

[0216] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.27B The processor 118 and the transceiver 120 are depicted as separate components, but it is to be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0217] The send / receive element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an example, the send / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an example, for example, the send / receive element 122 may be a transmitter / detector configured to transmit and / or receive IR signals, UV signals, or visible light signals. In yet another example, the send / receive element 122 may be configured to transmit and receive both RF signals and optical signals. It is to be understood that the send / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0218] In addition, although Fig.27B 102 as a single element, but the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an example, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0219] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0220] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other examples, the processor 118 may access information from a memory, and may store data in a memory, that is not physically located on the WYRU 102, such as, for example, on a server or a home computer (not shown). The processor 118 may be configured to control a lighting pattern, image, or color on the display or indicator 128 in response to whether the setup of the mobility signaling is successful or unsuccessful in some of the examples described herein or otherwise indicating a reduction in the mobility signaling load and the status of associated components. Controlling the lighting pattern, image, or color on the display or indicator 128 may reflect the figures illustrated or discussed herein (e.g., Figure 22 to Figure 26 The message and process of reducing the mobility signaling load are disclosed herein. In addition to other things that can be displayed on the display 128, the message and process can be extended to provide an interface / API for the user to request resources related to resources and request, configure, or query information related to the mobility signaling load reduction via an input source (e.g., speaker / microphone 124, keypad 126, or display / touchpad / indicator 128).

[0221] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power provided to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0222] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that, while remaining consistent with the example, the WTRU 102 may acquire location information by any suitable location-determination method.

[0223] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors, such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, sensors, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0224] The WTRU 102 may be embodied in other devices or apparatuses, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes). The WTRU 102 may be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces (such as an interconnect interface that may include a peripheral device 138).

[0225] Fig.27C 1 is a system diagram of the RAN 103 and the core network 106 that may implement the methods and systems for mobility signaling load reduction as disclosed herein. As mentioned above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Fig.27CAs shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 134a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with the example.

[0226] As in Fig.27C As shown in FIG. 1 , Node Bs 140a, 140b may communicate with RNC 142a. In addition, Node B 140c may communicate with RNC 142b. Node Bs 140a, 140b, 140c may communicate with respective RNCs 142a, 142b via Iub interfaces. RNCs 142a, 142b may communicate with each other via Iur interfaces. Each of RNCs 142a, 142b may be configured to control the respective Node Bs 140a, 140b, 140c to which it is connected. In addition, each of RNCs 142a, 142b may be configured to implement or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0227] exist Fig.27C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it is to be understood that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0228] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0229] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuCS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0230] As mentioned above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0231] Fig.27D 1 is a system diagram of the RAN 104 and the core network 107 that may implement the methods and systems for mobility signaling load reduction as disclosed herein. As mentioned above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0232] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with the example. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an example, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0233] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink and / or downlink, etc. Fig.27D As shown in FIG. 1 , the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0234] exist Fig.27DThe core network 107 shown in FIG. 1 may include a mobility management entity (MME) gateway 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it is to be understood that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0235] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0236] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0237] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0238] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0239] Fig.27E 1 is a system diagram of the RAN 105 and the core network 109 in which the methods and systems for mobility signaling load reduction as disclosed herein may be implemented. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be discussed further below, the communication links between the different functional entities WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0240] As in Fig.27E As shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, but it is to be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the example. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an example, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy implementation, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of user profiles, routing to the core network 109, etc.

[0241] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0242] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and data transfer between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0243] As in Fig.27E , the RAN 105 may be connected to a core network 109. For example, the communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes protocols for facilitating data transmission and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements is depicted as part of the core network 109, it is to be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0244] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (such as the PSTN 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0245] Although in Fig.27E Not shown, but to be understood, the RAN 105 may be connected to other ASNs, and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0246] By giving the description herein and in certain existing 3GPP specifications Fig.27A , Fig.27B , Fig.27C , Fig.27D ,and Fig.27E The core network entities illustrated in the figure are identified by their names, but it should be understood that in the future, these entities and functions may be identified by other names, and certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig.27A , Fig.27B , Fig.27C , Fig.27D ,and Fig.27EThe specific network entities and functionality described and illustrated in the , and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0247] Fig.27F It can be reflected in Fig.27A , Fig.27B , Fig.27C , Fig.27D ,and Fig.27E 106 / 107 / 109, PSTN 108, Internet 110, or some nodes or functional entities in other networks 112) in one or more devices in the communication network illustrated in FIG. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software or stored or accessed by any method. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Unlike the main processor 91, the coprocessor 81 is an optional processor that performs additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the method and apparatus for mobility signaling load reduction disclosed herein (such as receiving context information or a handover message).

[0248] In operation, the CPU 91 fetches instructions, decodes instructions, and executes instructions, and transmits information to and from other resources via the computing system's primary data transfer path (system bus 8). Such a system bus connects the components in the computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0249] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally includes stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when executing an instruction. The memory controller 92 can also provide a memory protection function that separates processes within the system and separates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by the virtual address space of its own process; it cannot access memory within the virtual address space of another process unless memory shared between processes has been set up.

[0250] In addition, the computing system 90 may include a peripheral device controller 83 that is responsible for transmitting instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0251] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0252] Further, the computing system 90 may include a communication circuit system (such as, for example, a network adapter 97) that can be used to connect the computing system 90 to an external communication network (such as, for example, the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, or Fig.27A , Fig.27B , Fig.27C , Fig.27D ,and Fig.27E The communication circuit system can be used to perform the transmission and reception steps of certain devices, nodes, or functional entities described herein, either alone or in combination with the processor 91.

[0253] Fig.28An exemplary display (e.g., a graphical user interface) that can be generated based on the method and system of mobility signaling load reduction as disclosed herein is illustrated. A display interface 901 (e.g., a touch screen display) can provide text associated with mobility signaling load reduction in block 902, such as parameters related to RRC, method flow, and current conditions associated with RRC. The progress of any step disclosed herein (e.g., a message sent or the success of a step) can be displayed in block 902. In addition, a graphical output 902 can be displayed on the display interface 901. The graphical output 903 can be a topology of an apparatus implementing the method and system of mobility signaling load reduction, a graphical output of the progress of any method or system discussed herein, etc.

[0254] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions, which are executed on a processor of a device or computing system configured for wireless and / or wired network communications. Computer readable storage media include volatile and non-volatile removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for storing information, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to: RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disc (DVD) or other optical disk storage device, tape cassette, tape, magnetic disk storage device or other magnetic storage device, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

[0255] In describing the preferred methods, systems, or devices of the subject matter of the present disclosure (mobility signaling load reduction) as illustrated in the accompanying drawings, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

[0256] Various techniques described herein can be implemented in combination with hardware, firmware, software or, where appropriate, in combination thereof. Such hardware, firmware and software can reside in the equipment at each node in the communication network. Equipment can operate individually or in combination with each other to implement the method described herein. As used herein, the terms "equipment", "network equipment", "node", "device", "network node" etc. can be used interchangeably. In addition, the term "or" is usually used inclusively unless otherwise specified herein.

[0257] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any included methods. The patent protection scope of the invention is defined by the claims, and may include other examples that occur to a person skilled in the art (for example, skipping steps, combining steps, or adding steps between the exemplary methods disclosed herein, such as, Fig.18A , Fig.18B or Figure 22 to Figure 26 ). Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims or if they include equivalent structural elements with insubstantial differences from the literal language of the claims. It should be understood here that, as discussed herein, the use of physical channels generally provides the same implementation as the use of transport channels.

[0258] Among other things, the methods, systems, and apparatus described herein may provide means for mobility signaling load reduction. The method, system, computer-readable storage medium, or apparatus has means for performing the following operations: receiving a request to create a radio access network registration area; and based on the request, providing instructions for creating a radio access network registration area anchor associated with the radio access network registration area. The radio access network registration area anchor may locally manage the mobility of the mobile device. The radio access network registration area anchor may be an eNodeB. The radio access network registration area anchor may track the reachability status of mobile devices in the local radio access area. Consider this paragraph and all combinations (including removal or addition of steps) herein in a manner consistent with other parts of the detailed description.

[0259] A method, system, computer-readable storage medium, or apparatus for a radio access network registration area anchor point (RRAaP) has means for: receiving a reachability status of a mobile device, wherein the mobile device is within a radio access network registration area RRAaP device; receiving downlink data for the mobile device; and providing instructions for wirelessly transmitting the downlink data based on the reachability status of the mobile device. The RRAaP device may be a base station (e.g., an eNodeB). The RRAaP device may serve as a point of presence for a mobile device. The RRAaP device may serve as a replacement RRA node for a serving RRA node to serve as a temporary presence for a mobile device. Consider this paragraph and all combinations (including removal or addition of steps) herein in a manner consistent with the rest of the detailed description.

[0260] A method, system, computer-readable storage medium, or device is used to monitor a cell and create a radio access network registration area based on a received request. A method, system, computer-readable storage medium, or device is used to receive a request and create a radio access network registration area based on the received request. A method, system, computer-readable storage medium, or device is used to determine a mobility state of a device, wherein the device is a user device, and in response to the mobility state of the device (including a change in the radio access network registration area of ​​the device), provide a location update to a base station and wirelessly transmit data through an unlicensed channel. A method, system, computer-readable storage medium, or device is used to obtain a measurement value from a user device, determine a drift radio access registration area node based on the measurement value, provide a handover request to the drift radio access registration area node in response to determining the drift radio access registration area node, receive a response to the handover request, and perform a handover.

[0261] The method, system, computer-readable storage medium, or device has means for performing the following operations: paging a user equipment; in response to paging the user equipment, obtaining measurement information from the user equipment; based on the measurement information, updating the context of the user equipment; and using a base station to exchange the context of the user equipment. The base station can be a radio access network registration area anchor point, a drift radio access network registration area anchor point, or a serving radio access network registration area anchor point. The method, system, computer-readable storage medium, or device may also have means for performing the following operations: obtaining a paging message including core network update information from a mobility management entity gateway; and providing the paging message to the user equipment based on the paging message including the core network update information. The method, system, computer-readable storage medium, or device may also have means for performing the following operations: obtaining a paging message including emergency broadcast information from a mobility management entity gateway; and providing the paging message to the user equipment based on the paging message including the emergency broadcast information. The method, system, computer-readable storage medium, or device may also have a device for performing the following operations: obtaining a paging message including downlink user equipment data from a mobility management entity gateway; and providing a paging message to the user equipment based on the paging message including downlink user equipment data. Paging can be used to wake up the user equipment from a discontinuous reception mode. The measurement information may include a mobility history, a mobility state, a traffic pattern, a length of time (amount of time or distance) that the user equipment expects to remain in a connected mode, or a user equipment state to be converted to. The RRC_Grant_Less state is a connected state. In the first scenario, there is an RRC context, but there is no signaling connection (dedicated or public), no resources are assigned for it, there is no data radio bearer (DRB) connection, and in this state, a DRB cannot be established. The RRC_Grant_Less state is similar to the RRC_IDLE state in the sense that it has the attributes of the above-mentioned RRC_IDLE state. The difference from the RRC_IDLE state is that for the RRC_Grant_Less state, there may be unauthorized uplink data transmission. The device, method, or system may initiate an unlicensed uplink data transmission. The context of the user equipment may include the location of the user equipment. When in an unlicensed state, the device, method, or system may acquire data on an assigned transmission channel. This paragraph and all combinations (including removal or addition of steps) herein are considered in a manner consistent with the rest of the detailed description.

[0262] A method, system, or computer-readable storage medium has means for: paging a user equipment through a first base station; obtaining measurement information from the user equipment in response to paging the user equipment; updating the context of the user equipment based on the measurement information; and exchanging the context of the user equipment with a second base station. The first base station or the second base station may be a radio access network registration area anchor point. The first base station or the second base station may be a drift radio access network registration area anchor point. The first base station or the second base station may be a serving radio access network registration area anchor point. Consider this paragraph and all combinations thereof (including removal or addition of steps) in a manner consistent with the rest of the detailed description.

[0263] A method, system, or computer-readable storage medium has means for performing the following operations: detecting a change associated with a user equipment, the change associated with the user equipment including a change in a radio access network registration area of ​​the user equipment; in response to detecting the change associated with the user equipment, performing a location update for the user equipment; and providing the location update to a base station through an unlicensed channel. An unlicensed channel may be assigned. The method, system, or computer-readable storage medium has means for performing carrier sensing to obtain access to an unlicensed channel. The method, system, or computer-readable storage medium has means for performing the following operations: receiving a paging based on the location update; and providing a response to the paging through an unlicensed channel. Detecting the change associated with the user equipment may further include: a mobility metric change reaching a threshold, wherein the mobility metric includes a number of handovers occurring during a specified period. Detecting the change associated with the user equipment may further include: a mobility metric change reaching a threshold, wherein the mobility metric includes a number of cell reselections. The unlicensed channel may be a physical channel or a transport channel. The base station may be a drift radio access network registration area anchor or a serving radio access network registration area anchor. This paragraph and all combinations thereof (including removal or addition of steps) are considered in a manner consistent with the rest of the detailed description.

[0264] A computer program product comprising a computer readable medium having stored thereon a computer program comprising program instructions, the computer program being loadable into a data processing unit and being adapted to cause the data processing unit to perform method steps according to any of the steps disclosed herein when the computer program is run by the data processing unit.

Claims

1. A user equipment, comprising: processor; as well as a memory coupled to the processor, the memory including executable instructions stored thereon, the executable instructions, when executed by the processor, causing the processor to perform operations including: operating in an unlicensed radio resource control (RRC) state, wherein the user equipment has established an RRC connection, wherein the user equipment stores an RRC context, and wherein no data radio bearer (DRB) connection exists; Detecting a change associated with the user equipment while the user equipment is operating in the unlicensed RRC state, the change associated with the user equipment comprising a change of a radio access network registration area (RRA) of the user equipment, wherein detecting the change associated with the user equipment further comprises: a first mobility metric reaching a first threshold, wherein the first mobility metric comprises a number of cell reselections that occurred during a specified time period; determining to perform location update of the user equipment based on a change of the RRA of the user equipment; and Sending a location update of the user equipment.

2. The user equipment of claim 1, wherein detecting a change associated with the user equipment further comprises a second mobility metric reaching a second threshold, wherein the second mobility metric comprises a number of handovers occurring during a specified period of time.

3. The user equipment of claim 1 , wherein the operations further comprise providing the location update to a base station via an unlicensed channel, wherein uplink data transmission occurs using the unlicensed channel without first requesting communication resources from the base station.

4. The user equipment according to claim 1, wherein: The user equipment has an unlicensed channel assigned or configured.

5. The user equipment of claim 4, further comprising operating in an RRC connectionless state, wherein there is an RRC context and signaling connection including location and reachability.

6. The user equipment of claim 1, the operations further comprising providing a location update of the user equipment to a base station via a grant-based channel.

7. The user equipment of claim 1, the operations further comprising providing a location update of the user equipment to a base station via a grant-based channel, wherein the grant-based channel is assigned.

8. The user equipment according to claim 1, wherein: The user equipment is provided with a threshold value related to a speed metric.

9. The user equipment of claim 1, the operations further comprising storing in the user equipment a connected RRC context including location and reachability without dedicated RRC connection signaling.

10. A method for performing wireless communication, the method comprising: operating a user equipment in an unlicensed radio resource control (RRC) state, wherein the user equipment has established an RRC connection, wherein the user equipment stores an RRC context, and wherein no data radio bearer (DRB) connection exists; Detecting a change associated with the user equipment while the user equipment is operating in the unlicensed RRC state, the change associated with the user equipment comprising a change of a radio access network registration area (RRA) of the user equipment, wherein detecting the change associated with the user equipment further comprises: a first mobility metric reaching a first threshold, wherein the first mobility metric comprises a number of cell reselections that occurred during a specified time period; determining to perform location update of the user equipment based on a change of the RRA of the user equipment; and Sending a location update of the user equipment.

11. The method of claim 10, further comprising operating in an RRC connectionless state.

12. The method of claim 10, further comprising providing a location update of the user equipment to a base station via a grant-based channel.

13. The method of claim 10, wherein detecting a change associated with the user equipment further comprises a second mobility metric reaching a second threshold, wherein the second mobility metric comprises a number of handovers occurring during a specified period of time.

14. A system comprising: one or more processors; as well as a memory coupled to the one or more processors, the memory including executable instructions stored thereon, the executable instructions, when executed by the one or more processors, causing the one or more processors to perform operations, the operations comprising: operating a user equipment in an unlicensed radio resource control (RRC) state, wherein the user equipment has established an RRC connection, wherein the user equipment stores an RRC context, and wherein no data radio bearer (DRB) connection exists; Detecting a change associated with the user equipment while the user equipment is operating in the unlicensed RRC state, the change associated with the user equipment comprising a change of a radio access network registration area (RRA) of the user equipment, wherein detecting the change associated with the user equipment further comprises: a first mobility metric reaching a first threshold, wherein the first mobility metric comprises a number of cell reselections that occurred during a specified time period; determining to perform location update of the user equipment based on a change of the RRA of the user equipment; and Sending a location update of the user equipment.

15. The system of claim 14, the operations further comprising providing location updates of the user equipment to a base station via a grant-based channel.

16. The system of claim 14, wherein detecting a change associated with the user equipment further comprises a second mobility metric reaching a second threshold, wherein the second mobility metric comprises a number of handovers occurring during a specified period of time.

Images