CN108370398B

CN108370398B - System and method for user equipment state configuration for multiple services

Info

Publication number: CN108370398B
Application number: CN201680072265.XA
Authority: CN
Inventors: 戎璐; 马江镭; 朱佩英; 童文; 凯文·卡尔·金·欧
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2015-12-08
Filing date: 2016-12-08
Publication date: 2020-09-29
Anticipated expiration: 2036-12-08
Also published as: CN108370398A; JP2018538752A; WO2017098442A1; JP6629450B2; EP3378276A4; EP3378276A1

Abstract

A system and method for a UE state machine supporting multiple services or air interfaces. A UE may have one state machine configuration for multiple services (or service sets) or air interfaces. A UE may have multiple state machines operating independently for different services (or service sets) or air interfaces. A UE may have multiple state machines working in concert for different services (or service sets) or air interfaces. The UE may have a state machine that uses a state machine configuration selected from a plurality of state machine configurations according to the service used. The state machine configuration may be adapted to the service. At initialization, the state machine configuration may be default or determined according to services that the UE may use. During operation, the configuration of the state machine may change (e.g., adding/removing states in the state machine) according to changes in the service for the UE.

Description

System and method for user equipment state configuration for multiple services

RELATED APPLICATIONS

This application claims priority and benefit from the following applications: united states provisional patent application serial No. 62/264,629 filed on 8/12/2015, united states provisional patent application serial No. 62/296,911 filed on 18/2/2016, and united states patent application serial No. 15/356,124 filed on 18/11/2016, the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates generally to wireless communications and, in particular embodiments, to systems and methods for user equipment state configuration for multiple services.

Background

In designing mobile networks, an architecture has emerged in which the Network can be divided into a core Network (core Network, CN) and a Radio Access Network (RAN). The RAN provides wireless communication channels to User Equipment (UE), while the CN typically includes nodes and functions that utilize fixed links. In the RAN, the forward and backhaul connections typically rely on wired connections, although there are some wireless connections (typically between fixed points). Compared to the CN, the RAN has different requirements and problems to solve.

With the planning of next generation networks and the research into technologies capable of supporting such networks, network slices have attracted attention due to the benefits that can be provided in the CN. When combined with technologies such as Network Function Virtualization (NFV) and Software Defined Networking (SDN), Network slices may allow Virtual Networks (VNs) to be created on top of a general pool of computing, storage, and communication resources. These VNs can be designed with control over the topology within the network and can be designed with traffic and resource isolation such that traffic and processing within one slice is isolated from traffic and processing requirements in another slice. By creating network slices, it is possible to create an isolated network with characteristics and parameters that are particularly suited to the requirements of the traffic flows intended for the slices. This allows a single pool of resources to be partitioned to serve very specific and different needs without requiring each slice to be able to support the needs of the services and devices supported by the other slices. Those skilled in the art will recognize that a CN that has been sliced may appear to the RAN as multiple core networks, or there may be a common interface, where each slice is identified by a slice identifier. It should also be understood that while slices may be tailored to the traffic flow patterns they are intended to carry, multiple services may be carried within each slice (often with similar requirements). Each of these services is typically distinguished by a service identifier.

In creating a sliced core network, it should be understood that the pool of resources for use by the sliced resources is typically static. The computing resources of a data center are considered to be non-dynamic for a short period of time. The bandwidth provided by a communication link between two data centers or between two functions instantiated within a single data center is typically not dynamic.

The topic of slicing in a radio access network is presented in some discussions. RAN slicing introduces problems not encountered when slicing in the CN. To usefully enable RAN slicing in a mobile wireless network, one must address: dynamic channel quality on the radio link with the UE, isolation for transmission over a common broadcast transmission medium, and how the RAN and CN slices interact.

In third and fourth generation (3G/4G) network architectures, base stations, base transceiver stations, nodebs, and evolved nodebs (enodebs) are terms used to refer to the radio interface to the network. In the following, the wireless edge nodes of the network are denoted by generic access points. An access Point will be understood to be any one of a Transmission Point (TP), a Reception Point (RP) and a Transmission/reception Point (TRP). It will be understood that the term AP may be understood to include the above mentioned nodes and their successor nodes, but is not necessarily limited to these.

Using SDN and NFV, functional nodes may be created at various points in the network and access to the functional nodes may be limited to a set of devices, such as UEs. This allows so-called network slicing, where a series of virtual network slices can be created to serve the needs of different virtual networks. The services carried by different slices can be isolated from the services of other slices, which not only can ensure the data security, but also can facilitate the decision of network planning.

Slices have been used in core networks because of the ease with which virtualized resources can be allocated and the manner in which traffic can be isolated. In a radio access network, all traffic is transmitted over common resources, which makes it impossible to effectively achieve traffic isolation. The benefits of network slicing in radio access networks are many, but technical hurdles in designing and implementing the architecture result in a lack of network slicing at the radio edge.

User Equipment (UE) devices (e.g., smartphones, tablets) are becoming more connected to Evolved nodebs (enbs), having not only different services running in the foreground, referred to as foreground services, but also different services running in the background, referred to as background services. A UE device may also be generally referred to as a terminal, subscriber, user, mobile station, mobile device, or the like. An eNB may also be generally referred to as a NodeB, base station, controller, communication controller, access point, etc.

Foreground services (and associated message services- "foreground services") include video streaming, web browsing, file transfer, gaming, and the like. Background services (and associated message traffic- "background traffic") include keep-alive messages generated by the mobile operating system or instant messaging, reports generated by sensors and/or smart meters, and the like.

Providing an always-on connection (maintaining an existing connection for low-latency communication, rather than allowing the existing connection to end and re-establish another connection when needed) while conserving power (e.g., maximizing battery life) is a continuing challenge.

User Equipment (UE) devices (e.g., smart phones, tablets) are becoming more connected to evolved nodeb (enb), with different services running in the foreground (referred to as foreground services) but also in the background (referred to as background services). A UE device may also be generally referred to as a terminal, subscriber, user, mobile station, mobile device, or the like. An eNB may also be generally referred to as a NodeB, base station, controller, communication controller, access point, etc.

In third and fourth generation (3G/4G) network architectures, base stations, base transceiver stations, nodebs and evolved nodebs (enodebs or enbs) are terms used to refer to the wireless interface to the network. In the following, the wireless edge nodes of the network are denoted by generic access points. An access point will be understood to be any one of a Transmission Point (TP), a Reception Point (RP) and a transmission/reception point (TRP). It will be understood that the term AP may be understood to include the above mentioned nodes and their successor nodes, but is not necessarily limited to these.

Services supported by a network operator may fall into a range of categories including, for example: enhanced mobile broadband (eMBB) communications, such as two-way voice and video communications; message transmission; streaming media content delivery; ultra-reliable and low latency communication (URLLC); and large Machine Type Communications (mtc). Each of these categories may include multiple service types-for example, both intelligent transportation systems and electronic health services may be categorized as URLLC service types.

In some embodiments, the status configuration for a given UE device may be based on services supported by the UE device. For example, an enhanced mobile broadband (eMBB) service may be mapped to a state configuration that includes active, ECO, and idle states and transition paths between various ones of these states. Accordingly, a state configuration to which the eMBB service is mapped may be selected for a UE device supporting the eMBB service.

The ECO state is a power saving state that allows transmission of some small packets of the UE. Which helps to reduce signaling overhead and energy consumption for background traffic, such as keep-alive messages generated by mobile operating systems, instant messaging, reports generated by sensors and/or smart meters, etc. The ECO state may also be referred to as an inactive state, which will be used in the present application.

Disclosure of Invention

A system and method for a UE state machine supporting multiple services or air interfaces. A UE may have one state machine configuration for multiple services (or service sets) or air interfaces. A UE may have multiple state machines operating independently for different services (or service sets) or air interfaces. A UE may have multiple state machines working in concert for different services (or service sets) or air interfaces. The UE may have a state machine that uses a state machine configuration selected from a plurality of state machine configurations according to the service used. The state machine configuration may be adapted for the service. Upon initialization, the state machine configuration may be default or determined according to services that the UE may use. During operation, the configuration of the state machine may change (e.g., adding/removing states in the state machine) according to changes in the service for the UE.

According to an aspect of the invention, a method for a UE in a wireless communication network, the method comprising: the UE operates based on a plurality of state machines, wherein each state machine is for a respective slice in the wireless communication network, each state machine having a plurality of states and state transitions dependent on conditions related to the respective slice.

In some embodiments, multiple state machines operate independently.

In some embodiments, in addition to the local conditions of each state machine related to the respective slice, there is at least one state machine dependency between two or more of the plurality of state machines, such that the condition of a state or state transition of one of the state machines is dependent on the state of another state machine or on a condition related to a service or service group or air interface of another state machine.

In some embodiments, the at least one state machine dependency comprises: the particular state of the first state machine directly results in a dependency of the particular state of the second state machine.

In some embodiments, the at least one state machine dependency comprises: the condition of a particular state transition in a first state machine depends on the dependency of a particular state of a second state machine.

In some embodiments, the at least one state machine dependency comprises: the condition of a particular state transition in a first state machine directly results in a dependency of a particular state of a second state machine.

In some embodiments, the at least one state machine dependency comprises: the condition of a particular state transition in a first state machine depends on the dependency of the condition of a particular state transition of a second state machine.

In some embodiments, the at least one state machine dependency comprises: when the first state machine has an inactive state but does not have an active state, and when any other state machine except the first state machine transitions to an active state or an inactive state and the current state of the first state machine is not an inactive state, then the current state of the first state machine transitions to an inactive state.

In some embodiments, the method further comprises: in a connection establishment procedure for a session-based service, the UE receives a message to configure some other state machine of the UE.

In some embodiments, the at least one state machine dependency comprises two state machine dependencies between a first state machine and a second state machine of the plurality of state machines, such that a condition of a state or state transition of the first state machine is dependent on a state of the second state machine or a condition related to a service or service group or air interface of the second state machine, and such that a condition of a state or state transition of the second state machine is dependent on a state of the second state machine or a condition related to a service or service group or air interface of the second state machine.

In some embodiments, the states of a first one of the state machines are a subset of the states of a second one of the state machines; the second state machine operates as a primary state machine and the first state machine operates as a secondary state machine dependent upon the primary state machine; the state transition of the primary state machine takes into account the conditions of the primary state machine and the secondary state machine; the state of the secondary state machine is determined by a mapping of the state from the primary state machine.

In some embodiments, the plurality of state machines includes at least two state machines having one or more states each of which is common between two or more of the state machines; at least one state machine dependency is such that when one state machine transitions to a state in common with one or more other state machines, the one or more other state machines also transition to that state if the one or more other state machines are not already in that state.

In some embodiments, the method comprises: the UE operates based on a state machine having a plurality of state machine configurations, wherein each state machine configuration is for a respective slice in the wireless communication network, each state machine configuration having a plurality of states and state transitions dependent on conditions related to the slice.

In some embodiments, the method further comprises: when only one of the slices is being used, the UE uses a state machine with a corresponding state machine configuration.

In some embodiments, the method further comprises: when multiple slices are in use, a state machine having a common state machine configuration for the multiple slices is used.

In some embodiments, the states in the common state machine configuration are determined from the states in the state machine configuration for the plurality of slices.

In some embodiments, the common state machine configuration includes all states used in any state machine configuration for the plurality of slices.

In some embodiments, the common state machine configuration comprises the states used in one state machine configuration having the strongest states.

In some embodiments, a common state machine configuration includes any state that is common to multiple state machine configurations.

In some embodiments, the common state machine configuration includes one or more additional states that are not common to the plurality of state machine configurations.

In some embodiments, the common state machine configuration is determined from a mapping table.

In some embodiments, the mapping table maps from combinations of slices to state machine configurations.

In some embodiments, the mapping table maps from each combination of the plurality of state sets to a respective single state set.

In some embodiments, the common state machine configuration is predefined, signaled from the network to the UE, or partially predefined and partially signaled.

In some embodiments, the common state machine configuration is updated according to the slice used by the UE.

In some embodiments, the method further comprises: the UE sends signaling to the network indicating a change in slice or indicating a change in common state machine configuration.

In some embodiments, the method further comprises: after a change of the common state machine configuration, a first state after said change is set according to predefined rules.

According to another aspect of the present invention, there is provided a UE configured to implement one of the methods outlined above or described herein.

Drawings

For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

fig. 1 is a schematic diagram of an exemplary communication system suitable for implementing various examples described in this disclosure;

fig. 2 is a diagram illustrating an example set of parameters defined by a RAN slice manager for a service-specific RAN slice instance, according to an example embodiment;

fig. 3 is a diagram illustrating an example of slice-based service isolation in a RAN;

fig. 4 is a diagram illustrating dynamic slice allocation for different services on a common carrier in accordance with an example embodiment;

fig. 5 is a schematic diagram illustrating another example of slice-based service isolation in a RAN;

fig. 6 is a schematic diagram illustrating a UE connected to multiple slices through different access technologies;

FIG. 7 is a schematic diagram illustrating a service customization virtual network implemented with slices in accordance with an illustrative embodiment;

FIG. 8 is a schematic diagram of an exemplary processing system suitable for implementing various examples described in this disclosure;

fig. 9 is a diagram of an architecture for routing traffic from a core network slice to a RAN slice in accordance with the disclosed embodiments;

fig. 10 is a flow diagram illustrating a method for routing downlink traffic received from a core network slice to an AP in accordance with the disclosed embodiments;

fig. 11 is a flow chart illustrating a method performed by an access point in accordance with the disclosed embodiments;

fig. 12 is a diagram of an architecture similar to that in fig. 9 for routing traffic from a core network slice to a RAN slice in accordance with the disclosed embodiments;

FIG. 13 is a flow chart illustrating a method performed by a network controller in accordance with the disclosed embodiments;

FIG. 14 illustrates an exemplary communication system according to an exemplary embodiment described herein;

fig. 15 shows an example of UE operating states according to an example embodiment described herein;

fig. 16 illustrates an example of signaling overhead in supporting two states compared to three states according to an example embodiment described herein;

FIG. 17A illustrates an example of a state configuration according to an example embodiment described herein;

FIG. 17B illustrates additional details of an enhanced idle state included in one of the exemplary state configurations shown in FIG. 4A;

FIG. 17C shows additional details of an enhanced active/connected state included in one of the exemplary state configurations shown in FIG. 4A;

FIG. 17D illustrates additional details of an enhanced idle state included in one of the exemplary state configurations shown in FIG. 4A;

fig. 18A illustrates an example of a mapping between network slices and state configurations according to an example embodiment described herein;

fig. 18B illustrates an example of a UE device configured with multiple status configurations according to example embodiments described herein;

FIGS. 19A and 19B illustrate exemplary message exchange diagrams in accordance with the exemplary embodiments described herein;

fig. 20 shows a flowchart of exemplary operations in a network device according to exemplary embodiments described herein;

fig. 21 shows a flowchart of exemplary operations in a UE device according to exemplary embodiments described herein;

fig. 22 shows a block diagram of an exemplary network device according to an exemplary embodiment described herein;

fig. 23 shows a block diagram of a UE device according to an example embodiment described herein;

FIG. 24 is an example of a state machine configuration that changes when a service stops or starts;

fig. 25 is an example of a state machine configuration that changes when a new air interface is connected or released;

FIGS. 26 and 27 are examples of two state machine configurations, where there is a state machine configuration dependency of one state machine configuration on the other state machine configuration;

FIG. 28 is an example of two state machine configurations where there is a state machine configuration dependency of one state machine configuration on the other state machine configuration and a state machine configuration dependency in the reverse direction;

FIG. 29 is an example of a two state machine configuration in which there is a state machine configuration dependency of one state machine configuration on another state machine configuration, wherein one of the state machine configurations has three states; and

FIG. 30 is an example of a three state machine configuration in which there is a synchronization state.

Detailed Description

Software Defined Networking (SDN) and Network Function Virtualization (NFV) have been used to implement network slices in physical core networks. Network slicing involves allocating resources (such as computing, storage, and connection resources) to otherwise create an isolated virtual network. From the perspective of the network entities inside the slice, the slice is a different containing network. Traffic carried on the first slice is not visible to the second slice, as are any processing requirements within the first slice. In addition to isolating networks from each other, slicing allows individual slices to be created using different network configurations. Thus, the first slice may be created with network functionality that responds with very low latency, while the second slice may be created with very high throughput. The two slices may have different characteristics, allowing different slices to be created to meet the needs of a particular service. A network slice is a dedicated logical (also referred to as virtual) network with service specific functionality and may be hosted on a common infrastructure along with other slices. The service specific functions associated with a network slice may, for example, manage geographic coverage area, capacity, speed, latency, robustness, security, and availability. Traditionally, network slicing is limited to the core network in view of the difficulty of implementing slicing in the Radio Access Network (RAN). However, an exemplary embodiment for implementing RAN slicing will now be described. In at least some examples, the RAN slice and the network core slice are coordinated to provide an end-to-end slice, which can be used to provide service specific network slices that extend throughout the entire core network and RAN communication infrastructure.

