Method and apparatus for unlicensed operation

Abstract

Methods and apparatus for unlicensed operation are disclosed. Current methods for transmitting uplink data in a network often require resources to be licensed. In the example, a node or apparatus can configure multiple devices to operate in unlicensed mode according to corresponding unlicensed access allocations. Unlicensed operation can be managed, for example, to meet the reliability and latency requirements, as well as battery life requirements, of different types of devices. For example, state transitions between unlicensed and licensed modes can be managed.

Description

[0001] This application is a divisional application of the invention patent application filed on June 15, 2017, entitled "Method and Apparatus Performed During Unlicensed Operation" with application number 201780049811.2.

[0002] Cross-reference to related applications

[0003] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 350,550, filed June 15, 2016; U.S. Provisional Patent Application No. 62 / 373,691, filed August 11, 2016; and U.S. Provisional Patent Application No. 62 / 401,062, filed September 28, 2016, the disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0004] This disclosure relates to methods and apparatus for unlicensed operation. Background Technology

[0005] International Mobile Telecommunications (IMT) in 2020 and beyond (e.g., IMT 2020) envisions expanding and supporting a diverse range of use cases and applications that will continue to extend beyond current IMT. Furthermore, a wide variety of capabilities can be tightly coupled with these different use cases. Example use cases include enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), massive machine-type communication (mMTC), and network operation. Example operating characteristics of eMBB may include macro and small cells, 1ms latency (air interface), and support for high mobility. Example operating characteristics of URLLC may include low to medium data rates (e.g., 50kbps-10Mbps), less than 1ms air interface latency, 99.999% reliability and availability, low connection establishment latency, and mobility from 0-500km / h. Example operating characteristics of mMTC may include low data rates (e.g., 1-100kbps), and high-density equipment (e.g., 200,000 / km). 2 Network operations address a variety of topics, including network slicing, routing, migration and interoperability, and energy saving. These include requirements such as latency, low power consumption (e.g., up to 15 years of battery life), and asynchronous access.

[0006] In contrast to the New Radio (NR) requirements, 3GPP TR 38.913 defines the scenarios and requirements for New Radio (NR) technologies. Key performance indicators (KPIs) for URLLC and mMTC equipment are summarized in Table 1 below:

[0007] Table 1 – KPIs for URLLC and mMTC devices

[0008]

[0009] System Information (SI) is information broadcast by the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). This message needs to be acquired by the UE to enable it to access and operate within the network. SI is divided into Main Information Blocks (MIBs) and numerous System Information Blocks (SIBs). A high-level description of MIBs and SIBs is provided in 3GPP TS 36.300. A detailed description is available in 3GPP TS 36.331. Examples of SI are shown in Table 2 below.

[0010] Table 2 - System Information

[0011]

[0012] Now let's turn to UE information state. After power-on, the UE can be in different states—such as... Figure 1 The "idle" or "packet communication" states shown are fully managed through EPS Mobility Management (EMM), EPS Connection Management (ECM), and Radio Resource Control (RRC) functions. Details are summarized in Table 3. Figure 2 (and Table 4).

[0013] Table 3 UEs in EMM, ECM, and RRC states

[0014]

[0015] Table 4 shows the UE location information set in each EPS entity.

[0016]

[0017] More example details are shown in Figure 3 middle, Figure 3 The examples illustrate the RRC_Idle and RRC_CONNECTED states. In the RRC_Idle state, there is no RRC context in the Radio Access Network (RAN), and the UE does not belong to a specific cell. No data transfer occurs in RRC_Idle. The UE is in a low-power state and listens for control traffic (control channel broadcasts), such as paging notifications for inbound services and changes in system information. In RRC_Idle, a given UE can first synchronize itself with the network by listening to network broadcasts, and then can request to be moved to the "connected" state to establish an RRC context between the RAN and the UE. In LTE Advanced, the target time is further reduced to 50ms.

[0018] In contrast to the RRC_CONNECTED state, there exists an RRC context and resource allocation for the UE. The cell to which the UE belongs is known and has been configured with the UE's identifier (Cell Radio Network Temporary Identifier (C-RNTI)) for signaling purposes between the UE and the network. Under RRC_CONNECTED, the UE is in a high-power state and ready to send or receive data to or from an Evolved Node B (eNB). Discontinuous Receive (DRX) is used to conserve UE power under RRC-connected conditions. In some cases, each radio transmission, however small, forces a transition to the high-power state. Then, once the transmission is complete, the radio remains in this high-power state until the inactivity timer expires. The size of the actual data transfer does not affect the timer. Additionally, the device must then cycle through several more intermediate states before it can return to idle. It is here to recognize the "energy tail" generated by the timer-driven state transitions, such as... Figure 4 As shown, this makes periodic switching a very inefficient network access mode on mobile networks. Summary of the Invention

[0019] It is recognized here that unlicensed operation can be better managed, for example, to meet the reliability and latency requirements of URLLC and the battery life requirements of mMTC devices. For example, state transitions between unlicensed and licensed operations can be better managed.

[0020] In various examples, fast synchronization for contention-based unlicensed uplink transmission may include synchronization pilots for UL frequency and time synchronization, timing advance adjustments estimated by the UE, transmit power control for contention-based unlicensed uplink transmission, UL path loss estimation based on measurements of the DL reference signal and DL transmit power in the DCI, and / or quasi-closed-loop power control using power information collected by the UE.

[0021] This summary is provided to introduce, in a simplified form, some concepts further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the limitations of addressing any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0022] A more detailed understanding can be obtained from the following description, which is given as an example in conjunction with the accompanying drawings, in which:

[0023] Figure 1 This shows the status of the operation associated with the example user equipment (UE);

[0024] Figure 2Examples of EMM, ECM, and Radio Resource Control (RRC) state transitions are shown;

[0025] Figure 3 An example RRC protocol state machine is shown;

[0026] Figure 4 An example of RRC-connection discontinuous reception (DRX) is shown;

[0027] Figure 5 Examples of use cases for power grids, including those in smart cities, are shown.

[0028] Figure 6 This illustrates an example RRC operation state according to an example embodiment;

[0029] Figure 7 An example RRC operation state is shown according to another example embodiment;

[0030] Figure 8 Depict downlink synchronization and reference pilots;

[0031] Figure 9A and Figure 9B A flowchart is drawn according to an example embodiment for a permissionless operation utilizing fast synchronization;

[0032] Figure 10 An example of open-loop transmit power control for unlicensed UL is depicted;

[0033] Figure 11A and Figure 11B A flowchart is drawn according to an example embodiment for unlicensed operation utilizing open-loop power control;

[0034] Figures 12A-13B Describes a call flow for an unlicensed UL transmitted for an mMTC device according to an example embodiment;

[0035] Figure 14A-15B Another example call flow for unlicensed UL transmission for a URLLC device is described according to another example embodiment;

[0036] Figure 16A-17B An example process for unlicensed UL transmission for an mMTC device is described according to an example embodiment;

[0037] Figures 18A-19B A sample process for unlicensed UL transmission for a URLLC device is described according to an example embodiment;

[0038] Figure 20A and Figure 20B A sample call flow for registration and license-free setup is described according to an example embodiment;

[0039] Figure 21A and Figure 21B An example call flow for unlicensed and licensed UL transmission for a URLLC device is described according to an example embodiment;

[0040] Figure 22A and Figure 22B An example call flow for unlicensed and licensed UL transmissions for an mMTC device is depicted according to an example embodiment;

[0041] Figure 23 This is an example GUI for UE configuration based on an example embodiment;

[0042] Figure 24A The diagram illustrates one embodiment of an example communication system that implements the methods and apparatus described and claimed herein;

[0043] Figure 24B This is a block diagram of an example apparatus or device configured for wireless communication according to embodiments illustrated herein;

[0044] Figure 24C This is a system diagram of an example radio access network (RAN) and core network according to an example embodiment;

[0045] Figure 24D This is another system diagram of the RAN and core network according to another embodiment;

[0046] Figure 24E This is another system diagram of the RAN and core network according to another embodiment; and

[0047] Figure 24F It is possible. Figure 24C -F is a block diagram of an exemplary computing system 90 comprising one or more devices of a communication network. Detailed Implementation

[0048] First, for different Radio Access Network (RAN) architectures, the mechanisms described herein can be implemented at NR nodes, Transmit and Receive Points (TRPs) or Remote Radio Headers (RRHs), as well as at the central controller or control functions within the RAN slice. Unless otherwise specified, the mechanisms described herein can be applied to TRPs, RRHs, central controllers, and control functions in different RAN architectures.

[0049] Now for reference Figure 5The illustration shows an example use case in which different sensors or monitoring devices of an example smart city's power grid system 500 are depicted. Sensors in a smart home 502 (e.g., massive machine-type communication (mMTC) devices) can send power consumption data weekly or monthly with very lenient latency requirements. Sensors on the smart city's power transmission network 504 (e.g., ultra-reliable low-latency communication (URLLC) devices) can continuously monitor power levels and periodically report to a power grid monitoring system 506, but when an abnormal power level is detected, for example, recognizing here that sensor 504 needs to immediately send an alert to power grid monitoring system 506, so that power grid monitoring system 506 can shut down the faulty power supply system and enable an immediate backup power supply system to avoid potential damage to the smart city's power grid system 500 and to avoid negative impacts on the operation of the smart city.

[0050] As another example use case, forest fire monitoring sensors (e.g., mission-critical MTC devices) may periodically transmit small amounts of data with very low duty cycles, but they may need to transmit one or more fire warning messages immediately and reliably. These devices can be sparsely located and can cover large areas of forest. These devices may also have limited battery life (e.g., 15 or 20 years).

[0051] As yet another example use case, medical equipment in ambulances can be used to transport patients to the emergency room. For instance, ultra-reliable low-latency communication (URLLC) devices can transmit patient temperature and blood pressure data, as well as cardiac monitoring images, to the hospital and the doctor's office. It should be understood that the embodiments described herein can be applied to various use cases as needed.

[0052] Use cases can leverage both URLLC and mMTC devices. For example, an unconstrained URLLC device can support both low UL data rate transmission and medium UL data rate transmission with ultra-low latency and very high reliability. A battery-constrained URLLC or mission-critical MTC device may support low UL data rate transmission with ultra-low latency and very high reliability. An mMTC device with battery constraints and dense connectivity may support pre-scheduled or long-latency-tolerant low UL data rate transmission.

