CN108370530B - Method and system for performing network slicing in a radio access network - Google Patents

Abstract

Systems and methods are provided for a user equipment to perform a handover between super cells. The handover is done on a per service basis. In some cases, a handover of one service from a source cell to a target cell is performed while continuing to use the source cell, the target cell, or another cell for another service. In some cases, the handover of the user equipment is a handover from the source cell to the target cell for one of the uplink and downlink communications, and the user equipment continues to use the source cell for the other of the uplink and downlink communications.

Description

Method and system for performing network slicing in a radio access network

RELATED APPLICATIONS

This application claims priority and benefit from the following applications: U.S. provisional patent application serial No. 62/264,629 filed on 8/12/2015 and U.S. 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 invention relates to systems and methods for performing a handover of a mobile device between super cells in a wireless network.

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 fronthaul 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: issues related to dynamic channel quality on the radio link to the UE, providing 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.

Typically, a cell is associated with a TRP (e.g., an eNB in LTE). Many times, a cell is a geographical area covered by a TRP. The cells are arranged so that a mobile device, such as User Equipment (UE), can maintain a connection with the serving cell as it moves. In an ideal situation, the UE will be able to connect to the second cell as the strength of coverage from the first cell decreases. Many times, there are areas at the cell edge where the UE can "see" more than one cell. This may cause problems such as poor cell edge throughput, frequent handovers, etc. To address these issues, in some proposed next generation mobile network proposals, a cell may no longer be associated with a fixed TRP. In contrast, a super cell may be associated with a set of TRPs and a specific frequency band that may provide a specific service for a User Equipment (UE). 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 URLL service types. Existing Handover procedures (e.g., those shown in 3GPP TS36.300 V12.0.0, section 10.1.2.1.1: Intra-Mobility Management Entity (MME)/Serving Gateway Handover (SGW) Handover (HO)) (Handover, within Mobility Management Entity (MME)/Serving Gateway Handover (SGW)) are not suitable for Handover between super cells.

Disclosure of Invention

Systems and methods for performing handover for user equipment between super cells are provided. The handover is done on a per service basis. In some cases, a handover of one service from a source cell to a target cell is performed while continuing to use the source cell, the target cell, or another cell for another service. In some cases, the handover of the user equipment is a handover from the source cell to the target cell for one of the uplink and downlink communications, and the user equipment continues to use the source cell for the other of the uplink and downlink communications.

A first broad aspect of the invention provides a method in a UE, comprising: communicating with at least one first serving cell to transmit or receive each of a plurality of packet streams. For each of at least one service, the uplink communication for the service comprises one of the plurality of packet flows, or the downlink communication for the service comprises one of the plurality of packet flows, or the uplink communication for the service comprises one of the plurality of packet flows and the downlink communication for the service comprises one of the plurality of packet flows. The method comprises transmitting at least one measurement report or transmitting a reference signal. In response to the instruction, completing a handover from one of the at least one serving cell to the target serving cell for at least one of the plurality of packet flows. After the handover, the UE continues to communicate with one of the at least one first serving cell to transmit or receive one of the plurality of packet streams.

In some embodiments, the handover may be completed without performing synchronization in the second cell for the second service. In other embodiments, the handover may be accomplished by performing synchronization in the second cell for the second service. In an embodiment, the handover may be an intra-MME/SGW handover or an inter-MME/SGW handover. In other embodiments, the method may further include, while in the inactive state, the UE transmitting a signal to cause the network to determine that the UE is moving into a new cell, and the UE receiving a message indicating a cell ID of the new cell.

According to a second broad aspect, the invention provides a method in an access network comprising a plurality of cells, each cell comprising at least one access point. The method comprises the following steps: communicating with the UE using at least a first serving cell of the plurality of cells to transmit or receive each of a plurality of packet flows, wherein for each of at least one service, an uplink communication for the service comprises one of the plurality of packet flows, or a downlink communication for the service comprises one of the plurality of packet flows, or an uplink communication for the service comprises one of the plurality of packet flows and a downlink communication for the service comprises one of the plurality of packet flows. The method continues with receiving at least one measurement report or receiving a reference signal. Transmitting an instruction to the UE to complete a handover from one of the at least one serving cell to a target serving cell of the plurality of cells for at least one of the plurality of packet flows. After the handover, the method involves continuing to communicate with the UE using one of the at least one first serving cell to transmit or receive one of the plurality of packet streams.

In some embodiments, the handover in any of the above mentioned aspects is a handover from a source cell to a target cell for a first service while continuing to use another cell for a second service. In other embodiments, the handover in any of the above mentioned aspects is a handover from a source cell to a target cell for a first service while continuing to use the target cell for a second service. In other embodiments, the handover in any of the above mentioned aspects is a handover from a source cell to a target cell for uplink communication of a service while continuing to use the source cell for downlink communication of the service. In some embodiments, the handover in any of the above mentioned aspects is a handover from a source cell to a target cell for downlink communication of a service while continuing to use the source cell for uplink communication of the service. Other embodiments provide a user equipment configured to perform one of the methods outlined above or disclosed herein. Other embodiments provide an access network configured to perform one of the methods outlined above or disclosed herein.

Those skilled in the art will appreciate that these embodiments can be combined with other listed embodiments or can be implemented separately as a variation of the aspects.

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. 14A is a diagram showing a super cell-based wireless access system;

fig. 14B is a diagram of the network in fig. 1, wherein TRPs are arranged in two super cells;

fig. 14C is a diagram of the network in fig. 1, with some TRPs arranged in a third supercell;

fig. 14D is a flowchart of a method of performing a handover provided by an embodiment of the present invention from the perspective of a UE;

fig. 14E is a flow chart of a method of performing a handover provided by an embodiment of the present invention from a network perspective;