The radio resources allocated to the RAN are typically a set of radio network permissions granted to the network operator, which may include, for example, one or more specified radio frequency bandwidths within one or more geographic regions. A network operator typically engages a customer with a Service Level Agreement (SLA) specifying the level of service that the network operator must provide. Services supported by a network operator may fall into a series of categories including, for example: basic mobile broadband (MBB) communications, such as two-way voice and video communications; message transmission; streaming media content delivery; ultra-reliable low latency (URLL) communications; micro Machine type communications (μ MTC); and large-scale machine type communication (mtc). Each of these categories may include multiple service types-for example, intelligent transportation systems and electronic health services may each be categorized as URLL service types. In some examples, network slices may be assigned for services for a group of customers (e.g., smart phone subscribers in the case of mobile broadband), and in some examples, network slices may be assigned for a single customer (e.g., an organization that provides an intelligent transportation system).

Fig. 1 is a schematic diagram of an exemplary communication system or network 100 in which examples described in this disclosure may be implemented. The communication network 100 is controlled by one or more organizations and includes a physical core network 130 and a Radio Access Network (RAN) 125. In some examples, the core network 130 and the RAN125 are controlled by a common network operator, whereas in some examples, the core network 130 and the RAN125 are controlled by different organizations. In some embodiments, multiple RANs 125, at least some of which are controlled by different network operators, may be connected to a core network 130 controlled by one or more network operators or by an independent organization. The core network 130 is sliced and is shown with CN slice 1132, CN slice 2134, CN slice 3136, and CN slice 4138. As will be discussed in more detail below, it is also understood that multiple core networks may use the same RAN resources.

An interface between the core network 130 and the RAN125 is provided to allow traffic from the CN 130 to be directed to the UE110 through an Access Point (AP) 105, which may be a base station, such as an evolved nodeb (enb), a 5G node in the Long-term evolution (LTE) standard, or any other suitable node or access point. The AP105, also referred to as a transmission/reception point (TRP), may serve multiple mobile nodes, commonly referred to as UEs 110. As described above, in the present specification, an Access Point (AP) is used to denote a wireless edge node of a network. Thus, the AP105 provides the wireless edge of the RAN125, where the RAN125 may be, for example, a 5G wireless communication network. UE110 may receive communications from AP105 and transmit communications to AP 105. Communication from the AP105 to the UE110 may be referred to as Downlink (DL) communication, and communication from the UE110 to the AP105 may be referred to as Uplink (UL) communication.

In the simplified example shown in fig. 1, network entities within the RAN125 may include a resource allocation manager 115, a scheduler 120, and a RAN slice manager 150, which in some embodiments may be under the control of a network operator controlling the RAN 125. The resource allocation manager 115 may perform mobility-related operations. For example, the resource allocation manager 115 may monitor the mobility state of the UE110, may oversee handover of the UE110 between or within networks, and may enforce UE roaming restrictions, among other functions. The resource allocation manager 115 may also include air interface configuration functionality. Scheduler 120 may manage the use of network resources and/or may schedule times for network communications, among other functions. RAN slice manager 150 is configured to implement RAN slices as described in more detail below. It should be understood that in some embodiments, scheduler 120 is a slice-specific scheduler and is specific to RAN slices and is not common to the RAN. Those skilled in the art will further recognize that in some embodiments, some slices will have a slice-specific scheduler, while other slices will use a common RAN scheduler. The common RAN scheduler may also be used to coordinate between slice-specific schedulers so that common RAN resources are properly scheduled.

In an exemplary embodiment, the core network 130 includes a core network slice manager 140 for implementing (and optionally managing) core network slices. As shown in fig. 1, the core network 130 has four illustrated slices: CN slice 1132, CN slice 2134, CN slice 3136 and CN slice 4138. In some embodiments, these slices may appear as different core networks to the RAN. UE110 may include any client device and may also be referred to as, for example, a mobile station, a mobile terminal, a user device, a client device, a subscriber device, a sensor device, and a machine type device.

Next generation wireless networks, such as fifth generation or so-called 5G networks, may support flexible air interfaces in RAN125 that allow for the use of different waveforms, and different transmission parameters for each waveform, such as different sets of underlying parameters (numerology) for some supported waveforms, different frame structures, and different protocols. Similarly, to take advantage of a large number of APs 105, which may take the form of transmission points of the size of both macro and pico cells operating in different frequency bands, a 5G network may group a series of APs 105 to create a virtual transmission point (vTP). One may refer to the vTP coverage area as a super cell. By coordinating the transmission of signals from APs 105 in a virtual TP, network 125 may improve capacity and coverage. Similarly, a grouping of APs may be formed to create virtual receive points (vRP) that allow for multipoint reception. By changing the APs 105 in the virtual group, the network 100 may allow the virtual TPs and RPs associated with the UE110 to move throughout the network.

From the perspective of a network operator, deploying network infrastructure can be very expensive. Maximizing the use of deployed infrastructure and radio resources is important to enable network operators to reclaim their investment. The following disclosure provides systems and methods for enabling network slicing at the radio edge of RAN125 and for facilitating the routing of traffic between the slicing of the radio edge of RAN125 and core network 130, which may also be sliced. In some examples, this may enable end-to-end network slicing and allow network operators to later partition the network and provide service isolation in wireless connections within a single network infrastructure.

Referring to fig. 2, in an exemplary embodiment, a RAN slice manager 150 is configured to create and manage RAN slices 152. Each RAN slice 152 has uniquely allocated RAN resources. The RAN resources available for allocation may be classified as: RAN access resources comprising

AP105 and UE 110;

a radio resource, comprising:

radio network frequency and time (f/t) resources 158, and

spatial resources based on the geographic location of the APs 105 associated with the slice and based on the directionality of the transmission if advanced antenna techniques are applied; and

a radio interface configuration 160 that specifies how radio resources and access resources interface with each other.

The wireless air interface configuration 160 may, for example, specify attributes for one or more of the following categories: radio access technology 162 (e.g., LTE, 5G, WiFi, etc.) to be used for slicing; the type of waveform 164 to be used (e.g., Orthogonal Frequency Division Multiple Access (OFDMA), Code Division Multiple Access (CDMA), Sparse Code Multiple Access (SCMA), etc.); base parameter set parameters 166 for a particular waveform (e.g., subcarrier spacing, transmission time interval length (TTI), Cyclic Prefix (CP) length, etc.); a frame structure 165 (e.g., UL/DL partition configuration for TDD systems); available multiple-input-multiple-output (MIMO) parameters 168; multiple access parameters 170 (e.g., grant/grant-less scheduling); coding parameters 172 (e.g., type of error/redundancy coding scheme); and functional parameters of the AP and the UE (e.g., parameters that manage AP handover, UE retransmission, UE state transition, etc.). It will be understood that not all embodiments will include the entire list of radio transmission functions described above, and in some cases there may be overlap in some of the categories described above-e.g. a particular waveform may be inherently defined by a given RAT.

In an exemplary embodiment, the RAN slice manager 150 manages allocation of RAN resources to particular RAN slices 152 and communicates with the resource allocation manager 115 and the scheduler 120 to enable serving a particular RAN slice 152 and to receive information regarding RAN resource availability. In an exemplary embodiment, the RAN slice manager defines RAN resources for the RAN slice 152 based on slice requirements received from the core network 130 and in particular the core network slice manager 140.

RAN slices are instances that may be established and maintained for different durations, ranging from long-term instances that may be established and maintained indefinitely to temporary RAN slice instances that may only persist briefly for a particular function.

In an exemplary embodiment, the RAN slice manager 150 is configured to implement RAN slices to achieve one or more of the following functions: service isolation within a carrier, dynamic radio resource allocation taking slices into account, mechanisms for radio access network abstraction, cell association on a per-slice basis, handover mechanisms at the physical layer, and per-slice state machines. Those skilled in the art will recognize that this list is neither exhaustive nor necessary to have all the features to provide RAN slices. The RAN slice for these functions will now be described in more detail.

In at least some examples, the RAN slices 152 are each associated with a particular service. In another embodiment, any or all of the RAN slices 152 may carry traffic associated with a set of services. Services that may require RAN slices 152 with similar parameters and characteristics can be combined together on a single slice to mitigate the overhead of creating different slices. As will be well understood, the traffic associated with different services may be distinguished by using a service identifier. As shown in fig. 2, RAN slice 152 will be associated with a set of AP105 nodes (AP set 154) and a set of receiving UEs 110(UE set 156) that communicate with each other using a particular air interface configuration 160 and a set of radio frequency/time resources 158. UEs 110 within UE set 156 are typically UEs associated with services within slice 152. By creating a slice, a set of resources is allocated and traffic in the slice is contained so that different services using RAN125 can be isolated from each other. In this regard, in the exemplary embodiment, isolation means that communications occurring in respective simultaneous RAN slices will not affect each other, and additional RAN slices can be added without affecting communications occurring in existing RAN slices. As will be explained in more detail below, in some example embodiments, isolation may be achieved by configuring each RAN slice 152 to use a different air interface configuration 160 (including the waveform base parameter set 166). By selecting the air interface configuration 160 based on the requirements for the slice, the performance of the slice may be improved or the impact of resource usage of the slice may be reduced, which may be achieved by using waveforms with better spectral localization. For example, subband filtering/windowing may be applied at the receiver to reduce interference between adjacent subbands where different sets of base parameters are applied. As will be discussed further below, different RAN slices 152 may be associated with different sets of physical transmitting and receiving nodes.

Thus, those skilled in the art will recognize that while the slices may be distinguished by the allocation of radio time/frequency resources 158, the slices may also be distinguished by a designated air interface configuration 160. For example, by allocating resources 172 based on different codes, different slices can be maintained separately. In access technologies using different layers, such as Sparse Code Multiple Access (SCMA), different layers may be associated with different slices. The slices may be separated from each other in the time domain, frequency domain, code domain, power domain, or specific domain (or any combination of the above).

In some embodiments, assigning a set of time/frequency resource pairs 158 to a slice enables transmission of traffic intended for that slice over dedicated radio resources. In some embodiments, this may include allocating the entire frequency band to a slice at fixed time intervals, or it may include always allocating a dedicated subset of the available frequencies to a slice. Both of these may provide service isolation, but they may be somewhat inefficient. Because such resource scheduling is typically predefined, there may be a long period of time between redefining resources during which the allocated resources are not fully used. If there are devices that are idle for a long period of time, the redefinition cannot be too frequent, otherwise the devices will have to reconnect to the network frequently to obtain this information. Thus, in the exemplary embodiment, service isolation on a common carrier (e.g., within the same carrier frequency) allows multiple services within the same carrier to coexist independently. Physical resources and other resources may be slice-by-slice dedicated within a set of dedicated slice resources. As noted above, in 5G networks, it is desirable that many different protocols and waveforms can be supported, some of which may have many different sets of underlying parameters.

In some examples, resource allocation manager 115 includes a slice-aware air interface configuration manager (saiicm) 116 that controls APs 105 based on the air interface configuration allocated to RAN slices 152 by RAN slice manager 150, allowing the waveform and underlying parameter sets to be dedicated to slices 152. Then, based on the set of network f/t resource parameters allocated by the at least one RAN slice manager 150, the network scheduler 120 allocates transmission resources to all nodes (AP 105 or UE 110) transmitting data in a slice, and the nodes transmit within the allocated AP resources 154 and UE resources 156. This allows one or more network entities, such as RAN slice manager 150 and resource allocation manager 115, to dynamically adjust resource allocation, as will be discussed in more detail below. The dynamic adjustment of resource allocation allows for providing the lowest level of service guarantees to slice 152 without requiring that the resources used to provide this level of service be exclusively dedicated to that slice. This dynamic adjustment allows otherwise unused resources to be allocated to other needs. Dynamic dedication of physical resources may allow a network operator to increase the use of available nodes and wireless resources. One or more network entities, such as RAN slice manager 150 and resource allocation manager 115, may allocate parameters to individual slices based on the requirements of the services supported by the slices. In addition to the service isolation discussed above, in some embodiments, generating service-specific (or class of service-specific) slices allows RAN resources to be tailored to the supported services. Different access protocols may be provided for each slice, allowing, for example, different acknowledgement and retransmission schemes to be used in each slice. A different set of Forward Error Correction (FEC) parameters may also be set for each slice. Some slices may support grant-free transmission, while other slices will rely on grant-based uplink transmission.

Thus, in some example embodiments, the RAN slice manager 150 is configured to achieve service isolation by differentiating air interface configurations 160 for each service-centric RAN slice 152. In at least some examples, differentiating between attributes of different over-the-air configurations 160 assigned to different RAN slices 152 by RAN slice manager 150 may provide service isolation even when other RAN slice parameter sets (e.g., one or more of AP set 154, UE set 156, and network f/t set 158) are similar.

Fig. 3 shows an example of service isolation within a carrier. Specifically, in the example of fig. 3, three services S1, S2, and S3 are allocated by RAN slice manager 150, respectively, for respective RAN slices 152(S1), 152(S2), and 152(S3) for common frequency range allocation (common carriers), with adjacent frequency sub-bands in RAN125 being allocated to these RAN slices. In the example of fig. 3, the RAN slices 152(S1), 152(S2), and 152(S3) allocated to the three services S1, S2, and S3 each include the same allocation for the AP set 154 and the UE set 156, and have similar network f/t resources 158 of adjacent sub-band allocation. However, the air interface configurations 160 assigned to the three services S1, S2, and S3 are distinguishable to provide service isolation even if these services are intended to operate using similar carrier frequency resources (i.e., adjacent subbands specified in the network f/t resources 158). In the example shown, differentiation is provided in one or both of the waveform 164 and base parameter set parameter 166 assignments. The base parameter set parameters define parameters that specify the waveform. For example, in the case of an OFDMA waveform, the base parameter set parameters include a subcarrier spacing, a length of a cyclic prefix, a length of an OFDM symbol, a duration of a scheduled transmission duration, and a number of symbols included in the scheduled transmission duration.

Specifically, in the example of fig. 3, the RAN slice 152(S1) and the RAN slice 152(S2) are each assigned the same waveform function (OFDMA), but are each assigned different base parameter set parameters (base parameter set a and base parameter set B, respectively) applied to the waveform function. For example, base parameter set a and base parameter set B may specify different TTI lengths and subcarrier spacings for respective OFDMA waveforms. A third RAN slice 152(S3) is assigned a different multiple access function 170 (e.g., SCMA) and a set of base parameter set parameters (base parameter set C) appropriate for the waveform associated with the different multiple access function.

In some examples, different transmission function 160 parameters assigned to different RAN slices may sufficiently partition different services such that RAN slices may be implemented in overlapping frequencies in overlapping times. However, in some embodiments, time differentiation may also be required, which may be accomplished, for example, by scheduler 120.

In some example embodiments, service isolation may also be achieved by differentiating access resources allocated to different RAN slices. For example, the AP sets 154 assigned to different RAN slices 152 may be sufficiently different that geographic isolation occurs. Furthermore, as described above, different network frequency/time resources 158 may be used to isolate different RAN slices.

In an exemplary embodiment, the parameters set for the RAN slice instance may be dynamically varied based on real-time network requirements and available resources. Specifically, in an exemplary embodiment, RAN slice manager 150 is configured to monitor real-time requirements and available resources on RAN125 and RAN slices 152, and based on the monitored information and performance requirements defined for a particular service (e.g., performance requirements specified in an SLA), RAN manager 150 may redefine its allocations for slices.

Fig. 3 also shows that AP 2105 is present in RAN 125. The AP 2105 serves a different UE110 than the illustrated UE110 served by the AP105, and supports services in slice 1152 (S1), which is one of the slices supported by the AP105, and slice 4152 (S4). The parameters of the slice 4152 (S4) are not shown, but should be understood to be different from those of the slice 1152 (S1). Accordingly, the UE110 connected to slice 1152 (S1) may be served by either or both of AP105 and AP 2105. It should also be understood that not all APs within a single RAN need to support the same set of slices.

Fig. 4 schematically illustrates a set of RAN resources, in particular radio frequency/time (f/t) resources, associated with a common carrier, e.g., RAN 125. In the example of fig. 4, the resource allocation manager 115 allocates f/t resources to the slices 152(S4), 152(S5), and 152(S6) respectively associated with the specific services S4, S5, and S6, respectively, according to an instruction received from the RAN slice manager 150. Service S4, which may be directed to an ultra-low-latency-reliable communication (ULLRC) device, is allocated with resources associated with ULLRC slice 152(S4), service S5 for mobile broadband (MBB) is allocated with resources associated with MBB slice 152(S5), and service S6 for large-scale machine type communication (mtc) is allocated with resources associated with mtc slice 152 (S6). As shown in fig. 4, the allocation may be dynamic in that the allocation of the associated frequency resources within the common carrier RAN resources 200 may change from time T1 to time T2. Further, between times T1 and T2, different resource allocations may be made for each slice 152 by setting a different wireless air interface configuration 160 (including one or more of the underlying parameter set, waveform, and protocol) for each slice. Other RAN slice resource parameters, including, for example, physical access resources (AP set 154 and UE set 156) may also be allocated differently to different slices between times T1 and T2. Although the frequency resources are illustrated as contiguous in fig. 4, the frequency subbands allocated to the respective slices are not necessarily contiguous, and within each slice 152, the allocated frequency subband resources may be non-contiguous. Although one MBB slice 152(S5) is shown in FIG. 4, there may be multiple MBB slices and additional non-MBB slices. It will be understood from the above description that by using different sets of base parameters, different waveforms, and different protocols for different slices 152(S4), 152(S5), and 152(S6), traffic from the respective slices 152(S4), 152(S5), and 1S2(S6) is effectively isolated. The functions and nodes within each slice, such as the device (UE 110) or entity (AP 105) supporting the service associated with the slice, only know their own set of underlying parameters, thus allowing their traffic isolation. In an exemplary embodiment, to reduce interference between channel frequency resources allocated to different slices with different sets of base parameters, subband filtering or windowing is applied at the receiving AP105 or UE110 to further enhance localization of waveforms with different sets of base parameters. In an exemplary embodiment, to accommodate different levels of functionality at AP105 and UE110, RAN slice manager may allocate multiple alternative sets of air interface configurations 160 to each RAN slice 152, with the appropriate transmission functionality selected by resource allocation manager 115 or AP105 at the time of transmission.