[0053] As illustrated by the use cases above, if current licensed UL data transmissions are used in LTE systems, URLLC devices may fail to meet latency requirements for UL data transmissions. The signaling overhead for UL licensed messages can be significant compared to infrequent small UL data transmissions for mMTC devices. This presents a challenge to the battery life requirements of mMTC devices. To reduce UL transmission signaling overhead for mMTC devices and reduce UL transmission latency for URLLC devices, various access mechanisms can be used, including, for example, unlicensed UL transmission, contention-based transmission, and non-orthogonal multiple access. As described below, embodiments implement unlicensed UL transmissions that meet the ultra-reliability and low-latency requirements of non-power-constrained URLLC devices. Furthermore, embodiments described herein implement unlicensed UL transmissions that meet the battery life requirements of mMTC devices.

[0054] Now for reference Figure 4 After sending small packet data 402, the device may have to remain in a high-power transmit state until the inactive timer expires, and then it must cycle through many short DRX cycles 404 with reduced sleep time before a longer DRX cycle 406, during which the device can sleep for a longer duration. It is understood that these timer-driven state transitions can make low-duty-cycle, small-data transfers inefficient. Based on various examples, dual operating states are now described, where the device can be instructed by a higher layer or NR node to operate in an unlicensed operating state for low-duty-cycle, small-data communication, e.g., to reduce latency and conserve battery power by utilizing reduced signal strength and extended timers; or to operate in a licensed operating state, e.g., for more frequent medium or high-capacity data communication.

[0055] Example implementations of this dual-state operation can be performed by traffic monitoring equipment. In some cases, the traffic monitoring equipment can operate in a no-permission operation state to periodically send small traffic report data, and the traffic monitoring equipment can switch to a permitted operation state to upload larger image data, such as image data related to traffic events (e.g., traffic accidents). Higher layers can configure or direct the operation of the equipment in either permitted or no-permission operation mode after power-on. In the example, mission-critical MTC equipment can operate in no-permission operation mode with reduced signaling to conserve battery power, and a digital patient monitor without battery constraints can operate in permitted operation mode to continuously send large image files.

[0056] In an alternative embodiment, the NR node can configure a given UE already operating in a licensed state to switch to unlicensed operation. Similarly, the NR node can configure a given UE operating in an unlicensed state to switch to licensed operation. The NR node can configure a UE to operate in an unlicensed state based on various information (inputs), such as, but not limited to, service type, bearer type, traffic flow type, network slice type and / or network slice-related requirements, the set of physical layer parameters or frame structure in use, measurement reports from the UE (e.g., RSRP, RSRQ, battery level, buffer status reports, etc.), QoS attributes (e.g., latency, reliability, guaranteed UL bit rate, minimum UL bit rate, maximum UL bit rate, etc.), and / or a request from the UE to operate in this state.

[0057] In some examples, a UE may request the network to be configured for unlicensed operation. This request may be allowed or permitted. Similarly, based on various inputs such as the example inputs described above, the network may configure a UE operating in an unlicensed state to switch to operating in a permitted state. In some examples, a UE may send a capability bit indication to the network indicating its ability to operate in various states (e.g., unlicensed or permitted). Similarly, the network may send an indication to the UE that it can operate in both states (e.g., unlicensed and permitted). This indication may be signaled to the UE via public RRC signaling (e.g., existing in the SIB via some System Information Block (SIB) or Information Element (IE)). Alternatively, the indication may be signaled to the UE via dedicated signaling (e.g., an RRC unicast message to the UE).

[0058] In another embodiment, the UE can autonomously transition between an unlicensed state and a licensed state. In some cases, the UE can determine the transition based on auxiliary information signaled to the UE via public RRC signaling or dedicated signaling (e.g., RRC unicast messages or MAC CE signaling). This transition determination at the UE can be based on various information, such as, but not limited to: service type, bearer type, traffic flow type, network slice type, the set of physical layer parameters or frame structure in use, measurement reports from the UE (e.g., RSRP, RSRQ, battery level, buffer status reports, etc.), and QoS attributes (e.g., latency, reliability, guaranteed UL bit rate, minimum UL bit rate, maximum UL bit rate, etc.).

[0059] In some cases, the unlicensed state can be regarded as a connected state from the perspective of the core network, enabling the maintenance of signaling connections between the core network (e.g., next-generation core) and NR nodes (e.g., next-generation RAN nodes).

[0060] In the example unlicensed state, a given UE can perform RAN-level registration with the RAN. The UE identifier used for this registration can be a RAN-level identifier or a core network-level identifier. In some cases, this registration follows a RAN-specific process and is therefore transparent to the core network. The reachability state associated with the UE can be maintained in the RAN while the UE is in an unlicensed state. Similarly, the mobility state associated with the UE can be maintained in the RAN while the UE is in an unlicensed state. In the unlicensed state, mobility can be controlled by the UE using assistance (information) from the NR node. In the unlicensed state, the UE can also perform registration with the core network, such as by performing an attachment procedure.

[0061] Now for reference Figure 6 Example dual-state operation 600 is illustrated. Dual-state operation can be implemented by a UE capable of operating in both an unlicensed state (or mode) 602 and a licensed state (or mode) 604. Dual-state operation 600 can allow the UE to transition from unlicensed state 602 to licensed state 604 if the UE receives a licensed operation command 606 from its higher layer (e.g., NAS or application layer). As an example, the UE's application layer can identify an incident based on traffic surveillance and then instruct the UE's Radio Resource Control (RRC) state to switch to licensed state 604 to upload images or video of the incident. The UE's RRC can alternatively transition from licensed state 604 to unlicensed state 602 once it receives an unlicensed operation command 608 from its higher layer. In some cases, the transition between licensed state 602 and unlicensed state 604 can be indicated by the NR node or determined by the UE. Therefore, licensed operation command 606 and unlicensed operation command 608 can be received from the RAN node (e.g., NR node) or generated within the UE. Unlicensed state 602 can include inactive state 602a and active state 602b, so the UE can transition from inactive state 602a to active state 602b within the unlicensed state, for example, when the UE has data to receive or transmit. In some cases, the UE transitions back to inactive state 602a immediately after receiving or transmitting small data packets. In the example, the UE does not need to go through short DRx and long DRx cycles to return to inactive state 602a after receiving or transmitting small packet data within unlicensed state 602. Therefore, signaling and cycles can be reduced in unlicensed state 602 compared to licensed state 604, thereby improving latency and battery life. While in inactive state 602a, the UE can operate in power-saving mode, which uses less power than sleep mode within DRx cycles to conserve battery power.

[0062] Various context information associated with the UE (referred to as UE context) can be included at the NR node to avoid message exchange with the core network (CN) via an interface similar to S1 for re-establishing radio connections or bearers when transitioning from inactive state 602a to active state 602b. Therefore, in some examples, fewer messages are exchanged when the UE transitions from inactive state 602a to active state 602b compared to when the UE transitions from RRC_idle state 604a to RRC_CONNECTED state 604b within licensed state 604. Example context information includes, but is not limited to: IMSI, LTE K, default APN, EPSQoS subscription profile, access profile, NAS secure context, last globally unique temporary UE identifier (GUTI), last tracking area indicator (TAI), last S1 TEID, C-RNTI, AS secure context, last bearer ID, etc. Context information can reduce message exchange, thereby conserving UE battery power, such as for UEs with battery-limited sensors that have static mobility.

[0063] To conserve battery power, this document describes UEs that do not need to frequently listen to control channel broadcasts for paging notifications for inbound services or for changes in system information, based on example embodiments, because their services consist of uplink small data and downlink triggers or maintenance messages from the IoT service system. Such downlink triggers and messages can be infrequent and can be pre-scheduled in many scenarios. Therefore, in some cases, it is recognized that the timer used for waking up to listen to the control channel can be significantly extended by device type, service, mobility, etc. As an example, a sparsely distributed forest fire monitoring sensor can wake up once a day if there is no UL transmission, which is significantly longer than the wake-up timer under permitted operating state 604. Additionally, UEs such as sparsely distributed forest fire monitoring sensors can wake up before sending a report or "keep alive" message to the NR node to first check the control channel broadcast.

[0064] In another example, to conserve battery power, a UE, such as an MTC device monitoring forest fires, can only wake up to perform measurements when it needs to send a report or keep-alive message to the NR node. Additionally, in this example, the UE can only perform cell reselection if the link measurement result falls below a predetermined threshold. Therefore, based on various parameters of the UE, such as device type, service, and mobility, the timer used for waking up for measurement and / or cell reselection can be significantly extended compared to other devices.

[0065] In yet another example, to conserve battery power, it is understood that a UE with low or static mobility can be configured to infrequently (e.g., once a day) transition to an active state to send an Accessibility and Mobility State Update (RMSU) to the NR node. In this example, the RMSU information can be sent to the NR node along with a UL report or "keep alive" message associated with the UE in the Information Element (IE) field.

[0066] In an example embodiment, one of the co-located (i.e., virtually grouped) RFID tags or wearable devices with medium or high mobility can send RMSU messages for virtual group scheduling or randomization.

[0067] Refer again Figure 6 While in active state 602b, the UE can operate at high power for transmitting or receiving, then return to inactive state 602b and thus directly operate at lower power without experiencing DRx cycles 604d and 604e as directly as in the RRC_CONNECTED state 604b of granted state 604. This avoids unnecessary DRx cycles for occasional small data transmissions, which can also reduce signaling for improved latency and battery life performance. In an alternative embodiment, ungranted state 602 may simply include inactive mode 602 with no data transmission. Ungranted channel resources in this case may only be used for resource allocation requests for predefined specific services such as URLLC services. Continuing the example, when the UE is granted resources, the UE can then transition to granted state 604 (e.g., RRC connected state 604b of the NRRRC equivalent state) before transmitting UL data.

[0068] Therefore, mechanisms for permissionless and permitted transmission are disclosed based on the various embodiments described herein. The permissionless and permitted states are further described below. Examples of permissionless and permitted operations with various state transitions between permissionless and permitted are now described in more detail.

[0069] First, switch to a permissionless operation, such as... Figure 4 As shown, in the permitted state, the device can cycle through many DRx cycles 404 and 406 after sending small packet data 402, and then the device can transition to the RRC_idle state 604a. Figure 6 It is recognized here that these timer-driven state transitions can make low-duty-cycle, small-data transfers inefficient.