figure 15 shows an example of a service handover from a source super cell to a target cell whilst maintaining the use of other serving super cells for another service;

figure 16 shows an example of a service handover from a source super cell to a target cell while maintaining the use of the source super cell for another service;

fig. 17 shows an example of a service handover from a source super cell to a target super cell, where the UE has used the target super cell for another service;

fig. 18 shows an example of a service handover from a source super cell to a target cell only for uplink communication, while keeping the source super cell used for downlink communication;

fig. 19 shows an example of a service handover from a source super cell to a target cell only for downlink communications, while keeping the source super cell used for uplink communications; and

fig. 20 is a flow chart illustrating a method for execution at a UE.

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, and therefore 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) under the Long-term evolution (LTE) standard, a 5G node, 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 the RAN that allow for the use of different waveforms and different transmission parameters of the respective waveforms, such as different sets of underlying parameters (numerology) of 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 where advanced antenna techniques are applied

A lower directionality based on the transmission; 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 allocations 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 TP 176 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. US 2015/0141002A 1 entitled "System and method for Non-Cellular Wireless Access"; U.S. patent publication No. US 2014/0113643A 1 entitled "System And Method For Radio Access visualization" And U.S. patent publication No. US 2014/0073287A 1 entitled "System And Method For User Equipment centralized System 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 TP 176 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 RAN125 with an indication of the slice 152 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 of a first service in a defined slice and a scenario where the UE is connected to a second service provider of 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 TP 176 operates in a high frequency band, such as the millimeter-wave band, and the other TP 176 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 TP 176 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 TP 176 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 TP 176 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. The super cell may be integrated 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 first service-centric RAN slice 152(S4) and communicate with a second super cell for traffic associated with a second service-centric RAN slice 152 (S5). 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. The interaction of the UE with a plurality of different cells or super cells will be discussed further on and will be more fully understood with reference to the discussion beginning with fig. 14A.

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 AP602 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 AP602 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 AP604 and the AP 606 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, AP604 and AP 606 may be directly connected to the core network. AP604 and AP 606 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 AP604, the UE110 may rely on the AP604 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 AP602 (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 AP 606 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. US 2015/0195788A 1 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 to Receive 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 the identity of at least one 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. CN 2918 had 3 slices: slice 2-1920, slice 2-2922, and slice 2-3924. Each slice carries traffic and slices 2-2922 are shown carrying traffic for service 1926 and service 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: AP1930, AP 2932, and AP 3934. As will be appreciated, different types of APs may be used for different purposes. AP1930 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 AP1930 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 CN 2918 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 4942. 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 AP1930 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 AP1930 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 AP1930, 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.

Fig. 14A is a diagram illustrating an embodiment of a super cell-based wireless access system. A super cell manager 1440 and a plurality of TRPs 1400, 1402. The super cell manager 1440 is connected to the TRP through a backhaul network not shown. The super cell manager 1440 is responsible for configuring TRP into super cells. This can be done on a static or dynamic basis. More generally, given a coverage area with multiple TRPs, one or more super cells may be configured, each super cell containing one or more TRPs. The number of TRPs and the configuration of TRPs to super cells are implementation specific. The coverage of a super cell may be identical to the coverage area provided by the combination of TRPs in the super cell. Alternatively, the coverage area defined by a super cell comprises an area smaller than all coverage areas provided by a combination of TRPs in that super cell. It should also be understood that in some environments, the membership in a super cell may be dynamic, such that the size of the coverage area of the super cell may vary as the membership in the super cell varies. In some embodiments, the TRP provides Radio Frequency (RF) functionality while one or more baseband units (BBUs) forming a BBU pool provide baseband functionality. The BBU pools may be centralized or distributed. In some embodiments, the BBU functionality may be provided by a virtualized network function. For example, it may be implemented using virtualized computing resources associated with the eNB with the smallest total distance to all relevant TRPs. For the purposes of this example, reference is made to TRP. However, any of the embodiments described herein are generally applicable to access points.

Also shown in fig. 14A is a handover manager 1450, which is responsible for some network side functions to enable handover between super cells, according to one or more embodiments described herein. In some embodiments, the handover manager 1450 includes a respective resource for each super cell. For example, where the handover manager 1450 is centralized for a plurality of super cells, it may include logical resources for each super cell to participate in a handover on behalf of the super cell. Alternatively, the handover manager 1450 may be allocated separate physical resources in each super cell. This may be, for example, there may be a separate handover manager 1450 associated with each super cell. In some embodiments, the handover manager 1450 is present in a particular one of the access points of each super cell that is assigned to manage handovers on behalf of the super cell. In such embodiments, more than one AP within a super cell may have a handover manager function, and within each super cell one of the APs having such a function is relied upon to provide the handover manager 1450. This may be accomplished by any number of different implementations, including using a virtualized representation of the underlying resources. In some embodiments, the handover manager is implemented as a function in a network element such as a Mobility Management Entity (MME), which may also be referred to as a Mobility Management Function (MMF). Those skilled in the art will recognize that radio access network functionality may rely on a set of connected data centers, allowing offloading of functionality from a node such as an eNB. In such an environment, the TRP may be a combination of functions provided in a virtual environment and a physical Remote Radio Head (RRH).

In the described embodiments, a method of handover between super cells is provided. From the UE perspective, the super cell looks like a normal cell. Membership changes of TRPs within a super cell may be performed in a manner that is transparent to the UE to which the super cell is connected. More generally, the methods described herein may be generally applied to handovers between cells. Some or all of the cells may be super cells including multiple access points. Some or all of the cells may each include a single access point.

As described above, a radio access network slice is a set of network resources and/or network functions that may be allocated to allow a set of services to be provided. The set of services may be a service for one UE, a class of services for a plurality of UEs, multiple types of services for a plurality of UEs, or multiple types of services for one UE. The set of services may be dedicated to an operator or may be shared among multiple operators. Alternatively, however, network resources may be allocated directly to one or more services. The same type of service may be provided by one or more slices. When isolation needs to be performed between multiple operators or service providers, multiple slices may be required.

Throughout the specification, when "service/slice" is used, it is intended to cover both service-specific embodiments and slice-specific embodiments. The disclosed methods and systems provide for super cells, configuration of super cells, and operation of super cells in a service-specific manner and/or a slice-specific manner.

Multiple (overlapping) super cells may coexist in the network to meet the requirements of various types of services/slices. In general, different UEs may use different services in different super cells. In some cases, one UE may also use multiple services/slices supported by different super cells. In some embodiments, one UE may use one service/slice supported by different super cells in the downlink and uplink, since the interference situation, link budget and traffic load may be very different for the downlink and uplink. This coexistence of multiple super cells may exist in a single carrier or in multiple carriers.

In some embodiments, access to different services/slices may be provided by the same super cell. This would be reasonable if the service/slice has similar requirements for TRP set configuration or if the network can only support a limited number of types of super cells.

In some embodiments, the same type of service/slice may be provided by different super cells (possibly with overlapping coverage) for different UEs. This may be required for UE-centric super cells, which serve not only specific but also UE-specific.

In general, different sets of TRPs may be associated with different super cells. However, different super cells may also be supported by the same TRP set. For example, the TRP set may use high frequencies for small coverage super cells for eMBB services and simultaneously use low frequencies for larger coverage super cells for URLLC services.

An exemplary configuration of the TRP in fig. 14A for providing a first service (e.g., an eMBB service) is depicted in fig. 14B. Here, the TRP labeled "a" is included in a first eMBB super cell and the TRP labeled "B" is included in a second eMBB super cell. There is a transparent boundary between the coverage areas of the neighboring supercells 1436, 1438. Also shown is a UE 1435 within the coverage area of two super cells 1436, 1438. The illustrated system may support seamless UE mobility. While receiving service from the super cell 1436, the UE 135 may communicate with one or more TRPs of the super cell 1436. At a later time, the UE 135 may change to receive service from the super cell 1438 and may communicate with one or more TRPs of the super cell 1438, e.g., due to movement. The change from super cell 1436 to super cell 1438 will typically involve a handover operation.

An exemplary configuration of the TRP of fig. 14A for providing a second service (e.g., a V2X (Vehicle-to-updating) service) is depicted in fig. 14C. Here, the TRP labeled "C" is included in super cell 1442. The configurations in fig. 14B and 14C may occur simultaneously in a single combined example, in which case a particular TRP 1400, 1406, 1416 is included in both the eMBB super cell 1436 and the V2X super cell 1442, and a particular TRP 1420, 1426, 1430 is included in both the eMBB super cell 1438 and the vehicular extravehicular (V2X) super cell 1442.

In a super cell, the TRP serving a UE may change as the UE moves. The UE may move freely in the super cell without handover. The TRP serving the UE may be changed by network functions according to information such as uplink measurements based on uplink reference signals (e.g., sounding signals, beacons, or preambles) transmitted by the UE.

Different UEs in a super cell may transmit uplink reference signals using different uplink reference signals or different resources so that the UEs can be distinguished by the network. The same reference signal may also be reused in a super cell if there is sufficient distance to avoid interference.

Handover may be required when a UE moves from the coverage area of the serving super-cell to the target super-cell. Systems and methods are provided for enabling handover between super cells.

For an active UE, messages are exchanged between the UE and the network to establish a new Radio Resource Control (RRC) connection in the target super cell. Context information associated with the UE may be transmitted to the target super cell. If there are any data transmissions associated with the ongoing session, it may be redirected to the target super cell. The context information is information characterizing the condition of the UE.

The uplink reference signals and uplink resources for the UE to use after handover may be signaled by the target super cell.

Different types of super cells may be used to support different services/slices. For example:

a. a super cell with small coverage using lower power nodes in a high frequency band may be used to support eMBB services requiring high data rates;

b. super cells using both high power nodes and low power nodes in a low frequency band may be used to support mtc services, which may require a large number of connections for low power devices to transmit small packets;

c. super cells with fast backhaul using high power nodes in low frequency band can be used to support URLLC services requiring high reliability and low latency; and

d. super cells with large coverage, each using a large number of high power nodes in the low frequency band, may be used to support V2X services requiring high mobility.

Thus, multiple types of super cells may coexist in the network. When a UE needs multiple services, it can be served by multiple types of super cells. The UE may know the type of the super cell by broadcasting information. Alternatively, each cell ID may be associated with a particular super cell type, such that the UE may determine the super cell type once it learns the cell ID of the super cell. The super cell types may be defined by services such that each super cell is used for a specific service. By way of example above, the super cell types will include eMBB, mtc, URLLC and V2X, but of course other types are possible.

According to embodiments of the present invention, different types of super cells may coexist in a network and may have overlapping coverage areas. Thus, a UE moving along a path and connected to more than one super cell may undergo handover between super cells at different times. In one example provided for purposes of illustration, a UE may be connected to a first super cell for accessing eMBB services and also connected to a second super cell for MTC services. The edges of the first and second super-cells may not always be aligned with each other (e.g., the coverage areas of the super-cells may not be the same). As the UE moves, it may experience being handed over to a third super cell as it leaves the coverage area of the first super cell. The handover between the first super cell and the third super cell providing the eMBB service may be performed without requiring a handover from the second super cell. As such, it will be appreciated that a method is provided for performing a handover for one type of super cell at a time.

Fig. 14D illustrates a method 1460 for performing a handover operation (which may also be referred to as handoff off) from the perspective of a UE provided in accordance with an embodiment of the present invention. The method 1460 begins at block 1462, where the UE communicates with at least one first serving cell to transmit or receive each of a plurality of packet streams. For each service, the uplink communication for the service includes one of the plurality of packet flows, or the downlink communication for the service includes one of the plurality of packet flows. For some services, a service may have two flows, one for uplink communications and one for downlink communications. The method continues in block 1464 with transmitting at least one measurement report or transmitting a reference signal. In block 1466, handover from one of the at least one serving cell to the target serving cell for at least one of the plurality of packet flows is completed in response to the instruction. Note that this refers to UE side functionality with respect to completing handover. In block 1468, after the handover, the UE continues to communicate with one of the at least one first serving cell to transmit or receive one of the plurality of packet streams.

Fig. 14E shows a method 1470 of handing over from the perspective of a network having multiple cells, each cell containing at least one access point. The method 1470 begins at block 1472 where at least a first serving cell of the plurality of cells is utilized to communicate with a UE to send or receive each of a plurality of packet flows. For each of at least one service, the uplink communication for the service includes one of the plurality of packet flows or the downlink communication for the service includes one of the plurality of packet flows. For some services, there may be two packet flows, one for uplink communications and one for downlink communications. In block 1474, the network receives at least one measurement report or reference signal. In block 1476, an instruction is transmitted to the UE to complete a handover from one of the at least one serving cell to a target serving cell of the plurality of cells for at least one of the plurality of packet flows. In block 1478, after the handover, the network continues to communicate with the UE using one of the at least one first serving cell to send or receive one of the plurality of packet flows.

Examples of these methods are described below with reference to fig. 15-19. It should be understood that the methods in fig. 15-19 are very detailed examples, and that these specific steps do not necessarily need to be performed. Some steps may be modified or omitted. Some steps are the same in multiple figures and the description of these steps will not be repeated. Each figure includes functionality for a UE and functionality for a network in one or more cells (each including one or more access points). For each figure, there is provided as an embodiment of the invention a corresponding method performed by a UE, comprising some or all of the steps performed by the UE, and as an embodiment of the invention there is provided a corresponding apparatus comprising a UE configured to implement some or all of the steps performed by the UE. For each figure, a corresponding method performed by a network component or functional entity (e.g., by one or more network components, or a specific combination of such components, which may include an access point, a super cell manager, or a handoff manager) is provided as an embodiment of the invention, which may include some or all of the steps performed by the network, and a corresponding apparatus is provided as an embodiment of the invention, which includes one or more network components configured to implement some or all of the steps performed by the UE.

For an active UE that obtains service from multiple super cells for different services, the UE may perform respective handovers from multiple source super cells to one or more target super cells. The handover may be initiated by a handover request message, where the UE may indicate to the network the desired target super cell. For example, the handover request message may contain an information element indicating the cell ID of the target super cell. In some embodiments, the handover request may be sent to a source super cell of the same type as the target super cell or another super cell of a different type with which the UE is associated.

Upon receiving a handover request from the UE, the network may first determine the source super cell as a super cell of the same type as the target super cell (with which the UE is currently associated) and then transmit the context of the UE from the source super cell to the target super cell.

During and after the handover, the UE may still maintain a connection with a different type of previous super cell from the target super cell.

In some embodiments, the UE may perform handover in multiple types of super cells simultaneously. In this case, the target super cell list may be indicated in the handover request message. The network may determine the source super cell list as a super cell of the same type as the target super cell in the list.

Handover from one of a plurality of serving cells

Fig. 15 shows an example of a procedure provided by an embodiment of the invention for handover from one of the super cells with which the UE is associated to a target super cell. Handover from one serving super cell (source super cell) does not affect packet data transmission between the UE and other serving super cells. For example, a UE may be handed over from one eMBB super cell to another eMBB super cell while still maintaining its existing connections with the mtc super cell and the URLLC super cell.

Fig. 15 shows transmissions between a UE 1504, a serving super cell to be a source super cell 1506 for handover, and a super cell to be a target super cell 1508 for handover. Other serving super cells 1502 are also shown. These are other super cells 1502 that are associated with the UE 1504 but are not handed over as part of the handover procedure. The various serving super cells 1502, 1506 may each be associated with a different service/slice, for example. It should be understood that the method in fig. 15 is a very detailed example and that these specific steps do not necessarily need to be performed. Some of which may be modified or omitted.

In step 1, measurement control messages may be sent from some (one, some, or all) of the serving super cells (including the source super cell 1506 and other super cells 1502) to the UE 1504. In some embodiments, a measurement control message sent from one serving super cell controls the measurement of some or all of the serving super cells 1502, 1506. Throughout, the UE 1504 exchanges packet data with the serving super cells 1502, 1506. The measurement procedure may be configured according to context information of the UE 1504 regarding one or more super cells. For example, the context may include information about roaming and access restrictions provided at connection setup or at the last timing advance update.

In step 2, a measurement report may be sent from the UE 1504 to one or more of the serving super cells 1502, 1506. In some embodiments, the serving super cell may forward the measurement report or some of the measurement report information therein to some other serving super cell. The measurement report indicates a measurement result of the downlink radio channel obtained by the UE. The UE may be configured by the network, e.g. by RRC signaling, with the content to be measured.

For this and other embodiments described herein, there are many different possible conditions under which measurement reports are triggered. For example:

the serving cell becomes better than the absolute threshold;

the neighbor cell becomes better than the offset with respect to the serving cell; and

the neighbor cell becomes better than the absolute threshold.

The cells reported in a given measurement report may depend on the trigger. For a given service handover, at least the source cell or the target cell is needed in the measurement report.

Alternatively, for any of the embodiments described herein, the UE may transmit multiple measurement reports, each handling one type of service.

After step 2, each serving super cell may individually determine whether it needs to be handed over based on the measurement report for it. In other embodiments, the measurement report may be sent to a network function that may make the determination of whether a handover is required based on a more global picture of the network requirements, rather than an entity within a particular super-cell. In the example shown in fig. 2, one serving super cell (source super cell 1506) makes a handover decision to the UE 1504 in step 3, while the other serving super cells 1502 decide that no handover is required for the UE 1504.

Logically, a TRP of a super cell may be considered to be a set of remote antennas of one cell. These can be, for example, transmission signals generated by one BBU (which, as described above, can be a discrete entity or can be a virtualized entity within the computing resources). From the UE's perspective, it is communicating with the cell and does not need to perceive individual TRPs. In some embodiments, there is a logical entity (e.g. part of the handover manager of fig. 1 described earlier) associated with each super cell that makes handover decisions for the super cell. As discussed above, the entity may be dedicated to a single super cell or it may be associated with a plurality of different super cells.

In step 4, a handover request message is sent from the source super cell 1506 to the target super cell 1508. This may include information that may allow the target super cell 1508 to prepare for handover on the target side. In step 5, if the super-cell 1508 can grant resources, the target super-cell 1508 may perform admission control to increase the likelihood of a successful handover, e.g., based on received quality of service (QoS) information. As will be appreciated by those skilled in the art, admission control may include interacting with other network functions to perform admission control processing. The target super cell 1508 may then configure the required resources according to the received E-RAB (radio access bearer) QoS information and reserve the C-RNTI and optional Random Access Channel (RACH) preamble. The AS configuration to be used in the target cell may be specified AS an increment (i.e., "setup") independently from the AS configuration used in the source cell (i.e., "reconfiguration"), or in other ways that will be apparent to those skilled in the art.

In step 6, the target super cell 1508 prepares for HANDOVER using L1/L2 and sends a HANDOVER REQUEST ACKNOWLEDGE (HANDOVER REQUEST ACKNOWLEDGE) message to the source super cell 1506. The handover request confirm message may include a transparent container to be sent to the UE 1504 as an RRC message to perform the handover. The container may include any or all of the following: the new C-RNTI, the target super cell security algorithm identifier of the selected security algorithm, and it may comprise the dedicated RACH preamble and possibly some other parameters, i.e. access parameters, SIBs, etc. The handover request confirm message may also include RNL/TNL information for forwarding the tunnel, if necessary.

Data forwarding may be initiated after the source super cell 1506 receives a handover request acknowledge message or when a handover command is transmitted in the downlink.

In step 7, an RRC connection reconfiguration message is sent from the source super cell 1506 to the UE 1504 and this may indicate that the UE 1504 should switch from the source super cell 1506 to the target super cell 1508. This may, for example, involve the target super cell 1508 generating an RRC message sent by the source super cell 1506 to the UE 1504 to perform the handover, i.e., an RRC connection reconfiguration (RRCConnectionReconfiguration) message that includes mobility control information (mobility control information). The source super cell 1506 may perform encryption and integrity protection of the message. The UE 1504 receives an RRC connection reconfiguration message with parameters (i.e., new C-RNTI, target eNB security algorithm identifier, and optionally a dedicated RACH preamble, target eNB SIB, etc.) and is instructed by the source super cell 1506 to perform handover. After step 7, the UE 1504 detaches from the source super cell 1506 and synchronizes to the target super cell 1508. At this point, the UE 1504 is not detached from the other serving super cells 1502.

Additional steps may be performed to help avoid data loss during handoff. For example, in step 8, the source super cell 1506 may send an SN state TRANSFER (STATUS TRANSFER) message to the target super cell 1508 to convey downlink PDCP SN transmitter STATUS and uplink PDCP SN receiver STATUS of the E-RAB that Packet Data Convergence Protocol (PDCP) STATUS remains applicable (i.e., for RLCAM). The uplink PDCP SN receiver status includes the PDCP SNs of at least the first missing uplink Service Data Unit (SDU) and may include a bitmap of the reception status of out-of-order uplink SDUs (if such SDUs exist) that the UE 1504 needs to retransmit in the target cell. The downlink PDCP SN transmitter status may indicate that the target super cell 1508 assigns the next PDCP SN to a new SDU that does not already have a PDCP SN. The source super cell 1506 may omit sending the message if none of the UE 1504's E-RABs remain in process with PDCP status.

In step 9, the UE 1504 starts synchronizing to the target super cell 1508 after receiving the RRC connection reconfiguration message including mobility control information. This may involve the UE 1504 accessing the target cell 1508 via the RACH after a non-contention procedure if a dedicated RACH preamble is indicated in the mobility control information, or after a contention-based procedure if no dedicated preamble is indicated. The UE 1504 may derive the target super cell 1508 specific key and configure the selected security algorithm to be used in the target cell 1508.

In step 10, the target super cell 1508 responds by transmitting uplink allocation and timing advance information to the UE 1504.

In step 11, when the UE 1504 has successfully accessed the target cell, the UE 1504 transmits an RRC connection reconfiguration complete (rrcconnectionreconfiguration complete) message (C-RNTI) to the target super cell 1508. This message may be used to confirm the handover and may be sent to the target super cell 1508 along with an uplink buffer status report to indicate that the handover procedure of the UE 1504 has been completed. It will be appreciated that the transmission of uplink buffer status reports may not always occur, but in some embodiments it may be advantageous to transmit uplink buffer status reports where possible. The target super cell 1508 may verify the C-RNTI sent in the RRC connection reconfiguration complete message. The target super cell 1508 may now start sending data to the UE 1504.

Handover for some services in a cell

Fig. 16 shows an example of a process 1600 for handing over some service for UE 1602 from source super cell 1604 to target super cell 1606 provided by an embodiment of the present invention. In this example, the UE is acquiring multiple services in the source super cell 1604 and is handing over some, but not all, of these services to the target super cell 1606.

With this embodiment, a handover for one service (or service set) B obtained through a super cell does not affect the packet data transmission of another service (or service set) a obtained through the same super cell. For example, a UE participating in both URLLC and mtc services in a super cell may switch its mtc service to a new super cell while still transmitting traffic associated with the URLLC service to the old super cell.

In step 3, the source super cell 1604 decides to handover service B to the target super cell 1606 and not to handover service a. It is to be appreciated that this may involve network function participation in sending instructions to the source supercell 1604 to initiate a handover.

In step 4, the source supercell 1604 sends a handover request message to the target supercell 1606. The handover request message requests a handover of traffic associated with service B.

In step 7, the source super cell 1604 sends a message to the UE 1602 instructing the UE 1602 to perform a handover of traffic associated with service B (but not for service a) to the target super cell 1606.

After receiving the message in step 7, the UE 1602 synchronizes to the target cell 1606 without detaching from the source cell 1604. Packet data for service a may still be transmitted in source super cell 1604.

After performing the handover, packet data for service B is sent through the target super cell 1606.

In step 12, the target super cell 1606 sends a message to the source super cell 1604 to inform the UE 1602 that its serving B cell has been changed. This allows source supercell 1604 to release resources associated with service B.

Handover to serving cell

Fig. 17 shows an example of a process 1700 for handing over from one serving super cell to another serving super cell provided by an embodiment of the present invention. In this case, there is a UE 1702 that is acquiring a first service (or service set) B with a source super cell 1704 and is acquiring a second service (or service set) a with a serving super cell that will become a target super cell 1706 for handover to the first service set B from the source super cell 1704. As shown, the handover to service (or service set) B does not affect the packet data transmission for service (or service set) a. For example, a UE using mtc service in a source super cell and URLLC service in a target super cell may handover its mtc service to the target super cell, thereby enjoying both mtc service and URLLC service in the target super cell.

In step 3, the source super cell 1704 decides that the UE 1702 should be handed over (for serving B) to the target super cell 1706.

After receiving the message in step 7, the UE 1702 may not need to make additional synchronization to the target super cell 1706 because it has already been synchronized to the target super cell 1706 to use service a. However, if service B requires different synchronization than service a, the UE 1702 may still perform synchronization.

After performing the handover, packet data for both service a and service B is transmitted through the target super cell 1706.

In step 12, the target super cell 1706 may send a message to the source super cell 1704 to inform the source super cell 1704 that the UE 1702 has changed its serving B cell, so resources in the source super cell for serving B may be released.

Handover in uplink only

Fig. 18 shows an example of a process 1800 provided by an embodiment for handover from one super cell to another cell in the uplink without handover in the downlink. In this case, there is a UE 1802 in uplink and downlink communication with a source super cell 1804 for a first service (or service set), and there is a target super cell 1806 that is the target for handover of service from source super cell 1804 only for the uplink. A serving Gateway (GW)1808 is also shown. As shown in fig. 18, the switching of the responsibility for the uplink connection does not affect the packet data transmission of the UE 1802 in the downlink direction. For example, UE 1802 may switch its uplink mtc service to a new super cell while remaining connected to the old cell for other services (and possibly for downlink traffic for the mtc service).

In step 2, the UE 1802 sends downlink measurement reports and/or uplink reference signals (such as sounding signals) for the network to perform uplink measurements.

In step 3, the source super cell 1804 makes a decision based on the measurement result that uplink handover is required for the UE 1802 without downlink handover.

In step 4, source super cell 1804 sends an uplink handover request message to target super cell 1806. The message may indicate that uplink handover is requested without downlink handover.

In step 7, the source super cell 1804 sends a message to the UE 1802 instructing the UE 1802 to perform a handover for uplink traffic without a corresponding handover for downlink traffic.

After receiving the message in step 7, the UE 1802 synchronizes to the target super cell 1806 without detaching from the source cell.

After performing the handover, UE 1802 sends uplink packets to target super cell 1806 and receives downlink packets from source super cell 1804.

After receiving the RRC connection reconfiguration complete message from the UE 1802, the target super cell 1806 does not need to send a path switch request to the MME. The target super cell 1806 will receive the uplink packet from the UE 1802 and forward it to a gateway function such as the serving GW 1808.

In step 12, target super cell 1806 sends a message to source super cell 1804 to inform source super cell 1804 that UE 1802 has changed its uplink cell, so resources in source super cell 1804 for uplink transmissions may be released.

Handover in downlink only

Fig. 19 shows an example of a process 1900 for switching from one super cell to another super cell in the downlink without switching traffic in the uplink direction provided by an embodiment of the present invention. In this example, there is a UE 1902 that is transmitting both uplink traffic and downlink traffic associated with a first service (or set of services) with a source supercell 1904. There is a target super cell 1906 that is the target for handover only for downlink traffic associated with the first service or first set of services from the source super cell 1904. As shown, the handover in the downlink does not affect the packet data transmission of the UE 1902 in the uplink. For example, the UE 1902 may handover its downlink Multimedia Broadcast Multicast Service (MBMS) service to a new cell while it remains in the old cell for other services.

In step 2, the UE 1902 sends downlink measurement reports and/or uplink reference signals (such as sounding signals) to the source super cell 1904. These reports may be used by entities within the network to perform uplink measurements.

In step 3, the source super cell 1904 makes a decision (or is informed of a decision made by another network entity): switching the downlink of the UE 1902 should be performed without a corresponding uplink switch. The determination may be made based on the measurement results.

In step 4, the source supercell 1904 sends a downlink handover request message to the target supercell 1906. The message may indicate that a downlink handover is requested without an uplink handover.

In step 7, the source super cell 1904 sends a message to the UE 1902 instructing the UE 1902 to perform a handover of downlink traffic to the target super cell 1906 without a corresponding uplink handover.

After receiving the message in step 7, the UE 1902 starts a synchronization procedure to synchronize to the target super cell 1906 without detaching from the source super cell 1904. Uplink synchronization and Tracking Area (TA) adjustment may not be required in all instances because the UE 1902 does not need to send uplink packets in the target cell.

After performing handover, the UE 1902 sends downlink packets to the target super cell 1906 and receives uplink packets from the source super cell 1904.

In step 12, the target super cell 1906 sends a message to the source super cell 1904 to inform the UE 1902 that its downlink cell has changed, so resources in the source super cell 1904 for downlink transmissions may be released.

Fig. 15 to 19 show procedures applicable to uplink handover within MME/S-GW. In some embodiments, the MME connects to multiple super cells and controls handovers within the MME and functions as the super cell manager in fig. 14A. In other embodiments, these procedures are extended to cover other handover scenarios, such as inter-MME uplink handover and inter-Serving Gateway (SGW) uplink handover without downlink handover. The SGW (not shown in fig. 14) may be connected to multiple handover managers/MMEs. In these cases, the handover of some services does not affect the packet data transmission of other services.

In some embodiments, for an inactive UE, the UE may send a signal to let the network know whether the UE is moving into another super-cell. The network may then assign it a new connection ID as needed. This connection ID may be used to authorize-free transmissions to identify the UE or to generate uplink reference signals to avoid collisions or interference in the super cell. Two possible ways for the UE to obtain a new connection ID for the target super cell include:

a. and generating a connection ID according to the cell ID of the target super cell. For example, the connection ID of a UE may be associated with both the UE ID and the cell ID of the super cell serving it. In this case, the connection ID may naturally change as the UE moves into a new super cell; and

b. the new connection ID in the target super cell allocated by the network for the UE is used. For example, the UE may send a message to the network indicating the cell ID of the target super cell and then receive a message from the network allocating a new connection ID for the UE.

In one embodiment, the UE transmits an uplink reference signal for detection by the network. The network may decide whether the UE should be served by another super cell based on the measurement results of one or more access points in the super cell. If the network decides to use another super cell to serve the UE, it may send a message to inform the UE of the target super cell with which the UE should be associated (in some embodiments, the message will include the ID of the selected super cell). The message may contain the new connection ID used by the UE in the target super cell. The message may also indicate the conditions under which the new connection ID applies. For example, it may indicate that the new connection ID should be applied: when the Reference Signal Received Power (RSRP) of the source super cell is below a threshold, when the Reference Signal Received Quality (RSRQ) of the target super cell is above a threshold, or when a timer times out, or any combination thereof. The message may also indicate the ID of the target super cell that may use the new connection ID.

When the UE is served by multiple super cells, the message sent by the network to the UE may also indicate which of these super cells should no longer be used. The indication may be explicit, for example by indicating in a message the connection ID or source super cell to release. The indication may also be implicit, for example by sending a message from the source super cell to the UE.

In another embodiment, the UE sends a message to the network to request a new connection ID or indicate that it is moving to another super cell. Such messages may be triggered by predefined or network-indicated conditions. Which may contain the ID of the target super cell. The network may respond with a message to indicate the connection ID that the UE may use in the target super cell. The new connection ID may be the current connection ID (if there is no conflict in the target super cell), a new connection ID derived by the UE according to a certain rule (e.g. according to the ID of the target super cell), or a new connection ID assigned in the message.

When the UE is served by multiple super cells, the message sent by the UE to the network may also indicate which of these super cells is the source super cell. The indication may be explicit, for example by indicating in a message the connection ID to release or the source super cell. The indication may also be implicit, for example by sending information to the source super cell.

As noted above, fig. 8 is a schematic diagram of an exemplary simplified processing system 400. As discussed above, the processing system 400 may be used to implement the methods and systems disclosed herein as well as the exemplary methods described below. The UE, access point, super cell manager, and handover manager may be implemented using exemplary 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. 7 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, microprocessor, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), special purpose logic circuitry, or a combination thereof. The processing system 400 may also include one or more 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. The network interface 415 may include a wired link (e.g., an ethernet cable) and/or a wireless link (e.g., one or more antennas) for intra-network and/or inter-network communication. 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. 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 or non-volatile memory such as flash memory, Random Access Memory (RAM), and/or Read Only Memory (ROM). The non-transitory memory 425 may store instructions for execution by the processing device 405, e.g., to implement examples as 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.