The wireless f/t resources may be viewed as two dimensions in a resource grid. In fig. 4, the different physical sizes of the blocks represent the relative usage of radio resources in the RAN125 by the services S4, S5, and S6, depending on the slice allocation made by the RAN slice manager 150 and implemented by the resource allocation manager 115 and scheduler 120. Dynamic allocation of resources may be performed by using a scheduling method that allows different waveforms to be transmitted in different resource blocks in the resource grid, as well as variations in resource grid allocation. The flexible resource grid coupled with the ability to allocate different transmission function resources, such as different waveforms with different sets of underlying parameters, provides an additional dimension of control. The wireless f/t resource allocation can be dynamically changed according to the load change of different slices.

Those skilled in the art will recognize that resources may be allocated to the slice 152 to account for the very different traffic configurations that different slices may have. For example, mobile broadband (MBB) connections are decentralized but very large in capacity, while Machine Type Communication (MTC) devices typically generate traffic configurations with a large number of devices that transmit small amounts of data at fixed intervals or in response to events, and devices connected to URLLC services may generate a large amount of traffic that may be fairly continuous over a limited period of their activity, and may occupy a large amount of resources due to the need for both low latency and reliability. When URLLC and MTC services do not consume their resource allocations, resources allocated to other services (such as MBBs) may be increased instead of dedicating resources to ULLRC deployments or large-scale MTC deployments, resulting in unused resources when ULLRC deployments or large-scale MTC deployments do not generate traffic. Fig. 2 illustrates an example of such an allocation change, where the portion of resource 200 allocated to MBB slice 152(S5) increases at time T2 relative to time Tl, while the portions of resource 200 allocated to ULLRC slice 152(S4) and mtc slice 152(S6) decrease at time T2 relative to time T1. Different waveforms may be selected for different types of connections and different sets of base parameters for a single waveform may be used to distinguish between two slices serving similar connection types (e.g., two MTC services may both use the same waveform but have different sets of base parameters) to maintain service isolation and efficient utilization of spectrum resources.

In at least some examples, the RAN slice may be used to decouple UE110 from physical AP105 and provide a radio access network abstraction layer. For example, different RAN slices 152 may be assigned different AP sets 154 such that the UE110 may maintain a first session for a first service with a first RAN slice 152(S1) and a first AP105, and also maintain a second session for a second service with a second RAN slice 152(S2) and a second AP 105. Such a configuration allows the use of the AP that is best suited for a particular service. It should be understood that a group of APs may be combined together to form a virtual access point. The service areas of the virtual access points may be represented as a union of the service areas of the constituent APs. An AP identifier may be assigned to vAP. vAP may be customized to act as a point of transmission or reception (vTP, vRP). Multiple different vAP may have overlapping membership such that: each vAP is composed of multiple different physical APs, some of which are part of different vAP. Some vAP may have the same membership as others vAP.

In some embodiments, RAN slice manager 150 may be configured to allocate both logical and physical access resources to RAN slice 152. For example, referring to fig. 5, there are a plurality of APs 105. As discussed above, these APs 105 may be used to create virtual APs rather than each AP105 operating independently. Virtual TP176 and virtual RP 178 may be created with different but overlapping sets of APs. Different vTP and vRP may be created for each slice. In addition to allocating different physical resources to the slices, the RAN slice manager 150 may also allocate logical resources such as vTP 176 and vRP 178 to each slice. The following patent applications describe wireless networks in which a UE is associated with virtual TPs and RPs: U.S. patent publication No. US2015/0141002A1 entitled "System and method for Non-Cellular Wireless Access"; U.S. patent publication No. US2014/0113643A1 entitled "System And Method For Radio Access visualization" And U.S. patent publication No. US 2014/0073287A 1 entitled "System And Method For use User Equipment centralized System Access In Radio Access Network", which are incorporated herein by reference. In an exemplary embodiment, aspects of the virtualization and abstraction methods disclosed in these patent publications may be performed for RAN slices to achieve slice-specific virtualization and abstraction as described below.

In some embodiments, the various devices (UEs 110) connected to the wireless network (RAN 125) will each participate in one or more different services (e.g., ULLRC service S4, MBB service S5, mtc service S6), and each service may be allocated a different RAN slice 152. The resource allocation manager 115 may allocate different slices to each virtual TP176 or RP 178 to adjust to demand. For example, a UE110 supporting multiple services, e.g., ULLRC services and MBB services for relaying information such as that generated by a heart rate monitoring service, may transmit data associated with each of these services on different slices. Each slice may be assigned a different encoding format and may be transmitted to the corresponding slice using a different virtual RP 178. When there is data to be transmitted, UE110 may provide 152 an indication to RAN125 of the slice being used.

As the UE110 moves, it may remain connected to the same virtual send/receive point TP/RP 176, 178, but the physical access point (AP 105) in the virtual access point TP/RP 176, 178 will change. Furthermore, as UE110 moves further distances, it is possible that the physical AP or wireless t/f resources that were originally used are no longer available to RAN 125. This may occur when UE110 travels far enough that the spectrum allocated to the slice by the carrier is no longer available, or if the network operator uses the infrastructure owned by another entity in the same area and cannot access the same resources in another entity. In the latter case, it is also possible that the particular waveforms allocated to slice 152 for use by UE110 in transmitting over RAN125 are no longer available. In such a case, the resource allocation manager 115 may notify the UE110 that the transmission parameters will change at a certain geographical point. In some embodiments, this may be performed as part of a handover procedure. It should also be understood that when virtual TP/RPs 176, 178 or other vAP are associated with UE110 on a per-slice basis, there may be instances where switching occurs for one slice rather than another. This may occur in a number of different scenarios, including a scenario where the UE110 is connected to a first service provider for a first service in a defined slice and a scenario where the UE is connected to a second service provider for a second service in another defined slice. In this scenario, the boundary between APs or vAP may differ from service provider to service provider. In the context of providing both services through the same provider (or at least access services provided by the same provider), the boundaries between slice-specific APs may be misaligned, which will result in slice-based handovers.

In some examples, the waveform parameters 164 may be changed when the UE110 is handed off to (or otherwise served by) a different TP 170 operating in a different frequency band. RAN slice 152 may have two alternative TPs 176 allocated to it for serving UE110, where one TP176 operates in a high frequency band, such as the millimeter-wave band, and the other TP176 operates in a lower frequency. The switching between different frequency bands and the corresponding switching between APs of slice 152 for serving UE110 may be dynamic, depending on scheduling decisions made at scheduler 120 and implemented by resource allocation manager 115.

By connecting the UE110 to the virtual access points TP/RPs 176, 178, the UE110 may be logically decoupled from the actual physical infrastructure. This may alleviate problems associated with cell handover and cell edge interference. Virtual TP176 and virtual RP 178 may be assigned different sets of physical APs 105 such that different slices may be served by different sets of hardware resources. This may allow network operators to dedicate expensive and high capacity access points to services such as MBBs and lower cost APs 105 to services such as MTC services. Moreover, allocating the TP176 and the RP 178 as separate logical entities may be used to decouple the uplink and downlink data paths, which may allow better use of the network infrastructure in some cases. If a given RAN slice 152 is dedicated to MTC devices that generate uplink traffic at fixed intervals but rarely send any downlink traffic, that slice may be served by a set of virtual RPs 178, which set of virtual RPs 178 is designed to be more robust than virtual TPs 176. This allows resource allocation to serve the needs of the services allocated to the RAN slice 152 to achieve a finer level of granularity than if the AP were allocated as a whole, as would be required in a conventional LTE network where enodebs would be allocated and two-way services would be provided.

Creating the virtual TP176 and the RP 178 may also be referred to as generating a super cell. The super cell allows multiple physical APs 105 to work together to serve the UE 110. A super cell may be associated with both UE110 and RAN slice 152. This allows the UE110 to communicate with different super cells in each slice. Each super cell may then be configured for the specific needs of the slice associated with each super cell. For example, the UE110 may communicate with a first super cell (TRP) for one RAN slice 152(S4) centered on a first service and communicate with a second super cell for traffic associated with a RAN slice 152(S5) centered on a second service. Slices carrying traffic associated with MTC services may be directed to serve fixed MTC devices (in the case where UE110 is an MTC device). Slices dedicated to fixed MTC devices may be designed to be stable and relatively invariant in their membership. Other slices, such as those dedicated to mobile MTC devices such as intelligent transportation system devices and other such mobile services, may be configured to accommodate greater mobility. Slices supporting fixed MTC devices may also be designed to have limited functionality in mobility management functions (e.g., mobility management entities) due to limited mobility of the supported devices. It should be appreciated that while the use of super cells allows for a reduction in the number of handovers, handovers may not be completely eliminated. Handover may occur when the waveform and base parameter sets assigned to a slice in a super cell are not available or supported at all points along the path of the mobile UE. By requiring a handover to a new super cell, the network may be able to ensure that new slice-specific information is transmitted to UE 110.

As described above, when different super cells are used to serve different slices, the UE110 may undergo a handover in a first RAN slice 152 without having to undergo a handover in another RAN slice 152. In some examples, RAN125 may encompass network resources allocated between multiple network operators, where different network operators each support different super cells. Because they are served by different super cells, different network operators may provide service support for the same UE110 for different service-based RAN slices 152. This allows the network operators to provide different services and allows the customer (user or service operator) to select different network operators to obtain different RAN slices 152 based on cost, coverage, quality of service, and other factors. Thus, in some examples, a UE110 utilizes a first RAN slice 152 supported by a first network operator to access a first service, and the same UE110 may utilize a second RAN slice 152 supported by a second network operator to access a second service.

Another example of allocating different access resources to different slices 152 will now be described with reference to fig. 6. As discussed above and shown in fig. 6, a single UE, such as UE110, may connect to different access points (both physical and virtual) for different services. Although

APs

602, 604, and 606 are shown as physical APs, it should be understood that they may also represent virtual APs having several constituent APs. In some examples, the RAN125 is a heterogeneous network with different types of APs and may support different RATs. The AP 602 is an access point that can provide a wide coverage area, also referred to as a macro cell, and generally provides access services in a lower frequency band. The AP 602 will typically be directly connected to the core network 130 and support a set of RATs (e.g., HSPA, LTE, 5G). Access point 604 and access point 606 can be APs directed to provide a smaller coverage area and are generally referred to as small cells, pico cells, and/or femto cells. The AP 604 and the AP606 may be indirectly connected to the core network 130 (e.g., through the internet, through a UE acting as a relay, or through a fixed wireless connection to the AP 602). In some embodiments, AP 604 and AP606 may be directly connected to the core network. AP 604 and AP606 may provide service in a higher frequency band (e.g., millimeter wave) and/or they may support a different set of RATs (e.g., WiFi or access technologies dedicated to higher frequency APs). As shown in fig. 6, where a heterogeneous network may be used, different access technologies or different waveforms may be used in conjunction with different access points to access different slices. When within the service range of the AP 604, the UE110 may rely on the AP 604 to the MBB slice 152 (S1). This may provide higher speed or lower cost connections to UE110, and it may remove high bandwidth connections with larger APs such as AP 602. The UE110 may also connect to an IoT service for MTC functionality. The MTC connection may be served by an IoT slice 152(S2) accessed through an AP 602 (which provides macro cell coverage). Macro cell coverage is generally more prevalent and may better support more devices at a given time than a smaller AP, such as AP 604. This increased coverage and the ability to support more devices may come at the expense of lower data rates than smaller access points 604. Since MTC devices typically require low bandwidth connections, most of them may be served in IoT service slice 152(S2) by connecting to AP 602. UE110 may also participate in services that require URLLC connections, which are supported by URLLC service slice 152 (S4). Downlink traffic in URLLC slice 152(S4) may be transmitted in the high-frequency band by AP606 as a TP. However, to ensure that uplink traffic is delivered reliably and does not switch between a large number of APs with smaller coverage areas, uplink traffic in the slice may be directed to AP 602. It should be understood that each AP may be represented by a virtual representation within each slice, such that uplink traffic in slice 152(S4) and uplink traffic in slice 152(S2) are sent to different logics vRP, where each logic vRP represents the same physical AP. In a 3G/4G network, UE110 is typically connected to one RAN access point at a time and routes all services through the same connection. By supporting simultaneous connections to different access points (both real and virtual), different slices can be isolated on a common access medium. Those skilled in the art will appreciate that different slices may use different waveforms (e.g., one slice may use an Orthogonal Frequency Division Multiple Access (OFDMA) waveform while a second slice uses another waveform such as a Sparse Code Multiple Access (SCMA) waveform), or that two slices may use the same type of waveform with different sets of base parameters (e.g., both may use OFDMA but with different spectral masks, different resource block sizes, etc.). It will also be understood that the TTI for each slice may be different, but in some embodiments it will be a multiple of the basic TTI value.

In an exemplary embodiment, the RAN slice manager 150 will allocate one set of APs (or TP/RP sets) and corresponding RATs or sets of RATs to a first RAN slice 152 and a different set of APs (or TP/RP sets) and corresponding RATs or sets of RATs to a second RAN slice. In some examples, overlapping sets of physical or virtual access points may be allocated to respective RAN slices, but with different usage priorities. For example, the MBB service slice 152(S1) would be assigned access point 604 as its primary RAN access and macro access point 602 as fallback; instead, IoT service slice 152(S2) will be assigned only macro access point 602 for its RAN access.

As described above, in at least some examples, each RAN slice 152 will effectively operate as a different virtual network indistinguishable from the physical network of most network nodes. In some embodiments, each RAN slice 152 may provide network resources tailored to the needs of the service operating within it. This may include providing both a data plane and a control plane in the network 100. Each slice may be equipped with a number of network functions that may operate as state machines. The scheduler may be represented as a state machine within a slice to provide scheduling in grant-based and grant-free transmission environments. In a slice, it may be determined that authorization-based transmission is to be used for transmission (e.g., a slice supporting MBB), while another slice may allow for authorization-free transmission (e.g., a slice supporting MTC or Internet of Things (IoT) devices). Slices may also be suitable for both unlicensed (or contention-based) and scheduled uplink transmissions. In some embodiments, different demands on the scheduler may result in the demands on the scheduler being very different from slice to slice, which may be advantageous for each slice to have its own scheduling function (or set of functions). This may be provided by a single scheduler shown as a logical scheduling state machine within each slice. Those skilled in the art will appreciate that access parameters, waveforms, base parameter sets, and other slice-specific parameters may be managed by different state machines in the UE and network entities associated with the slice. Thus, a UE connected to multiple slices may serve as a platform for multiple state machines.

A UE110 connected to a different slice may support a different set of state machines for each slice to which it is connected. These state machines will preferably run simultaneously and there may be an arbiter to ensure that contention for access to the physical resources in the UE is handled. Different state machines within the UE may cause the UE to perform both unlicensed and scheduling-based transmissions. There may also be functionality within the UE for coordinating the operation of multiple state machines.

Examples of state machine enabled UEs 110 and supporting networks are described in the following patent applications: U.S. patent publication No. US2015/0195788A1 entitled "System and Method For Always On Connection in Wireless Communication System"; U.S. patent publication No. US2016/0227481A1 entitled "Apparatus And Method For A Wireless Device ToReceive Data In An Eco State"; and U.S. patent application Ser. No. 15/165,985 entitled "System And Method of UE-Central Radio Access Procedure", all of which are incorporated herein by reference. In an exemplary embodiment, the state machine related functions described in the above documents are implemented on a slice-by-slice basis on the UE110 and the network, rather than on a device level basis. By way of example, in one embodiment, the RAN125 and the UE110 are configured to support different operating states of the UE110 for each RAN slice 152(S1) and 152(S2), wherein each operating state supports different UE functionality. Specifically, in one example, the UE110 is configured to implement a state machine that can transition between two different states, namely a first Active state and a second power saving ECO state, for each RAN slice 152(S1) and 152 (S2). In an exemplary embodiment, the set of radio access functions supported in the ECO state is reduced compared to the active state. At least some degree of connectivity to the RAN125 is supported in both states such that the UE 104 maintains an always connected to the RAN125 with respect to the RAN slice 152(S1) and the second RAN slice 152 (S2). In some embodiments, the UE110 is configured to receive both the grant-less and grant-based transmissions in the "active" state, but only the "grant-less" transmissions in the "ECO" state, and to receive the UE110 uplink state information more frequently and on a different channel in the active state relative to the ECO state.