[0070] Now for reference Figure 7Another example of dual-state operation 700 is illustrated. Dual-state operation 700 can be implemented by a UE capable of operating in both an unlicensed state (or mode) 702 and a licensed state (or mode) 704. Dual-state operation 700 allows the UE to transition from unlicensed state 702 to licensed state 704 if the UE receives a license command 706 from its higher layer (e.g., NAS or application layer) or from an NR node. As described above, the UE can be configured or instructed to operate in licensed state 704, for example, for more frequent medium or high-capacity data communication. Higher-layer or NR nodes can configure the UE to operate in an unlicensed state 702 based on various information such as, but not limited to: service type, bearer type, traffic flow type, network slice type and / or requirements, the set of physical layer parameters or frame structure in use, measurement reports from the UE (e.g., RSSI, RSRP, RSRQ, QCI, battery level, buffer status reports, etc.), QoS attributes (e.g., latency, reliability (e.g., bit error rate or packet error rate, guaranteed UL bit rate, minimum UL bit rate, maximum UL bit rate, etc.) and / or requests from the UE to operate in this state.

[0071] In another example embodiment, the UE can autonomously switch between an unlicensed state 702 and a licensed state 704. The UE can make this decision based on auxiliary information signaled to it via, for example, public RRC signaling or dedicated signaling (e.g., RRC unicast messages or MAC CE signaling). This switching decision at the UE can be based on service type, bearer type, traffic flow type, network slice type, the set of physical layer parameters in use or frame structure, measurement reports from the UE (e.g., RSRP, RSRQ, battery level, buffer status reports, etc.), QoS attributes (e.g., latency, reliability, guaranteed UL bit rate, minimum UL bit rate, maximum UL bit rate), etc.

[0072] In some examples, the unlicensed state 702 can be a registered state from the core network's perspective, allowing the core network to know information about the UE (e.g., the UE's environment, its current location within the cell, its tracking area, etc.). The UE can register with the core network via an attachment process. Alternatively, the UE can be configured and / or pre-registered through system management in a controlled and secure network. Therefore, the UE can be in a core registered state.

[0073] In some examples, the unlicensed state 702, from the core network perspective, includes either a half-connected state 702a or a connected state 702b, where a signaling connection (e.g., similar to NR S1) is maintained between the core network and the NR node (RAN node or device). In some cases, the half-connected state 702a may also be referred to as an inactive state. In some examples, radio and network resources have been allocated when the UE is in the half-connected state 702a or connected state 702b. In some examples, a UE is considered to be in connected state 702b if dedicated resources are specifically allocated to the UE. In some examples, a UE is considered to be in half-connected state 702a if dedicated resources are allocated to a group of UEs and the UEs are authorized to share the resources of that group. Therefore, in the example of half-connected state 702b, the UE can share dedicated resources with other UEs.

[0074] Unlicensed state 702 includes half-connected state 702a and connected state 702b, such that when a UE is in unlicensed state 702, from the RAN's perspective, the UE can be in either half-connected state 702a or connected state 702b. When the UE is in connected state 702b, dedicated radio resources can be specifically allocated to the UE. For example, resources can be pre-configured for the UE so that it can use these resources to perform autonomous UL transmissions without explicit UL permission. When the UE is in half-connected state 702, dedicated radio resources can be allocated to a group of UEs, and UEs can be authorized to share radio resources. For example, in half-connected state 702a, the UE can share dedicated resources with other UEs via contention-based radio network access.

[0075] For the sake of simplicity in the examples described here, half-connection state 702a is often used for illustrative purposes, but unless otherwise specified, the mechanisms proposed herein apply to half-connection state 702a and connection state 702b of unlicensed state 702.

[0076] In unlicensed state 702, the UE can perform RAN-level registration with the RAN. The UE identifier used for this registration can be a RAN-level identifier or a core network-level identifier. In some cases, the process for this registration can be RAN-specific and therefore transparent to the core network. The UE's reachability and / or mobility status in unlicensed state 702 can be maintained in the RAN. In unlicensed state 702, in some cases, mobility can be UE-controlled mobility with assistance (information) from the NR node.

[0077] In some cases, the transition between the granted state 704 and the ungranted state 702 can be determined by the UE, for example, by sending a request to the NR node after a certain criterion for the state transition is met. The state transition criterion may be based on the following information, presented as examples and not as limitations: service type, bearer type, traffic flow type, network slice type and / or requirements associated with the UE, the set of physical layer parameters or frame structure that the UE can or can be configured with, measurements or statuses collected by the UE (e.g., RSSI, RSRP, RSRQ, QCI, battery level, buffer status reports, etc.) and / or the UE's data transmission QoS requirements (e.g., latency, reliability such as bit error rate or packet error rate, guaranteed bit rate, minimum bit rate and / or maximum bit rate, etc.).

[0078] As stated above, and as Figure 7 As illustrated, in some cases, when data needs to be received or transmitted, the UE transitions from RRC_Idle state 708 to half-connected state 702a (RRC_Half-Connected), and then the UE can immediately transition back to RRC_Idle state 708 after receiving or transmitting, for example, small amounts of data. Therefore, the UE does not need to go through short DRx 704a and long DRx 704b cycles to return to RRC_Idle state 708, as it might be in licensed state 704. This reduces signaling and cycles compared to licensed state 704, and can, for example, improve latency and battery life.

[0079] In some cases, when operating in RRC_Idle state 708, the UE operates in a power-saving mode that uses less power than in sleep mode during DRx cycles 704a and 704b. In examples, various UE scenarios as described above can be included at the NR node to avoid message exchange with the core network (CN) for re-establishing radio connections or bearers when transitioning from RRC_Idle state 708 to active state 702c (e.g., half-connected state 702a). In some cases, when operating in active state 702c, such as when operating in half-connected state 702a of unlicensed mode 702, the UE maintains high power for transmitting or receiving until an ACK or NACK is received, or until a timer expires. When an ACK or NACK is received or the timer expires, the UE can directly return to the RRC_Idle state 708 without going through the DRx cycle as it would in the RRC_CONNECTED state 704c under the granted state 704. This avoids unnecessary DRx cycles for occasional small data transmissions and reduces signaling for improved latency and battery life performance.

[0080] In an alternative embodiment, unlicensed state 702 may not include data transmission. Unlicensed channel resources in this case can be used to request resource allocation for predefined specific services such as, for example, URLLC services. When resources are granted to the UE via a response from the NR node, the UE can then transition to licensed state 704 (e.g., RRC-connection 704c of licensed state 704) before transmitting data for ultra-reliability (UL).

[0081] The shift now towards fast synchronization for unlicensed UL transmissions is problematic for mMTC devices, where the overhead and latency of the current Random Access Channel (RACH) procedure can be excessive for small packet transmissions. To avoid this cost, RACH-free unlicensed UL transmission can further reduce the signaling load in both DL and UL required for simultaneous active UE access to the radio network. For URLLC devices, it is recognized that UL transmission is expected to be initiated whenever an urgent UL packet occurs at the UE, and therefore RACH-free and unlicensed UL transmission can reduce signaling overhead to further accelerate UL data transmission. In some cases, the RACH-free and unlicensed UL access schemes described herein reduce the number of signaling messages exchanged between the radio access network and the UE, thereby providing the potential for URLLC devices to accelerate data transmission with reduced latency and also reducing the energy consumption required by mMTC devices (e.g., due to shorter radio uptime). This can also lead to an increase in the number of UEs that can simultaneously access the radio network, thereby increasing system capacity.

[0082] In some cases, contention-based unlicensed access can provide the option to send UL data packets immediately following the DRx, for example, by omitting the random access procedure. However, in LTE, UL synchronization is achieved through the random access procedure, where the eNodeB estimates the initial timing advance based on the PRACH sent by the UE. The PRACH is used as a timing reference for the uplink during the UE's initial access. The eNodeB sends a timing advance command in the Random Access Response (RAR). Once the UE is in connected mode, the eNodeB continues to estimate the timing advance and sends a timing advance command MAC control element to the UE if correction is needed. In the example, as long as the UE sends some uplink data (PUSCH / PUCCH / SRS), the eNodeB can estimate the uplink signal arrival time, which can then be used to calculate the required timing advance value. Using broadcast messages sent by the NR node, in some cases such as unlicensed access, a given UE is DL synchronized rather than UL synchronized. It is recognized here that UL synchronization is critical in some cases, for example, when the cell covers a certain distance.

[0083] In some examples, to achieve UL synchronization relative to a specific eNB, it may be required that the UE transmit UL frames with timing advance (TA) to align with the eNB's time frame in the LTE system. However, in some cases, the timing advance (TA) is unknown, and tight UL synchronization between UEs achieved via the RACH procedure may not be possible. Nevertheless, in some cases, a certain degree of synchronization may still be required for OFDM-based NOMA access schemes. According to various embodiments, fast synchronization for RACH-free and unlicensed UL transmission reduces latency for URLLC devices and reduces signaling for mMTC devices.