There may be a bus 430 that provides 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. In fig. 8, input devices 435 (e.g., keyboard, mouse, microphone, touch screen, and/or keypad) and output devices 440 (e.g., display, speakers, and/or printer) are shown external to processing system 400. 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.

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.

Fig. 20 is a flow chart illustrating a method 2000 for execution at a UE. Those skilled in the art will appreciate that the method 2000 may be used by a UE in interacting with a super-cell handover command. In step 2002, the UE communicates with a first super cell. The communication is for carrying traffic associated with the first service. In some embodiments, both uplink and downlink traffic are transmitted through the first super cell, while in other embodiments only one of the two is transmitted through the first super cell. In step 2004, the UE communicates with a second super cell for transmissions associated with a second service. Again, it may be both uplink and downlink, or it may be only unidirectional traffic. In step 2006, the UE receives a handover instruction. The instructions may be the result of decisions made by the network components or functions based on a variety of different inputs, which may include any or all of traffic reports from the UE, loading information from infrastructure elements, and other data that will be understood by those skilled in the art to be relevant to cell loading and handover decisions. The handover instruction received in step 2006 instructs the UE to handover at least one of uplink traffic and downlink traffic associated with the first service to the third super cell. In the case where only uplink traffic or only downlink traffic is transmitted with the first super cell, the instructions will be related to that traffic. In the case where both uplink and downlink traffic are transmitted, either or both of the uplink and downlink traffic may be associated with the instruction. In response to receiving the instruction in 2006, the UE performs the indicated handover in step 2008 without initiating a handover of traffic associated with the second service.