Accordingly, the UEs 110 supporting each slice state machine may operate simultaneously in the same state (e.g., both slices are active or both slices are ECO state) or in different states (e.g., one slice is active and the other slice is ECO state) for both RAN slices 152(S1) and 152 (S2). In an exemplary embodiment, multiple states or different numbers of states may be supported for different RAN slices 152. In an exemplary embodiment, information defining whether and which states are supported in a slice is specified in the AP/UE function parameter set 174 (see fig. 2).

In another embodiment, the UE connects to a different RAN slice. A first slice may support services such as eMBB, while a second slice supports services that do not necessarily require the same level of connection reliability, e.g., MTC services. However, within the first slice, the UE may be in one of an active state or an idle state, while within the MTC slice, the UE may be in any one of an active state, an idle state, or an ECO state. In general, MTC devices may perform some grant-free or contention-based transmission from the ECO state and enter the active state only when there is a scheduled transmission window or a pre-scheduled downlink transmission. If a physical UE is in an active state within an eMBB slice, the physical UE may allow the MTC slice to perform transmissions without transitioning out of an idle state. This may allow a process or MTC slice within the UE to take advantage of the active state of another part of the UE.

It should be appreciated that although the above discussion has referred to having slices for each service, it may be more practical to provide a limited number of slices by the network, where each slice serves a plurality of different services with sufficiently similar properties. In one example, various different content delivery networks may coexist in a single RAN slice.

In the core network, each network-supported service may be provided with its own slice and associated with a corresponding RAN slice, such that end-to-end slice management may be performed under the control of the slice manager 130. In this regard, fig. 7 schematically illustrates a Service Customized Virtual Network (SCVN) implementation in which slices 1 through 5 are implemented as Virtual networks extending through the core Network 130 and the RAN125, respectively. In an exemplary embodiment, the slice manager 130 exchanges information with each of the core slice manager 140 and the RAN slice manager 150 to create end-to-end, service-centric slices 1 through 5. Each of slice 1 through slice 5 includes a set of resources for the core network defining an associated core network slice and a set of resources for the RAN125 defining an associated RAN slice 152.

In embodiments where both core and RAN slices occur, the resource allocation manager 115 (under instruction from the slice manager 130) may ensure that traffic received in a slice from the RAN125 is provided to a virtualized decoder connected to the corresponding slice in the core network 130. This ensures that isolation is maintained when data is received from the UE110 device, since decoding may occur within the appropriate network slice rather than at the public radio access point.

FIG. 8 is a schematic diagram of an example simplified processing system 400 that may be used to implement the methods and systems disclosed herein and the example methods described below. UE110, AP105, resource allocation manager, scheduler 120, slice manager 130, core network slice manager 140, and/or RAN slice manager may be implemented using example processing system 400 or variations of processing system 400. The processing system 400 may be, for example, a server or a mobile device, or any suitable processing system. Other processing systems suitable for implementing examples described in this disclosure may be used, which may include components different from those discussed below. Although fig. 8 shows a single instance of each component, there may be multiple instances of each component in processing system 400.

The processing system 400 may include one or more processing devices 405, such as a processor, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), dedicated logic circuitry, or a combination thereof. The processing system 400 may also include one or more optional input/output (I/O) interfaces 410, which may enable interfacing with one or more suitable input devices 435 and/or output devices 440. The processing system 400 may include one or more network interfaces 415 for wired or wireless communication with a network (e.g., an intranet, the internet, a P2P network, a WAN, and/or a LAN) or other node. Network interface 415 may include one or more interfaces to wired and wireless networks. Wired networks may use wired links (e.g., ethernet cables), while wireless networks (when used) may utilize wireless connections transmitted through antennas, such as antenna 445. The network interface 415 may provide wireless communication, for example, via one or more transmitters or transmit antennas and one or more receivers or receive antennas. In this example, a single antenna 445 is shown, which may serve as both a transmitter and a receiver. However, there may be separate antennas for transmission and reception in other examples. In embodiments where the processing system is a network controller (such as an SDN controller), there may be no wireless interface and antenna 445 may not be present in all embodiments. The processing system 400 may also include one or more storage units 420, which may include large scale storage units, such as solid state drives, hard disk drives, magnetic disk drives, and/or optical disk drives.

The processing system 400 may include one or more memories 425, which may include volatile memory or non-volatile memory (e.g., flash memory, Random Access Memory (RAM), and/or read-only memory (ROM)). The non-transitory memory 425 (as well as the storage device 420) may store instructions for execution by the processing device 405, e.g., to perform methods such as those described in this disclosure. The memory 425 may include other software instructions, such as for implementing an operating system and other applications/functions. In some examples, one or more data sets and/or modules may be provided by an external memory (e.g., an external drive in wired or wireless communication with processing system 400) or may be provided by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include RAM, ROM, Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, CD-ROM, or other portable memory.

A bus 430 may be present to provide communication among the components of the processing system 400. The bus 430 may be any suitable bus architecture including, for example, a memory bus, a peripheral bus, or a video bus. Optionally, an input device 435 (e.g., a keyboard, mouse, microphone, touch screen, and/or keypad) and an output device 440 (e.g., a display, speakers, and/or printer) are shown external to processing system 400 and connected to optional I/O interface 410. In other examples, one or more of the input device 435 and/or the output device 440 may be included as a component of the processing system 400. Embodiments in which processing system 400 is a network controller may lack physical I/O interface 410, and may instead be a so-called headless (thread) server that performs all interactions through a connection to network interface 415.

In an exemplary embodiment, the processing system 400 configured to implement the RAN slice manager 150 may be configured to maintain information specifying resource allocations for each RAN slice 152 in the memory 425 or the storage 420, or a combination thereof.

Fig. 9 shows an architecture 900 in which a sliced RAN interacts with multiple core network slices. The RAN slice manager 902 establishes traffic routes and may be used to direct traffic from a CN slice to an appropriate TP based on at least the identity of the CN slice and, in some cases, according to a service ID associated with the service carried by the slice. CN 1904 has been sliced to create 4 slices: slice 1-1906, slice 1-2908, slice 1-3910, and slice 1-4912. Each slice of CN 1904 carries traffic, and slices 1-1906 are shown as carrying traffic associated with service 1914 and service 2916. CN2918 had 3 slices: CN 2-1920, CN 2-2922 and CN 2-3924. Each slice carries traffic and slices 2-2922 are shown carrying traffic for service 1926 and slice 2928. It should be understood that the service 1914 and the service 1926 are not necessarily the same service. If they each carry the same service ID, they can be distinguished on a slice basis or even on the CN from which they come. The RSM 902 is shown as a discrete element in the figure for ease of illustration. It will be apparent to those skilled in the art that the described functionality may be incorporated into other elements, such as a set of routers for which routing instructions are given by an SDN controller.

A radio access node, such as a base station, typically does not perform slicing of the radio interface. At best, virtual channels are created with a static partitioning of time or frequency based resources. As described above, slicing of the RAN may also be accomplished by using different waveforms, sets of base parameters, and transmission parameters. In a RAN, multiple APs may provide overlapping coverage areas. Some APs may be associated with all slices, other APs may be associated with a single slice, and still other APs may be associated with a subset of slices. Fig. 9 shows 3 APs within the RAN: AP 1930, AP 2932, and AP 3934. As will be appreciated, different types of APs may be used for different purposes. AP 1930 supports 4 different RAN slices: RAN slice 1936, RAN slice 2938, RAN slice 3940, and RAN slice 4942. AP 2932 supports two of the four RAN slices: RAN slice 1936 and RAN slice 4942. AP 3934 supports RAN slice 1936 and RAN slice 3940.

When traffic from the above two CNs is received within the RAN, the RAN slice manager 902 directs the traffic to the respective RAN slice based on the CN, CN slice and service. As shown, services 1914 within slices 1-1906 are directed to RAN slice 1936. Thus, traffic from the service may be sent to all three APs 1930, 2932, and 3934. Traffic from service 2916, which is also traffic from slices 1-1906, is sent through RAN slice 3940, so RAN slice manager 902 directs the traffic to AP 1930 and AP 3934. Those skilled in the art will appreciate that different services may carry the same service ID if they are within different CN slices, as described above. This may result in different service providers not knowing the service ID values used in other slices. Because the slice ID, and even the core network ID in some cases, may be associated with traffic, the RAN slice manager may ensure that services 1926 carried within slices 2-2922 may be routed to the RAN slice 3940. As a way of providing assistance in visual differentiation, traffic from CN 1904 is shown traversing the path indicated by the solid line, while traffic from CN2918 is shown traversing the path indicated by the dashed line.

Traffic from slices 1-2908 is carried by RAN slice 2938; traffic from slices 1-3910 is carried by RAN slice 2938; traffic from slices 1-4912 is carried by RAN slice 4194. Traffic from slices 2-1920 is carried by RAN slice 2938; traffic from both service 926 and service 928 within slices 2-2922 is carried by RAN slice 3940, and traffic from slices 2-3924 is carried in RAN slice 2938.

Fig. 10 is a flow diagram illustrating a method 1000 of routing downlink traffic at an RSM. Those skilled in the art will recognize that this function may be performed by a router having a RAN under the instruction of a controller, such as a software defined network controller. As shown, traffic for transmission to the UE is received in step 1002. The traffic is received from a core network and may be associated with one or both of CN slices and services. Any of the CNs and optional CN slices associated with the received traffic are identified in step 1004. In step 1006, a service ID associated with the service may optionally be identified. As will be appreciated, in the network of fig. 9, the service ID of traffic from slices 1-1906 must be identified so that it can be routed differentially, while the service ID for traffic from slices 2-2922 need not be so required, since traffic from both slices is routed to the same RAN slice. In step 1008, the RAN slice associated with the identified CN, CN slice, and service ID (as appropriate) is selected. Data for transmission to the UE is then routed to the appropriate TP (which may be an AP) according to the identified RAN slice in step 1010. A RAN slice ID may be associated with the traffic to assist the TP in selecting transmission parameters. In other embodiments, the TP may determine which RAN slice it supports through which traffic should be transported. As will be well understood by those skilled in the art, mobile networks are typically designed to allow mobility for connected UEs. Accordingly, routing data to the appropriate TP after selecting the RAN slice may include selecting the TP based on information provided by a mobility management function that tracks the location of the UE relative to the network topology. In another embodiment, a TP may be a logical entity consisting of a set of varying physical APs selected to track the location of a UE. In such embodiments, a TP may be uniquely associated with a UE, and forwarding data to the TP may be a function of selecting the TP associated with the UE and determining the set of APs currently associated with the TP. The data may then be transmitted (using any number of techniques including multicast transmission) to the constituent APs in the selected TP.

Fig. 11 is a flow diagram illustrating a method 1100 for processing downlink traffic at an AP (optionally a TP). Traffic for transmission to the UE is received at the AP in 1102. Optionally, the received traffic is associated with a RAN slice supported by the AP in 1104. This may be performed in advance in the RAN, in which case no redo is required. Association with a RAN slice may be accomplished according to any number of different identifiers, including a core network ID, a core network slice ID, a service ID, or a tunnel ID or gateway address as will be discussed in fig. 12. In step 1106, the AP may select RAN transmission parameters according to the RAN slice. This step need not be performed if the AP supports only a single slice, nor if parameters are provided to the AP. In step 1108, the data is transmitted to the UE using parameters associated with the RAN slice with which the data is associated. As will be understood with reference to the above discussion, these parameters may include specifications for f/t resources, waveform selection, base parameter set parameters, and other such transmission characteristics.

Fig. 12 illustrates an architecture 1200 associated with the network illustrated in fig. 9. For ease of illustration, only a single CN is shown, and only a single AP is shown. CN 1904 is shown connected to AP 1930. The RANs are sliced to provide RAN slices 1 through 4 as previously discussed in fig. 9. It should be understood that there is a gateway function 1202 within the CN slices 1-1906. The gateway 1202 is the connection point between the slices 1-1906 and the RAN. This means that all traffic from slices 1-1906 (including traffic associated with both service 1914 and service 2916) will be sent to the RAN through GW 1202. Similarly, traffic from slices 1-2908 is sent through GW1204, traffic from slices 1-3910 is sent through GW 1206, and traffic from slices 1-4912 is sent through GW 1208. In terminology associated with current LTE networks, traffic from the gateway is sent to the AP 1930 using a GPRS Tunneling Protocol (GTP) tunnel (in this case, a GTP-U tunnel because it is user plane traffic). The GTP-U tunnel has an identifier associated with it. GTP-U tunnels or their mimics in future generations of networks may be designed to route traffic to APs supporting RAN slices to which CN slices and services are directed. Such setting of the tunnel may be performed by a controller, such as SDN controller 1210, and implemented by sending instructions to a routing function within the RAN. Similarly, SDN controller 1210 may provide instructions to AP 1930 to allow it to select an appropriate RAN slice for received traffic based at least on the tunnel ID associated with the tunnel over which the traffic was received and the address of the gateway from which the traffic was received. In the case where the GW or tunnel is associated with a CN slice that supports services routed to a different slice, the AP may be instructed to associate with the traffic based on the CN slice and the service ID (as shown in step 1104 in fig. 11).

In the uplink, it will be understood that a UE (such as UE 110) may have multiple different virtual machines, each for services associated with a different RAN slice. This allows the UE to be associated with a different vAP per slice and also allows handovers to occur on a per slice basis. An AP, such as AP 1930, will receive traffic associated with the RAN slice. The traffic will also carry an indication of the CN or CN slice with which it is associated and may also include an indication of the CN services with which it is associated. The AP may use this information to select any of a tunnel to which traffic is transmitted, a gateway to which traffic is transmitted, and a CN or CN slice to which traffic is to be transmitted. From the destination information, the AP may transmit the received data to the associated CN slice. It should be understood that in the case where there is a one-to-one mapping between RAN slices and CN slices, the AP may direct traffic to the CN slices based on the RAN slices through which the traffic is received. In the case where the RAN slice supports traffic from multiple different CN slices, the determination may be made using other information such as CN slice ID or unique service ID.

Those skilled in the art will recognize that in embodiments of the present invention, there is a method 1300 as shown in FIG. 13. The method involves creating a plurality of RAN slices that can be applied for wireless communication in a RAN. Each RAN slice may be assigned a unique allocation of RAN resources. The unique assignments provide isolation from transmissions in other RAN slices. Such resource allocation may include a unique set of transmission parameters. The method may be performed at a controller, such as SDN controller 1202. In step 1302, an instruction is sent to an AP to create a plurality of slices in a wireless edge of a RAN. Information about the core networks and possible core network slices to be served by the RAN slice is received in 1304. The information may include an identification of the gateway from which the traffic is to be received and may also include an identification of the service carried in the core network. The information may also include information about the nature of the service in the core network. Optionally, this information is utilized in step 1306 to determine a transmission requirement (e.g., a wireless edge transmission requirement). In 1308, each core network or core network slice is associated with at least one slice of a radio edge of the RAN. It should be understood that if multiple different services are carried within a core network or core network slice, there may be more than one slice of the RAN radio edge associated with the core network or core network slice. In 1310, routing instructions based on the association of the core network or core network slice with the RAN slice are transmitted to a node within the radio access network. This information may be transmitted to the AP which is the interface between the wireless edge slice and the unsliced portion of the RAN. The routing information may also be communicated to routing functions within the RAN. These instructions may also be sent to the gateway function at the edge of the core network (or core network slice) and RAN. The routing instructions may contain information that may be used to establish a logical tunnel between the gateway and the AP. This may enable the network to operate such that traffic from the core network or core network slice is directed to APs associated with the wireless edge slices allocated to the core network traffic.

In an alternative embodiment, information associated with changing traffic demands or requirements of a core network (or slice) or wireless edge slice is received. This information received in optional step 1312 may indicate that there is an excess of capacity or an excess demand for capacity in the wireless edge slice. This information may be used to determine a new resource allocation for the wireless edge slice, which may be transmitted to the respective node. In some embodiments, the instruction may be transmitted to only the APs or a subset of the APs. In other embodiments, the modification may create a new wireless edge slice or remove an existing wireless edge slice, in which case a modification message (possibly a different message than the modification message sent to the AP) may be sent to other nodes in the RAN so that a logical connection may be created or removed.

In some embodiments of the above method, the RAN resources may include any or all of the following resources: a network access resource connecting the RAN to a physical core network; radio frequency and time resources of the RAN; and specifying how the network access resources are configured with the air interface of the radio frequency resource interface of the RAN. Optionally, at least some of the RAN slices may have a common allocation of network access resources and adjacent radio frequency resources, and an air interface configuration allocated to each of the at least some RAN slices is differentiated to isolate wireless communications of the at least some RAN slices from each other. The over-the-air configuration may specify a waveform for the RAN slice and a set of underlying parameters to be applied to the waveform. The plurality of RAN slices may include a first RAN slice and a second RAN slice whose air interface configuration specifies the same waveform but different sets of base parameters. In this way, the base parameter set may allow for a degree of isolation between slices, as a receiver associated with a first slice will not be able to correctly decode data transmitted in a second slice due to a different transmission base parameter set. In one such example, the common waveform may be an OFDMA waveform, and the base parameter set associated with each slice may have a different combination of one or more of: subcarrier spacing, cyclic prefix length, symbol length, duration of scheduled transmission duration, and number of symbols included in the scheduled transmission duration.