[0084] General reference Figure 8 The diagram illustrates the DL synchronization signal and DL reference signal during the unpermitted interval, with particular reference to... Figure 9A and Figure 9B The UL TA is estimated using the DL synchronization signal and / or DL ​​reference signal. In one example, at 902, the UE powers on. At 904, the UE performs cell search and synchronization after power-on. At 906, the UE can connect to the RAN to register with the RAN. At 908, the UE is in a licensed state (e.g., licensed state 704), and the UE can send and receive licensed UL and DL messages respectively via the network. At 910, the UE determines, or is indicated by the radio network, whether it has UL data that should be sent using an unlicensed mode, such as unlicensed mode 702. If so, at 912, the UE establishes or updates its unlicensed operation. At 915, the UE enters an unlicensed inactive state, which may also be referred to as a half-connected state 702a. The UE can remain in the unlicensed inactive state while sleeping, for example, until it receives a notification that new UL data is ready to be sent. The UE can then switch from the unlicensed inactive state to the unlicensed active state at 918 using fast synchronization with the unlicensed DL synchronization signal, as... Figure 8 As shown in the figure, it is used for DL ​​synchronization to decode DL control messages, and for UL synchronization for frequency subcarriers and time self-contained interval (A', B', X') boundaries.

[0085] Compared to the fast synchronization in the uplink, various scenarios are considered for illustrative purposes. In one example scenario ( Figure 9BIn scenario 1), the UE has only achieved DL synchronization via DL reference signals or control pilots, but has never acquired UL synchronization through UL random access operations. For example, the UE can select / reselect a new cell or Transmit and Receive Point (TRP) under the current serving cell, and can have an unlicensed UL transmission configuration that is already validly stored through previously visited cells or through pre-authorization for access, which can refer to pre-configuration provided by the factory or operator, configuration through the service administrator's DM-OTA, etc. In this scenario, the new cell or TRP may already have the UE context (e.g., the previous serving cell or TRP forwards the UE context to the new target cell during forward handover), and the UE can be in an unlicensed inactive state and initiate unlicensed UL transmission without a RACH procedure.

[0086] In another example scenario ( Figure 9B In scenario 2), in addition to DL synchronization, the UE has also initially acquired UL synchronization. For example, the UE may have performed UL random access operation as part of the initial RRC connection process in the new cell, and also acquired UL synchronization in the cell before transitioning to an unlicensed inactive state.

[0087] Also refer to Figure 11, which can be used for Figure 9B The scenarios 1 and 2 illustrated in the diagram utilize different schemes for UL TA estimation. In one example, relative to scenario 1, the UE has never obtained UL synchronization in a new cell / TRP before unlicensed UL transmission. The UE can use various mechanisms according to various embodiments to achieve fast UL synchronization with the estimated TA. In the example, the UL TA can be estimated based on cells / TRPs previously visited by the UE. For example, the UE can evaluate the nearest UL TA and associated distance based on cell / TRPs previously obtained by the UE from visited neighboring cells / TRPs or based on visited cell / TRPs as a subset configured for timing advance reference purposes. These timing advance references can be referred to as unlicensed TA cell groups. The time difference between the UL TAs of the currently serving cell and neighboring cells can be stored on the UE. For example:

[0088] UL_TA_estimated = UL_TA_visited + delay_visited_to_serving + adjustment (distance difference)

[0089] In the example, the UE can use DL synchronization pilots or reference signals (such as...). Figure 10 (As shown in the diagram) and the DL timestamp from the NR node carried on the DCI, or the DL message header from the MAC layer or higher, are used to estimate the DL propagation delay. For example:

[0090] DL_delay = Arrival time of DL synchronization pilot or reference signal at UE - DL timestamp from NR node.

[0091] UL_TA_estimated = 2 × DL_delay

[0092] Therefore, the UE can use DL path loss to estimate DL propagation delay. In some cases, assuming free-space path loss, if the UE knows the DL unlicensed synchronization transmission (Tx) power at the NR cell / TRP (network node), the UE can estimate the DL propagation delay by estimating that path loss. The UE can be configured with the Tx power of the DL unlicensed synchronization at the network node. In the example, the UE knows the received power of the DL synchronization reference signal through its own measurement of the DL synchronization reference signal. Furthermore, the UE can further refine the DL propagation delay estimation using deployment-specific configuration parameters to account for deployment-specific path loss models. For example, the NR node (e.g., eNB) can configure the UE with a path loss offset. The UE can apply this offset to the free-space path loss to account for the deviation between the free-space path loss and the actual deployment-specific path loss model.

[0093] exist Figure 9B In Example Scenario 2, in addition to DL synchronization, the UE also acquires UL synchronization with the serving cell / TRP before transitioning to the unlicensed inactive state. The UE may have received an initial TA or multiple updated TA values ​​from the serving cell / TRP before transitioning to the unlicensed inactive state. In one embodiment, the UE uses the method described above relative to Scenario 1 to estimate the DL propagation delay DL_delay. For example, the UE can estimate the DL propagation delay during the RACH procedure or by using a timestamp or location context stored from the previous TA update operation. The UE can then use the UL TA (UL_TA_ref) from the previous RACH or TA update operation to calculate the UL TA correction UL_TA_correct, for example:

[0094] UL_TA_correct = UL_TA_ref – 2 × DL_delay. The UE can estimate the new UL TA (UL_TA_new) using the DL delay estimated at the current position (DL_delay_current) and the UL TA correction estimated as described above (UL_TA_correct), for example:

[0095] UL_TA_new=2×DL_delay_current+UL_TA_correct

[0096] In some cases, the estimation of DL propagation delay and the calculation of UL TA correction can be repeated whenever the UE performs a random access procedure or receives a UL TA update. UL TA updates can be received from the MAC CE or from the DL DCI after a UL transmission in a licensed state.

[0097] In some cases, the UE may be triggered to determine or update the TA stored on the UE. For example, but not limited to, the need to transmit unlicensed data can trigger the determination or update of the TA, the reception of an unlicensed DL synchronization signal can trigger the determination or update of the TA, or performing a random access procedure in a licensed state can trigger the determination or update of the TA. In another example, the UE may receive an updated TA from the NR node after transmitting UL data in a licensed state. In yet another example, the update of the propagation delay correction factor increment is performed as part of a random access procedure (e.g., ...). Figure 9B This is based on the result of scenario 2), which can trigger the TA to be determined or updated. In another example, the UE is configured with a TA timer, and when the TA timer expires, the TA is triggered to be updated, so that the TA is updated periodically.

[0098] The focus now shifts to transmit power (TP) management for unlicensed UL transmissions. Contention-based unlicensed UL transmissions with infrequent, small-data bursts are infrequent UL bursts that can disable conventional closed-loop transmit power control (TPC) for continuous communication. However, it is recognized that transmit power control for unlicensed UL transmissions remains critical, in addition to ensuring adequate signal strength at the NR node receiver to meet the reliability performance requirements of URLLC devices, and for limiting interference to other UEs in multi-user access scenarios to achieve the system capacity required for mMTC devices.

[0099] In the example embodiment, reference Figure 11A and Figure 11B The TP level of the NR node associated with the downlink synchronization signal or reference signal is indicated to the UE on the DL control information (DCI) element (e.g., the DCI for unlicensed UL may include DL TP information for the DL synchronization or reference signal). The UE can use the measured synchronization or reference signal power and the associated TP carried on the DCI to calculate the DL path loss. In one example:

[0100] DL path loss = DL TP - Signal strength at UE Rx

[0101] The UE can calculate the UL path loss based on the DL path loss. In one example:

[0102] UL path loss = DL path loss

[0103] In some examples, power adjustment can be based on the UE's path loss and / or historical TP level (e.g., weighted or unweighted moving average power level). Power adjustment can also be based on relevant UE context such as location, mobility, etc. Power adjustment can also be based on UL resources and associated modulation and coding schemes (MCS). In one example:

[0104] UL power rating = min.{UL path loss + adjustment (UL TP1, UL TP2, ..., total UL resources and MSC), maximum Tx power}

[0105] In some cases, if, for example, there is no DL signal to be measured before the unlicensed UL transmission, the UE's unlicensed UL TP can be estimated based on historical unlicensed UL transmission power levels. The NR node can include the measured unlicensed UL path loss or TP adjustment in its DL ACK or any other DL feedback message to the received unlicensed UL message. This can be used by the UE to calculate the next unlicensed UL transmission power level, allowing quasi-closed-loop power control to be defined. In one example:

[0106] UL power rating = min.{UL path loss + adjustment (previously measured UL path loss or TP adjustment, total UL resources and MSC), maximum Tx power}

[0107] Now for reference Figures 12A to 13B An example system 2500 is shown, comprising an mMTC UE 2502, an NR node 2504, and a core network (CN) 2506. The NR node 2504 includes a RAN slice management function or device (node) 2508 and an mMTC slice 2510. The CN 2506 includes a CN slice management function or device (node) 2512 and an mMTC slice 2514. The mMTC 2514 may include a mobility management node or device 2516, a gateway 2518 (e.g., SWG, PGW), and a subscription management function or device (node) 2520 (e.g., HSS). It should be understood that the example system 2500 is simplified for the convenience of describing the disclosed subject matter and is not intended to limit the scope of this disclosure. In addition to, etc. Figures 12A to 13B The system illustrated in the diagram is outside or replaces systems such as Figures 12A to 13B The system illustrated in the figure may also be implemented using other devices, systems, and configurations, and all such embodiments are contemplated within the scope of this disclosure.

[0108] Special reference Figure 12AAt point 1, according to the illustrated example, UE 2502 is powered on. After power-on, UE 2502 can perform cell search and synchronization, and then the UE can obtain system information, for example, from the MIB and SIB. At point 2, UE 2502 sends a radio connection request to NR node 2504. Specifically, the UE can send a radio connection request message to RAN slice management device 2508 (at point 2A) or mMTC slice 2510 (at point 2B). This request can be a request for access to RAN slice 2510 selected by the UE at NR node 2504. This request can include various context information associated with UE 2502. Context information may include, but is not limited to, the device type of UE 2502 (e.g., mMTC, URLLC), the services associated with UE 2502 (e.g., forest fire monitoring or traffic monitoring), latency requirements (e.g., ultra-low latency of 100ms or 0.5ms), data service context (e.g., data packet size or data rate), service type (e.g., non-IP or IP based); mobility context associated with UE 2502 (e.g., static, pedestrian, vehicle-based), planned scheduling of data transmission from UE 2502, and the type of access that can be performed by UE 2502 (e.g., licensed access, unlicensed access, or access switching between licensed and unlicensed). In some cases, operations 3, 4, and 5 are not performed when the UE selects slice 2510.

[0109] In some cases, such as when UE 2502 has not selected a slice, RAN slice management 2508 selects slice 2510 as the UE's radio access slice at 3A, for example, based on the UE context in the request at 2A. Selection can also be based on RAN traffic load and resource allocation. At 4A, according to the illustrated example, RAN slice management 2508 sends a RAN slice connection request to the selected mMTC slice 2510. This request can also be forwarded from 2A to the context of all or some UEs, enabling the establishment of a radio connection between UE 2502 and mMTC slice 2510. At 5A, mMTC slice 2510 can send a RAN slice connection response to RAN slice management 2508. This response can indicate whether the slice connection request has been accepted. If the request is rejected, one or more reasons for rejection can be included in the response message.

[0110] At point 6, as illustrated in the example, RAN slice management 2508 (at point 6A) or mMTC slice 2510 (at point 6B) sends a RAN slice connection response to UE 2502. In this message, RAN slice management 2508 or RAN mMTC slice 2510 can confirm whether the radio connection request has been accepted. If the request is rejected, one or more reasons for the rejection can also be included in the response message. In the illustrated example, UE 2502 receives confirmation that a successful radio connection has been established with mMTC slice 2510. At point 7, the UE can send a registration request to RAN slice management 2508 (at point 7A) or RAN mMTC slice 2510 (at point 7B). A registration request can be sent to establish a secure service connection with core network (CN) 2506.

[0111] Now for reference Figure 12B At point 8, a registration request is sent to CN slice management device 2512 (8C and 8C') or CN mMTC slice 2514 (8D and 8D'). This request can be sent by RAN slice management 2508 (8C and 8D) or mMTC slice 2510 (8C' and 8D'). The request may include context information associated with the UE and information associated with mMTC slice 2510, such as, for example, the slice ID. In some cases, operations 9 and 10 described now are skipped when NR node 2504 selects CN slice 2514. At point 9C, according to the illustrated example, CN slice management device 2512 selects mMTC IP service slice 2514, for example, based on the UE context, RAN mMTC slice 2510, traffic load of CN 2506, available mMTC slices, etc. At point 10C, according to the illustrated example, CN slice management node 2512 sends a registration request to mobility management node 2516. The registration request may include the UE’s context information and information associated with the RAN mMTC slice 2510.