Those skilled in the art will recognize that in some embodiments, the first super cell and the second super cell may be the same super cell, in which case communications for both services are transmitted over the same super cell, and after handover, traffic associated with the first service is transmitted in a different super cell than traffic associated with the second service. In other embodiments, the first and second super-cells are different, but the third cell may be the same as the second cell. This has the effect of moving traffic associated with both services to the same cell.

In other embodiments, in step 2002, the first super cell may have been used to carry both uplink traffic and downlink traffic associated with the first service, but after performing step 2008, only one of the uplink traffic and the downlink traffic is transferred to the third cell. In other embodiments, the first super cell carries only one of uplink traffic and downlink traffic in step 2002, and after performing step 2008, both uplink and downlink traffic are carried in the third super cell.

A single handover instruction may contain information about more than one traffic flow and possibly more than one service. As an example, the handover instruction may instruct a UE that is transmitting uplink traffic and downlink traffic in the first super cell to switch uplink traffic to the third cell and downlink traffic to the fourth cell while leaving traffic associated with the second service in the second super cell. In another embodiment, instructions may be received to switch uplink traffic associated with both the first and second services (carried in the first and second super cells, respectively) to a third cell while leaving downlink traffic in the respective super cells.

It should be appreciated that the ability of the network to provide a sliced RAN may allow the network to provide multiple different super cells in each slice. Then, a UE that can connect to multiple different slices can connect to multiple different super cells (per serving per super cell connection model). The handover procedure may then require that the UE be able to handle each slice of connections individually, resulting in being able to experience handovers between different super cells independently. The ability to further decouple the uplink and downlink connections associated with a service also allows greater flexibility.