In another embodiment, RAN slices may be assigned different network access resources, and different combinations of time and radio frequency resources, to provide isolation.

Those skilled in the art will recognize that this approach allows for associating a RAN slice with a corresponding core network slice (or service within a core network slice) to enable communications associated with the service to use the RAN slice and its associated core slice.

In other embodiments, for at least one RAN slice, the network access resources comprise at least one logical transmission point for downlink communications and at least one logical reception point for uplink communications. The TP and RP may be based on different sets of physical access points. In some embodiments, there may be an overlap between the logical TP and the members of the physical access point within the RP. In other embodiments there may be no overlap. Assigning different logical identifiers to TPs and RPs associated with a slice creates a logical differentiation of UEs even in the case where the members of the physical AP are the same. It is also possible that the set of physical APs assigned to a TP or RP in one slice may be different from the set of physical APs assigned to a TP or RP in another slice. The membership of a TP or RP in any slice may change without notifying the UE, as long as the logical TP or RP identifier is maintained. The UE may communicate with the same set of physical APs in two different slices without being aware of the overlap.

After the slices are established and the logical TPs and RPs within each slice are defined, traffic destined for a UE attached to more than one slice may be received and routed to an AP associated with the CN, CN slice, or service with which the traffic is associated. The traffic may then be transmitted to the UE using the transmission parameters associated with the RAN slice. Traffic associated with different slices may be transmitted to the UE through different logical TPs (which may or may not have the same physical AP).

When a UE has traffic to transmit, it may transmit the traffic to the RPs associated with the slices associated with the respective services. The received traffic may be routed to the appropriate core network or core network slice based on any or all of the identifier of the UE, the RP through which the traffic is received, the service identifier associated with the transmission, and the destination address.

According to an aspect of the present invention, there is provided a method performed by an Access Point (AP) in a Radio Access Network (RAN), the method comprising: receiving data transmitted to a User Equipment (UE); and wirelessly transmitting the received data to the UE using the set of transmission parameters associated with the RAN slice with which the received data is associated.

In some embodiments, the method includes selecting a RAN slice associated with the received data from a set of RAN slices supported by the AP.

In some embodiments, the RAN slice is selected according to a RAN slice identifier associated with the received data.

In some embodiments, the method includes selecting transmission parameters according to the selected RAN slice.

In some embodiments, the set of transmission parameters is selected according to an address of a gateway between the RAN and the core network.

In some embodiments, the set of transmission parameters is selected according to one of a service identifier, a core network identifier, and a core network slice identifier associated with the received data.

In some embodiments, at least one parameter in the transmission parameter set is selected from the list comprising: radio frequency/time resources; a radio access technology; transmitting the waveform; a frame length; and a base parameter set.

According to another aspect of the present invention, there is provided a network Access Point (AP) for transmitting data to a User Equipment (UE) through a radio channel in a Radio Access Network (RAN), the network access point comprising: a network interface for receiving data from a radio access network; a wireless network interface for transmitting data to the UE; a processor; and a non-transitory memory to store instructions that, when executed by the processor, cause the network access point to: in response to receiving data for transmission to the UE over the network interface, the data is transmitted to the UE over the wireless network interface using the set of transmission parameters associated with the RAN slice.

In some embodiments, the non-transitory memory further stores instructions for selecting transmission parameters according to an address of a gateway from which the data is received.

In some embodiments, the non-transitory memory further stores instructions for selecting at least one transmission parameter of the set of transmission parameters as a function of a RAN slice identifier associated with the data.

In some embodiments, the non-transitory memory further stores instructions for selecting at least one transmission parameter of the set of transmission parameters as a function of one of a service identifier, a core network identifier, and a core network slice identifier associated with the data.

According to another aspect of the present invention, there is provided a method for execution by a routing function in a Radio Access Network (RAN): receiving data traffic from a core network destined for a User Equipment (UE); transmitting the received data traffic to a transmission point in the selected RAN slice associated with the received data traffic.

In some embodiments, the method further comprises selecting a RAN slice associated with the received data traffic according to one of: an identifier associated with the core network; an identifier associated with a slice of a core network to which the received data is associated; and a service identifier associated with the received data.

In some embodiments, the identifier associated with one of the core network and the core network slice is one of an address of a core network gateway function and a tunnel identifier.

In some embodiments, receiving data traffic comprises receiving data traffic from a gateway function in a core network.

In some embodiments, receiving data traffic includes receiving data traffic from a slice of a core network.

In some embodiments, the RAN slice and the core network slice are pre-associated.

In some embodiments, the method further comprises the steps of: the transmission points in the RAN slice are selected according to information about the location of the UE relative to the network topology.

In some embodiments, the method further comprises: selecting a transmission point uniquely associated with the UE; and determining a set of constituent access points associated with the transmission point; wherein transmitting the received data comprises transmitting the received data to the set of constituent access points.

In some embodiments, the transmitting step comprises: the received data is modified to include a RAN slice identifier associated with the selected RAN slice prior to transmission of the data to the transmission point.

According to yet another aspect of the present invention, there is provided a router for use in a Radio Access Network (RAN), comprising: a network interface for receiving and transmitting data; a processor; and a non-transitory memory to store instructions that, when executed by the processor, cause the router to:

in response to receiving data traffic destined for a User Equipment (UE) over a network interface, the data traffic is transmitted over the network interface to a transmission point associated with a selected RAN slice in the RAN.

In some embodiments, the non-transitory memory further contains further instructions that, when executed by the processor, cause the router to select the RAN slice according to one of: an identifier associated with the core network; an identifier associated with a core network slice with which the received data is associated; and a service identifier associated with the received data.

In some embodiments, the non-transitory memory further contains further instructions that, when executed by the processor, cause the router to select the transmission point according to the information about the location of the UE relative to the network topology.

In some embodiments, the non-transitory memory further contains further instructions that, when executed by the processor, cause the router to: selecting a transmission point uniquely associated with the UE; determining a set of constituent access points associated with the selected transmission point; and transmitting the data to the transmission point by transmitting the data to the set of constituent access points.

In some embodiments, the non-transitory memory further contains further instructions that, when executed by the processor, cause the router to: modifying the received data to include a RAN slice identifier associated with the selected RAN slice prior to transmitting the data to the transmission point.

The operation of the present exemplary embodiment and its structure are discussed in detail below. It should be appreciated, however, that the present disclosure provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific structures and ways to operate the disclosure, and do not limit the scope of the disclosure.

Fig. 14 illustrates an exemplary communication system 2100. The communication system 2100 includes an eNB 2105 serving a plurality of UEs including UE 2110, UE2112, UE 2114, UE 2116, and UE 2118. As discussed previously, as UEs become more advanced, they are able to run a wider range of applications. These applications may be classified as session-based applications or non-session-based applications. Session-based applications (which may include video streaming, web browsing, file transfer, gaming, etc. applications) are typically applications that utilize a series of data exchanges and do not tolerate large delays, generate large amounts of message traffic, have large data bandwidth requirements, etc. Non-session based applications (which may include keep-alive messages generated by mobile operating systems or instant messaging, reports generated by sensors and/or smart meters, etc.) are typically applications that utilize short data exchanges, and some can tolerate larger delays, generate a small amount of message traffic, have small data bandwidth requirements, etc. However, some non-session based applications may not tolerate large delays, such as security sensors, health sensors, and the like.

As an illustrative example, UE 2110 runs a multimedia streaming application, a web browser, and an instant messaging application, while UE2112 runs a multi-user video game. Similarly, UE 2114 runs a web browser while performing large file transfers, UE 2116 runs an inactive instant messaging application and sends keep-alive messages to maintain connectivity, while UE 2118 is a sensor that reports occasionally.

For simplicity, only one eNB and multiple UEs are shown, although it is understood that the communication system may employ multiple enbs capable of communicating with multiple UEs.

In order to control the use of radio resources and power consumption by the UE device, a connection state (e.g., LTE/UMTS RRC state, EVDO connected state) is defined in many wireless communication standards.

These states define the characteristics of the UE device in terms of resource usage (e.g., dedicated, shared resources), control channel usage, and control channel monitoring patterns, affecting one or more of the following indicators: terminal power consumption; network resources (e.g., physical resources, terminal ID assignments, etc.); a data transmission delay; and control plane signaling overhead.

Many existing wireless communication standards include only two valid operating states. For example, the LTE/UMTS RRC states include a connected state and an idle state.

As an illustrative example, if a state machine includes two states: connected and idle, where the idle state does not allow the UE to transmit, the UE executing the non-session based application transitions to the connected state before sending or receiving the transmission (this is not always the case due to the nature of the non-session based application). State transitions typically require multiple messages to be exchanged between the UE and its eNB, which can result in significant communication overhead and communication delays, particularly when considering that the UE may send or receive messages that are only a few bytes long (or less).

A third operating state, the ECO state, is proposed in the following patent applications: U.S. patent application No. 14/150,539, which is now disclosed as U.S. patent application publication No. us2015/0195788a 1. Only unlicensed transfers are supported in ECO state to reduce signaling overhead and energy consumption for small packet (e.g., background traffic) transfers. In contrast to the conventional idle state defined in LTE/UMTS, the ECO state (such as that proposed in U.S. patent application No. 14/150,539 entitled "System and Method for always on Connections in Wireless Communications System," filed on 8.1.2014, the entire contents of which are incorporated herein by reference) allows a UE device executing a non-session based application to communicate using background messages without having to change the state from a first state that would result in significant energy consumption savings to a second state (e.g., a connected state) that would result in greater energy consumption but generally no limitations on how the UE device communicates). To facilitate data transfer in ECO state, the context of the UE and the RAN needs to be maintained. For example, the UE maintains a connection ID (e.g., MAC ID, RNTI (radio network temporary identifier)) and/or RRC connection.

Fig. 15 illustrates an example of operational characteristics that may be associated with an active/connected state, an ECO state, and an idle state according to example embodiments described herein. It should be clear that these are merely examples of operational characteristics that may be associated with these operational states, and in other embodiments one or more of these operational states may have different operational characteristics. Generally, as discussed above, the operating states differ from each other in terms of network connectivity, which may affect terminal power consumption, network resources, data transmission delays, and/or control plane signaling overhead.

However, as shown in fig. 16, supporting state transitions between three potential operating states (e.g., between an active/connected state, an ECO state, and an idle state) may result in additional signaling overhead relative to supporting state transitions between only two potential operating states. Fig. 16 shows three examples of signaling overhead to support transitions between only two states and to support transitions between three states, where the active/connected state, ECO state, and idle state are referred to using letters A, E and I, respectively. Again, it should be noted that the example of signaling shown in fig. 16 is provided as an illustrative example only, and different signaling may be used in other implementations.

While it may be advantageous for some UE devices (e.g., smartphones capable of supporting a wide range of services) to support a greater number of operating states, some UE devices (e.g., embedded sensor devices configured for Machine Type Communication (MTC)) may not need to support state transitions among all potential operating states.

Thus, for UE devices that may only need to support state transitions in a subset of all potential operating states, it may be desirable to configure these devices to avoid incurring the additional signaling overhead that may be associated with supporting transitions between all potential operating states.

One embodiment of the present disclosure relates to supporting multiple UE status configurations in a wireless network such that the operational status of the supported UEs is configurable. For example, in one embodiment, the network selects a state configuration for each UE from a pool of candidate state configurations, wherein each candidate state configuration is associated with a respective set of one or more predefined operating states. For example, one candidate state configuration may include all potential operating states, while a second candidate state configuration may include only some subset of all potential operating states.

Fig. 17A shows six examples of state configurations according to example embodiments described herein. The examples shown include:

a first state configuration (configuration 1) comprising an active state and an ECO state;

a second state configuration (configuration 2) comprising an ECO state and an idle state;

a third state configuration (configuration 3) comprising an active state and an enhanced idle state, wherein the enhanced idle state comprises therein an idle substate and an ECO substate, and within the enhanced idle state there is a transition path between the two substates;

a fourth state configuration (configuration 4) comprising an active state and an idle state;

a fifth state configuration (configuration 5) comprising an idle state and an enhanced active state, wherein the enhanced active state comprises among the active substates an ECO substate and within the enhanced active state there is a transition path between the two substates; and

a sixth state configuration (configuration 6) comprising an active state, an ECO state and an idle state;

in the enhanced idle state shown in fig. 17B, the UE may transition between the idle substate and the ECO substate. It should also be noted that the ECO substate and the idle substate may not need to be explicitly defined in the enhanced idle state. As explained below, they may be implicitly specified by virtue of whether the relevant process is supported and/or enabled. The ECO substates are the same as the ECO states described earlier. However, to further conserve battery power, the UE may enter a deep sleep, i.e., idle, sub-state. In another embodiment, the UE may not enter the idle substate. In the ECO (sub) state, the UE is configured with a tracking channel such as that proposed in the following patent applications: U.S. provisional patent application No. 62/141,483 entitled "System and Method for a Tracking Channel" filed on 1/4/2015 and U.S. patent application No. 15/009,626 entitled "System and Method for a Tracking Channel" filed on 28/1/2016, the entire contents of which are incorporated herein by reference and the copies of which are appended to appendices B and C, respectively. The tracking channel allows the network to periodically track the UE location and also maintain the uplink timing alignment of the UE. The UE may periodically monitor for simplified paging and downlink Data notification messages such as the Data notification message set forth in U.S. patent application No. 14/609,707 entitled "apparatus and Method for a Wireless Device to Receive Data in an ECO State" filed on 30.1.2015, which is incorporated herein by reference in its entirety and a copy of which is appended to appendix D. Such a message is unicast to the UE. Maintaining light connection management on the uplink and downlink facilitates small packet data exchanges with reduced delay when the UE is in an ECO (sub) state. On the other hand, the UE may further reduce power consumption by disabling the tracking channel procedure. In this case, the network does not actively track the UE. If the UE needs to send a small packet on the uplink, the tracking channel procedure needs to be re-enabled or the random access procedure needs to be performed. On the downlink, the UE only periodically monitors for paging messages from the network, which are multicast messages destined for all UEs belonging to the paging group. A paging procedure similar to that of LTE may be used. Therefore, in the idle sub-state, the UE may cause more delay in transmitting and receiving data. Furthermore, the transition between the ECO substate and the idle substate has no explicit state transition signaling. Only the signaling associated with disabling and enabling the tracking process is required.

As shown in fig. 17D, the enhanced idle state may be configured by the network based on service and/or UE type. That is, not all UEs need to support the procedures associated with the ECO sub-state. Some UEs (e.g., legacy UEs, UEs without delay sensitive traffic, UEs requiring more power saving) may support only the idle sub-state in the enhanced idle state. Some other UEs (e.g., UEs with delay sensitive traffic, UEs with unlimited battery power) may support both the ECO substate and the idle substate in the enhanced idle state. For UEs that support procedures associated with the ECO substate, the context of the UE and the RAN is maintained to allow fast transition (contention-free) to the connected/active state. The state transition between the connected/active state and the enhanced idle state is similar to the state transition between the connected/active state and the ECO state shown in fig. 16. For UEs that do not support procedures associated with the ECO substate or for which such procedures are disabled, the UE context with the RAN is released in the enhanced idle state. The state transition between the connected/active state and the enhanced idle state is similar to the state transition between the connected/active state and the idle state shown in fig. 16.

In the enhanced connected/active state as shown in fig. 17C, the UE may transition between the active substate and the ECO substate. When the tracking procedure is enabled and the uplink sounding procedure is disabled, the UE is in the ECO substate. Further, the UE stops monitoring the dynamic signaling resource allocation for uplink grants and downlink scheduling allocations.

The six exemplary state configurations shown in fig. 17A are merely illustrative examples. Other permutations and combinations of active, ECO, and idle states and enhanced versions thereof may be used in other candidate state configurations in some embodiments of the present disclosure. For example, another state configuration may include an active state, an ECO state, and an idle state, which is similar to but different from the sixth state configuration shown in fig. 19 in that the configuration omits one or more transition paths between operating states. Thus, it should be noted that a state configuration may not only define a set of one or more operational states, but may also define an effective transition path between its constituent operational states. However, an effective transition path may not be defined if each operational state in a state configuration may transition to every other operational state in the state configuration.

Defining such a pool of candidate state configurations and allocating to the UE a candidate state configuration comprising only the operating state required by the UE, would otherwise cause additional signalling overhead for supporting the operating state not used by the UE. Thus, the selection of a state configuration for a given UE may be based on different UE-specific factors, which may include the UE type associated with the UE and/or one or more services supported by the UE. Thus, different UE devices may have different status configurations.

