Systems and Methods for Determining Air Interface Configuration
Systems and methods are provided for configuring an air interface between a UE and an access point for one or more radio access network slices or services. The access point may transmit an indication of an option for each of a plurality of air interface building blocks to use for each service/slice. Methods are provided to address a situation where there are multiple options.
This application is a continuation of PCT Application No. PCT/CN2016/109052 filed Dec. 8, 2016, which claims priority to U.S. patent application Ser. No. 15/356,124 filed Nov. 18, 2016 and to U.S. Provisional Application No. 62/264,629 filed Dec. 8, 2015, all of which applications are hereby incorporated herein by reference.
TECHNICAL FIELDThe present invention relates to slicing of Radio Access Networks and creating end to end network slices in wireless networks.
BACKGROUNDIn designing mobile networks, an architecture has arisen in which the network can be divided into a Core Network (CN) and a Radio Access Network (RAN). The RAN provides wireless communication channels to User Equipment (UE), while the CN is typically comprises of nodes and functions making use of fixed links. In the RAN, fronthaul and backhaul connections often rely on wired connections, although some wireless connections (typically between fixed points) are present. The RAN has different requirements and issues to address than the CN.
With planning for next generation networks, and researching techniques that can enable such networks, network slicing has drawn attention for the benefits that it can provide in the CN. When combined with such techniques as Network Function Virtualization (NFV) and Software Defined Networking (SDN), network slicing can allow for the creation of Virtual Networks (VNs) atop a general pool of compute, storage and communications resources. These VNs can be designed with control over in-network topology, and can be designed with traffic and resource isolation so that traffic and processing within one slice is isolated from traffic and processing demands in another slice. By creating network slices, isolated networks can be created with characteristics and parameters specifically suited to the needs of the traffic flows intended for the slice. This allows for a single pool of resources to be divided up to service very specific and disparate needs, without requiring that each slice be able to support the demands of the services and devices supported by other slices. Those skilled in the art will appreciate that a CN that has been sliced, may appear to the RAN as a plurality of core networks, or there may be a common interface, with each slice identified by a slice identifier. It should also be understood that while a slice may be tailored to the traffic patterns of the flows that it is intended to carry, there may be multiple services (typically with similar requirements) carried within each slice. Each of these services is typically differentiated by a service identifier.
In creating a sliced core network, it should be understood that typically the resource pool that is being drawn upon for slice resources is somewhat static. The compute resources of a data center are not considered to be dynamic on a short term basis. The bandwidth provided by a communications link between two data centers, or between two functions instantiated within a single data center does not typically have dynamic characteristics.
The topic of slicing within a Radio Access Network, has arisen in some discussions. RAN slicing poses problems not encountered with slicing in the CN. Issues associated with dynamic channel quality on the radio link to the UE, provision of isolation for transmissions over a common broadcast transmission medium, and how RAN and CN slices interact, have to be addressed to usefully enable Ran slicing in mobile wireless networks.
In Third Generation and Fourth Generation (3G/4G) network architecture, a base station, base transceiver station, NodeB, and evolved NodeB (eNodeB) have been the terms used to refer to the wireless interface to the network. In the following, a generic Access Point is used to denote the wireless edge node of the network. An Access Point will be understood to be any of a Transmission Point (TP), a Receive Point (RP) and a Transmit/Receive Point (TRP). It will be understood that the term AP can be understood to include the above mentioned nodes, as well as their successor nodes, but is not necessarily restricted to them.
Through the use of SDN and NFV, functional nodes can be created at various points in the network and access to the functional nodes can be restricted to sets of devices, such as UEs. This allows what has been referred to as Network Slicing in which a series of virtual network slices can be created to serve the needs of different virtual networks. Traffic carried by the different slices can be isolated from the traffic of other slices, which allows for both data security and easing of network planning decisions.
Slicing has been a used in core networks due to 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 a common resource which has made traffic isolation effectively impossible. The benefits of network slicing in the Radio Access Network are numerous, but the technical obstacles to designing and implementing an architecture have resulted in a lack of network slicing at the radio edge.
SUMMARYAccording to an example aspect, the present disclosure describes methods and systems of allocating resources in a radio access network (RAN) that includes associating each of a plurality of services with a slice that is allocated a unique set of network resources, and transmitting information in the RAN for at least one of the services using the slice associated with the at least one service.
According to a further aspect is a method for execution by an access point (AP) within a radio access network (RAN). The method includes receiving data for transmission to a User Equipment (UE), and wirelessly transmitting the received data to the UE using a set of transmission parameters associated with a RAN slice associated with the received data. In some example embodiments, the RAN slice associated with the received data is selected from a set of RAN slices supported by the AP. Furthermore, the RAN slice may be selected in accordance with a RAN slice identifier associated with the received data. In some configurations, the transmission parameters are selected in accordance with the selected RAN slice. In some embodiments, the set of transmission parameters are selected in accordance with an address of a gateway between the RAN and a core network. In some embodiments, the set of transmission parameters are selected in accordance with one of a core network identifier, a core network slice identifier and a service identifier associated with the received data. In some examples, at least one parameter in the set of transmission parameters is selected from a list comprising: radio frequency/time resources; a radio access technology; a transmission waveform; a frame length; and a numerology.
According to a further aspect, there is provided a network access point (AP) for transmitting data to a User Equipment (UE) over a radio channel in a radio access network (RAN). The AP includes a network interface for receiving data from a radio access network; a wireless network interface for transmitting data to the UE; a processor; and a non-transient memory for storing instructions. The instructions, when executed by the processor cause the network access point to: transmit data to the UE over the wireless network interface using a set of transmission parameters associated with a RAN slice, in response to receipt of the data for transmission to the UE over the network interface. In some example embodiments, the non-transient memory further stores instructions to select the transmission parameters in accordance with an address of a gateway from which the data is received. In some example embodiments, the non-transient memory further stores instructions to select at least one transmission parameter in the set in accordance with a RAN slice identifier associated with the data. In some configurations, the non-transient memory further stores instructions to select at least one transmission parameter in the set in accordance with one of a core network identifier, a core network slice identifier and a service identifier associated with the data. In some examples, at least one parameter is the set of transmission parameters is selected from a list comprising: radio frequency/time resources; a radio access technology; a transmission waveform; a frame length; and a numerology.
According to another aspect is a method for execution by a routing function in a radio access network (RAN), which includes receiving data traffic from a core network destined for a User Equipment (UE), and transmitting the received data traffic to a transmission point within a selected RAN slice associated with the received data traffic. In some configurations, the RAN slice associated with the received data traffic is selected in accordance with one of: an identifier associated with the core network; an identifier associated with a slice of the core network associated with the received data; and a service identifier associated with the received data. In some examples, the identifier associated with one of the core network and the slice of the core network is one of an address of a core network gateway function and a tunnel identifier. In various examples, receiving the data traffic includes one or more of receiving the data traffic from a gateway function within the core network and/or receiving the data traffic from a core network slice that the RAN slice can be pre-associated with. In some examples, the transmission point within the RAN slice is selected in accordance with information about the location of the UE with respect to the network topology. In some example embodiments, the method includes selecting a transmission point uniquely associated with the UE, and determining a set of constituent access points associated with the transmission point; wherein transmitting the received data comprises transmitting the received data to the set of constituent access points. In some examples, the step of transmitting includes modifying the received data to include a RAN slice identifier associated with the selected RAN slice prior to transmitting the data to the transmission point.
According to another aspect is a router for use in a radio access network (RAN) which includes a network interface for receiving and transmitting data, a processor, and a non-transient memory for storing instructions. When executed by the processor, the instructions cause the router to: transmit data traffic, over the network interface, to a transmission point associated with a selected RAN slice within the RAN, in response to receiving data traffic destined for a User Equipment (UE) over the network interface. In some examples, the instructions cause the router to select the RAN slice in accordance with one of an identifier associated with the core network; an identifier associated with a slice of the core network associated with the received data; and a service identifier associated with the received data. In some examples, the identifier associated with one of the core network and the slice of the core network is one of an address of a core network gateway function and a tunnel identifier. In some example embodiments, the instructions cause the router to select the transmission point in accordance with information about the location of the UE with respect to the network topology. In some examples, the instructions cause the router to select a transmission point uniquely associated with the UE; determine a set of constituent access points associated with the selected transmission point; and transmit the data to the transmission point by transmitting the data to the set of constituent access points. In some examples, the instructions cause the router to modify the received data prior to transmission to the transmission point to include a RAN slice identifier associated with the selected RAN slice.
In at least some example embodiments the methods and systems described can facilitate network slicing in a radio access network, providing benefits that include one or more of efficient use of RAN resources, isolation within in the RAN of different services, virtualization of RAN resources, and coordination of virtualized resources between the RAN and the Core network.
According to one aspect of the present invention, there is provided a method for an access point in an access network comprising: communicating with a first user equipment (UE) with a first air interface configuration for a first service; and communicating with a second UE with a second air interface configuration for a second service; wherein the first service is in a first slice differentiating from a second slice for the second service in the access network.
In some embodiments, the first and second services include at least one of an eMBB service, a URLLC service, an mMTC service, a video service, a voice service, a gaming service, a V2X service, an emergency service.
In some embodiments, the first and second air interface configurations are respectively in association with different numerologies.
In some embodiments, the method further comprises for the first service, broadcasting information indicating at least one option supported by the access point for each of a plurality of air interface building blocks; wherein communicating with the first user equipment with the first air interface configuration for the first service comprises: transmitting to the first UE and/or receiving from the first UE using the first air interface configuration composed of air interface building blocks set to options supported by both the access point and the first UE.
In some embodiments, broadcasting information comprises using an air interface in which at least one building block is set to a default value.
In some embodiments, broadcasting information comprises using an interface in which at least one building block is not set to a default value.
In some embodiments, broadcasting information comprises: for each building block, transmitting a respective index for each of the options supported by the access point.
In some embodiments, the method further comprises receiving an indication of UE type or capability from the first UE, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks; wherein transmitting to the first UE and/or receiving from the first UE using the first air interface configuration composed of air interface blocks building blocks set to options supported by both the access point and the first UE comprises: where the UE type or capability is associated with support for only one option for a given building block, setting the option of the given building block to the one option.
In some embodiments, the method further comprises receiving an indication of UE type or capability from the first UE, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks; wherein transmitting to the first UE and/or receiving from the first UE using the first air interface configuration composed of air interface building blocks set to options supported by both the access point and the first UE comprises: where the UE type or capability is associated with support for two or more options for a given building block, receiving an indication from the first UE of a selected one of the two or more options and transmitting and/or receiving with the given building block according to the selected one of the two or more options; OR where the UE type or capability is associated with support for two or more options for a given building block, selecting one of the two or more options for the given building block, and transmitting an indication to the first UE of the selected one of the two or more options.
In some embodiments, for at least one service, transmitting and/or receiving comprises setting an option for at least air interface one building block to a default value for the service.
In some embodiments, the method further comprises broadcasting information comprising an index of a respective option for each of at least one building block of the first air interface configuration, each building block having a predefined set of possible options each having an index, wherein communicating with the first user equipment with the first air interface configuration for the first service comprises transmitting to the first UE and/or receiving from the first UE using the first air interface configuration in accordance with the broadcast information.
In some embodiments the set of building blocks, and/or the set of available options for a given building block is dependent on frequency band or system bandwidth.
In some embodiments, the method further comprises when downlink data arrives or when a session initiates, transmitting a signal or message indicating a service of the first and second services used for the transmission or session, and transmitting the data using the indicated service; or transmitting the downlink data using a service of the first and second services, the transmission implicitly indicating the service used for the transmitting.
In some embodiments, the method further comprises transmitting downlink control information in a control channel to schedule a transmission, and including in the control information an indication of which service to use for the transmission.
According to another aspect of the present invention, there is provided a method in a user equipment in an access network comprising: communicating with a first access point (AP) with a first air interface configuration for a first service; communicating with a second AP with a second air interface configuration for a second service; and wherein the first service is in a first slice differentiating from a second slice for the second service in the access network.
In some embodiments, the first and second services include at least one of an eMBB service, a URLLC service, and an mMTC service.
In some embodiments the first AP and the second AP are same AP.
In some embodiments the first and second air interface configuration are respectively in association with different numerologies.
In some embodiments, the method further comprises for the first service, receiving broadcast information indicating at least one option supported by the first access point for each of a plurality of air interface building blocks; wherein communicating with the first access point with the first air interface configuration for the first service comprises transmitting to the first access point and/or receiving from the first access point using the first air interface configuration composed of air interface building blocks set to options supported by both the access point and the UE.
In some embodiments, receiving the broadcast information comprises using an air interface in which at least one building block is set to a default value.
In some embodiments, receiving the broadcast information comprises using an air interface in which at least one building block is not set to a default value, and using blind detection to select a value for each of the at least one building block.
In some embodiments, receiving broadcast information comprises: for each building block, receiving a respective index for each of the options supported by the first access point.
In some embodiments, the method further comprises transmitting an indication of UE type or capability to an access point, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks.
In some embodiments, the method further comprises transmitting an indication of UE type or capability to the first access point, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks; where the UE type or capability is associated with support for two or more options for a given building block, transmitting an indication to the first access point of a selected one of the two or more options.
In some embodiments, the method further comprises receiving broadcast information comprising an index of a respective option for each of at least one building block of the first air interface configuration, each building block having a predefined set of possible options each having an index; wherein communicating with the first access point with the first air interface configuration for the first service comprises transmitting to the first access point and/or receiving from the first access point using the first air interface configuration in accordance with the broadcast information.
In some embodiments, the method further comprises receiving a signal or message indicating a service of the first and second services used for a downlink transmission or session; OR receiving a downlink transmission using a service of the first and second services, the transmission implicitly indicating the service used for the transmission.
In some embodiments, the method further comprises receiving uplink scheduling information on a control channel to schedule an uplink transmission, and scheduling information including an indication of which service to use for the uplink transmission.
According to still a further aspect of the present invention, there is provided a method in a user equipment comprising: transmitting an indication of an air interface configuration to use for uplink transmission and/or for downlink transmission; transmitting an uplink transmission or receiving a downlink transmission using the indicated air interface configuration.
According to yet a further aspect of the present invention, there is provided selecting at least one option for an air interface configuration to use for a grant-free uplink transmission; transmitting the grant-free uplink transmission using the selected at least one option for the air interface configuration, the transmission including an implicit indication of at least one option for the air interface configuration.
In some embodiments, selecting the at least one option for the air interface configuration includes selecting a numerology, and transmitting using the selected numerology implicitly indicates the selected numerology.
In some embodiments, selecting the at least one option for the air interface configuration includes selecting a numerology, and wherein transmitting using wireless resources corresponding with the selected numerology implicitly indicates the selected numerology.
According to another aspect of the present invention, there is provided an access point configured to implement one of the methods summarized above or described herein.
According to yet another aspect of the present invention, there is provided a user equipment configured to implement one of the methods summarized above or described herein.
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 drawing, in which:
Software Defined Networking (SDN) and Network Function Virtualization (NFV) have been used to enable network slicing in a physical core network. Network slicing involves allocating resources, such as compute, storage, and connectivity resources, to create otherwise isolated virtual networks. From the perspective of a network entity inside a slice, the slice is a distinct and contained network. Traffic carried on a first slice is invisible to a second slice, as are any processing demands within the first slice. In addition to isolating networks from each other, slicing allows for each slice to be created with a different network configuration. Thus, a first slice can be created with network functions that can respond with very low latency, while a second slice can be created with very high throughput. These two slices can have different characteristics, allowing for the creation of different slices to service the needs of specific services. A network slice is a dedicated logical (also referred to as virtual) network with service specific functionalities, and can be hosted on a common infrastructure with other slices. The service specific functionalities associated with a network slice can, for example, govern geographical coverage areas, capacity, speed, latency, robustness, security and availability. Traditionally, network slicing has been limited to the core network, in view of the difficulties in implementing slicing in a Radio Access Network (RAN). However example embodiments will now be described for implementing RAN slicing. In at least some examples, RAN slicing and network core slicing are coordinated to provide end-to-end slicing that can be used to provide service-specific network slices extending across the entire core network and RAN communications infrastructure.
Radio resources allocated to a RAN are typically a set of wireless network rights granted to a network operator which may include for example one or more specified radio frequency bandwidths within one or more geographic regions. A network operator typically enters into service level agreements (SLAs) with customers that specify the level of service that the network operator must provide. Services that are supported by a network operator can fall within a range of categories, including for example: basic mobile broadband (MBB) communications such as bi-directional voice and video communications; messaging; streaming media content delivery; ultra-reliable low latency (URLL) communications; micro Machine Type Communications (μMTC); and massive Machine Type Communications (mMTC). Each of these categories could include multiple types of services—for example intelligent traffic systems and eHealth services could both be categorized as types of URLL services. In some examples, a network slice may be assigned for a service for a group of customers (for example smart phone subscribers in the case of mobile broadband), and in some examples a network slice may be assigned for a single customer (for example, an organization that is providing intelligent traffic systems).
An interface between the core network 130 and RAN 125 is provided to allow traffic from CN 130 to be directed towards UEs 110 through access points (APs) 105, which may be base stations, such as an evolved Node B (eNB) in the Long-Term Evolution (LTE) standard, a 5G node, or any other suitable nodes or access points. APs 105, also referred to as Transmit/Receive Points (TRPs), may serve a plurality of mobile nodes, generally referred to as UEs 110. As noted above, in the present description access point (AP) is used to denote the wireless edge node of the network. Thus, the APs 105 provide the radio edge of RAN 125, which may for example be a 5G wireless communication network. The UEs 110 may receive communications from, and transmit communications to, the AP's 105. Communications from the APs 105 to the UEs 110 may be referred to as downlink (DL) communications, and communications from the UEs 110 to the APs 105 may be referred to as uplink (UL) communications.
In the simplified example shown in
In example embodiments, the core network 130 includes a core network slice manager 140 for implementing (and optionally managing) core network slicing. As shown in
Next generation wireless networks (e.g. fifth generation, or so-called 5G networks) are likely to support a flexible air interface in RAN 125 that allows for the use of different waveforms, and different transmission parameters of each of the waveforms (e.g. different numerology for some of the supported waveforms), different frame structures, as well as different protocols. Similarly, to take advantage of a large number of APs 105, which may take the form of both macro and pico-cell sized transmission points operating in different frequency bands, it is possible that a 5G network will group a series of APs 105 to create a virtual transmission point (vTP). The coverage area of a vTP may be referred to by some as a hyper-cell. By coordinating the transmission of signals from the APs 105 in the virtual TP, the network 125 can improve capacity and coverage. Similarly, a grouping of APs 105 can be formed to create a virtual receive point (vRP) that allows for multipoint reception. By varying the APs 105 in the virtual groups, the network 100 can allow the virtual TP and RP associated with an UE 110 to move through the network.
From the perspective of a network operator, deploying network infrastructure can be very expensive. Maximizing the utilization of the deployed infrastructure, and the wireless resources, is of importance to allow network operators to recover their investments. The following disclosure provides systems and methods for enabling network slicing at the radio edge of RAN 125, and for facilitating routing of traffic between slices of the radio edge of RAN 125 and core network 130, which may also be sliced. In some examples, this can enable an end-to-end network slice, and allows network operators to then divide the network and provide service isolation in wireless connections within a single network infrastructure.
Referring to
radio resources, which include:
wireless network frequency and time (f/t) resources 158, and spatial resources based on the geographic placement of APs 105 associated with the slice and based on the directionality of transmissions if advanced antenna technologies are applied; and
radio air interface configurations 160 that specify how the radio resources and the access resources interface with each other.
The radio air interface configuration 160 can, for example, specify attributes in one or more of the following categories: the radio-access technology 162 to be used for the slice (e.g. LTE, 5G, WiFi, etc.); types 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.); numerology parameters 166 for the specified waveforms (e.g. subcarrier spacing, transmission time interval length (TTI), cyclic prefix (CP) length, etc.); frame structures 165 (e.g. UL/DL partition configuration for TDD system), applicable multiple-input-multiple-output (MIMO) parameters 168; multiple access parameters 170 (e.g. grant/grant free scheduling); coding parameters 172 (e.g. type of error/redundancy coding scheme); and functionality parameters for APs and UEs (e.g. parameters governing AP handover, UE retransmission, UE state transition, etc.). It will be appreciated that not all embodiments may include the entire list of radio transmission functions describe above, and in some cases there may be overlap in some of the categories stated above—for example a specific waveform may be inherently defined by a specified RAT.
In example embodiments, the RAN slice manager 150 manages the allocation of RAN resources for the specific RAN slices 152 and communicates with resource allocation manager 115 and scheduler 120 to implement service specific RAN slices 152 and to receive information about RAN resource availability. In example embodiments, the RAN slice manager defines the RAN resources for RAN slices 152 based on slicing requirements received from the core network 130, and in particular the core network slice manager 140.
RAN slices are each instances that can be set up and maintained for varying durations, ranging from long term instances that may be set up and maintained indefinitely, to temporary RAN slice instances that may last only momentarily for a specified function.
In example embodiments, RAN slice manager 150 is configured to implement RAN slicing to affect one or more of the following functions: service isolation within a carrier, dynamic radio resource allocation taking slices into account, a mechanism for a radio access network abstraction, per-slice based cell association, a handover mechanism at the physical layer and a per-slice state machine. Those skilled in the art will appreciate that this list is neither exhaustive nor is it essential to have all the features to provide RAN slicing. RAN slicing in respect of these functions will now be described in greater detail.
In at least some examples, the RAN slices 152 are each associated with a specific service. In another embodiment, any or all of the RAN slices 152 can carry traffic associated with a set of services. Services which would require a RAN slice 152 with similar parameters and characteristics can be grouped together on a single slice to reduce the overhead of creating distinct slices. The traffic associated with the different services can be differentiated through the use of service identifiers, as will be well understood. As illustrated in
Accordingly, those skilled in the art will appreciate that although slices can be differentiated by the allocated by radio time/frequency resources 158, they could also be differentiated by the assigned air interface configuration 160. For example, by allocating different code based resources 172, different slices can be maintained separately. In access technologies that make use of different layers, such as Sparse Code Multiple Access (SCMA), different layers can be associated with different slices. Slices may be separated from each other in a time domain, a frequency domain, a code domain, a power domain, or special domains (or any combination of the above).
In some embodiments, allocating a set of time/frequency resource pairings 158 to the slice allows the traffic intended for the slice to be transmitted over dedicated radio resources. In some embodiments, this could include the allocation of an entire frequency band at fixed time intervals to a slice, or it could include allocation of a dedicated subset of the available frequencies to the slice at all times. Both of these can provide service isolation, but they may be somewhat inefficient. Because such a scheduling of resources is typically predefined, there may be long periods of time between redefinition of the resources during which the allocated resources are not fully used. The redefinitions cannot be too frequent if there are devices that have long periods of being idle, or these devices would have to frequently re-connect to the network to obtain this information. Accordingly, in example embodiments, service isolation over a common carrier (for example within the same carrier frequency) allows independent co-existence of multiple services within the same carrier. Physical and other resources can be dedicated on slice by slice basis within a set of dedicated slice resources. As noted above, in 5G networks, it is anticipated that a number of different protocols and waveforms, some of which may have a number of different numerologies, can be supported.
In some examples, resource allocation manager 115 includes a slice-aware air interface configuration manager (SAAICM) 116 that controls AP 105s based on the air interface configuration assignments made to the RAN slices 152 by RAN slice manager 150, thus allowing a waveform and numerology to be dedicated to a slice 152. All nodes (AP's 105 or UEs 110) transmitting data in the slice are then allocated transmission resources by network scheduler 120, based on the network f/t resource parameter set assigned by at least one of RAN slice manager 150, and the nodes transmitting within the allocated AP resources 154 and UE resources 156. This allows a network entity or entities such as the RAN slice manager 150 and resource allocation manager 115 to adjust the resource allocation dynamically, as discussed in greater detail below. The dynamic adjustment of resources allocations allows a slice 152 to be provided a minimum level of service guarantee without requiring that the resources used to provide this level of service are dedicated exclusively to the slice. This dynamic adjustment allows resources that would otherwise be unused to be allocated to other needs. Dynamic dedication of the physical resources may allow a network operator to increase the usage of the available nodes and wireless resources. A network entity or entities, such as the RAN slice manager 150 and resource allocation manager 115 can assign parameters to each slice based on the requirements of the service supported by that slice. In addition to the service isolation discussed above, the generation of a slice specific to a service (or a class of services) allows for the RAN resources to be tailored to the supported services in some embodiments. Different access protocols can be offered for each slice, allowing for example, different acknowledgement and re-transmission schemes to be employed in each slice. A different set of Forward Error Correcting (FEC) parameters can also be set for each slice. Some slices may support grant free transmissions, while others will rely on grant based uplink transmissions.
Accordingly, in some example embodiments the RAN slice manager 150 is configured to enable service isolation by differentiating the air interface configuration 160 for each service-centric RAN slice 152. In at least some examples, the differentiation amongst the attributes of different air interface configurations 160 assigned by the RAN slice manager 150 to different RAN slices 152 can provide service isolation even when the other RAN slice parameter sets (for example one or more of the AP set 154, UE set 156, and Network f/t set 158) are similar.
Specifically, in the example of
In some examples, the different transmission function 160 parameters allocated to the different RAN slices may sufficiently distinguish the different services such that the RAN slices can be implemented in overlapping frequencies in overlapping times. However, in some embodiments, time differentiation may also be required, which may for example be implemented by scheduler 120.
In some example embodiments, service isolation can also be implemented through differentiation in the access resources allocated to different RAN slices. For example, the AP set 154 assigned to different RAN slices 152 can be sufficiently different that geographic isolation occurs. Also, as noted above, different network frequency/time resources 158 can be used to isolate different RAN slices.
In example embodiments, the parameters set for RAN slice instances can be dynamically varied based on real-time network demands and available resources. In particular, in example embodiments, RAN slice manager 150 is configured to monitor the real-time demands and available resources across RAN 125 and the RAN slices 152 and based on the monitored information and the performance requirements defined for specific services (for example the performance requirements set out in an SLA), the RAN manager 150 can re-define the allocations it has made in respect of the slices.
Radio f/t resources can be viewed as two dimensions in a resource lattice. In
One skilled in the art will appreciate that resources can be allocated to slices 152 to account for the very different traffic profiles that different slices may have. For example, mobile broadband (MBB) connections are sporadic, but very high volume, while Machine Type Communications (MTC) devices typically generate traffic profiles that have a large number of devices communicating small amounts of data at fixed intervals, or in response to an event, and devices connecting to a URLLC service generate high volume traffic that may be quite consistent over the limited time period in which they are active, and may be resource intensive due to the need for both low latency and reliability. Instead of dedicating resources to either ULLRC deployments, or to massive MTC deployments, resulting in unused resources when they are not generating traffic, the resources allocated to other services, such as MBB, can be increased while the URLLC and mMTC services are not consuming their allocation of resources. An example of such a change in allocation is illustrated in
In at least some examples, RAN slices can be used to decouple UEs 110 from a physical AP 105 and provide a layer of radio access network abstraction. For example, different RAN slices 152 can be assigned different AP sets 154, such that UE 110 can maintain a first session for a first service with a first AP 105 using a first RAN slice 152(S1), and also maintain a second session for a second service with a second AP 105 using a second RAN slices 152(S2). Such a configuration allows APs that that are most suitable for the specific services to be used. It should be understood that a set of APs can be grouped together to form a virtual access point. The service area of the virtual access point can be represented as the union of the service areas of the constituent APs. The vAP can be assigned an AP identifier. The vAP can be specialized so that it is either a transmit or receive point (vTP, vRP). A plurality of different vAPs can have overlapping memberships so that each vAP is composed of a plurality of different physical APs, with some of the physical APs being part of different vAPs. Some vAPs may have identical memberships to other vAPs.
In some embodiments, the RAN slice manager 150 may be configured to allocate both logical access resources and physical access resources to a RAN slice 152. For example, with reference to
In some embodiments, various devices (UEs 110) connecting to wireless network (RAN 125) will each participate in one or more different services (e.g. ULLRC service S4, MBB service S5, mMTC service S6), and each service can be assigned a different RAN slice 152. Resource allocation manager 115 can assign different slices to each virtual TP 176 or RP 178 to be adjusted along with demand. For example, a UE 110 that supports multiple services, such as both an MBB service, and an ULLRC service used to relay information such as that generated by a heart rate monitoring service, could transmit data associated with each of these services on different slices. Each slice could be assigned different encoding formats, and may be transmitted to the respective slices using different virtual RPs 178. The UE 110 could provide an indication of the slice 152 that is being used to the RAN slice 125 when there was data to transmit.
As a UE 110 moves, it may remain connected to the same virtual transmit point/receive point TP/RP 176,178, but the physical access points (APs 105) in the virtual access point TP/RP 176,178 will change. Furthermore, as a UE 110 moves a greater distance, it may be possible that the physical AP or radio t/f resources initially used are no longer available to the RAN 125. This can happen when the UE 110 travels sufficiently far that the spectrum allocated to the slice by the carrier is no longer available, or it could happen if the network operator makes use of infrastructure owned by another entity in one area, and cannot access the same resources in another. In the latter case, it may also be that the particular waveform assigned to the slice 152 for the UE 110 to use while transmitting over the RAN 125 is no longer available. In such a case, resource allocation manager 115 can notify the UE 110 that the transmission parameters will change at a certain geographic point. This may, in some embodiments, be performed as part of a handover procedure. It should also be understood that when a virtual TP/RP 176,178, or other vAP, is associated with a UE 110 on a per-slice basis, there may be occasions in which a handover occurs for one slice, but not another. This may occur in a number of different scenarios, including ones in which a UE 110 connects to a first service provider for a first service in a defined slice, and connects to a second service provider for a second service in another defined slice. In such a scenario, it is likely that the boundaries between APs or vAPs will vary between the service providers. In a scenario in which both services are provided through the same provider (or at least access services are provided by the same provider), boundaries between APs that are slice specific may not align, which will result in a per-slice handover.
In some examples, waveform parameters 164 could be changed when a UE 110 is handed over to (or otherwise served by) a different TP 170 operating in different frequency bands. A RAN slice 152 may have two alternative TPs 176 assigned to it for serving a UE 110, with one TPs 176 operating in a high frequency band, such as the mm band, and the other TP 176 operating in a lower frequency. The switch between different frequency bands, and corresponding switch between the APs used to serve the UE 110 for the slice 152, can be dynamic depending on a scheduling decision made at scheduler 120 and implemented by resource allocation manager 115.
By having the UE 110 connect to virtual access points TP/RP 176,178, the UE 110 can be logically decoupled from the actual physical infrastructure. This can mitigate problems associated with cellular handover, and cell edge interference. Different sets of physical APs 105 can be allocated to the virtual TPs 176 and virtual RPs 178, so that different slices can be served by different sets of hardware resources. This could allow a network operator to dedicate expensive and high capacity access points to services such as MBB, and lower cost APs 105 to services such as MTC services. Additionally, allocating TPs 176 and RPs 178 as separate logical entities can be used to decouple the Uplink and Downlink data paths, which may, in some circumstances, allow for better usage of the network infrastructure. If a given RAN slice 152 is dedicated to MTC devices that generate uplink traffic at fixed intervals, but are rarely sent any downlink traffic, the slice can be served by a set of virtual RPs 178 that is designed to be more robust than virtual TPs 176. This allows for resource allocation to serve the needs of service assigned to the RAN slice 152, to a finer grained level than would be possible if APs are assigned in their entirety (as would be required in a conventional LTE network where an eNodeB would be allocated and would provide bi-directional service).
The creation of virtual TPs 176 and RPs 178 may also be referred to as the generation of a hypercell. A hypercell allows for multiple physical APs 105 to work together to serve a UE 110. The hypercell can be associated with both a UE 110 and a RAN slice 152. This allows for a UE 110 to communicate with different hypercells in each slice. Each hypercell can then be configured for the specific needs of the slice that it is associated with. For example a UE 110 may communicate with a first hypercell (TRP) in respect of one first service-centric RAN slice 152(S4), and with a second hypercell for traffic associated with a second service-centric RAN slice 152(S5). The slices that carry traffic associated with an MTC service may be directed to serving stationary MTC devices (in the case where UE 110 is an MTC device). A slice dedicated to stationary MTC devices can be designed to be stable and relatively unchanging in their membership. Other slices, such as those dedicated to mobile MTC devices, such as intelligent traffic systems devices, and other such mobile services, can be configured to accommodate greater mobility. The slice that supports stationary MTC devices may also be designed to have limited function in the mobility management function (e.g. a Mobility Management Entity), due to the limited mobility of the supported devices. It should be understood that although the use of hypercells allows for a reduction in the number of handovers, handovers may not be completely eliminated. Handovers may happen when the waveform and numerology assigned to a slice in the hypercell are not available or supported at all points along the path of a mobile UE. By requiring a handover to a new hypercell, the network may be able to ensure that the new slice specific information is transmitted to the UE 110.
As noted above, when different hypercells are used to serve different slices, a UE 110 may undergo a handover in a first RAN slice 152, without necessarily having to undergo a handover in another RAN slice 152. In some examples, RAN 125 may encompass network resources that are allocated among multiple network operators, with the different network operators each supporting different hypercells. Because they are served by different hypercells, different network operators can provide service support to the same UEs 110 for different service-based RAN slices 152. This allows network operators to provide different services, and for customers (either users or service operators) to select different network operators for different RAN slices 152 based on cost, coverage, service quality and other factors. Accordingly, in some examples, a UE 110 accesses a first service using a first RAN slice 152 that supported by a first network operator, and the same UE 110 can then access a second service using a second RAN slice 152 that supported by a second network operator.
Another example of the assignment of different access resources to different slices 152 will now be described with reference to
In example embodiments, RAN slice manager 150 will allocate one AP set (or TP/RP sets) and a corresponding RAT or set of RATs to a first RAN slice 152, and different AP set (or TP/RP sets) and corresponding RAT or set of RATs to a second RAN slice. In some examples, overlapping sets of physical or virtual access points may be allocated to each RAN slice, but with different use priorities. For example MBB service slice 152(S1) will be allocated access points 604 as its primary RAN access with macro access points 602 as a backup; conversely IoT service slice 152(S2) will be allocated only macro access points 602 for its RAN access.
As described above, in at least some examples, each RAN slice 152 will effectively operate as a distinct virtual network, indistinguishable from a physical network to most network nodes. In some embodiment, each RAN slice 152 can provide network resources tailored to the needs of the service that operates within it. This may include the provision of both data and control planes in the network 100. Each slice may be provisioned with a number of network functions that may operate as state machines. A 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 grant-based transmissions will be used for transmission (e.g. a slice that supports MBB), while another slice may allow for grant free transmission (e.g. slices that support MTC or Internet of Things (IoT) devices). It is also possible for a slice to accommodate both grant free (or contention based) and scheduled uplink transmissions. In some implementations, the differing demands on the schedulers may result in the demands on a scheduler being very sufficiently different between slices that it may be advantageous for each slice to have its own scheduling function (or set of functions). This could be provided by a single scheduler that is represented within each slice as a logical scheduling state machine. Those skilled in the art will appreciate that the access parameters, the waveform, numerology and other slice specific parameters can be managed by the different state machines in either of the UE and network entities associated with the slice. Thus, a UE that is connecting to multiple slices may serve as a platform for multiple state machines.
A UE 110 that connects to different slices may support a different set of state machines for each slice that it connects to. These state machines will preferably run simultaneously, and there may be an arbitrator to ensure that contention for access to physical resources in the UE is handled. The different state machines within a UE may result in a UE that performs both grant free and scheduling based transmissions. There may also be, within a UE, a function that serves to coordinate the operation of the plurality of state machines.
Examples of state machine enabled UEs 110 and supporting networks are described in United States Patent Publication No. US2015/0195788 A1 entitled “System and Method For Always On Connections in Wireless Communications System”, United States Patent Publication No. US 2016/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-Centric Radio Access Procedure” all of which are incorporated herein by reference. In example embodiments, the state machine related functionality described in the above documents are implemented at the UE 110 and the network on a slice by slice basis rather than on a device level basis. By way of example, in one embodiment RAN 125 and UE 110 are configured to support different operating states for UE 110 in respect of each RAN slice 152(S1) and 152(S2), with each operating state supporting different UE functionality. In particular, in one example the UE 110 is configured to implement a state machine that can transition between two different states in respect of each RAN slice 152(S1) and 152(S2), namely a first “Active” state and a second, energy economizing, “ECO” state. In example embodiments, a reduced set of radio access functionality is supported in the ECO state compared to the Active state. At least some degree of connectivity to RAN 125 is supported in both states, such that UE 104 maintains an always-on connection to the RAN 125 in respect of both RAN slice 152(S1) and second RAN slice 152(S2). In some embodiments, the UE 110 is configured to receive both grant-free and grant based transmissions in the “Active” state, but only “grant-free” transmissions in the “ECO” state, and the UE 110 uplinks status information more frequently and on a different channel in the Active state relative to the ECO state.
Accordingly, a UE 110 that supports a per slice state machine can simultaneously operate in the same state for both RAN slices 152(S1) and 152 (S2) (for example Active state for both slices or ECO state for both slices) or in different states (for example Active state for one slice and ECO state for the other slice). In example embodiments, multiple states or different numbers of states may be supported for different RAN slices 152. In example embodiments, information defining if and what states are supported in a slice are specified in the AP/UE functionality parameter set 174 (see
In another embodiment, a UE is connected to different RAN slices. The first slice can support a service such as eMBB, while the second supports a service that does not necessarily require the same level of connection reliability, such as an MTC service. While within the first slice, the UE may be in one of an Active or Idle state, within the MTC slice, the UE may be in any of an Active, Idle or ECO state. Normally, an MTC device may perform some grant-free or contention-based transmissions from an ECO state, and only enter the active state when there is a scheduled transmission window, or a pre-scheduled downlink transmission. The physical UE may allow for the MTC slice to perform transmissions without requiring transition out of an IDLE state, if it is in the active state within the eMBB slice. This can allow the MTC slice or process within the UE to take advantage of the active state of another portion of the UE.
It should be understood that although the above discussion has made reference to having a slice for each service, it may be more practical for the network to provide a limited number of slices, with each slice serving a number of different services that have sufficiently similar properties. In one example, a variety of different content delivery networks could co-exist in a single RAN slice.
In the core network, it may be possible to provide each of the network supported services with their own slice, and have this slice associated with a corresponding RAN slice such that end-to end slice management can be carried out under the control of slice manager 130. In this regard,
In embodiments in which both core and RAN slicing occur, resource allocation manager 115 (under instructions from Slice Manager 130) can ensure that traffic received in a slice from RAN 125 is provided to a virtualized decoder that is connected to the corresponding slice in the Core network 130. This ensures that as data is received from a UE 110 device, isolation is maintained as the decoding can take place within the appropriate network slice instead of at the common radio access point.
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), a dedicated logic circuitry, or combinations 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 appropriate input devices 435 and/or output devices 4400. 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 interfaces 415 may include one or more interfaces to wired networks and wireless networks. Wired networks may use of wired links (e.g., Ethernet cable), while wireless networks, where they are used, may make use of wireless connections transmitted over an antenna such as antenna 445. The network interfaces 415 may provide wireless communication via one or more transmitters or transmit antennas and one or more receivers or receive antennas, for example. In this example, a single antenna 445 is shown, which may serve as both transmitter and receiver. However, in other examples there may be separate antennas for transmitting and receiving. In embodiments in which 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 a mass storage unit such as a solid state drive, a hard disk drive, a magnetic disk drive and/or an optical disk drive.
The processing system 400 may include one or more memories 425, which may include a volatile or non-volatile memory (e.g., a flash memory, a random access memory (RAM), and/or a read-only memory (ROM)). The non-transitory memories 425 (as well as storage 420) may store instructions for execution by the processing devices 405, such as to carry out methods such as those described in the present disclosure. The memories 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 the processing system 400) or may be provided by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include a RAM, a ROM, an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a CD-ROM, or other portable memory storage.
There may be a bus 430 providing communication among 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 input devices 435 (e.g., a keyboard, a mouse, a microphone, a touchscreen, and/or a keypad) and output devices 440 (e.g., a display, a speaker and/or a printer) are shown as external to the processing system 400, and connected to optional I/O interface 4100. In other examples, one or more of the input devices 435 and/or the output devices 440 may be included as a component of the processing system 400. Embodiments in which processing system 400 is a network controller may lack a physical I/O interface 410, and instead may be a so-called headless server for which all interactions are carried out through a connection to network interface 415.
In example embodiments, a processing system 400 configured to implement RAN slice manager 150 may be configured to maintain information that specifies the resource allocations for each of RAN slices 152 in memory 425 or storage 420 or a combination thereof.
Radio Access Nodes, such as base stations etc., have typically not performed slicing of the Radio interface. At best, static partitioning of time or frequency based resources has been employed to create virtual channels. As indicated above, slicing of the RAN can also be accomplished through the use of different waveforms, numerologies and transmission parameters. In a RAN, a plurality of 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 the slices.
As traffic from the two CNs, is received within the RAN, RAN slicing manager 902 directs traffic on the basis of the CN, CN slice and service, to the respective RAN slice. As illustrated, service 1914 within slice 1-1 906 is directed to RAN slice 1936. Thus traffic from this service can be sent to all three of AP1 930 AP2 932 and AP3 934. Traffic from service 2 916, which is also traffic from slice 1-1 906, is transmitted over RAN slice 3 940, so RAN slice Manager 902 directs this traffic to AP1 930 and AP 3 934. Those skilled in the art will appreciate that as discussed earlier different services may carry the same service ID if they are within different CN slices. This may be a result of different service providers not knowing the service ID values used in other slices. Because the slice ID and even in some cases a core Network ID can be associated with traffic, the RAN slicing Manager can ensure that service 1 926 carried within slice 2-2 922 can be routed to RAN slice 3 940. As a manner of aiding in visual distinction, traffic from CN 1 904 is shown traversing a path indicated by a solid line, while traffic from CN 2 918 is shown traversing a path indicated by a dashed line.
Traffic from slice 1-2 908 is carried by RAN slice 2 938; traffic from slice 1-3 910 is carried by RAN slice 2 938; traffic from slice 1-4 912 is carried by RABN slice 4 194. Traffic from slice 2-1 920 is carried by RAN slice 2 938; traffic from both services 926 and 928 within slices 2-2 922 is carried by RAN slice 3 940, and traffic from slice 2-3 924 is carried in RAN slice 2 938.
In the uplink, it will be understood that a UE, such as UE 110 can have a plurality of different virtual machines, each of which is used for the services associated with a different RAN slice. This allows the UE to be associated with different vAPs for each slice, and further allows handovers to happen on a per slice basis. An AP, such as AP 1930 will receive traffic associated with a RAN slice. This 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 service it is associated with. This information can be used by the AP to select any of the tunnels that the traffic is transmitted to, the GW to which the traffic is transmitted, and the CN or CN slice that the traffic is to be transmitted to. In accordance with this destination information, the AP can transmit the received data to the associated CN slice. It should be understood that in situations in which there is a one to one mapping between the RAN slice and a CN slice, the AP can direct traffic to a CN slice on the basis of the RAN slice over which it is received. Where a RAN slice supports traffic from a plurality of different CN slices, further information, such as a CN slice ID, or a unique service ID, can be used to make the determination.
Those of skill in the art will appreciate that in an embodiment of the present invention, there is a method 1300 as illustrated in
In an optional embodiment, information associated with changing traffic demands or requirements for either a core network (or slice) or a radio edge slice is received. This information, received in optional step 1312, may indicate that there is excess capacity, or surplus demand for capacity in the radio edge slices. This information can be used to determine a new resource allocation for the radio edge slices, which can be transmitted to the respective nodes. In some embodiments this instruction may only be transmitted to the APs, or to a subset of APs. In other embodiments, the modification may create new radio edge slices, or remove existing radio edge slices, in which case a modification message (possibly not the same modification message sent to the AP) may be sent to other nodes in the RAN so that logical connections can be created or removed.
In some of the embodiments of the above described method, the RAN resources can include any or all of: network access resources that connect the RAN to a physical core network; radio frequency and time resources of the RAN; and an air interface configuration specifying how the network access resources interface with the radio frequency resources of the RAN. Optionally, at least some of the RAN slices can have common allocations of network access resources and adjacent radio frequency resources, with differentiating air interface configurations being allocated to each of the at least some of the RAN slices to isolate the radio communications of the at least some of the RAN slices from each other. The air interface configurations may specify waveforms for the RAN slices and numerology to apply to the waveforms. The plurality of RAN slices can comprises first and second RAN slices for which the air interface configurations specify the same waveform but different numerologies. In this manner, a numerology can allow a degree of isolation between the slices, as a receiver associated with the first slice would not be able to properly decode data transmitted in the second slice due to the differing transmission numerology. In one such example, the common waveform can be an OFDMA waveform, and the numerologies associated with each slice can have a different combination of one or more of: sub-carrier spacing, cyclic prefix length, symbol length, a duration of a scheduled transmission duration and a number of symbols contained in a scheduled transmission duration.
In another embodiment, different network access resources and different combinations of time and radio frequency resources can be allocated to RAN slices to provide isolation.
Those skilled in the art will appreciate that this method allows for the association of RAN slices with respective core network slices (or services within the core network slices) to enable communications associated with service to use a RAN slice and its associated core slice.
In other embodiments, for at least one of the RAN slices, the network access resources comprise at least one logical transmit point for downlink communications and at least one logical receive point for uplink communications. The TP and RP can be based on different sets of physical access points. In some embodiments, there may be overlap between the membership of physical access points within the logical TP and RP. In other embodiments there may be no overlap. Even if the membership of the physical APs is identical, the assignment of different logical identifiers to a TP and RP associated with a slice create a logical distinction for a UE. It is also possible that a set of physical APs assigned to a TP or RP in one slice may differ from the set of physical APs assigned to a TP or RP in another slice. The membership of the TP or RP in any slice can be changed without informing the UE, so long as the logical TP or RP identifiers are maintained. A UE may be communicating with the same set of physical APs in two different slices without being aware of this overlap.
After the establishment of the slices, and the definition of logical TPs and RPs within each slice, traffic destined for a UE attached to more than one slice can be received and routed to the APs associated with the CN, CN slice, or service, that the traffic is associated with. The traffic can then be transmitted to the UE using the transmission parameters associated with the RAN slice. Traffic associated with a different slice may be transmitted to the UE by a different logical TP, which may or may not have the same physical APs.
When the UE has traffic to transmit, it can transmit the traffic to the RP associated with the slice associated with the respective service. Based on any or all of an identification of the UE, the RP that traffic is received over, a service identifier associated with the transmission, and a destination address, the received traffic can be routed to the appropriate core network or core network slice.
Each RAN service/slice should have its air interface configurations in the radio access network. As detailed above, there may be corresponding resource and functional allocations in the core network. Embodiments described herein focus on the air interface configurations for service/slices.
Throughout the following description, where “service/slice” is used, this is intended to encompass an embodiment specific to services, e.g. in which case service/slice manager 150 is a service manager and the methods and systems provide configuration of air interfaces that are service specific, an embodiment specific to slices, e.g. in which case service/slice manager 150 is a slice manager and the methods and systems provide configuration of air interfaces that are slice specific, and an embodiment in which both are used, e.g. in which service/slice manager 150 manages services and slices, and the methods and systems provide configuration of air interfaces that are slice specific and service specific.
Systems and methods for defining air interface configurations that support different service/slices are provided, that allow the different requirements for different service/slices to be satisfied. The air interface configurations of a service/slice need to be known by both the network and the UE (no matter predefined or indicated by signalling) before the service/slice is used for transmissions between the network and the UE.
An air interface can be defined by a set of parameters. The specific set of parameters can be defined on an implementation specific basis.
In some embodiments, air interfaces are predefined for a specific set of service/slices. Table 1 below shows an example of different predefined air interface configurations for eMBB, URLLC and mMTC service/slices, where each air interface configuration is defined by a specific set of parameters that includes the following:
Access point type. Examples include:
-
- Pico—access points with relatively small coverage area (pico, femto, hotspot, etc.)
- Macro—access points with relatively large coverage area
SCS=sub-carrier spacing:
Here, there are three possibilities, small, normal and large. In a specific example, small=15 kHz, normal=30 kHz, and large=60 kHz, CP length=cyclic prefix length: - A large CP length is longer in time than a small CP length. In a specific example, a frame includes one or more symbols with a first cyclic prefix length and one or more symbols with a second cyclic prefix length.
BW=bandwidth=amount of resources to allocate to the service: - Note bandwidth is delivered using time-frequency resources that may include one or more non-contiguous regions.
Frame structure—indicates one of multiple frame structures:
-
- where multiple frame structures are available, this parameter indicates one of the frame structures. FS type 1 is a first frame structure type, and FS type 2 is a second frame structure type. This can for example indicate one or more of:
- the time duration of the frame;
- how many OFDM symbols are in a frame
how many pilot symbols there are and how many data symbols there are
- Slot duration:
- This is the length of a slot, with is the smallest scheduling opportunity in the time domain. Alternatives to specifying slot duration include specifying transmission duration, subframe duration, mini-slot duration, time domain scheduling unit, smallest scheduling opportunity in time domain.
- Access scheme—this indicates the manner in which a given UE accesses capacity on the network. Examples include:
- Scheduled—resources for a given UE are scheduled, for example, though a request, grant mechanism; and
- Grant-free—a request, grant mechanism is not used for uplink transmission
Semi-persistent Scheduling (SPS)—this is scheduling that defines a recurring resource that is used when needed.
Retransmission scheme—an indication of the scheme used to transmit retransmissions to deal with unsuccessful transmission. Examples include hybrid automatic repeat request (HARQ) band automatic repeat request (ARQ).
- Waveform—this is an indication of the physical waveform transmitted over the air waveform. Examples include:
- Orthogonal access schemes, for example Orthogonal frequency division multiple access (OFDMA)
- Non-orthogonal multiple access schemes, for example, Sparse code multiple access (SCMA). Examples include schemes based on UE specific code, signature, spreading sequence, bit or symbol interleaving pattern, resource assignment pattern or some combination of these. These might include one or a combination of Interleave-Grid Multiple Access (IGMA), Multi-user shared access (MUSA), Low code rate spreading, Frequency domain spreading, Semi-orthogonal multiple access (SOMA), Non-orthogonal coded multiple access (NCMA), Non-orthogonal multiple access (NOMA), Pattern division multiple access (PDMA), Resource spread multiple access (RSMA), Low density spreading with signature vector extension (LDS-SVE), Low code rate and signature based shared access (LSSA), Non-orthogonal coded access (NOCA), Interleave Division Multiple Access (IDMA), Repetition division multiple access (RDMA) and Group Orthogonal Coded Access (GOCA)), Discrete Fourier Transform-OFDM (DFT-OFDM-), low density signature OFDM (LDS-OFDM). The benefits of using non-orthogonal multiple access is to allow for more simultaneous transmissions in the same wireless resource, thus increasing the spectrum efficiency.
- Channel coding—indicates the coding used for data sent over the channel. Examples include:
- Low density parity check (LDPC)
- Polar codes
- Convolutional code (CC)
- Modulation and coding scheme (MCS)—this can indicate code rate and/or modulation scheme, the combination of which indicate a data rate. In the example below, the table only includes two MCS's one of which is high data rate, and one of which is low data rate.
Protocol stack—various protocol stack options can be provided that vary in complexity from simple, to normal to full.
State machine—a different state machine can be defined for each service. In the example in the table, there is a state machine without an ECO state, and a state machine with an ECO state. The state machine without ECO includes states CONNECTED and IDLE, while the state machine with ECO includes the states CONNECTED, IDLE, and ECO. The ECO state (or inactive state—an energy saving state) may be used for devices with limited power but is unnecessary for devices with a power supply. Examples of state machine enabled UEs and supporting networks are described in United States Patent Publication No. US2015/0195788 A1 entitled “System and Method For Always On Connections in Wireless Communications System”, United States Patent Publication No. US 2016/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-Centric Radio Access Procedure” all of which are incorporated herein by reference. In the ECO state grant-free transmission is supported to reduce signaling overhead and energy consumption of transmission of small packets (e.g., background traffic).
- where multiple frame structures are available, this parameter indicates one of the frame structures. FS type 1 is a first frame structure type, and FS type 2 is a second frame structure type. This can for example indicate one or more of:
In some embodiments, the behavior/performance of the wireless channel can be a function of the carrier frequency used for the wireless channel, and the air interface can be configured taking this into account. For example, bands of frequency can be defined that have certain similarities in behavior for any carrier frequency within each band. In a specific example, a low frequency (LF) band might be 0.6 to 3 GHz, a medium frequency (MF) band 3 to 6 GHz, and a high frequency (HF) band over 6 GHz. With these frequency band definitions, a 900 Mhz carrier frequency, for example, would be within the LF band. In a specific example of how behavior may differ based on frequency band, the coverage may vary as a function of frequency. For example, the coverage area may be largest for the LF band, smaller for the MF band, and smallest for the HF band. The carrier frequency, or the frequency band containing the carrier frequency, may affect the air interface configurations. For different frequency bands, different air interface configurations may be defined. Examples are provided below.
As noted above, Table 1 shows air interface configuration examples for each of eMBB, URLLC, and mMTC, defined using the above-discussed parameters. These examples will each be described in detail.
Different wireless resources may be allocated for different service/slices. They may be multiplexed in frequency, time, code, space, etc. or any combination of them.
Different service/slices may share a common frame structure or use different frame structures. In the detailed examples described below, eMBB uses frame structure type 1 while mMTC uses frame structure type 2. For this example, the DL URLLC transmissions can be scheduled with high priority in the wireless resources usually used for eMBB or mMTC. So FS type 1 or FS type 2 may be used for URLLC, depending on whether the specific URLLC transmission is multiplexed with eMBB or mMTC.
eMBB Example Air Interface Configuration
Frequency band: for eMBB, the HF band is more suitable due to its high available bandwidth
Access point type: since the coverage for the HF band is small, eMBB may be applied in small cells (Pico, Femto, Hotspot, etc.)
SCS: because the frequency noise may lead to a high frequency shift in the HF band, the subcarrier spacing should be large to avoid inter-SC interference (interference between adjacent sub-carriers)
CP length: because the delay spread is usually small in HF band scenarios, a small CP length should be sufficient to avoid inter-symbol interference
Slot duration: normal, because eMBB service does not have special latency requirements
Access scheme: scheduled, because the signaling overhead for scheduling is very small in comparison to the data rate required for eMBB service
Retransmission Scheme: HARQ+ARQ, because eMBB service does not have special latency requirements and thus can allow for HARQ retransmissions to improve the throughput.
Waveform: different waveforms may be used for eMBB in different situations to optimize the performance. For example, OFDMA may be used for dynamically scheduled transmissions. The same waveform may be used for both the uplink and the downlink because their link budget may be close to each other when lower power nodes are used for small cells.
Frame structure: FS type 1
Channel coding: Different channel coding schemes may also be used in different situations to optimize the performance. In a specific example, LDPC or TC is used when the code length is long, while PC, CC or TC is used when the code length is short. The code length can be determined according to the number of bits to be transmitted, the wireless resource scheduled for the transmission, the modulation scheme used for the transmission, etc. Different channel coding schemes may also be selected according to the number of information bits to be coded, or the type of physical channel used for transmission (DL/UL, data/control, scheduled/contention-based, etc.)
MCS: high data rate because eMBB service requires high data rate
Protocol stack: For eMBB, the advanced (most complex/full) protocol stack processing may be supported to optimize the spectrum efficiency for data transmission without too much consideration about latency and signaling overhead
State Machine: without ECO because the eMBB service do not have energy-saving requirement
URLLC Example Air Interface Configuration
Frequency band: for URLLC, the LF band is more suitable due to the wide coverage and good reliability of its wireless channels
Access point type: to support the LF band, at least macro TRPs should be used, although small cells may also support the LF band. However, the backhaul delay for some small cells might be too large for latency sensitive services/slices. Those small cells with acceptable backhaul delay may also be used
Slot duration and retransmission scheme: a small transmission slot with quick HARQ acknowledgement is beneficial to ensure both low latency and high reliability
Access scheme: a grant-free access may be used for low latency. Note that the grant-free access scheme is an example of a multiple access scheme mainly for uplink transmissions, for situations where multiple UEs send uplink transmissions signals to access the network. In the downlink transmissions are usually always scheduling based.
Waveform: DFT-OFDM because it has good performance for grant-free access.
Frame structure: frame structure type 1 or type 2
Channel coding: polar codes/CC because they have good performance for short code lengths
MCS: low data rates may be used to further improve the possibility of successful decoding within just a few retransmissions to control the latency
Protocol stack: normal as there are no special requirements
State Machine: a state machine including ECO may be used for URLLC devices with limited power. However, those URLLC devices with a power supply may not need to use this energy saving state.
mMTC Example Air Interface Configuration
Frequency band: for mMTC, at least the LF band should be used to provide good link budget for low power devices located in a wide area. The HF band is also possible to be used for those fixed devices located very close to a small cell
Access point type: Both macro base stations and small cells supporting LF can be used, and a small cell supporting HF for fixed devices close to the small cell.
SCS: small, because the frequency shift in the LF band is small, and also because the Doppler shift for fixed devices is small
Access scheme: grant-free access or semi-persistent scheduling may be used to reduce signaling overhead.
Slot duration and MCS: a large transmission slot with a low coding rate may be used to improve link budget.
Waveform: non-orthogonal multiple access because this has good performance in supporting massive access.
Frame Structure: frame structure type 2
Channel coding: polar codes because it offers good performance for short code lengths.
Protocol stack and retransmission scheme: a simple protocol stack and simple retransmission scheme without HARQ may be used to reduce the cost of the devices
State machine: a state machine with ECO may be used for mMTC devices, as they typically have limited power.
While example predefined air interface configurations have been described for each of eMBB, URLLC and mMTC, based on the specific set of parameters detailed above, it should be understood that the set of parameters used to define an air interface configuration are not limited to the specific example. In addition, or alternatively, air interface configurations may be predefined for services/slices apart from eMBB, URLLC and mMTC to be predefined, such as Video, Voice, Gaming, V2X, Emergency, delay sensitive HDR, etc. In some embodiments, other more detailed types of sub-services/sub-slices are predefined, such as URLLC-HDR, URLLC-LDR, mMTC-DL, mMTC-UL, etc.
Building BlocksTable 1 contains a list of parameters that can be used to configure an air interface. The set of parameters may be different. However, the parameters in general should correspond with air interface configuration parameters of the network and/or UE. More generally, an air interface configuration can be defined using a set of building blocks. Each building block represents an aspect or aspects of the air interface. For example, the columns of Table 1 may be used to define air interface building blocks.
Having defined the air interface building blocks, an air interface configuration can be defined by configuring each of the building blocks for the air interface configuration. This approach can be used for predefined air interface configurations, or for flexible air interface configurations.
Some building blocks may have a hierarchical structure. For example a building block for numerology may contain several detailed building blocks such as SCS, CP length, RB size, etc., as listed in the first column of Table 2 detailed below.
Systems and methods for determining which air interface to use for communications between a UE and a BS are provided that are based upon such a building block framework. A detailed set of embodiments will now be described for determining the configuration of a single building block. For the purpose of simplicity, the single building block that is being configured is the numerology. However, the approaches described in all of these embodiments can be applied equally to determining any other building blocks. Where signaling is sent from the access point to the UE and/or from the UE to the access point in respect of the numerology, similar signaling can be sent in respect of one or more other building blocks. The signaling for multiple blocks may be combined, or separate signaling may be employed for each block.
In some embodiments, each UE has a UE type or capability information that is associated with specific capabilities for one or more specific building blocks. In such embodiments, once the network knows the UE type or capability information, the network knows the UE capabilities for the one or more building specific blocks.
Numerology Building Block Example
In the above example, subcarrier spacing and cyclic prefix length were two of the parameters used to define the air interface. More generally, an air interface uses a numerology. For the purpose of this description, a numerology is considered one building block in an air interface configuration, and includes the following:
-
- SCS—sub-carrier spacing;
- Resource block (RB) size—the RB may be a unit of allocation, and the size is the bandwidth of the RB. The number of sub-carriers is equal to the RB size/sub-carrier spacing;
- Number of symbols per subframe, including a total number, and indications of number of symbols for pilot and data (pilot/data);
- Symbol duration without CP—this is the portion of the symbol not including the cyclic prefix;
- CP length in samples; and
- CP length in ρs.
Each numerology may have a numerology index which is an index of the particular numerology within a set of numerologies.
In some embodiments, a predefined numerology set or sets of numerologies are provided and used. Table 2 is an example of different numerology sets that are predefined for different frequency bands, in this case, the previously referenced LF and MF bands. In the example of Table 2, the numerologies are indexed separately within each frequency band. Note “592/576*2−m” means 592*2−m samples for 1st CP while 576*2−m samples for other CPs. “m” is a factor to address sampling frequency or FFT size, i.e., m=2048/Nfft or m=30.72 MHz/Fs.
In another example, a single common set of indexes is used for all the numerologies, and the numerologies thus defined are then assigned/available to specific frequency bands. A specific example of this is shown in Table 3 below which shows a set of numerologies with a single set of indices, and Table 4 which indicates which numerologies thus indexed are available for each frequency band.
In some embodiments, there is a default numerology defined for each frequency band. The default numerology is known to the network and to some UEs that are capable of supporting the default numerology, at least for initial access. In a specific example, numerology #1 from Table 3 is defined as the default numerology in the 0.6˜3 GHz band, and numerology #0 is defined as the default numerology in the 3˜6 GHz band. A UE can use the default numerology to synchronize to the network and receive numerology configuration information which may, for example contain information that indicates a wireless resource allocation for each numerology. This may be broadcast by the access point (e.g., on a broadcast channel (BCH), main information block (MIB) or supplementary information block (SIB).
Alternatively, or in addition to the transmission of control information using a default numerology, control information may be sent using a numerology that is not predefined to be a default numerology. In some embodiments, certain advanced UEs that support all of the a predefined set of numerologies may try each of the numerology candidates that are predefined in the numerology set until the UE successfully decodes the control information. Alternatively, for a UE that supports less than all of the predefined set of numerologies, the UE may only try to use the numerology (or numerologies) it can support to decode the control information.
Referring now to
In block 302, the access point transmits to a UE and/or receives from the UE using an air interface composed of air interface blocks building blocks set to options supported by both the access point and the UE.
Various approaches are provided for selecting a suitable numerology or numerologies by the UE or the network to use for transmission and/or reception, for example to use in block 302 of the method of
In a first scenario, only one numerology is supported by UE If the UE can only support one numerology (e.g., an mMTC device that only needs to use mMTC service), then the UE just uses that one supported numerology if it is also supported by the access point. If the access point does not support that one numerology, then the UE cannot access the network through this access point.—When such a UE accesses the network using the single numerology it supports, the network should already know the UE supports this numerology. For example, in some embodiments, when a UE accesses the network, it sends a signal for initial access. Upon detection of this signal, the network knows that the UE has successfully decoded the downlink broadcast/control information which was transmitted using a certain numerology. The network may also know that the UE is sending this signal using a certain numerology or according to a certain numerology. There may be different initial access signals used for different Numerologies. In some embodiments, the UE informs the network of its UE type or capability so that the network will know the UE cannot support any other numerologies.
In a second scenario, multiple numerologies are supported by a UE, only one of which supported by access point. If the UE can support multiple numerologies, but only one numerology out of the supported numerologies is used by the access point, and the UE obtains information on the supported numerology from the network, then the UE may make a decision to use that one supported numerology and feedback an indication of the supported numerology to the access point. Alternatively, the UE may report its UE type or capability to the access point and let the access point decide which numerology it shall use. In the latter case, the access point makes a decision and sends a message to inform the UE which numerology should be used.
In a third scenario, multiple numerologies are supported by both the UE and the access point. If the UE can support multiple numerologies that are also supported by the access point, then the UE may report its UE type, capability or suggested numerologies to the access point and let the access point inform the UE of the numerology or numerologies to use.
In some embodiments, to reduce the signaling overhead, the access point and UE each independently determine the numerologies supported by both the access point and the UE. For example, the UE may obtain information about the numerologies supported by the access point, for example from broadcast information, and then determine which of the supported numerologies to use, while the access point can receive UE type or UE capability report from the UE and then determine the numerologies to be used by the UE. Although the access point and the UE make decisions independently, the result of their decision is the same, and as such, signaling indicating which numerologies to use is not needed.
In some embodiments, when there are multiple numerologies supported by both the UE and the access point, the specific numerology to use may be selected by the access point or the UE according to the service/slice (type or quality requirements of the service/slice).
In some embodiments, the numerology is determined according to a predefined table (or description, equivalently). An example is illustrated in Table 5.
In some embodiments, different preferred numerologies may also be defined for different frequency bands.
Multiple preferred numerologies may also be defined for a service. In this case, the access point or UE may select one out of them either randomly or according to a predefined method or criteria.
In another embodiment, the numerology to be used is determined by the access point or the UE and then indicated by signaling/message to the other. For example, when downlink data arrives at an access point, the access point can select a suitable numerology for the session and send the UE a signal (e.g., PHY signal, MAC signalling, RRC message, etc.) indicating the index of the numerology to be used. Similarly, when UL data arrives at the UE, the UE can select a suitable numerology for the session and send the access point a signal indicating the numerology to be used. This indication may be explicit (e.g., by information in a scheduling request message) or implicit (e.g., by sending grant-free signal using the selected numerology or using the wireless resource allocated for the selected numerology).
As noted above, any of the approaches described for determining/selecting a numerology can equivalently be employ to determine/select one or more other building blocks of an air interface configuration.
In some embodiments, for a given service/service/slice, one or more of the building blocks is predefined, such that only the remaining building blocks need to be settled using one of the approaches described above.
Broadcast of Per-Service/Slice Air Interface Parameters
Optionally, some embodiments include blocks 454 and 456 for downlink transmission. In block 456, when downlink data arrives (or when a session initiates), the network may send a signal (or message) to the UE to indicate the service/slice used for the transmission (or for the session). As an alternative to sending an explicit signal, the network may simply send the data in the wireless resource allocated for a service/slice.
Optionally, some embodiments include blocks 458 and 460 for uplink transmission. When uplink data arrives at the UE, the UE may send a signal to the network to indicate the service/slice used for the transmission, and then transmit using the service/slice thus indicated. At the network side, in block 458, the network receives signaling indicating a service/slice to be used for an uplink transmission, and in block 460, the network receives the uplink transmission on the indicated service/slice.
In an embodiment, the network sends a message, such as a radio resource control (RRC) message, to the UE in the following format to indicate the configurations of the service/slices referred to above:
This format may be predefined. But a similar format can be defined with different parameters, and/or different enumerated values for the parameters, and the order of the parameters is not important. In this example, the set of building blocks for air interface configuration include numerologyIndex, accessScheme, channelCoding, etc. For the building block of numerologyIndex, the set of possible configurations is composed of four integers ranging from 0 to 3. For the building block of subframeType, the set of possible configurations is composed of four choices: UL dominated, DL dominated, UL-DL balanced and flexibly adjusted. The indices of these four possible configurations are defined as integers from 1 to 4 according to the order that these possible configurations are listed in the enumeration.
The network may use this format to broadcast to UE the configurations for each service/slice, for example up to some maximum number of service/slices. Upon receiving this broadcast message, the UE will know the bandwidth resources (with its location implicitly indicated by the order of service/slice configurations in the broadcast message) for the service/slice, the Numerology used for the service/slice, the access scheme supported for the service/slice, etc.
For example, upon receiving an index of 3 for the building block of miniSlotDuration in the sequence for the 2nd Service/sliceConfigNR, the UE will know that the mini-Slot duration configured for the 2nd service/slice should be ¼ of the slot length.
Upon receiving an index of 4 for the building block of bandwidth for the 1st Service/sliceConfigNR and then an index of 4 for the building block of bandwidth for the 2nd Service/sliceConfigNR, the UE will know that the resource allocation for the 1st service/slice is the first 500 RBs (0˜49) and the resource allocation for the 2nd service/slice is the next 100 RB (50˜149) in the system bandwidth.
Dynamic SchedulingIn some embodiments, dynamic scheduling is performed. With dynamic scheduling, time-frequency resources to be used are defined on a per-scheduling instance. For uplink transmission, the network sends a grant message to a UE indicating the resources to use for transmission using a scheduling control channel.
In some embodiments, the scheduling control channel is used to indicate one or a combination of air interface parameter selections and/or air interface building blocks (for example one or more of the parameters discussed previously, such as numerology type, scheduling duration type, re-transmission scheme type). In some embodiments, a sub-set of the air interface parameters/building blocks are initially set, and then the scheduling control channel is used to specify remaining air interface parameters/building blocks. Alternatively, in embodiments where the air interface configuration is predefined for each service/slice/service, the scheduling channel can be used to transmit a service/slice/service/slice indicator, and that will service/slice to indicate the air interface configuration.
In a detailed dynamic scheduling example in which the downlink control information (DCI) is sent by a network to a UE to indicate the air interface configuration in transmissions, the following information is transmitted as downlink control information (for example DCI using format 1E):
-
- Carrier indicator—0 or 3 bits
- Numerology type—3 bits
- Resource allocation header (resource allocation type 0/type 1)—1 bit
- Resource block assignment—number of bits depending on Resource allocation type
- Scheduling duration type—2 bits
- Modulation and coding scheme—5 bits
- Retransmission scheme type—1 bit
- HARQ process number—3 bits
- New data indicator—1 bit
- Redundancy version—2 bits
- Additional fields.
- Carrier indicator—0 or 3 bits
In this example, the Numerology type information indicates the Numerology (including subcarrier spacing, CP length, etc.) used for the transmission, the scheduling duration type information indicates the duration scheduled for the transmission, the retransmission scheme type indicates the scheme used for retransmissions.
Another example for the DL control information that the network sends to UE to indicate the AI configuration in transmissions involves transmitting the following information as downlink control information (again, for example, as part of DCI format 1E):
-
- Carrier indicator—0 or 3 bits
- Service/slice type—2 bits
- Resource block assignment—number of bits depending on Resource allocation type
- Modulation and coding scheme—5 bits
- HARQ process number—3 bits
- New data indicator—1 bit
- Redundancy version—2 bits
- Additional fields.
- Carrier indicator—0 or 3 bits
In this example, the Service/slice type information indicates the service/slice for the transmission. The air interface configurations such as Numerology, scheduling unit, retransmission scheme, etc., can be derived from this Service/slice type information according to a mapping relationship pre-defined or indicated over the air by messages (e.g., RRC signaling).
In the detailed embodiments described above, various approaches have been described for indicating the air interface configuration to a UE. These have included:
using pre-defined air interface, for example, in accordance with a specification;
using a downlink channel broadcasting or multicasting air interface configurations—which can be a channel fully configured as a default air interface configuration, a channel with some default air interface configurations, or a channel without default air interface configurations; and
using a control channel used to send downlink control information for downlink scheduling or uplink scheduling.
In some embodiments, the air interface configuration is configured through using radio resource control (RRC) signaling to indicate the air interface configuration. For example, in LTE, RRC signaling may be carried in Physical Broadcast Channel (PBCH) or Physical Downlink Shared Channel (PDSCH). For example, a Master Information Block (MIB) is carried in PBCH while a secondary System Information Block (SIB) is carried in PDSCH. Both MIB and SIB contain system information and are broadcasted, although SIB is not sent in the broadcast channel. To the extent channels analogous to these are present in a 5G network, they can be used to send RRC signaling indicating the air interface configuration.
In some embodiments, where there is a primary, or default, information partition for RRC signaling, this can be used to indicate air interface configurations. The MIB referred to above is a specific example of this. In some embodiments, an information partition for RRC signaling that is not a primary or default partition is used to indicate air interface configurations. The SIB referred to above is a specific example of this.
In some embodiments, there are multiple wireless resource partitions in a carrier, each supporting an air interface. The air interface configuration for some physical channels in each of at least one partitions is indicated by signaling transmitted in that partition.
In some embodiments, there are multiple wireless resource partitions in a carrier, each supporting an air interface. Part of the air interface configuration (or some BB configurations) for some physical channels in a secondary (dependent) partition is indicated by signaling transmitted in the primary partition. Some other part of the air interface configuration for the physical channels in the secondary partition is indicated by signaling transmitted in the secondary partition.
In some embodiments, there are multiple carriers, each supporting an air interface. The air interface configuration for some physical channels in each of at least one carriers is indicated by signaling transmitted in that carrier.
According to one aspect of the present invention, there is provided a method for execution by an access point (AP) within a radio access network (RAN), the method comprising: receiving data for transmission to a User Equipment (UE); and wirelessly transmitting the received data to the UE using a set of transmission parameters associated with a RAN slice associated with the received data.
Optionally, the method further comprises selecting the RAN slice associated with the received data from a set of RAN slices supported by the AP.
Optionally, the RAN slice is selected in accordance with a RAN slice identifier associated with the received data.
Optionally, the method further comprises selecting the transmission parameters in accordance with the selected RAN slice.
Optionally, the set of transmission parameters are selected in accordance with an address of a gateway between the RAN and a core network.
Optionally, the set of transmission parameters are selected in accordance with one of a core network identifier, a core network slice identifier and a service identifier associated with the received data.
Optionally, at least one parameter in the set of transmission parameters is selected from a list comprising: radio frequency/time resources; a radio access technology; a transmission waveform; a frame length; and a numerology.
According to another aspect of the present invention, there is provided a network access point (AP) for transmitting data to a User Equipment (UE) over a radio channel in a radio access network (RAN), comprising: a network interface for receiving data from a radio access network; a wireless network interface for transmitting data to the UE; a processor; and a non-transient memory for storing instructions that when executed by the processor cause the network access point to: transmit data to the UE over the wireless network interface using a set of transmission parameters associated with a RAN slice, in response to receipt of the data for transmission to the UE over the network interface.
Optionally, the non-transient memory further stores instructions to select the transmission parameters in accordance with an address of a gateway from which the data is received.
Optionally, the non-transient memory further stores instructions to select at least one transmission parameter in the set in accordance with a RAN slice identifier associated with the data.
Optionally, the non-transient memory further stores instructions to select at least one transmission parameter in the set in accordance with one of a core network identifier, a core network slice identifier and a service identifier associated with the data.
Optionally, at least one parameter is the set of transmission parameters is selected from a list comprising: radio frequency/time resources; a radio access technology; a transmission waveform; a frame length; and a numerology.
According to another aspect of the present invention, there is provided a method for execution by a routing function in a radio access network (RAN): receiving data traffic from a core network destined for a User Equipment (UE); transmitting the received data traffic to a transmission point within a selected RAN slice associated with the received data traffic.
Optionally, the method further comprises selecting the RAN slice associated with the received data traffic in accordance with one of: an identifier associated with the core network; an identifier associated with a slice of the core network associated with the received data; and a service identifier associated with the received data.
Optionally, the identifier associated with one of the core network and the slice of the core network is one of an address of a core network gateway function and a tunnel identifier.
Optionally, receiving the data traffic includes receiving the data traffic from a gateway function within the core network.
Optionally, receiving the data traffic includes receiving the data traffic from a core network slice.
Optionally, the RAN slice is pre-associated with the core network slice.
Optionally, the method further comprises the step of selecting the transmission point within the RAN slice in accordance with information about the location of the UE with respect to the network topology.
Optionally, the method further comprises selecting a transmission point uniquely associated with the UE; and determining a set of constituent access points associated with the transmission point; wherein transmitting the received data comprises transmitting the received data to the set of constituent access points.
Optionally, the step of transmitting includes modifying the received data to include a RAN slice identifier associated with the selected RAN slice prior to transmitting the data to the transmission point.
According to a further aspect of the present invention, there is provided a router for use in a radio access network (RAN), comprising: a network interface for receiving and transmitting data; a processor; and a non-transient memory for storing instructions that when executed by the processor cause the router to: transmit data traffic, over the network interface, to a transmission point associated with a selected RAN slice within the RAN, in response to receiving data traffic destined for a User Equipment (UE) over the network interface.
Optionally, the non-transient memory contains further instructions that when executed by the processor cause the router to select the RAN slice in accordance with one of an identifier associated with the core network; an identifier associated with a slice of the core network associated with the received data; and a service identifier associated with the received data.
Optionally, the identifier associated with one of the core network and the slice of the core network is one of an address of a core network gateway function and a tunnel identifier.
Optionally, the non-transient memory contains further instructions that when executed by the processor cause the router to select the transmission point in accordance with information about the location of the UE with respect to the network topology.
Optionally, the non-transient memory contains further instructions that when executed by the processor cause the router to select a transmission point uniquely associated with the UE; determine a set of constituent access points associated with the selected transmission point; and transmit the data to the transmission point by transmitting the data to the set of constituent access points.
Optionally, the non-transient memory contains further instructions that when executed by the processor cause the router to modify the received data prior to transmission to the transmission point to include a RAN slice identifier associated with the selected RAN slice.
While this 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 encompass any such modifications or embodiments.
Claims
1. A method for an access point in an access network comprising:
- communicating with a first user equipment (UE) with a first air interface configuration for a first service;
- communicating with a second UE with a second air interface configuration for a second service;
- wherein the first service is in a first slice differentiating from a second slice for the second service in the access network; and
- wherein the first and second air interface configurations are respectively in association with different numerologies, and each numerology comprises at least two of the following parameters: sub-carrier spacing, symbol duration, or CP length.
2. The method of claim 1 wherein the first and second services include at least one of an eMBB service, a URLLC service, an mMTC service, a video service, a voice service, a gaming service, a V2X service, or an emergency service.
3. The method of claim 2 further comprising:
- for the first service, broadcasting information indicating at least one option supported by the access point for each of a plurality of air interface building blocks;
- wherein communicating with the first user equipment with the first air interface configuration for the first service comprises: transmitting to or receiving from the first UE using the first air interface configuration composed of air interface building blocks set to options supported by both the access point and the first UE.
4. The method of claim 3 wherein broadcasting information comprises using an air interface in which at least one building block is set to a default value; or using an interface in which at least one building block is not set to a default value.
5. The method of claim 3 wherein broadcasting information comprises:
- for each building block, transmitting a respective index for each of the options supported by the access point.
6. The method of claim 3 further comprising:
- receiving an indication of UE type or capability from the first UE, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks;
- wherein transmitting to or receiving from the first UE using the first air interface configuration composed of air interface blocks building blocks set to options supported by both the access point and the first UE comprises: where the UE type or capability is associated with support for only one option for a given building block, setting the option of the given building block to the one option.
7. The method of claim 3 further comprising:
- receiving an indication of UE type or capability from the first UE, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks;
- wherein transmitting to or receiving from the first UE using the first air interface configuration composed of air interface building blocks set to options supported by both the access point and the first UE comprises:
- where the UE type or capability is associated with support for two or more options for a given building block, receiving an indication from the first UE of a selected one of the two or more options and transmitting or receiving with the given building block according to the selected one of the two or more options; or
- where the UE type or capability is associated with support for two or more options for a given building block, selecting one of the two or more options for the given building block, and transmitting an indication to the first UE of the selected one of the two or more options.
8. The method of claim 3 wherein:
- for at least one service, transmitting or receiving comprises setting an option for at least air interface one building block to a default value for the service.
9. The method of claim 1 further comprising:
- broadcasting information comprising an index of a respective option for each of at least one building block of the first air interface configuration, each building block having a predefined set of possible options each having an index,
- wherein communicating with the first user equipment with the first air interface configuration for the first service comprises transmitting to or receiving from the first UE using the first air interface configuration in accordance with the broadcast information.
10. The method of claim 9 wherein the at least one building block, or the set of possible options for a given building block, is dependent on frequency band or system bandwidth.
11. The method of claim 9 further comprising:
- when downlink data arrives or when a session initiates, transmitting a signal or message indicating a service of the first and second services used for the transmission or session, and transmitting the data using the indicated service; or
- transmitting the downlink data using a service of the first and second services, the transmission implicitly indicating the service used for the transmitting.
12. The method of claim 9 further comprising:
- transmitting downlink control information in a control channel to schedule a transmission, and including in the control information an indication of which service to use for the transmission.
13. A method in a user equipment in an access network comprising:
- communicating with a first access point (AP) with a first air interface configuration for a first service;
- communicating with a second AP with a second air interface configuration for a second service;
- wherein the first service is in a first slice differentiating from a second slice for the second service in the access network; and
- wherein the first and second air interface configurations are respectively in association with different numerologies, and each numerology comprises at least two of the following parameters: sub-carrier spacing, symbol duration, or CP length.
14. The method of claim 13 wherein the first and second services include at least one of an eMBB service, a URLLC service, an mMTC service, a video service, a voice service, a gaming service, a V2X service, or an emergency service.
15. The method of claim 13 further comprising:
- for the first service, receiving broadcast information indicating at least one option supported by the first access point for each of a plurality of air interface building blocks;
- wherein communicating with the first access point with the first air interface configuration for the first service comprises transmitting to or receiving from the first access point using the first air interface configuration composed of air interface building blocks set to options supported by both the access point and the UE.
16. The method of claim 15 wherein receiving the broadcast information comprises using an air interface in which at least one building block is set to a default value; or using an interface in which at least one building block is not set to a default value.
17. The method of claim 15 wherein receiving broadcast information comprises
- for each building block, receiving a respective index for each of the options supported by the first access point.
18. The method of claim 15 further comprising:
- transmitting an indication of UE type or capability to an access point, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks.
19. The method of claim 15 further comprising:
- transmitting an indication of UE type or capability to the first access point, the UE type or capability associated with one or more supported options for each of a plurality of the air interface building blocks;
- where the UE type or capability is associated with support for two or more options for a given building block, transmitting an indication to the first access point of a selected one of the two or more options.
20. The method of claim 15 further comprising:
- receiving uplink scheduling information on a control channel to schedule an uplink transmission, and scheduling information including an indication of which service to use for the uplink transmission.
21. The method of claim 13 further comprising:
- receiving broadcast information comprising an index of a respective option for each of at least one building block of the first air interface configuration, each building block having a predefined set of possible options each having an index;
- wherein communicating with the first access point with the first air interface configuration for the first service comprises transmitting to or receiving from the first access point using the first air interface configuration in accordance with the broadcast information.
22. The method of claim 21 further comprising:
- receiving a signal or message indicating a service of the first and second services used for a downlink transmission or session; or
- receiving a downlink transmission using a service of the first and second services, the transmission implicitly indicating the service used for the transmission.
23. An access point comprising:
- a non-transitory memory storage comprising instructions; and
- one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to: communicate with a first user equipment (UE) with a first air interface configuration for a first service; and communicate with a second UE with a second air interface configuration for a second service; wherein the first service is in a first slice differentiating from a second slice for the second service in an access network; and wherein the first and second air interface configurations are respectively in association with different numerologies, and each numerology comprises at least two of the following parameters: sub-carrier spacing, symbol duration, or CP length.
24. A user equipment comprising:
- a non-transitory memory storage comprising instructions; and
- one or more processors in communication with the non-transitory memory storage, wherein the one or more processors execute the instructions to: communicate with a first access point (AP) with a first air interface configuration for a first service; and communicate with a second AP with a second air interface configuration for a second service; wherein the first service is in a first slice differentiating from a second slice for the second service in an access network; and wherein the first and second air interface configurations are respectively in association with different numerologies, and each numerology comprises at least two of the following parameters: sub-carrier spacing, symbol duration, or CP length.
Type: Application
Filed: Feb 15, 2018
Publication Date: Jun 28, 2018
Inventors: Lu Rong (Shenzhen), Jianglei Ma (Ottawa), Peiying Zhu (Ottawa), Wen Tong (Ottawa), Kelvin Kar Kin Au (Kanata)
Application Number: 15/897,798