While the present invention has been described with reference to illustrative embodiments, this description is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to the description. It is therefore intended that the appended claims cover any such modifications or embodiments.

Claims (11)

1. A method in a UE, comprising:

communicating with at least one first serving cell to transmit or receive each of a plurality of packet flows, wherein each of the at least one serving cell is a super cell comprising a plurality of access points, for each of at least one service, an uplink communication for the service comprises one of the plurality of packet flows, or a downlink communication for the service comprises one of the plurality of packet flows, or an uplink communication for the service comprises one of the plurality of packet flows and a downlink communication for the service comprises one of the plurality of packet flows;

transmitting at least one measurement report or transmitting a reference signal;

completing a handover from one of the at least one first serving cell to a target serving cell for at least one of the plurality of packet flows in response to the instruction;

continuing to communicate with one of the at least one first serving cell to transmit or receive one of the plurality of packet streams after the handover,

wherein:

communicating with at least one first serving cell comprises: communicating with a first cell for a first service and for a second service;

transmitting at least one measurement report or transmitting a reference signal comprises: transmitting a measurement report for at least one of the first cell and a second cell;

the method further comprises the following steps: receiving a control message including the instruction indicating that the UE should be handed over from the first cell to the second cell for the second service;

wherein:

completing the handover comprises: completing handover to the second cell for the second service without detaching from the first cell;