As noted above, one of the factors upon which the selection of the status configuration for a given UE device may be based is the category or type of UE. For example, the UE devices may be categorized or typed according to some criteria. These categories or types may include, for example, a first category or type of UE device configured for Machine Type Communication (MTC). This first category or type may be associated/mapped to a state configuration (e.g., configuration 2 and/or configuration 1) that includes only two operating states. The second category or type may be used, for example, for more capable devices, such as smart phones. The second category or type may be associated/mapped to a state configuration (e.g., configuration 6) that includes three operating states. A third category or type may be defined as having backward compatibility with the operational states defined in earlier wireless communication system standards (e.g. configuration 4, where active and idle states are defined, for example, according to the RRC state in LTE/UMTS). For example, information regarding the UE type may be exchanged with the network as part of an initial network access procedure.

Another factor on which the selection of a state configuration for a given UE device may be based is the services supported by the UE device. For example, an enhanced mobile broadband (eMBB) service may be mapped to a state configuration (e.g., configuration 6) that includes an active state, an ECO state, and an idle state with a transition path between each of these states. Accordingly, a state configuration to which the eMBB service is mapped may be selected for a UE device supporting the eMBB service.

In some cases, a UE device may support multiple different services that may be mapped to different state configurations including different permutations and combinations of operating states. Thus, in some cases, a UE device supporting multiple services may be assigned multiple state configurations from a pool of candidate state configurations.

In some cases, the network may be flexibly constructed such that speed, capacity, and coverage may be allocated in logical network "slices" to meet the specific needs of different services/traffic types. For example, a network slice may be configured to support communication services of a particular connection type with a particular way of handling the control plane and the user plane of the communication service. To this end, a network slice may include a set of network functions and specific Radio Access Technology (RAT) settings that are combined together for a particular use case or traffic pattern. Thus, a network slice may span all domains of the network: a software module running on the cloud node, a specific configuration of the transport network supporting flexible positioning of the functionality, a dedicated radio configuration or even a specific RAT and configuration of the UE device. Not all network slices contain the same functionality. For example, a network slice may be configured to provide only the traffic processing required for a particular use case and avoid all other unnecessary functionality.

In some embodiments, services supported by a UE device may be supported through different network slices. From a network perspective, a UE device supporting a particular service belonging to a network slice may be associated with a particular status configuration. In other words, there may be a mapping between network slices and state configurations.

Fig. 18A illustrates an example of a mapping between network slices and state configurations according to an example embodiment described herein. The illustrated example includes three network slices. The first network slice supports eMBB services and maps to a state configuration (e.g., configuration 6) that includes an active state, an ECO state, and an idle state with transition paths between each state. The second network slice supports ultra-reliable low-latency communications (URLLC), such as vehicle-to-outside-vehicle (V2X) communications, and maps to a state configuration (e.g., configuration 1) including an active state and an ECO state for an always-on connection with low-latency unlicensed transmission of Uplink (UL) small packets and Downlink (DL) scheduled transmission of large packets. The third network slice supports large-scale machine type communication (mtc), such as embedded sensor communication, and maps to a state configuration (e.g., configuration 2) including an ECO state and an idle state to save energy and support large-scale connection of small packets for unlicensed transmission.

In some embodiments, a UE device supporting multiple network slices (e.g., a UE device supporting, for example, a first service in a first network slice and a second service in a second network slice) may be configured with multiple status configurations, and may support services within a given network slice according to its respective status configuration. Fig. 18B illustrates an example of a UE device configured with multiple status configurations according to example embodiments described herein. In the illustrated example, the UE device is configured to support services in two network slices corresponding to the first and second network slices illustrated in fig. 18A, and is configured with two corresponding state configurations (e.g., configuration 6 and configuration 1).

However, in some embodiments, a UE device supporting multiple network slices may be configured with a single state configuration that includes all predefined operating states associated with the respective state configurations associated with the multiple network slices supported by the UE device. For example, referring to fig. 17 and 18A, a UE device supporting eMBB services in a first network slice and critical MTC services in a second network slice may be configured with configuration 6, as configuration 6 accommodates all operating states (and transition paths) of the state configurations associated with the first and second network slices. In other words, the state configuration associated with the first network slice may also be used for the second network slice because the state configuration associated with the first network slice, i.e., { active, ECO, idle } includes all of the operating states associated with the state configuration associated with the second network slice, i.e., { active, ECO }.

In some cases, network slices may be mapped to frequency subbands. In this case, different state configurations can thus be configured on different sub-bands. As a result, control channels (e.g., periodicity of monitoring and transmission, feedback reporting and tracking channels on the uplink, monitoring paging and downlink control channels on the downlink) may be configured accordingly. That is, the UE may be in an ECO state in one sub-band and in an active state in another sub-band.

Information regarding services supported by the UE device may be exchanged with the network as part of an initial network access procedure and/or as part of a UE-supported service change procedure in which the UE device provides information to the network regarding changes to one or more services supported by the UE device. Thus, it should be noted that a change in the services supported by the UE device may result in a different state configuration being selected for the UE device. Thus, it will be appreciated that the selection of one or more state configurations for the UE device may be done statically and/or may change (semi-statically) over time based on the type of service/traffic supported.

Fig. 19A and 19B illustrate exemplary message exchange diagrams between a UE device and a network device according to exemplary embodiments described herein.

Fig. 19A illustrates a message exchange diagram between a UE device and a network device for static state configuration. As part of a UE Air Interface (AI) capability exchange procedure, information regarding a UE type associated with a UE device and/or information regarding service(s) supported by the device is exchanged with a network. The UE AI capability exchange procedure may occur when the UE initially attempts to access the network. According to example embodiments described herein, a network device selects a status configuration for a UE device and sends information to the UE device for the selected status configuration. For example, the network device may select the status configuration based at least in part on information received as part of the UE AI capability exchange procedure (e.g., information about a UE type associated with the UE device and/or information about one or more services supported by the UE device). The information regarding the selected state configuration may be broadcast in a broadcast message, multicast in a multicast message, or unicast to a particular UE device in a unicast message.

Fig. 19B illustrates a message exchange diagram between a UE device and a network device for semi-static state configuration. Information regarding a change in one or more services supported by the UE device is exchanged with the network as part of a service change procedure supported by the UE. In response to receiving the information regarding the one or more service changes supported by the UE device, the network device selects an alternative state configuration from a plurality of candidate state configurations based at least in part on the information regarding the one or more service changes supported by the UE device. The network device then transmits information regarding the selected alternative status configuration to the UE device. In some cases, a change in one or more services supported by a UE device may not necessarily change to a state configuration selected by the UE device. Thus, in some cases, the selected alternative state configuration may be the same as the previously selected state configuration of the UE device. The information regarding the selected state configuration may be broadcast in a broadcast message, multicast in a multicast message, or unicast to a particular UE device in a unicast message.

In another embodiment, the UE state configuration may be indicated implicitly without explicit signaling if there is a predefined mapping of UE state configuration to services and/or UE types. For example, after exchanging information about a UE type associated with the UE device and/or information about service(s) supported by the apparatus with the network as part of a UE Air Interface (AI) capability exchange procedure, the UE may then determine the UE state configuration(s) based on the predefined mapping. In another example, after exchanging information about one or more service changes supported by the UE device with the network as part of a UE-supported service change procedure, the UE may then determine the UE state configuration(s) based on the predefined mapping.

Fig. 20 shows a flowchart of exemplary operations 2700 in a network device, according to exemplary embodiments described herein. Operation 2700 may indicate operations occurring in a network device, such as an eNB, pico cell, etc.

Operation 2700 may begin with the UE device performing initial entry into the network (block 2705). The UE device may be a smartphone, a sensor, a personal computer, a tablet, etc. As previously discussed, the network device may select a status configuration for the UE device from a plurality of candidate status configurations (block 2710). Each candidate state configuration may be associated with a respective set of one or more of a plurality of predefined operating states. The network device may send information regarding the selected status configuration to the UE device (block 2715).

Exemplary operation 2700 is an illustration of an exemplary embodiment. In other embodiments, similar or different operations may be performed in a similar or different order and/or certain operations may be omitted. Various ways of performing the operations shown, as well as examples of other operations that may be performed, are described herein. Other variations may be or become apparent.

For example, in some embodiments, selecting the status configuration at block 2710 includes selecting the status configuration based at least in part on a UE type associated with the UE device and/or one or more services supported by the UE device. For example, as part of the initial entry at block 2705 or sometime thereafter, the UE device may provide information to the network regarding the UE type associated with the UE device and/or information regarding one or more services supported by the UE device, which the network device may utilize to select a state configuration at block 2710.

In some embodiments, information regarding one or more service changes supported by a UE device may be received as part of a service change procedure supported by the UE. As previously discussed with reference to fig. 19B, in response to receiving such information, the network device may select an alternative status configuration and transmit information regarding the selected alternative status configuration to the UE device.

In some embodiments, selecting the state configuration at block 2715 includes selecting a first state configuration based at least in part on a first service supported by the UE device and selecting a second state configuration based at least in part on a second service supported by the UE device. Similarly, transmitting information regarding the selected state configuration to the UE device at block 2715 may include transmitting information regarding the selected first state configuration and the second state configuration. In such a case, operation 2700 may further include configuring the first service in the first network slice according to the first state and configuring the second service in the second network slice according to the second state.

In some embodiments, each of the plurality of network slices may be associated with a respective status configuration, and selecting a status configuration at block 2710 may involve selecting a status configuration for the plurality of network slices supported by the UE device, wherein the selected status configuration includes all predefined operating states associated with the respective status configurations associated with the plurality of network slices supported by the UE device. In such embodiments, operation 2700 may further include configuring provision of service to the UE device in a plurality of network slices supported by the UE device according to the selected state.

Fig. 21 shows a flowchart of exemplary operations 2800 in a UE device according to exemplary embodiments described herein. Operation 2800 may indicate operation in a UE device, such as a smartphone, sensor, personal computer, tablet, etc.

Operation 2800 may begin with the UE device performing initial entry into a wireless network (block 2805). For example, the UE device may perform initial entry into a network device such as an eNB, pico cell. As previously discussed, the UE device may receive information from the wireless network regarding a status configuration selected for the UE device from a plurality of candidate status configurations (block 2810). Each candidate state configuration may be associated with a respective set of one or more of a plurality of predefined operating states. The UE device may communicate via the wireless network according to the selected status configuration (block 2815). For example, the UE device may use information about the selected state configuration to configure a state machine in the UE device.

Exemplary operation 2800 is illustrative of an exemplary implementation. In other embodiments, similar or different operations may be performed in a similar or different order, and/or certain operations may be omitted. Various ways of performing the operations shown, as well as examples of other operations that may be performed, are described herein. Other variations may be or become apparent.

For example, in some embodiments, the initial entry procedure at block 2805 involves a UE air interface capability exchange procedure that involves sending information to the wireless network regarding a UE type associated with the UE apparatus and/or one or more services supported by the UE apparatus.

In some embodiments, operation 2800 may further comprise: as part of a UE-supported service change procedure, information regarding one or more service changes supported by the UE device is transmitted, and then followed by receiving alternative state configuration-related information selected for the UE device based at least in part on the information regarding the one or more service changes supported by the UE device. The UE device may then communicate via the wireless network according to the selected alternative status configuration.

In some embodiments, a UE device may support multiple services, including at least a first service and a second service. In such embodiments, receiving information regarding the selected status configuration for the UE device at block 2810 may include: the method may include receiving a first status configuration selected based at least in part on a first service supported by the UE device, and receiving a second status configuration selected from a plurality of candidate status configurations based at least in part on a second service supported by the UE device. Then communicating via the wireless network according to the selected status configuration at block 2815 may include: communication is conducted via the wireless network with respect to the first service in accordance with the selected first status configuration, and communication is conducted via the wireless network with respect to the second service in accordance with the selected second status configuration.

In some embodiments, the first service and the second service may be supported by the first network slice and the second network slice, respectively. As such, in some embodiments, communicating via the wireless network for the first and second services according to the selected first and second status configurations may include communicating via first and second network slices of the wireless network according to the selected first and second status configurations.

In some embodiments, the first network slice and the second network slice may be allocated to first time-frequency resources and second time-frequency resources (e.g., subbands). Thus, in some embodiments, communicating via the wireless network according to the selected first and second state configurations may include communicating via the first and second time-frequency resources.

Fig. 22 illustrates a block diagram of an example communication device 2900, according to an example embodiment described herein. The communications apparatus 2900 may be an implementation of a network apparatus such as an eNB, pico cell, etc. The communication device 2900 may be used to implement various embodiments discussed herein.

As shown in fig. 23, the communication device 2000 includes a wireless interface 2905. The wireless interface 2905 includes a transmitter 2930 configured to send messages and the like, and a receiver 2935 configured to receive messages and the like.

The UE device information processing unit 2920 is configured to receive, via the wireless interface 2905, information about a UE type associated with the UE and/or information about one or more services supported by the UE device. For example, the UE device information processing unit 2920 may be configured to perform actions of the network device according to the UE air interface capability exchange procedure shown in fig. 19A.

The state configuration selection unit 2925 is configured to select a state configuration for the UE device from a plurality of candidate state configurations as described herein. Each candidate state configuration may be associated with a respective set of one or more of a plurality of predefined operating states. The state configuration selection unit 2925 is further configured to transmit information about the selected state configuration to the UE device via the radio interface 2905.

In some embodiments, the state configuration selection unit 2925 is configured to select a state configuration based at least in part on the information received by the UE device information processing unit 2920 regarding the type of UE associated with the UE device and/or the one or more services supported by the UE device.

In some embodiments, the UE device information processing unit 2920 may be further configured to receive information from the UE device via the wireless interface 2905 regarding one or more service changes supported by the UE device. The information may be received as part of a service change procedure supported by the UE. For example, the state configuration selection unit 2925 may be further configured to select an alternative state configuration for the UE device in response to the UE device information processing unit 2920 having received such information. The state configuration selection unit 2925 may be further configured to transmit information regarding the selected alternative state configuration to the UE device via the wireless interface 2905, as discussed previously with reference to fig. 19B.

In some embodiments, the state configuration selection unit 2925 is configured to select a first state configuration based at least in part on a first service supported by the UE device and to select a second state configuration based at least in part on a second service supported by the UE device. Similarly, the state configuration selection unit 2925 may be further configured to transmit information about the selected first and second state configurations to the UE device via the wireless interface 2905. In such embodiments, network apparatus 2900 may be configured to provide a first service in a first network slice according to a first state configuration and a second service in a second network slice according to a second state configuration.

In some embodiments, each of the plurality of network slices may be associated with a respective state configuration, and state configuration selection unit 2925 may be configured to select state configurations for the plurality of network slices supported by the UE device, wherein the selected state configurations include all predefined operating states associated with the respective state configurations associated with the plurality of network slices supported by the UE device. In such embodiments, network apparatus 2900 may be configured to provide services to the UE apparatus in a plurality of network slices supported by the UE apparatus according to the selected state configuration.

The memory 2915 is configured to store information about: predefined operating states, candidate state configurations, selected state configurations, UE types, services supported, detected signals, decoded signals, and the like.

Elements of communications apparatus 2900 may be implemented as specific hardware logic blocks. In the alternative, the elements of the communications apparatus 2900 may be implemented as software executing in a processor, controller, application specific integrated circuit, or the like. In yet another alternative, elements of the communications apparatus 2900 may be implemented as a combination of software and/or hardware.

As an example, the transmitter 2930 and the receiver 2935 may be implemented as specific hardware blocks, while the UE device information processing unit 2920 and the state configuration selection unit 2925 may be software modules executed in a processor 2910 (such as a microprocessor), a digital signal processor, custom circuitry, or a custom compiled logic array of a field programmable logic array. The UE apparatus information processing unit 2920 and the state configuration selection unit 2925 may be modules stored in the memory 2915.

Fig. 23 illustrates a block diagram of an example communication device 2000, according to an example embodiment described herein. The communication device 3000 may be an implementation of a UE device such as a smartphone, sensor, PC, tablet, etc. The communication device 3000 may be used to implement the various embodiments discussed herein.

As shown in fig. 23, the communication device 3000 includes a wireless interface 3005. The wireless interface 3005 comprises a transmitter 3030 configured to transmit messages and the like and a receiver 3035 configured to receive messages and the like.

The UE device information notification unit 3020 is configured to transmit information about a UE type associated with the UE device and/or information about one or more services supported by the UE device via the radio interface 3005. For example, the UE apparatus information notification unit 3020 may be configured to perform the actions of the UE apparatus according to the UE air interface capability exchange procedure shown in fig. 19A.

The state configuration control unit 3025 is configured to receive information regarding a state configuration selected for the UE device from a plurality of candidate state configurations as described herein via the radio interface 3005. Each candidate state configuration may be associated with a respective set of one or more of a plurality of predefined operating states. The status configuration control unit 3025 is further configured to control the UE device 3000 to facilitate communication via the radio interface 3005 according to the selected status configuration. For example, the state configuration control unit 3025 may configure the state machine using information about the selected state configuration.

In some embodiments, the UE device information notification unit 3020 is further configured to transmit information regarding one or more service changes supported by the UE device via the radio interface 3005. For example, the UE apparatus information notification unit 3020 may be configured to perform the action of the UE apparatus according to the service change procedure supported by the UE shown in fig. 19B. In such embodiments, the state configuration control unit 3025 may also be configured to receive, via the wireless interface 3005, information regarding an alternative state configuration selected for the UE device based at least in part on the information regarding the one or more service changes supported by the UE device. The state configuration control unit 3025 may then control the UE device 3000 to facilitate communication via the radio interface 3005 in accordance with the selected alternative state configuration.