[0112] Now for reference Figure 13AContinuing the illustrated example, at point 11, Mobility Management Node 2516 exchanges messages with Subscription Management Node 2520 to authenticate UE 2502 for service access. Following authentication, at point 12, Mobility Management Node 2516 exchanges messages with UE 2502, enabling UE 2502 and Mobility Management Node 2516 to mutually authenticate each other and then establish a secure mode between them. At point 13, according to the illustrated example, Mobility Management Node 2516 can exchange messages with Subscription Management Node 2520 to update the location of UE 2502. Location Update: Mobility Management uses Subscription Management for location updates to exchange messages. At point 14, an IP session can be established between RAN mMTC slice 2510 and CN mMTC slice 2514. An IP session can also be established within CN mMTC slice 2514.

[0113] Continue to refer to Figure 13A As illustrated in the example, at point 15, no-license operation is configured. For example, NR node 2504, particularly RAN mMTC slice 2510, can exchange messages with UE 2502 to configure the no-license operation parameters described herein. Example parameters include, but are not limited to: contention access allocation parameters; unlicensed configuration parameters (e.g., DACTI, CTI, DCA, UAP, GLUCI, etc.); seeds or indices of orthogonal codes for code domain multiple access; seeds or values ​​for random backoff to avoid contention access in case of priority conflicts; redundancy parameters for reliable transmission; timers in an inactive state (e.g., for listening to broadcast channels for paging or system information changes, for measuring radio link management, for updating states related to reachability and mobility, etc.); unlicensed power control values ​​(e.g., minimum and maximum UL transmit power levels and incremental adjustments, which can be calculated by NR node 2504 at least in part based on path loss and required received signal quality during message exchange between UE 2502 and NR node 2504 as described above); parameters related to the schedule for unlicensed UL transmission; coding rate; modulation scheme, etc.

[0114] At 16A, according to the illustrated example, UE 2502 utilizes a higher layer to confirm the unlicensed configuration (assignment) as compared to the physical layer. Alternatively or additionally, UE 2502 can confirm the unlicensed setting together with NR node 2504, particularly RAN slice management node 2508 (at 16B) or mMTC slice 2510 (at 16C). Therefore, UE 2502 can receive a command to enter the "unlicensed" operating mode from a higher layer or from NR node 2504. At 17, UE 2502 enters the inactive state of the unlicensed operating mode. The inactive state can be pre-configured. In some cases, the inactive state can be triggered by a command from a higher layer or NR node to operate in unlicensed mode after registration. In some cases, UE 2502 can automatically enter the inactive state in unlicensed operating mode if configured to do so. At 18, according to the illustrated example, UE 2502 receives the data it needs to transmit in UL transmission from a higher layer. Example data includes, but is not limited to, "keep-alive" small data, measurement data, and data associated with the reachability and mobility status of UE 2502. At point 19, UE 2502 may need to check system information on the broadcast channel. As another example, at point 19, UE 2502 may need to perform radio link measurements or select a new cell based on the results of system information or radio link measurements. At point 20, according to the illustrated example, UE 2502 synchronizes with a reference signal or available synchronization pilot (e.g., a first available synchronization pilot) at the symbol timing boundary used to allocate the contention access area.

[0115] At 21, according to the illustrated example, UE 2502 sends an unlicensed UL transmission to NR node 2504, specifically RAN mMTC slice 2510. In some cases, UE 2502 may engage in contention-based access for unlicensed UL transmission (without redundancy) at an initial UL transmission power, which may be defined during the unlicensed setup phase (at 15) or signaled by NR node 2504 via system information broadcast or RRC signaling. In some cases, UE 2502 may indicate whether this transmission at the transmission power level requires an acknowledgment (ACK). UE 2502 may also include radio link measurements, reachability or mobility status, or other information related to the UL data transmission at 21. At 22, UE 2502 may wait for an ACK response for its UL transmission from mMTC slice 2510. If, for example, an ACK is required, UE 2502 may wait until the ACK timer expires. At 23, according to the example, UE 2502 retransmits the UL message. For example, if its unlicensed UL data requires reliable transmission, UE 2502 can contend for access again. At 24, according to the illustrated example, NR node 2504, specifically mMTC slice 2510, sends an ACK message to UE 2502, indicating that the UL transmission from UE 2502 has been successfully received. The message at 24 may also include a power adjustment value for the UE's next unlicensed UL transmission, thereby providing quasi-closed-loop power control. At 25, UE 2502 can enter an inactive state of unlicensed operation mode. An inactive state generally refers to a state where the UE is not transmitting. An inactive state can be pre-configured or triggered by a higher-level command after an unlicensed UL transmission. An inactive state can also be triggered when UE 2502 receives an ACK from NR node 2502, for example, when transmission requires an ACK. In some cases, if, for example, UE 2502 is configured to do so, UE 2502 can automatically enter an inactive state after an unlicensed UL transmission.

[0116] For further reference Figures 14A to 15BAn example of unlicensed UL transmission for a URLLC device is illustrated. An example system 2700 is shown, including a URLLC UE 2702, an NR node 2704, and a core network (CN) 2706. The NR node 2704 includes a RAN slice management function or device (node) 2708 and a RAN URLLC slice 2710. The CN 2706 includes a CN slice management function or device (node) 2712 and a URLLC slice 2714. The URLLC slice 2714 may include a mobility management node or device 2716, one or more gateways 2718 (e.g., SWG, PGW), and a subscription management function or device (node) 2720 (e.g., HSS). It should be understood that the example system 2700 is simplified for the convenience of describing the disclosed subject matter and is not intended to limit the scope of this disclosure. In addition to, etc. Figures 14A to 15B The system illustrated in the diagram is outside or replaces systems such as Figures 14A to 15B The system illustrated in the figure may also be implemented using other devices, systems, and configurations, and all such embodiments are contemplated within the scope of this disclosure.

[0117] Figures 14A to 15B The example embodiment of the URLLC device illustrated in the figure may be similar to the example embodiment of the mMTC device described above, and therefore referenced. Figures 12A to 13B Similar operations are described. However, relative to the URLLC device, the context information associated with UE 2702 may include values ​​instructing UE 2702 to switch between licensed and unlicensed operation. Additionally, an eMBB / URLLC slice may be selected at NR node 2704 to optimize overall system resource utilization. In the example, URLLC slice 2714 is selected to meet short latency requirements across system (core network 2706) 2700. In some examples, UE 2702 utilizes redundancy for its unlicensed UL transmissions. For example, UE 2702 may transmit multiple transmissions in the same or different unlicensed contention spaces on multiple contention blocks with the same or different redundancy schemes. In one example, at 24, UE 2702 switches from unlicensed operation mode to licensed operation mode after receiving a command from a higher layer. As an example, UE 2702 may include a traffic monitor that switches from unlicensed mode to licensed operation mode to upload images of traffic accidents to the network.

[0118] Now for reference Figures 16A to 17BAn example system 2500 is illustrated. In the illustrated example, unlicensed UL operation is performed for mMTC device 2502. According to the illustrated example, RAN slice management node 2508 and CN slice management node 2512 can be logical entities that perform common control functions in RAN and CN 2506, respectively. For example, RAN slice management node 2508 and CN slice management node 2512 can exchange service subscription and policy information, which can be used to verify requests for access slices. Such information can also be used to establish security settings, charging parameters, etc. RAN slice management node 2508 and CN slice management node 2512 can also exchange context information associated with UE 2502. Such context information may include, for example, mobility information, location information, transmission scheduling information, data service information, etc. Context information can allow the selection of appropriate (e.g., optimal) slices in RAN and CN 2506.

[0119] Mobility management node 2516 and subscription management node 2520 may represent common functions used for CN slices (slice public) associated with a service provider. In some cases, as shown, mobility management node 2516 and subscription management node may be part of CN slice management 2506, or may represent specific functions (slice specific) within a CN slice 2514 provided by a specific service provider.

[0120] Special reference Figure 16A and Figure 16BAt point 1, as illustrated in the example, UE 2502 powers on. After powering on, UE 2502 can perform cell / TRP / slice search and synchronization. UE 2502 can also obtain system information from the MIB and SIB. At this time, in some cases, UE 2502 may be in a state similar to EMM-deregistration, ECM-Idle, and RRC-idle as defined in current LTE systems. At point 2, UE 2502 can send a radio connection request to RAN slice management node 2508 (at point 2A) or mMTC slice 2510 (at point 2B). This request may include various contextual information associated with UE 2502, such as, but not limited to: device type (e.g., mMTC or URLLC), service (e.g., service for forest fire monitoring or traffic monitoring); latency requirements (e.g., 100ms or ultra-low latency of 0.5ms); context related to data services (e.g., data packet size and / or data rate and / or duty cycle); CN service type (e.g., non-IP or IP based); mobility context (e.g., static, walking, or vehicular, or low speed in a restricted area, etc.); location context (e.g., UE tracking area at the RAN); scheduling context (e.g., scheduling of data transmission); access context (e.g., permitted or unlicensed access, whether switching between permitted and unlicensed access is possible, access priority, etc.). In some cases, such as when UE 2502 selects RAN slice 2510, operations 4 and 5 are not performed.

[0121] At point 3A, RAN slice management node 2508 can select RAN slice 2510. Selection can be based at least in part on context information associated with UE 2502, traffic load and resource allocation at various RAN slices, relevant service profiles or subscriptions, charging policies, etc. This information can be stored at NR node 2504 or received from CN 2506 via CN slice management node 2512 and / or subscription management entity 2520 on CN 2506. At point 3A, RAN slice management 2508 selects mMTC slice 2510 as the radio access slice for UE 2510. At point 3B, RAN slice 3510 can determine whether to accept a connection request from the UE to RAN-selected or UE-selected RAN slice 3510. At point 4A, RAN slice management 2508 can send a RAN slice connection request to mMTC slice 2510. This connection request can include context information associated with UE 2502, enabling the establishment of a radio connection between UE 2502 and slice 2510. At 5A, as illustrated in the example, mMTC slice 2510 sends a RAN slice connection response to RAN slice management 2508. This response can indicate whether the slice connection request has been accepted. If the request is rejected, the reason for rejection can be included in the response message. If the request is accepted, radio configuration parameters for the selected RAN slice 2510 (e.g., dedicated radio resource configurations similar to SRB1 and / or DBR for UE 2502) can be included in the response.