continuing to communicate includes: continuing to communicate with the first cell for the first service.

2. The method of claim 1, wherein the handover is a handover within a mobility management entity/serving gateway.

3. The method of claim 1, wherein the handover is an inter-mobility management entity/serving gateway handover.

4. The method of any of claims 1 to 3, comprising:

while in the inactive state, the UE transmits a signal to cause a network to determine that the UE is moving into a new cell;

the UE receives a message indicating a cell ID of the new cell.

5. The method of claim 4, wherein transmitting signals while in the inactive state comprises transmitting uplink reference signals for detection by the network.

6. The method of claim 4, wherein the message includes a new connection ID for the UE to use in the new cell.

7. The method of claim 6, wherein the message indicates a condition for the new connection ID to be applied.

8. The method of claim 4, wherein the message further indicates that at least one of a plurality of serving super cells should no longer be used.

9. A method in an access network comprising a plurality of cells, each cell comprising at least one access point, the method comprising:

communicating with a UE with at least one first serving cell of the plurality of cells to transmit or receive each of a plurality of packet flows, wherein each cell of the at least one first serving cell is a super cell comprising a plurality of access points, and for each service of at least one service, an uplink communication for the service comprises one of the plurality of packet flows, or a downlink communication for the service comprises one of the plurality of packet flows, or an uplink communication for the service comprises one of the plurality of packet flows and a downlink communication for the service comprises one of the plurality of packet flows;

receiving at least one measurement report or receiving a reference signal;

transmitting instructions to the UE to complete a handover from one of the at least one first serving cell to a target serving cell of the plurality of cells for at least one of the plurality of packet flows;

continuing to communicate with the UE, after the handover, using one of the at least one first serving cell to transmit or receive one of the plurality of packet streams,

wherein:

communicating with the UE using the at least one first serving cell comprises: communicating with a UE for at least a first service and a second service in a first cell of the plurality of cells;

receiving at least one measurement report or receiving a reference signal comprises: receiving at least one measurement report at the first cell for at least one of the first cell and a second cell;

the method further comprises the following steps:

the first cell making a decision to switch to the second cell for the second service but not to perform a switch to the first service;

wherein transmitting the instruction comprises: the first cell transmitting a control message indicating that the UE should be handed over from the first cell to the second cell for the second service; and is

The method further comprises the following steps: completing a handover from the first cell to the second cell for the second service;

wherein continuing to communicate comprises: continuing to communicate with the UE for the first service.

10. The method of claim 9, wherein the control message indicates to the UE a message to perform a handover for the second service but not the first service.

11. A user equipment comprising a processor and a memory for storing instructions that, when executed, implement the method of any one of claims 1 to 8 by the processor.

Images