In some embodiments, UE device 3000 may support multiple services, including at least a first service and a second service. In such embodiments, the state configuration control unit 3025 may be configured to: receive first and second status configurations for the first and second services, and control the UE device 3000 to facilitate communications for the first and second services via the wireless interface 3005 according to the selected first and second status configurations.

In some embodiments, the first service and the second service may be supported by the first network slice and the second network slice, respectively. Thus, in some embodiments, the state configuration control unit 3025 may be configured to control the UE apparatus 3000 to facilitate communication over the first and second network slices via the network interface 3005 in accordance with the selected first and second state configurations.

The storage 3015 is configured to store information about: predefined operating states, candidate state configurations, selected state configurations, UE type of device, services supported, detected signals, decoded signals, and the like.

The elements of the communications apparatus 3000 may be implemented as specific hardware logic blocks. In the alternative, the elements of the communications apparatus 3000 may be implemented as software executed in a processor, controller, application specific integrated circuit, or the like. While in yet another alternative, the elements of the communications apparatus 3000 may be implemented as a combination of software and/or hardware.

As an example, the transmitter 3030 and the receiver 3035 may be implemented as specific hardware blocks, while the UE device information notification unit 3020 and the state configuration control unit 3025 may be software modules executed in a processor 3010 (such as a microprocessor), a digital signal processor, a custom circuit, or a custom compiled logic array of a field programmable logic array. The UE apparatus information notification unit 3020 and the state configuration control unit 3025 may be modules stored in the memory 3015.

Furthermore, although described primarily in the context of methods, apparatus and devices, other implementations are also contemplated, such as in the form of instructions stored on a non-transitory computer-readable medium, for example.

According to yet another aspect of the present invention, a method in a network apparatus for supporting multiple User Equipment (UE) status configurations in a wireless network is provided. The method comprises the following steps: selecting a state configuration for the UE device from a plurality of candidate state configurations, each candidate state configuration being associated with a respective set of one or more predefined operating states from a plurality of predefined operating states; and transmitting information about the selected state configuration to the UE device.

In some embodiments, selecting the status configuration comprises selecting the status configuration based at least in part on at least one of a UE type associated with the UE device and one or more services supported by the UE device.

In some embodiments, the method further comprises: information regarding at least one of a type of UE associated with the UE device and one or more services supported by the UE device is received as part of a UE air interface capability exchange procedure.

In some embodiments, the method further comprises: receiving information regarding one or more service changes supported by the UE device as part of a service change procedure supported by the UE; in response to receiving information regarding one or more service changes supported by the UE device, selecting an alternative state configuration from a plurality of candidate state configurations based at least in part on the information regarding the one or more service changes supported by the UE device; and transmitting information regarding the selected alternative status configuration to the UE device.

In some embodiments, selecting a state configuration from a plurality of candidate state configurations comprises: selecting a first state configuration based at least in part on a first service supported by the UE device; and selecting a second state configuration based at least in part on a second service supported by the UE device; and transmitting information about the selected state configuration to the UE device comprises: transmitting information about the selected first and second state configurations to the UE device.

In some embodiments, the method further comprises: providing a first service in a first network slice according to a first state configuration; providing a second service in a second network slice according to a second state configuration.

In some embodiments, each of the plurality of network slices is associated with a respective one of a plurality of candidate state configurations; selecting a state configuration from the plurality of candidate state configurations comprises selecting a state configuration for a plurality of network slices supported by the UE device, the selected state configuration comprising all predefined operating states associated with respective state configurations associated with the plurality of network slices supported by the UE device; and the method further comprises providing services to the UE device in a plurality of network slices supported by the UE device according to the selected state configuration.

In some embodiments, the predefined operating states differ from each other according to at least one of: UE device power consumption; network resource usage; control channel usage; and a control channel monitoring mode.

In some embodiments, the plurality of predefined operating states include at least two of the following operating states: an active state; an ECO state; an idle state; an enhanced idle state; and an enhanced ECO status.

In some embodiments, the plurality of candidate state configurations includes at least two of the following candidate state configurations: a candidate state configuration associated with a predefined set of operating states including an active state and an ECO state; a candidate state configuration associated with a predefined set of operating states including an ECO state and an idle state; a candidate state configuration associated with a predefined set of operating states including an active state, an ECO state, and an idle state; a candidate state configuration associated with a predefined set of operating states including an active state and an idle state.

A candidate state configuration associated with a predefined set of operating states including an enhanced active state and an idle state; and a candidate state configuration associated with a predefined set of operating states including an enhanced idle state and an active state.

In some embodiments, the enhanced active state includes, among other things, an active substate and an ECO substate, and within the enhanced active state there is a state transition path between the two substates.

In some embodiments, the enhanced idle state includes, among other things, an idle substate and an ECO substate, and within the enhanced idle state there is a state transition path between the two substates.

In some embodiments, the method further comprises communicating with the UE device according to the selected state configuration.

According to another aspect of the present invention, there is provided a network apparatus including: a wireless interface; a processor operatively coupled to the wireless interface; and a computer-readable storage medium operatively coupled to the processor, the computer-readable storage medium storing a program for execution by the processor, the program comprising instructions for: selecting a state configuration for a User Equipment (UE) device from a plurality of candidate state configurations, each candidate state configuration being associated with a respective set of one or more predefined operating states from a plurality of predefined operating states; and transmitting information about the selected status configuration to the UE device via the radio interface.

In some embodiments, the instructions for selecting a state configuration comprise: instructions to select a state configuration based at least in part on at least one of: a UE type associated with the UE device; and one or more services supported by the UE device.

In some embodiments, the program further includes instructions to receive, via the wireless interface, information regarding at least one of: a UE type associated with the UE device; and one or more services supported by the UE device.

In some embodiments, the program further comprises instructions for: receiving, via a wireless interface, information regarding one or more service changes supported by a UE device as part of a UE-supported service change procedure; in response to receiving information regarding one or more service changes supported by the UE device, selecting an alternative state configuration from a plurality of candidate state configurations based at least in part on the information regarding the one or more service changes supported by the UE device; and transmitting information about the selected alternative status configuration to the UE device via the radio interface.

In some embodiments, the instructions for selecting a state configuration from a plurality of candidate state configurations comprise: instructions for selecting a first state configuration based at least in part on a first service supported by the UE apparatus and selecting a second state configuration based at least in part on a second service supported by the UE apparatus; and the instructions for transmitting information about the selected status configuration to the UE device via the wireless interface comprise: instructions for transmitting information about the selected first and second state configurations to the UE device via the wireless interface.

In some embodiments, the program further comprises instructions for: providing a first service in a first network slice according to a first state configuration; and providing a second service in a second network slice according to the second state configuration.

In some embodiments, each of the plurality of network slices is associated with a respective one of a plurality of candidate state configurations;

the instructions for selecting a state configuration from the plurality of candidate state configurations comprise instructions for selecting a state configuration for a plurality of network slices supported by the UE device, the selected state configuration comprising all predefined operating states associated with respective state configurations associated with the plurality of network slices supported by the UE device; and the program further includes instructions for configuring provision of services to the UE device in a plurality of network slices supported by the UE device according to the selected state.

In some embodiments, the predefined operating states differ from each other according to at least one of: UE device power consumption; network resource usage; control channel usage and control channel monitoring mode.

In some embodiments, the plurality of candidate state configurations includes at least two of the following candidate state configurations: a candidate state configuration associated with a predefined set of operating states including an active state and an ECO state; a candidate state configuration associated with a predefined set of operating states including an ECO state and an idle state; a candidate state configuration associated with a predefined set of operating states including an active state, an ECO state, and an idle state; a candidate state configuration associated with a predefined set of operating states including an active state and an idle state; a candidate state configuration associated with a predefined set of operating states including an enhanced active state and an idle state; and a candidate state configuration associated with a predefined set of operating states including an enhanced idle state and an active state.

In some embodiments, the program further includes instructions for communicating with the UE device in accordance with the selected state configuration.

According to another aspect of the present invention, there is provided a method in a User Equipment (UE) device for supporting a plurality of UE status configurations in a wireless network, the method comprising: receiving information from a wireless network regarding a selected status configuration for a UE device, the selected status configuration being selected from a plurality of candidate status configurations, each candidate status configuration being associated with a respective set of one or more predefined operating states from a plurality of predefined operating states; and communicating via the wireless network according to the selected status configuration.

In some embodiments, the method further comprises: sending, as part of a UE air interface capability exchange procedure, information regarding at least one of: a UE type associated with the UE device; and one or more services supported by the UE device, wherein the state configuration selected for the UE device is selected from a plurality of candidate state configurations based at least in part on at least one of: information about a UE type associated with the UE device; and information about one or more services supported by the UE device.

In some embodiments, the method further comprises: transmitting information regarding one or more service changes supported by the UE device as part of a service change procedure supported by the UE;

receiving information from a wireless network regarding an alternative status configuration selected for a UE device from a plurality of candidate status configurations based at least in part on information regarding one or more service changes supported by the UE device; and communicating via the wireless network according to the selected alternate status configuration.

In some embodiments, a UE device supports a plurality of services, including at least a first service and a second service; receiving information from the wireless network regarding a status configuration selected for the UE device includes: receiving information regarding a first state configuration selected from a plurality of candidate state configurations based at least in part on a first service supported by the UE device; and receiving information regarding a second state configuration selected from the plurality of candidate state configurations based at least in part on a second service supported by the UE device; and communicating via the wireless network according to the selected status configuration, comprising: communicating via the wireless network with respect to the first service in accordance with the selected first status configuration; and communicating via the wireless network with respect to the second service in accordance with the selected second status configuration.

In some embodiments, configuring communication via the wireless network with respect to the first service according to the selected first state comprises: communicating via a first network slice of a wireless network according to the selected first state configuration; and communicating via the wireless network for the second service according to the selected second status configuration comprises: communicating via a second network slice of the wireless network according to the selected second status configuration.

According to another aspect of the present invention, there is provided a method for operating a User Equipment (UE) device, the method comprising: operating a UE device according to an operating state, wherein the UE device is transitionable between two sub-states of the operating state, the two sub-states comprising: a first sub-state in which the UE device maintains light connection management on at least one of uplink and downlink; and an idle substate having reduced power consumption relative to the first substate.

In some embodiments, in the first sub-state, the UE device is configured with a tracking channel to facilitate periodic location tracking of the UE device.

In some embodiments, among other things, the tracking channel is also used to maintain UE uplink timing alignment.

In some embodiments, the UE device is operable to selectively disable the tracking channel process in the first sub-state to reduce energy consumption.

In some embodiments, in the first sub-state, if the tracking channel procedure is disabled and the UE device needs to send a small packet on the uplink, the UE device is configured to either re-enable the tracking channel procedure or perform a random access procedure.

In some embodiments, in the first sub-state, the UE device is configured to transmit signaling associated with disabling and enabling the tracking channel procedure.

In some embodiments, in a first substate, the UE device monitors for simplified paging and downlink data notification messages.

In some embodiments, the simplified paging and downlink data notification messages are unicast to the UE device.

In some embodiments, in the first sub-state, the UE device maintains light connection management on the uplink and downlink.

In some embodiments, maintaining light connection management on the uplink and downlink facilitates small packet data exchanges with reduced delay.

In some embodiments, for the downlink, the UE device periodically monitors for paging messages in the idle substate.

In some embodiments, for the downlink, the UE device does not monitor for paging messages in the first sub-state.

In some embodiments, the paging message is a multicast message destined to all UE devices belonging to the paging group.

In some embodiments, the transition between the first substate and the idle substate is accomplished without explicit state transition signaling to the network.

In some embodiments, a UE context with a Radio Access Network (RAN) is maintained in a first sub-state.

In some embodiments, the UE context with the Radio Access Network (RAN) is maintained in two sub-states.

In some embodiments, a UE context with a Radio Access Network (RAN) is not maintained in an operational state.

In some embodiments, the transition between the operating state and the other operating state is contention-free.

In some embodiments, the operating state is an enhanced idle state and the first sub-state is an ECO state.

In some embodiments, a UE device is configured to operate in an enhanced idle state based on services supported by the UE device and/or UE types associated with the UE device.

Embodiments of the present invention provide systems and methods for configuration of a UE state machine (also referred to as state machine configuration) supporting multiple services, multiple slices, or multiple air interfaces. Embodiments can be generally classified as follows:

a UE has an embodiment of one state machine configuration for multiple services (or service sets), for multiple slices, or for multiple air interfaces;

a UE has an embodiment with multiple state machine configurations for different services (or service sets), for multiple slices, or for multiple air interfaces working independently; and

a UE has embodiments with multiple state machine configurations for different services (or service sets), for multiple slices, or for multiple air interfaces for cooperative work.

In the following description, embodiments are described largely in the context of providing a state machine or multiple state machines or state machine configurations to support multiple services. However, all of these embodiments may alternatively be implemented to support multiple slices or multiple network slices.

In some embodiments, the UE may have a state machine that uses a state machine configuration selected from a plurality of state machine configurations according to the service used. The configuration of the state machine may be adapted to the service. In some embodiments, upon initialization, the configuration of the state machine may be default or determined according to the services that the UE may use. During operation, the configuration of the state machine may change (e.g., adding/removing states in the state machine) according to changes in the service for the UE.

In the following detailed description, all embodiments are described in the context of different state machine configurations for different services. All of these embodiments are equally applicable to different state machine configurations for service sets, service types, or air interfaces. In some embodiments, an access point/base station or UE according to one of the above embodiments is further configured to implement one of the embodiments described herein for providing a state machine configuration supporting multiple services.

One state machine for multiple services

In some embodiments, when a UE requires multiple services (e.g., eMBB and mtc), the UE may use a common state machine configuration for two or more of the multiple services. In some embodiments, a common state machine configuration is used for all services. The states in the common state machine configuration may be determined according to the states in the state machine configuration for the services.

In some implementations (example a), the common state machine configuration includes all states used in any state machine configuration of the plurality of services for which the common state machine configuration is defined.

In some embodiments (example B), the common state machine configuration comprises states used in one state machine configuration for those services having the strongest states. The strongest state may be, for example, the most power consuming, at the highest power level, supporting the strongest function, or having the best performance.

In some implementations (example C), the common state machine configuration includes any state that is common to all state machine configurations for the services, and may also include one or more additional states of one or more state machine configurations of the services that are not common to all state machine configurations from the services. The additional states may include the strongest large state selected from the remaining states that are not common to all state machine configurations.

In some implementations (example D), the common state machine configuration is determined from a mapping table. In one example, the mapping table maps from a service to a state or state machine configuration indicator. A state configuration is a configuration indicator indicating a state in a state machine configuration or a parameter (such as an index) indicating a state machine configuration including a state configuration. In a second example, the mapping table maps each combination of a set of states (or state configurations) to a respective single set of states (or state machine configurations).

As an example, consider combining three state machine configurations for eMBB, mtc, and URLLC, where the basic state machine configuration definitions for these services include the following:

for eMBB: active state and idle state

For mtc: an inactive (ECO) state and an idle state,

for URLLC: inactive (although in another example the state of URLLC may always be an active state)

For the four examples A, B, C and D introduced above, the states used in the state machines of eMBB, mtc, and URLLC may be:

a. example a: active, inactive and idle

b. Example B: active and idle

c. Example C: active and inactive

d. Example D: table 1 below shows a specific example of a table mapping from service to state (or state machine configuration). Table 2 below shows a specific example of a table that maps multiple sets of states (or state configurations) to a single set of states (or one state machine configuration). Taking table 2 as an example, the table maps from a pair of state machine configurations to one state machine configuration, but the same approach may be used to map two or more state machine configurations to one state machine configuration.

Table 1: mapping from service to state

Table 2: mapping from multiple state configurations to one state machine configuration

	Configuration #1	Configuration #2	Configuration #3	Configuration #4	···
						Configuration #1	Configuration #1	Configuration #1	Configuration #4	Configuration #4	···
Configuration #2	Configuration #1	Configuration #2	Configuration #2	Configuration #4	···
						Configuration #3	Configuration #4	Configuration #2	Configuration #3	Configuration #4	···
Configuration #4	Configuration #4	Configuration #4	Configuration #4	Configuration #4	···
						···	···	···	···	···	···

The method for determining the state in the common state machine configuration may be predefined or signaled from the network to the UE. It may also be partly predefined and partly signalled. For example, there may be a predefined basic scheme and some parameters or configurations are signaled. In another example, there may be a predefined plurality of candidate schemes and the selected scheme is signaled.

The common state machine configuration may be fixed or long-term stable for the UE, depending on all services supported by the UE. In some embodiments, the common state machine configuration is fixed for a particular type of UE. In some embodiments, the UE informs the network of the common state machine configuration by reporting the UE type or capability to the network. The network operates accordingly in its interaction with the UE.

Alternatively or additionally, the common state machine configuration may be flexible or dynamic for the UE depending on the services used by the UE. In this case, the common state machine configuration may be changed from a first common state machine for one service configuration used by the UE to a second common state machine configuration for another service configuration used by the UE.