[0122] Still referencing Figure 16A and Figure 16BAt point 6, as illustrated in the example, RAN slice management 2508 (at point 6A) or mMTC slice 2510 (at point 6B) sends a radio connection response to UE 2502. This response may indicate that the radio connection was acknowledged by RAN slice management 2508 or RAN mMTC slice 2510. If the request for the selected RAN slice 2510 is rejected, the reason for rejection may also be included in the response message. If the request is accepted, radio configuration parameters for the selected RAN slice 2510 (e.g., dedicated resource configurations for UE 2502, such as SRB1 and / or DRB) may be included in the response. In some cases, RAN slice management 2508 or the selected RAN slice 2510 may (e.g., within the response message) send dedicated SBR1 and / or DRB resources (e.g., SRB and / or DRB configurations) for UE 2502. Therefore, UE 2502 can be confirmed as having a successful radio connection with mMTC slice 2510, which can be a NAS connection with the selected RAN slice 2510. At point 7, according to the illustrated example, UE 2502 can send a registration request to RAN slice management 2508 (at point 7A) or RAN mMTC slice 2510 (at point 7B). This registration request can be sent at the NAS layer and can be encapsulated in a radio connection completion message, which can also include radio configuration as indicated by the selected RAN slice 251. RAN slice management 2508 can send the registration request to CN slice management 2512 (at point 8A) or mobility management 2516 (at point 8D). Alternatively, RAN mMTC slice 2510 can send the registration request to mobility management 2516 (at point 8D'). When slice 2512 is selected by NR node 2510, the registration request can be sent to mobility management 2516. In some examples, when RAN slice 2510 is selected by UE 2502 (at 8B), a registration request can be sent to CN slice management 2512. The registration request may include context information associated with the UE, as well as slice information (e.g., ID) associated with mMTC slice 2510.

[0123] In some examples, NR node 2504 or CN 2506 can select CN slice 2514 based on various context information associated with UE 2502. For example, CN slice selection may be based at least in part on the UE ID assigned by RAN slice management 2508 or RAN slice 2510 in NR node 2508, the type of UE 2502 (e.g., mMTC or URLLC), the service performed by UE 2502 (e.g., forest fire monitoring or traffic monitoring), latency requirements (e.g., long latency of 100ms or ultra-low latency of 0.5ms for end-to-end latency of a session or stream); data services (e.g., data bit rate and / or traffic load for a session or stream); routing type (e.g., non-IP or IP based), mobility (e.g., static, walking, or vehicular or low speed in a restricted area); location (e.g., the tracking and / or routing area of ​​the UE in the network, such as TAI and ECGI in an LTE system); scheduling (e.g., scheduling of UL data transmission); billing (e.g., online or offline billing), etc.

[0124] In some cases, such as when NR node 2504 selects CN slice 2514, operations 9 and 10 are not performed. In other cases, at 9C, CN slice management 2512 selects an mMTC IP service slice (slice 2514) based on at least a portion of context information associated with the UE, RAN mMTC slice 2510, CN service load, or available mMTC slices. At 10C, CN slice management 2506 may send a registration request to mobility management node 2616. This registration request may include context information associated with UE 2502 and information related to RAN mMTC slice 2510. At 10C, in some cases, a connection is established between the NAS layer of UE 2502 and mobility management 2516 or CN slice 2514. The UE can then transition to various states, such as EMM-registered, ECM-connected, and RRC-connected states in an LTE system.

[0125] Now for reference Figure 17AAt point 11, according to the illustrated example, Mobility Management 2516 and Subscription Management 2520 exchange messages for authenticating UE 2502 with the requested service. The exchanged messages may include, but are not limited to, UE ID (such as IMSI and Serving Network ID) and context, RAN and CN slice information (such as RAN Slice ID and CN Slice ID), Serving Network ID, UE service profile or subscription and charging policy, assigned UE default IP address, etc. A security key can be generated for establishing a secure connection in CN 2506 and the RAN. At point 12, after authenticating with Subscription Management 2520, Mobility Management 2516 and UE 2502 may exchange messages to mutually authenticate each other and then establish a secure mode between them for NAS signaling. At point 23, according to the illustrated example, Mobility Management 2516 and Subscription Management 2520 exchange messages to update the location associated with UE 2502. At point 14, according to the illustrated example, an IP or non-IP session is established within the CN mMTC slice 2514 on the radio bearer between the UE 2502 and the mobility management 2516 in CN 2506 via the interface between the RAN mMTC slice 2510 and the CN mMTC slice 2514 and the network connection bearer in the core network 2506.

[0126] At point 15, no-license operation is configured. For example, NR node 2504, particularly RAN mMTC slice 2510, can exchange messages with UE 2502 to configure the no-license operation parameters described herein. Example parameters include, but are not limited to: contention access allocation parameters; access priority and / or contention priority; unlicensed configuration parameters (e.g., DACTI, CTI, DCA, UAP, GLUCI, etc.); seeds or indices for orthogonal codes used for code domain multiple access; seeds or values ​​for random backoff to avoid contention access in case of priority conflicts; redundancy parameters for reliable transmission; timers in an inactive state (e.g., for listening to broadcast channels for paging or system information changes, for measuring for radio link management, for updating states related to reachability and mobility, etc.); unlicensed power control values ​​(e.g., minimum and maximum UL transmit power levels and incremental adjustments, which can be calculated by NR node 2504 at least in part based on path loss and required received signal quality during message exchange between UE 2502 and NR node 2504 as described above); parameters related to scheduling for unlicensed UL transmission; coding rate; modulation scheme, etc. At 16A, according to the illustrated example, UE 2502 utilizes a higher layer of UE 2502 to confirm the unlicensed configuration (allocation) as compared to the physical layer. Alternatively or additionally, UE 2502 can confirm the no-license setting together with NR node 2504, particularly RAN slice management node 2508 (at 16B) or mMTC slice 2510 (at 16C). Therefore, UE 2502 can receive a command to enter the "no-license" operating mode from a higher layer or from NR node 2504.

[0127] Now for reference Figure 17BAt point 17, UE 2502 enters an inactive state in unlicensed operation mode. This inactive state can be pre-configured. In some cases, the inactive state can be triggered by commands from a higher layer or NR node to operate in unlicensed mode after registration. In some cases, UE 2502 can automatically enter an inactive state in unlicensed operation mode if configured to do so. At point 18, according to the illustrated example, UE 2502 receives data it needs to transmit in UL transmission from a higher layer. Example data includes, but is not limited to, "keep-alive" small data, measurement data, data associated with UE 2502's reachability and mobility status, etc. At point 19, UE 2502 may need to check system information on the broadcast channel. As another example, at point 19, UE 2502 may need to perform radio link measurements or select a new cell based on the system information or the results of radio link measurements. At point 20, according to the illustrated example, UE 2502 synchronizes with a reference signal or available synchronization pilot, such as the first available synchronization pilot, at the symbol timing boundary used for allocating contention access areas. UE 2502 can also estimate timing advance (TA) for unlicensed UL synchronization at 20 points. In addition, UE 2502 can estimate transmit power (TP) level for UL transmission using the received DL reference signal.

[0128] At point 21, according to the illustrated example, UE 2502 sends an unlicensed UL transmission to NR node 2504, specifically RAN mMTC slice 2510. In some cases, UE 2502 may engage in contention-based access for unlicensed UL transmission (without redundancy) at an initial UL transmission power, which may be defined at the unlicensed setup phase (at point 15) or signaled by NR node 2504 via system information broadcast or RRC signaling. In some cases, UE 2502 may indicate whether an acknowledgment (ACK) is required for this transmission at that power level. UE 2502 may also include radio link measurements, reachability or mobility status, or other information regarding the UL data transmission at point 21. At point 22, UE 2502 may wait from mMTC slice 2510 for an ACK response to its UL transmission. If, for example, an ACK is required, UE 2502 may wait until the ACK timer expires. At 23, according to the example, if reliable transmission is required, UE 2502 retransmits the UL message at an adjusted (e.g., increased) TP level. For example, if reliable transmission is required for its unlicensed UL data, UE 2502 can again contend for access. At 24, according to the illustrated example, NR node 2504, specifically mMTC slice 2510, sends an ACK message to UE 2502, indicating that the UL transmission from UE 2502 has been successfully received. The message at 24 may also include a power adjustment value for the UE's next unlicensed UL transmission, thereby providing quasi-closed-loop power control. At 25, UE 2502 can enter an inactive state of unlicensed operation mode. An inactive state generally refers to a state where the UE is not transmitting. The inactive state can be pre-configured or triggered by a higher-level command after an unlicensed UL transmission. For example, when transmission requires an ACK, the inactive state can also be triggered when UE 2502 receives an ACK from NR node 2502. In some cases, if, for example, UE 2502 is configured to do so, UE 2502 can automatically enter an inactive state after unlicensed UL transmission.

[0129] Also refer to Figures 18A to 19B The illustration shows an example embodiment of a URLLC device, which may be similar to the example embodiment of the mMTC device described above, and therefore referenced. Figures 16A to 17BSimilar operations are described. However, relative to the URLLC device, the context information associated with UE 2702 may include values ​​instructing UE 2702 to switch between licensed and unlicensed operation. Additionally, at 3A or 2B, eMBB / URLLC slice 2710 may be selected at NR node 2704 to optimize overall system resource utilization. In the example, at 9C or 8D, URLLC slice 2714 is selected to meet short latency requirements across system (network) 2700. In some examples, UE 2702 utilizes redundancy (e.g., by using multiple competing blocks to transmit the same data) for its unlicensed UL transmission. In one example, at 24, UE 2702 switches from unlicensed operation mode to licensed operation mode after receiving a command from a higher layer. As an example, UE 2702 may include a traffic monitor that switches from unlicensed mode to licensed operation mode to upload images of a traffic accident to the network.

[0130] Now let's turn to examples of unlicensed and licensed UL sending, such as Figure 20A and Figure 20B As shown, the UE can be pre-configured for registration with the subscription management node in the core network. Alternatively, the UE can be registered via an "attachment" process that assigns a temporary radio identifier (ID) for use in unlicensed access. After registration (if applicable), the UE can set unlicensed-related parameters, which may generally be referred to as its unlicensed configuration. In some cases, that is, a UE pre-configured for registration can also be pre-configured with unlicensed parameters. Figure 21A and Figure 21B An example of unlicensed and licensed operation for a URLLC device is depicted, wherein the UE (URLLC device) transitions between an unlicensed state and a licensed state according to instructions from the NR node. Figure 22A and Figure 22B Examples of unlicensed and licensed operations for mMTC devices are depicted, in which the UE (mMTC device) transitions between unlicensed and licensed states by commands from higher layers (such as compared to the physical layer).

[0131] Now for reference Figure 23 This document describes an example graphical user interface (GUI) 2300 for configuring unlicensed operation of a UE. Specifically, using GUI 2300, a user can configure the UE to transmit UL data using only unlicensed operation. Alternatively, using GUI 2300, a user can enable the UE to switch between licensed and unlicensed operation, allowing the UE to operate in both states. It should be understood that the GUI can be adapted to display or configure additional or alternative parameters as needed. Furthermore, the GUI can display parameters in various visual depictions as needed.

[0132] Therefore, as described above, the device can send messages on the uplink in the network according to the unlicensed access mode, allowing the device to send messages even when not permitted to do so, thus enabling operation in unlicensed mode. Additionally, the device can switch between unlicensed and licensed modes. In one example, the device switches between unlicensed and licensed modes in response to an instruction from a layer higher than the device's physical layer. In another example, the device switches between unlicensed and licensed modes in response to an instruction from the network. The device can switch from unlicensed mode to licensed mode in response to an increase in the frequency or capacity of data communication performed by the device. The device can switch from licensed mode to unlicensed mode in response to a low duty cycle associated with the device. When operating in unlicensed mode, the device can obtain an allocation of radio resources shared with at least one other device to operate in a half-connected state within the unlicensed mode. In one example, the radio access node maintains communication with the core network while the device operates in a half-connected state. In another example, when operating in unlicensed mode, the device obtains an allocation of radio resources dedicated to the device to operate in a connected state within the unlicensed mode.

[0133] As described above, when in a licensed state, the device can identify data that should be transmitted in the uplink of the network using an unlicensed state. In the unlicensed state, data is transmitted without the device being licensed to transmit messages. In the example, the device can transition from a licensed state to an unlicensed state. When in the unlicensed state, the device can transmit data without performing a random access procedure. In some cases, data is transmitted via a first cell based on a stored uplink transmission configuration obtained via another or a second cell. The device can estimate a timing advance and transmit data according to that timing advance. The device can store the estimated timing advance. The device can update the stored timing advance in response to receiving an unlicensed DL synchronization signal or in response to the need to transmit data in the unlicensed state. In another example, the device updates the timing advance when a timer expires, such that the timing advance is updated periodically. The device can also estimate the transmission power and transmit data according to the estimated transmission power. The device can store the estimated transmission power. The device can update the stored transmit power in response to the need to transmit data in an unlicensed state, in response to receiving an unlicensed downlink (DL) synchronization signal, or in response to receiving an unlicensed downlink (DL) reference signal.

[0134] The various techniques described herein can be implemented in combination with hardware, firmware, software, or, where appropriate, a combination thereof. Such hardware, firmware, and software can reside in devices located at various nodes of a communication network. Devices can operate individually or in combination with each other to influence the methods described herein. As used herein, the terms “device,” “network device,” “node,” “entity,” “function,” “equipment,” and “network node” are used interchangeably without limitation unless otherwise specified.

[0135] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities—including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE Advanced. 3GPP has begun working on the standardization of next-generation cellular technologies known as New Radio (NR), also referred to as "5G." 3GPP NR standard development is expected to include the definition of next-generation radio access technologies (New RATs), which are expected to include the provision of new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward-compatible radio access in the new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with divergent requirements. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with flexible radio access below 6 GHz, while featuring centimeter-wave and millimeter-wave specific design optimizations.

[0136] It should be understood that, for different RAN architectures, the aforementioned unlicensed UL control and management can be performed at NR nodes, Transmit and Receive Points (TRPs), Remote Radio Headers (RRHs), and control functions in the central controller or RAN slice within the RAN. The embodiments described herein can also be applied to TRPs, RRHs, central controllers, and control functions in different RAN architectures.

[0137] 3GPP has identified a wide range of use cases that NR is expected to support, resulting in diverse 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-bandwidth indoor access, broadband access in crowds, 50+ Mbps everywhere, ultra-low-cost broadband access, vehicular mobile broadband), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interoperability, energy saving), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications within these categories include, for example, surveillance and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, haptic internet, and virtual reality, among others. All of these use cases, and others, are envisioned in this document.