In one embodiment, the configuration of the common state machine configuration for the UE may be changed to support a more powerful state when a new service is started. When the existing service is stopped, the common state machine configuration may be changed to a state machine configuration with lower power consumption. Fig. 24 depicts an example showing two

state machine configurations

3100, 3102, in which the state machine configuration 3100 has a more powerful state. When a new service starts, the UE starts to use state machine configuration # 1. When the existing service stops, the UE starts to use state machine configuration # 23102.

In this case, the UE may send a signal to the network indicating a change in service or state machine configuration. The network may send an acknowledgement or configuration signaling to acknowledge the transfer of the state machine configuration.

In another embodiment, the state machine configuration of the UE may transition to a different configuration when a new air interface is connected or an existing air interface is released. Fig. 25 depicts an example showing two

state machine configurations

3200, 3202. When a new air interface is connected, the UE starts to use state machine configuration # 13200. When the existing air interface is released, the UE starts to use state machine configuration # 23202.

In this case, in some embodiments, the network may learn of the change in state configuration without additional signaling according to the air interface connection/release procedure.

In another embodiment, the UE has a state machine configuration that includes all states for all services. But some states may be disabled depending on the service to be used. For example, a UE may be configured with an idle state, an inactive state, and an active state in a state machine and then configured or reconfigured to disable the inactive state. Its result is physically similar to a state machine configured with only idle and active states.

In a common state machine configuration for a plurality of services, conditions for state transitions between pairs of states of the common state machine configuration may be defined for the plurality of services. Table 3 below shows several examples to illustrate this. Table 3 relates to session-based connections and non-session-based connections. A session-based connection (e.g., ftp, web browsing, video traffic) is a connection where there is a series of packet exchanges. A non-session based connection (e.g., keep-alive messages, background traffic) is a connection that typically only sends packets and may have packet reception.

Table 3: condition of state transition

Although some examples have been described for various conditions of state transitions, many other examples are possible. A non-exhaustive list of other examples includes:

if the UE is not in the active state, the UE should transition to the active state when a session of any service, slice, or AI is started.

When a session-based service (e.g., an eMBB service) is started, the UE should transition to an active state.

When the UE accesses a slice supporting the session (e.g., an eMBB slice), the UE should transition to an active state.

When the UE is connected to an air interface for session-based services (e.g., AI for eMBB), the UE should transition to an active state.

The condition for the UE to transition to the active state is session based connection establishment.

The condition for the UE to transition to the active state is the initiation of a session-based service (e.g., an eMBB service).

The condition for the UE to transition to the active state is access to a slice (e.g., an eMBB slice) that supports the session.

The condition for the UE to transition to the active state is to establish a connection to an AI for the session-based service (e.g., an AI for the eMBB).

Establishing a session-based connection triggers a transition (from another state) to an active state.

When the UE (or a state machine of the UE) is not in an active state, initiation of a session-based service (e.g., an eMBB service) may trigger a transition to the active state.

Access to a slice supporting a session (e.g., an eMBB slice) may trigger a transition (from an idle state or an inactive state) to an active state.

Establishing a connection to an AI for a session-based service (e.g., an AI for eMBB) may trigger a transition (from another state) to an active state.

Other state transition conditions are also possible.

In some embodiments, the condition for state transition may also include expiration of one or more timers. The following is a non-exhaustive list of examples:

the UE should transition to the idle state only when all connections (including session-based and non-session-based) have been released and all associated timers expire.

The UE should transition to the idle state only when the last connection is released and the relevant timer (the timer that was started or reset when the connection was released) expires.

The UE should transition to the idle state only when a timer T770 (a timer started when the last connection is released) expires.

Other timer-based transition conditions are also possible.

In some embodiments, when the state machine configuration changes, the state after the state reconfiguration is determined according to predefined rules. Several examples of possible predefined rules include:

rule 1: if the reconfigured state machine configuration supports an active state, the UE should transition to the active state when a new service is initiated

Rule 2: if the reconfigured state machine configuration does not support the active state, the UE should transition to the inactive state when a new service is started

Rule 3: if the reconfigured state machine configuration supports the inactive state, the UE should transition to the inactive state when the existing service is released

Rule 4: if the reconfigured state machine configuration does not support the inactive state, the UE should transition to the idle state when the existing service is released

Multiple state machines operating independently

In some embodiments, multiple state machines are implemented that work independently. A separate state machine is used for each of the plurality of services. In this embodiment, the UE may have multiple states simultaneously, one for each service.

In a particular example, the UE may use three independent state machines separately for eMBB, mtc, and URLLC transmissions. And thus can have three states simultaneously. For example, at a particular time, the UE may be in an active state for eMBB, an idle state for mtc, and an inactive state for URLLC.

In another example thereof, the UE may use two independent state machines for two air interfaces. The state machine to be used over the air may be indicated by signaling sent from the network. The state machine to be used may be explicitly indicated by including state machine information in the signaling. Alternatively, the state machine to be used may be indicated implicitly by including some other information in the signaling that may be used to derive the state machine.

Implementations featuring independent state machines add complexity compared to implementations using a single common state machine. Furthermore, these embodiments may not provide the UE with the best performance when the different state machines are in different states. For example, when a UE is in an active state for eMBB, it cannot actually save power even though it is in an idle state for mtc (although it comes at the cost of large delay).

Multiple state machines working in concert

In these embodiments, the UE is configured with multiple state machines that work together to improve UE performance. The state or state transition condition in one state machine may depend on a state or event in another state machine of the UE. The following is a non-exhaustive list of such dependency types:

1. the particular state of the first state machine directly results in the particular state of the second state machine. In this example, this is shown as a dotted dependency arrow from a particular state of a first state machine to a particular state of a second state machine. An example is shown and described below with reference to fig. 30.

2. The conditions for a particular state transition in the first state machine depend on the particular state in the second state machine. Such a condition is a condition other than the other conditions in the first state machine for a particular state transition. In this example, this is shown as a dotted dependency arrow from a particular state of the second state machine to the state transition arrow in the first state machine. Arrow 3412 of fig. 27, described in detail below, is an example thereof.

3. The condition of a particular state transition in the first state machine directly results in a particular state in the second state machine. In this example, this is shown as a dotted dependency arrow transitioning from a particular state in the first state machine to a particular state in the second state machine. Arrow 3312 of fig. 26, described in detail below, is an example thereof.

4. The condition of a particular state transition in the first state machine depends on the condition of a particular state transition in the second state machine.

A first set of examples will be described with reference to fig. 26. In fig. 26, the UE has a state machine # 13300, and has a state machine # 23302. State machine # 13300 is used for non-session based applications, and state machine # 23302 is used for session based applications. Each state machine has one or more states and has conditions local to the state machine that transition between the states of the state machine. The state of state machine # 13300 includes idle and inactive. State transitions include transitions from inactive to idle upon connection release, and transitions from idle to inactive upon connection establishment. The state of state machine # 23302 includes idle and active. State transitions include transitions from idle to active at connection establishment and active to idle at connection release.

In this example, an additional state transition condition is defined for state machine # 13300 that depends on state machine # 23302. Several examples of state machine dependencies that would normally exist between two or more state machines will now be described, as well as a description of how each example applies to the particular state machine of FIG. 26. Some of these examples consider the presence of two or more state machines (only two shown in fig. 26). For all examples in fig. 25, some aspects of state machine # 23302 directly result in an inactive state in state machine # 13300.

First example

When state machine #2 is in the active state, state machine #1 should be in the inactive state. For the example in fig. 26, if state machine # 13300 is in an idle state, then state machine # 23302 transitions from the idle state to an active state resulting in: if the state machine # 13300 is not already in the inactive state, the state machine # 13300 transitions from the idle state to the inactive state.

Second example

When any other state machine transitions to the active state, the current state machine should transition to the inactive state if it is not in the inactive state. In the example of fig. 26, the transition from idle to active in state machine # 23302 results in: if state machine # 13300 is not already in the inactive state, it will transition from the idle state to the inactive state.

Third example

When a connection is established for a state machine of a session based service, the state machine for the non-session based service should transition to an inactive state if it was (previously) in an idle state. In the example of fig. 26, state machine # 23302 is used for session-based services. When a connection is established, state machine # 23302 transitions from an idle state to an active state, and connection establishment further results in: if state machine # 13300 is not already in the inactive state, it transitions from the idle state to the inactive state. This dependency is indicated by arrow 3312 in fig. 26.

Fourth example

The state machines include a state machine #2 for the eMBB service and a state machine #1 for the mtc service. When a connection for the eMBB service is established, if a state machine #1 (previously) for the mtc service is in an idle state, it should transition to an inactive state.

Fifth example

When a connection is established for the air interface corresponding to state machine #2, state machine #1 transitions to an inactive state. In the example of fig. 26, when a connection is established for an air interface corresponding to state machine # 23302, state machine # 13300 transitions to an inactive state.

The benefit from these dependencies is that the performance of the non-session based services supported by state machine #1 is improved at similar UE power consumption. This is because when state machine #2 is active, the UE must operate in a high power mode regardless of the state of the other state machines.

In some embodiments, during the connection establishment procedure for the session-based service, the network may also send messages to configure some other state machines of the UE.

Another set of examples will now be described with reference to fig. 28, which shows state machine # 13400 and state machine # 23402. In these examples, the conditions under which state machine # 13400 transitions to the idle state depend on state machine # 23402. Several examples of state machine dependencies that apply to two state machines in general, and a description of how the examples apply to the particular state machine in FIG. 28, will now be described. Some of these examples consider the presence of two or more state machines (only two shown in fig. 28). First example

When the connections of all state machines are released, state machine #1 transitions to the idle state after a predetermined period of time (e.g., when a timer expires). For the example in fig. 28, when connections for all state machines including state machine # 13400 and state machine # 23402 are released, state machine # 13400 transitions to an idle state after a predetermined period of time if not already in an idle state.

Second example

When the connection is released all over and all other state machines except the state machine #1 are in the idle state, the state machine #1 transitions to the idle state. For the example in fig. 28, when the connection for state machine # 23402 is released and all other state machines except state machine # 13400 are in an idle state, state machine # 13400 transitions to an idle state. Third example

When all connections for the non-session based service are released and all other state machines (except state machine # 1) are not in an active state, state machine #1 should transition to an idle state. For the example in fig. 28, state machine # 13400 is used for non-session based services. State machine # 13400 transitions to the idle state when all other state machines, including state machine # 23402, are not in the active state.

Fourth example

One state machine is used for mtc services and another state machine is used for URLLC. When the connection for the mtc service is released and there are no other connections (except for possible URLLC service connections), the state machine for the mtc service transitions to an idle state. Such an approach may be appropriate, for example, if URLLC service is too important and/or too sensitive to delay such that its state machine cannot have an idle state.

In some implementations, the state transitions of each state machine are dependent on the states of the other state machines. An example is shown in fig. 28, which shows

state machines

3500, 3502. In fig. 28, an arrow 3504 indicates that state machine # 13500 is in the idle state, which is a condition in which state machine # 23502 transitions from the active state to the inactive state. Arrow 3506 indicates that connection establishment of state machine #1 (which is also a condition for idle state to active state transition in state machine # 13500) results in state machine 3502 being in the active state. Arrow 3508 indicates that a connection establishment in state machine # 23502 (which is also a condition of state machine # 23502 from inactive to active) results in state machine # 13500 being in an active state.

FIG. 29 shows an example of state machine dependencies with three states for one of the state machines. Shown is a first state machine #13600 having two states and a second state machine #23602 having three states. In the example of fig. 29, the various correlations are illustrated by

arrows

3604, 3606, 3608, 3610:

arrow 3604 indicates that state machine #13600 is in an idle state is a condition under which state machine #23602 transitions to an idle state.

Arrow 3606 indicates that an idle to active state transition condition in state machine #13600 results in state machine #23602 transitioning to an active state if not already in an active state.

Arrow 3608 indicates that state machine #13600 is in an idle state is a condition under which state machine #2 transitions to an idle state.

Arrow 3610 indicates that the inactive to active transition condition in state machine #23602 results in state machine #13600 transitioning to the active state if not already in the active state.

In another embodiment, when the state of the first state machine #1 is a subset of the state in the second state machine #2 (e.g., as is the case with the state machines in fig. 29), the state machine #2 operates as a master state machine and the state machine #1 operates as a slave state machine that depends on the master state machine. There may be multiple auxiliary state machines. The state transition in the primary state machine may take into account the conditions of all of the secondary state machines that depend on it. The auxiliary state machine does not need to determine these conditions. Instead, the state of the secondary state machine may be determined by simply mapping the state from the primary state machine. Examples are given in table 4 below.

Table 4: state mapping from a primary state machine to a secondary state machine

Main state machine (Idle, inactive, active)	Free up	Is inactive	Movement of
				Auxiliary state machine (Idle, active)	Free up	Free up	Movement of
Auxiliary state machine (Idle, inactive)	Free up	Is inactive	Is inactive

In another embodiment, the UE has three or more state machines. The three or more state machines have one or more states, each state being common between two or more state machines. State machines are interdependent, i.e. when one state machine transitions to a state common to the other state machines, the other state machines also transition to that state if not (previously) in that state. The state machines are synchronized with respect to a common state. An example is depicted in fig. 30, which shows three

state machines

3700, 3702, 3704. The state common among the three

state machines

3700, 3702, 3704 is inactive, so a transition to inactive state in any state machine results in the other two state machines transitioning to inactive state. The active state is common between the second state machine 3702 and the third state machine 3704, so a transition to the active state in one of the second state machine and the third state machine results in the other of the second state machine and the third state machine transitioning to the active state. The idle state is common between the first state machine 3700 and the second state machine 3702, so transitioning to the idle state in one of the first state machine and the second state machine results in the other of the first state machine and the second state machine transitioning to the idle state.

Many modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the application may be practiced otherwise than as specifically described herein.

Claims

1. A method for a User Equipment (UE) in a wireless communication network, the method comprising:

the UE operating based on a first state of a state machine, wherein the state machine corresponds to a particular logical configuration set in the wireless communication network, the state machine having a plurality of states and state transitions dependent on conditions related to the particular logical configuration;

the UE transitions to a second state of the state machine upon receiving a signal to transition to the second state;

wherein the state machine is a first state machine of a plurality of state machines, each state machine of the plurality of state machines corresponding to a different set of logical configurations in the wireless communication network, the different set of logical configurations allowing for the creation of different slices having different service-specific functions;

wherein at least two of the plurality of state machines have different state configurations and each have a non-idle state;

wherein, in addition to local conditions of each state machine related to the particular logic configuration, there is at least one state machine dependency between two or more of the plurality of state machines, such that a condition of a state or state transition of one of the state machines depends on a state of another state machine or a condition related to a service or service group or air interface of another state machine;

wherein the at least one state machine dependency comprises: when a first state machine has an inactive state but does not have an active state, and when any other state machine except the first state machine transitions to an active state or an inactive state and the current state of the first state machine is not an inactive state, then the current state of the first state machine transitions to an inactive state.

2. The method of claim 1, wherein the plurality of state machines operate independently.

3. The method of claim 1, wherein the at least one state machine dependency comprises: the particular state of the first state machine directly results in a dependency of the particular state of the second state machine.

4. The method of claim 1, wherein the at least one state machine dependency comprises: the condition of a particular state transition in a first state machine depends on the dependency of a particular state of a second state machine.

5. The method of claim 1, wherein the at least one state machine dependency comprises: the condition of a particular state transition in a first state machine directly results in a dependency of a particular state of a second state machine.

6. The method of claim 1, wherein the at least one state machine dependency comprises: the condition of a particular state transition in a first state machine depends on the dependency of the condition of a particular state transition of a second state machine.

7. The method of claim 1, further comprising:

in a connection establishment procedure for a session based service, a UE receives a message to configure some other state machine of the UE.

8. The method of claim 1, wherein the at least one state machine dependency comprises two state machine dependencies between a first state machine and a second state machine of the plurality of state machines, such that a condition of a state or state transition of the first state machine is dependent on a state of the second state machine or a condition related to a service or service group or air interface of the second state machine, and such that a condition of a state or state transition of the second state machine is dependent on a state of the first state machine or a condition related to a service or service group or air interface of the first state machine.

9. The method of claim 1, wherein:

the states of a first one of the state machines are a subset of the states of a second one of the state machines;

the second state machine operates as a primary state machine and the first state machine operates as a secondary state machine that is dependent on the primary state machine;

state transitions of the primary state machine take into account conditions of the primary state machine and the secondary state machine;

the state of the secondary state machine is determined by a mapping of the state from the primary state machine.

10. The method of claim 1, wherein:

the plurality of state machines includes at least two state machines having one or more states each of which is common between two or more of the state machines;

the at least one state machine dependency is such that when one state machine transitions to a state in common with one or more other state machines, the one or more other state machines also transition to that state if the one or more other state machines are not already in that state.

11. A User Equipment (UE) comprising a non-transitory memory containing instructions, and one or more processors in communication with the memory, wherein:

the processor, when executing the instructions, performs the method of any one of claims 1 to 10.