[0138] Figure 24A The illustration shows an embodiment of an example communication system 100 that implements the methods and apparatus described and claimed herein. As shown, the example communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c and / or 102d (which may generally or commonly be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d, and 102e may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU102a, 102b, 102c, 102d, 102e is in Figures 24A-24E While described as a handheld wireless communication device, it should be understood that each WTRU can include or be implemented in any type of device or apparatus configured to transmit and / or receive wireless signals, utilizing a wide variety of use cases envisioned for 5G wireless communication. Such devices or apparatuses, by way of example only, include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes, etc.

[0139] The communication system 100 may further include base station 114a and base station 114b. Base station 114a may be any type of device configured to wirelessly connect to at least one interface of WTRU 102a, 102b, 102c to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, and / or other network 112. Base station 114b may be any type of device configured to wired and / or wirelessly connect to at least one interface of RRH (Remote Radio Header) 118a, 118b and / or TRP (Transmit and Receive Point) 119a, 119b to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, and / or other network 112. RRH 118a, 118b can be any type of device configured to wirelessly connect to at least one interface in WTRU 102c for easy access to one or more communication networks (such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112). TRP 119a, 119b can be any type of device configured to wirelessly connect to at least one interface in WTRU 102d for easy access to one or more communication networks such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. As an example, base stations 114a, 114b can be base transceiver stations (BTS), node B, e-node B, home node B, home e-node B, site controllers, access points (APs), wireless routers, etc. Although base stations 114a, 114b are each depicted as a single element, it should be understood that base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0140] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, for example, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and therefore, multiple transceivers may be used for each sector of the cell.

[0141] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115 / 116 / 117.

[0142] Base station 114b can communicate with one or more of RRH 118a, 118b and / or TRP 119a, 119b via wired or air interfaces 115b / 116b / 117b, wherein the wired or air interfaces 115b / 116b / 117b can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115b / 116b / 117b.

[0143] RRH 118a, 118b and / or TRP 119a, 119b can communicate with one or more of WTRU 102c, 102d via air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

[0144] More specifically, as noted above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b and TRP 119a, 119b in RAN 103b / 104b / 105b and WTRU 102c, 102d can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0145] In this embodiment, base station 114a in RAN 103 / 104 / 105 and WTRUs 102a, 102b, 102c or RRHs 118a, 118b and TRPs 119a, 119b and WTRUs 102c, 102d in RAN 103b / 104b / 105b can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) to establish air interfaces 115 / 116 / 117. In the future, air interfaces 115 / 116 / 117 can implement 3GPP NR technology.

[0146] In the embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0147] Figure 24A Base station 114c can be, for example, a wireless router, home node B, home e node B, or access point, and can utilize any suitable RAT for convenient wireless connectivity in localized areas such as commercial spaces, homes, vehicles, campuses, etc. In one embodiment, base station 114c and WTRU 102e can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114c and WTRU 102e can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 24A As shown, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114c is not required to access the Internet 110 via core network 106 / 107 / 109.

[0148] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication.

[0149] Despite Figure 24AAlthough not shown, it should be understood that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM radio technology.

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

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

[0152] Figure 24B This is a block diagram of an example apparatus or device, such as WTRU 102, configured for wireless communication according to embodiments illustrated herein. Figure 24BAs shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be understood that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments. Additionally, the embodiments envision that base stations 114a and 114b and / or base stations 114a and 114b may represent nodes such as, but not limited to, transceiver stations (BTS), node B, site controllers, access points (APs), home node B, evolved home node B (eNode B), home evolved node B (HeNB), home evolved node B gateways, and proxy nodes, etc., which may be included in... Figure 24B Some or all of the elements depicted in and described herein.

[0153] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 24B While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0154] The transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in an embodiment, the transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, although in Figure 24AAlthough not shown, it should be understood that RAN 103 / 104 / 105 and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105. For example, in addition to being connected to RAN 103 / 104 / 105, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) using GSM radio technology.

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

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

[0157] Figure 24B This is a block diagram of an example apparatus or device, such as WTRU 102, configured for wireless communication according to embodiments illustrated herein. Figure 24BAs shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be understood that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments. Additionally, the embodiments envision that base stations 114a and 114b and / or base stations 114a and 114b may represent nodes such as, but not limited to, transceiver stations (BTS), node B, site controllers, access points (APs), home node B, evolved home node B (eNode B), home evolved node B (HeNB), home evolved node B gateways, and proxy nodes, etc., which may be included in... Figure 24B Some or all of the elements depicted in and described herein.

[0158] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 24B While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0159] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. For example, in one embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0160] Furthermore, although the transmitting / receiving element 122 is in Figure 24BWhile depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in embodiments, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0161] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode functionality. Therefore, transceiver 120 may include, for example, multiple transceivers enabling WTRU 102 to communicate via multiple RATs such as UTRA and IEEE 802.11.

[0162] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad / indicator 128. Furthermore, the processor 118 can access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of storage device. The removable storage device 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital storage (SD) card, etc. In an embodiment, the processor 118 may access information from memory not physically located on the WTRU 102, such as memory on a server or home computer (not shown), and store data in memory not physically located on the WTRU 102.

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

[0164] The processor 118 may also be coupled to a 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 instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

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

[0166] WTRU 102 can be implemented in other devices or equipment such as sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, and vehicles such as cars, trucks, trains, or airplanes. WTRU 102 can be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as the relevant interconnect interface that may be included in peripheral 138.

[0167] Figure 24C This is a system diagram of RAN 103 and core network 106 according to an embodiment. As noted above, RAN 103 can use UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 24CAs shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 134a and 142b. It should be understood that RAN 103 may include any number of nodes B and RNCs while remaining consistent with the embodiments.

[0168] like Figure 24C As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the corresponding node B 140a, 140b, or 140c to which it is connected. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functionalities such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0169] Figure 24C The core network 106 shown 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. While each of the above elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0170] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment.

[0171] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices.

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

[0173] Figure 24D This is a system diagram of RAN 104 and core network 107 according to an embodiment. As noted above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with core network 107.

[0174] RAN 104 may include eNodeBs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNodeB 160a may, for example, use multiple antennas to transmit and receive radio signals from WTRU 102a.

[0175] Each of eNodeB 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 24D As shown, nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0176] Figure 24D The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the above elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0177] The MME 162 can connect to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0178] Service gateway 164 can connect to each of the e-nodes B160a, 160b, and 160c in RAN 104 via the S1 interface. Service gateway 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, and 102c. Service gateway 164 can also perform other functions, such as anchoring the user plane during handover between e-nodes B, triggering paging when downlink data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0180] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include or can communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between core network 107 and PSTN 108. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0181] Figure 24EThis is a system diagram of RAN 105 and core network 109 according to an embodiment. RAN 105 may be an access service network (ASN) that uses IEEE 802.16 radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 117. As will be discussed further below, communication links between different functional entities of WTRUs 102a, 102b, 102c, RAN 105, and core network 109 can be defined as reference points.

[0182] like Figure 24E As shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182; however, it should be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. Base stations 180a, 180b, and 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 117. In the embodiment, base stations 180a, 180b, and 180c may implement MIMO technology. Therefore, base station 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, service classification, and Quality of Service (QoS) policy enforcement. ASN Gateway 182 can be used as a service aggregation point and can be responsible for paging, subscriber profile caching, routing to the core network 109, etc.

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

[0184] The communication link between each of base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between the base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can 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 WTRUs 102a, 102b, and 102c.

[0185] like Figure 24E As shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the above elements is depicted as part of core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0186] MIP-HA manages IP addresses and enables WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA184 provides WTRUs 102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 handles user authentication and supports user services. Gateway 188 facilitates interoperability with other networks. For example, Gateway 188 provides WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as the PSTN 108, facilitating communication between WTRUs 102a, 102b, and 102c and traditional terrestrial communication equipment. In addition, gateway 188 can provide WTRU102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0187] Despite Figure 24EAlthough not shown, it should be understood that RAN 105 can connect to other ASNs and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0188] Described in this article and Figure 24A , Figure 24C , Figure 24D and Figure 24E The core network entities illustrated in the diagram are identified by the names given to those entities in certain existing 3GPP specifications. However, it should be understood that these entities and functions may be identified by other names in the future, and certain entities or functions may be combined in future specifications released by 3GPP, including future 3GPP NR specifications. Therefore, Figure 24A , Figure 24B , Figure 24C , Figure 24D and Figure 24E The specific network entities and functions described and illustrated herein are provided as examples only, and it should be understood that the subject matter disclosed and claimed herein can be implemented or realized in any similar communication system, whether or not it is currently defined or will be defined in the future.

[0189] Figure 24F It is feasible. Figure 24A , Figure 24C , Figure 24D and Figure 24EThe diagram illustrates an exemplary computing system 90 of one or more devices in a communication network, such as RAN 103 / 104 / 105, core network 106 / 107 / 108, PSTN 108, Internet 110, or other network 112. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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 functionality that enables the computing system 90 to operate within the communication network. Coprocessor 81 is an optional processor, distinct from main processor 91, that can perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and apparatus disclosed herein.

[0190] In operation, processor 91 fetches instructions, decodes and executes them, and transfers information to and from other resources via the main data transfer path (system bus 80) of the computing system. This system bus connects components within the computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0191] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. 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 the memory controller 92. The memory controller 92 provides address translation functionality, translating virtual addresses into physical addresses as instructions are executed. The memory controller 92 also provides memory protection functionality that isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped through its own process virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing has been configured.

[0192] In addition, the computing system 90 may include a peripheral controller 83 responsible for passing instructions from the processor 91 to peripherals such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0193] A display 86, controlled by a display controller 96, is used to display visual output generated by a computing system 90. This 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 touchpad. The display controller 96 includes the electronic components necessary to generate the video signals sent to the display 86.

[0194] Additionally, the computing system 90 may include communication circuitry, such as, for example, a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as... Figure 24A , Figure 24B , Figure 24C , Figure 24D and Figure 24E The RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112 are used to enable the computing system 90 to communicate with other nodes or functional entities in those networks. The communication circuitry, alone or in combination with the processor 91, can be used to perform the transmitting and receiving steps of certain means, nodes, or functional entities described herein.

[0195] It should be understood that any or all of the apparatuses, systems, methods, and processes described herein can be implemented 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, cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein can be implemented in the form of such computer-executable instructions that execute on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented using any non-transitory (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 memory technologies, CD-ROM, Digital Universal Disc (DVD) or other optical disc storage devices, magnetic cartridges, magnetic tapes, disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and is accessible by a computing system.

[0196] The following is a list of abbreviations related to access technologies that may appear in the above description. Unless otherwise specified, the abbreviations used herein refer to the corresponding terms listed below.

[0197] ACK confirmation response

[0198] AID associated identifier (802.11)

[0199] AP access point (802.11)

[0200] APN (Access Point Name)

[0201] AS Access Layer

[0202] BS base station

[0203] CA Conflict Avoidance

[0204] CD conflict detection

[0205] CFI Control Format Indicator

[0206] CN Core Network

[0207] CMAS Commercial Mobile Alarm System

[0208] C-RNTI (Cell Radio Network Temporary Identifier)

[0209] CSMA (Carrier Sense Multiple Access)

[0210] CSMA / CD with Collision Detection

[0211] CSMA / CA with Conflict Avoidance CSMA

[0212] DCA Dedicated Conflict Zone

[0213] DCI Downlink Control Information

[0214] DACTI Dynamic Access Configuration Time Interval

[0215] DL downlink

[0216] DRX discontinuous reception

[0217] ECGI E-UTRAN Cell Global Identifier

[0218] ECM EPS Connection Management

[0219] eMBB Enhanced Mobile Broadband

[0220] EMM EPS Mobility Management

[0221] eNB Evolutionary Node B

[0222] ETWS Earthquake and Tsunami Warning System

[0223] E-UTRA Evolved Universal Terrestrial Radio Access

[0224] E-UTRAN Evolved Universal Terrestrial Radio Access Network

[0225] FDM (Frequency Division Multiplexing)

[0226] FFS for further research

[0227] GERAN GSM EDGE radio access network

[0228] GSM Global Mobile Communication System

[0229] GUTI Globally Unique Temporary UE Identifier

[0230] HE High Efficiency

[0231] HSS (Host Subscriber Server)

[0232] IE Information Elements

[0233] IMSI International Mobile Subscriber Identity

[0234] IMT (International Mobile Telecommunications)

[0235] KPIs (Key Performance Indicators)

[0236] LTE Long Term Evolution

[0237] MAC Media Access Control

[0238] MBMS Multimedia Broadcasting and Multicast Service

[0239] MCL maximum coupling loss

[0240] MIB Master Information Block

[0241] MME (Mobility Management Entity)

[0242] MTC Machine Type Communication

[0243] mMTC (Mass Machine Type Communication)

[0244] NACK (Negative Response)

[0245] NAS Non-Access Layer

[0246] NR New Radio

[0247] OBO OFDM backoff (802.11)

[0248] OFDM (Orthogonal Frequency Division Multiplexing)

[0249] PDCCH (Physical Downlink Control Channel)

[0250] PDSCH (Physical Downlink Shared Channel)

[0251] PHY physical layer

[0252] PCFICH Physical Control Format Indicator Channel

[0253] PDCP (Packet Data Convergence Protocol)

[0254] PHICH Physical Hybrid ARQ Indicator Channel

[0255] PPDU (PLCP Protocol Data Unit) (802.11)

[0256] PRACH (Physical Random Access Channel)

[0257] PRB (Physical Resource Block)

[0258] PUCCH (Physical Uplink Control Channel)

[0259] PUSCH Physical Uplink Shared Channel

[0260] QoS (Quality of Service)

[0261] RA Random Access

[0262] RACH Random Access Channel

[0263] RAN (Radio Access Network) (3GPP)

[0264] RMSU Accessibility and Mobility Status Update

[0265] RB resource block

[0266] RLC Radio Link Control

[0267] RNTI (Radio Network Temporary Identifier)

[0268] RRC Radio Resource Control

[0269] RU Resource Unit (802.11)

[0270] SI System Information

[0271] SIB System Information Block

[0272] SR scheduling request

[0273] STA Station (802.11)

[0274] TAI Tracking Area Indicator

[0275] TAU tracking area update

[0276] TBD to be defined

[0277] TDM (Time Division Multiplexing)

[0278] TEID (Tunnel Endpoint ID)

[0279] TRP Sending and Receiving Points

[0280] TTI Transmission Time Interval

[0281] UCI uplink control information

[0282] UE User Equipment

[0283] UL uplink

[0284] UR / LL Ultra-Reliable - Low Latency

[0285] URLLC Ultra-Reliable Low-Latency Communication

[0286] This draft specification uses examples to disclose the invention, including the best mode, and also enables those skilled in the art to practice the invention, including making and using any device or system and performing any incorporated methods. The patentable scope of the invention is defined by the claims, but may include other examples as conceived by those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that are not substantially different from the literal language of the claims.

Claims

1. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to an access network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus, the computer-executable instructions, when executed by the processor of the apparatus, causing the apparatus to perform operations including the following steps: Receive an indication for one or more access assignments for unlicensed transmission; Select an access allocation from the one or more access allocations; Determine the first transmit power level for unlicensed transmission; At the first transmit power level, a first uplink message is transmitted on the selected access allocation, wherein the first uplink message is transmitted without permission; Receive feedback information from the access network for the unlicensed transmission, the feedback information including a power control indication; Determine whether to set the uplink transmission mode to unlicensed access mode and licensed access mode; Based on the power control instruction, a second transmission power level is determined for the determined uplink transmission mode; as well as According to the determined uplink transmission mode, the second uplink message is transmitted at the second transmission power level.

2. The apparatus according to claim 1, wherein the second uplink message corresponds to the first uplink message to enable retransmission in the determined uplink transmission mode.

3. The apparatus of claim 2, wherein the determined uplink transmission mode corresponds to permitted uplink transmission.

4. The apparatus of claim 2, further comprising computer-executable instructions stored in the memory of the apparatus, the computer-executable instructions, when executed by the processor of the apparatus, causing the apparatus to perform further operations including: In response to the expiration of the unlicensed transmission timer, the retransmission is determined to be performed.

5. The apparatus of claim 1, wherein the feedback information is transmitted on a downlink control channel for the unlicensed transmission.

6. The apparatus of claim 1, wherein determining the first transmit power level and the second transmit power level comprises: Execution path loss estimation.

7. The apparatus of claim 6, further comprising computer-executable instructions stored in the memory of the apparatus, the computer-executable instructions, when executed by the processor of the apparatus, causing the apparatus to perform the following further operations: Receive synchronization signals or reference signals from the access network; and The path loss estimation is performed using the synchronization signal or the reference signal.

8. The apparatus of claim 1, wherein determining the first transmit power level and the second transmit power level further comprises: The modulation and coding scheme used for the unlicensed transmission is executed.

Images