This invention relates generally to mobile network architectures and, more specifically, relates to how different “logical instantiations” of mobile networks can be supported over a fully or partially shared infrastructure.
This section is intended to provide a background or context to the invention disclosed below. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise explicitly indicated herein, what is described in this section is not prior art to the description in this application and is not admitted to be prior art by inclusion in this section. Abbreviations that may be found in the specification and/or the drawing figures are defined below, after the main part of the detailed description section.
As a UE traverses cellular networks, the UE interacts with many different RANs. The UE could interact with RANs from different operators, for instance, and/or with RANs having different bearers or air interfaces, and/or with RANs from different cells (e.g., large cells commonly called macro cells, or small cells). These different RANs can be thought of as different “logical instantiations” of mobile networks, which can be supported over a fully or partially shared (e.g., by different operators) infrastructure. These logical instances (often denoted as herein as “network slices” or simply “slices”) can be tailored for different use cases and services, depending on the customers' requirements.
In general, a mobile network may have to support very different use cases which vary in their required connectivity (or coverage), robustness (or frame errors), throughput, latency, mobility pattern, and/or number of connected devices. Each use case may require different technologies in order to satisfy the demands of one or multiple UEs.
Current approaches for RAN sharing (e.g., multi-operator RAN, MORAN) exhibit limited flexibility, scaling, and customization characteristics and therefore do not enable operation of multiple logical mobile networks (each addressing a particular use case) in the RAN domain.
This section is intended to include examples and is not intended to be limiting.
In an exemplary embodiment, a method comprises the following: determining one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks; and sending information for the determined one or more requirements to a multiple node controller to allow the multiple node controller to output information to enable configuration of radio resource control, the configuration causing the radio resource control to cause one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
In another exemplary embodiment, a method comprises the following: receiving information corresponding to one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks; and configuring radio resource control such that the radio resource control causes one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
A further exemplary embodiment is a method. The method comprises the following: receiving mapping that maps different logical instances of mobile networks and their associated service flows to radio subflows that flow through different radio legs and to user equipment, wherein the radio subflows correspond to data flows between the user equipment and the logical instances of the mobile networks, and wherein each data flow has one or more requirements; and causing one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
Another exemplary embodiment is a computer program comprising program code for executing the method according to the previous paragraphs. A further example is the computer program according of this paragraph, wherein the computer program is a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
In a further example, an apparatus comprises at least one processor, and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to perform the method of any of the methods in the previous paragraphs.
An additional exemplary embodiment is an apparatus, comprising: means for determining one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks; and means for sending information for the determined one or more requirements to a multiple node controller to allow the multiple node controller to output information to enable configuration of radio resource control, the configuration causing the radio resource control to cause one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
A further exemplary embodiment is an apparatus. The apparatus comprises the following: means for receiving information corresponding to one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks; and means for configuring radio resource control such that the radio resource control causes one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
An additional exemplary embodiment is an apparatus, comprising: means for receiving mapping that maps different logical instances of mobile networks to radio subflows that flow through different radio legs and to user equipment, wherein the radio subflows correspond to data flows between the user equipment and the logical instances of the mobile networks, and wherein each data flow has one or more requirements; and means for causing one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
A further example is a communication system comprising any of the apparatus described in this section.
In the attached Drawing Figures:
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.
As noted above, a mobile network may have to support very different use cases and each use case may require different technologies in order to satisfy the demands of one or multiple UEs. One difficulty is the mapping of different logical mobile networks to a multi-connectivity setup with appropriate parameterization in order to guarantee quality of service requirements of each logical mobile network (e.g., slice) in general as well as the service flow specific requirements of single UEs in particular. A logical instantiation of a mobile network, briefly referred to herein as “logical mobile network” (or “slice”), forms a self-contained and complete mobile network. While this network is comprised of all required (3GPP) functionality to operate as a dedicated mobile network, the network can at the same time share infrastructure resources and functions with other logical mobile network instantiations.
Further, for the purpose of isolation, different security contexts may apply. Each service flow might require a separate security context for integrity protection and encryption.
Exemplary embodiments herein serve as enablers for operating multiple logical mobile networks (each addressing a particular use case) in the RAN domain. Exemplary embodiments may also guarantee the quality of service requirements of mobile networks and the service flow specific requirements of single UEs.
The exemplary embodiments herein address operating multiple logical mobile networks using the same radio access network infrastructure. In particular, the exemplary embodiments consider a case where a user terminal (referred to as a UE herein) connects, through different radio legs, to different network slices. Different radio legs may mean the following:
1) Different air interface technologies;
2) Different physical radio access points (using the same or different air interface technologies); and
3) Different carrier frequencies.
In the following, the above list is referred to as a general ‘multi-connectivity’ setup.
Before proceeding with description of the exemplary embodiments, some additional introduction is presented.
In terms of one possible technique for operating multiple logical mobile networks using the same radio access network infrastructure, there is the multi-operator RAN (MORAN). This exploits the concept of network sharing. See 3GPP TR 32.851 V12.1.0, “Study on Operations, Administration and Maintenance (OAM) aspects of Network Sharing”, December 2013; and 3GPP TS 23.251 V8.2.0, “Network sharing; Architecture and functional description”, March 2010.
In this example, shared resources include one or more of the following: transport interface (resource splitting); eNB hardware; baseband capacity; feeder cables and antennas (using a combiner if needed); server racks, power supply and batteries at an eNB level.
The following resources are dedicated: cell level parameter settings (e.g., a dedicated PLMN is broadcasted); licensed frequencies; S1 interfaces; and EPC and services.
It is noted that further MORAN variants with varying levels of sharing exist. However, in contrast to the techniques presented herein, those variants support neither 5G multi-connectivity scenarios nor UE attachment to multiple logical networks. Rather, one UE connects to a single operator's PLMN.
Another possible technique for operating multiple logical mobile networks using the same radio access network infrastructure is MOCN (Multi-Operator Core Network). MOCN for LTE has been standardized in 3GPP since Rel. 8. See the following: 3GPP TS 23.251 V8.2.0, “Network sharing: Architecture and functional description”, March 2010; 3GPP TS 23.401 V13.5.0, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” December 2015; and 3GPP TR 22.951, V13.0.0, “Service aspects and requirements for network sharing,” January 2016. In MOCN, the eUTRAN is common to several mobile network operators and shared between them.
In terms of network selection, the PLMN IDs 230 of different mobile network operators 275 are broadcasted on the air in the System Information Block (SIB). In total up to six PLMNs can be broadcasted in SIB1. The user equipment (UE) 290 decodes system information and performs PLMN ID selection. The finally selected PLMN ID 230 is specified in an RRC connection procedure.
The eNodeB 260 uses the selected PLMN ID 230 to forward an attachment request to an MME 270 belonging to the correct PLMN. In order to fulfil the Service Level Agreement (SLA) between eUTRAN and different CN operators (e.g., an excess of traffic of one CN operator may lead to a violation of SLA of another operator sharing the eUTRAN), non-standard features are provided by vendors, e.g., with resource reservation and smart scheduler on the transport side, different VLANs on S1 and X2 may provide separation between CN operators 275 and the shared eNodeB 260. Since neighbor cells are common for both operators 275, mobility is provided by proprietary features.
Concerning LTE dual connectivity, which is also known as inter-site carrier aggregation, this is used to achieve carrier aggregation between sites. This is an attractive solution for Heterogeneous Networks (HetNets) with no ideal backhaul network. Dual connectivity allows mobility management to be maintained on the macro layer while aggregating small cells to provide extra user plane capacity.
With regard to dual connectivity,
In both options, the user plane is split between the MeNB 325, typically a macro cell, and the SeNB 335, typically a small cell. In Option 1a, the user plane is conveyed either to bearer #1320-1 or bearer #2320-2, while in Option 3c the data bearer split/aggregation is performed in the macro cell. The radio signaling bearer is always terminated in the macro cell.
Regarding terminology, the term “multi-connectivity” refers to a RAN feature where a single UE is configured with resources in different radios (e.g., radio cells). In case of 3GPP, the dual connectivity feature has been described above. The Packet Data Convergence Protocol (PDCP) serves as the aggregation layer and anchor for this kind of multi-connectivity option, configured and controlled by the Radio Resource Control (RRC) function. See, e.g., 3GPP, “TS 36.300 V12.8.0; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description”, January 2016. In 5th Generation (5G) mobile networks, a new layer called Network Convergence Sublayer (NCS) may be introduced with a similar scope as PDCP for multi-connectivity. Both terms can be used as synonyms in the following. It is further noted that NCS may be considered to be a combination of a PDCP instance and a SDAP instance.
Further concepts with a similar scope in 5G and in LTE are the following:
The exemplary embodiments herein provide techniques for implementing radio access network slicing in a mobile network. Additional detail regarding these techniques is presented after an example is presented of a system for implementing radio access network slicing in a mobile network. Turning to
By way of introduction, in
The slicing controller 481 can be: 1) co-located with a RAN processor, i.e., an entity (illustrated in reference 420) which processes RAN signals; or 2) connected through any communication link with RAN processing equipment. In the example of
The slices 410 are different logical mobile networks. Slice A 410-1 includes a SF A 405-1 and a NAS 415-1, and slice B 410-2 includes SF B 405-2 and NAS 415-2. The slices 410 communicate with the RAN 420 via the links 482, which may be wired or wireless. The RAN 420 includes NCS 430-1 (operating with slice A 410-1) and NCS 430-2 (operating with slice B 410-2) and also RRC function 445. The NCS 430-1 interacts with 5G radio leg 1425-1 and 5G radio leg 2425-2 and the NCS 430-2 interacts with 5G radio leg 1425-1 and 5G radio leg 3425-3. UE A 290-1 interacts with 5G radio legs 425-1 and 425-2 via radio links 475-1 and 475-2, respectively, and via RSFs 465-1 and 465-2, respectively. UE B 290-2 interacts with 5G radio legs 425-1 and 425-3 via radio links 475-3 and 475-4, respectively and via RSFs 465-3 and 465-4, respectively. Thus, UE A 290-1 interacts with slice A 410-1 (through the 5G radio legs 425-1 and 425-2 and NCS 430-1), and the UE B 290-2 interacts with slice B 410-2 (through the 5G radio legs 425-1 and 425-3 and NCS 430-2). It should be noted that the NCS instances 430 are not necessarily co-located. That is, the NCS instance 430 may not necessary performed on the same processor or even the same computer. Instead, NCS instances 430-1 and 430-2 may be performed by two separate computers, e.g., at different physical locations.
The elements of
The computer readable memories 455 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories 455 may be means for performing storage functions. The processors 452 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors 452 may be means for performing functions, such as controlling the MNC 470, and other functions as described herein.
For instance, the slicing controller 481 may be separate from the RAN 420 and communicate with the RAN using N/W I/F 461 and not use wireless. The slicing controller 481 in this example would not use or contain the antennas 458 or the transceiver 460. The MNC 470/RRC function 445 may also communicate with the slicing controller 481, slices 410, and radio legs 425 via (e.g., multiple) N/W I/F(s) 461 and therefore also not use or contain the antennas 458 or the transceiver 460. The links 423, 482, and those used for RSFs 465 are wired. Meanwhile, the radio legs 425 would contain all the elements of the device 471 illustrated in
Additional examples and details are presented using
A mobile network as above may be further characterized in the following.
Further details are as follows. As illustrated by
For instance, one UE 290 may be connected to two slices 410 (as in
A controller such as the slicing controller 481, which is informed about the individual requirements of each slice, then may perform either of the following in an exemplary embodiment:
a) configure the RRC function 445 such that the individual radio subflows will satisfy the slice requirements, or
b) provide the RRC function 445 with a set of policies which allows appropriate configuration of the multi-connectivity setup and according radio subflows while satisfying the defined requirements.
The set of policies may cover one or more of the following parameters:
In order to support this setup, the RRC function 445 maps services from individual logical mobile networks to different service/radio flows (e.g., bearers in 3GPP LTE). Each service/radio flow is uniquely assigned to an NCS instance 430 which processes the data and may be differently configured. The corresponding mapping 440 may be performed using the following as examples:
In a similar procedure for LTE-based networks, EPS bearers are mapped to radio bearers which may support dual connectivity configurations (i.e., split bearer, MCG bearer, SCG bearer) and are configured according to the policy mentioned above. EPS bearers may be connected to different network slices by using enhanced RAN-CN interface features such as the S1-Flex feature or DÉCOR (dedicated core networks).
For each slice 410, the RRC function 445 may maintain context data for each user terminal and for each slice, i.e., RRC states may be defined on the tuple (UE, slice). For instance, the RRC connection state may be IDLE for (UE1, slice A 410-1) and CONNECTED for (UE1, slice B 410-2). Therefore, slice-specific RRC messages are exchanged. This further implies that a user terminal which is connected to multiple slices also maintains for each slice its own RRC state. In order to ensure that control and user plane data can be correctly assigned to individual slices, service flows from different slices are eventually mapped to different logical and possibly physical channels. For instance, if a UE is connected to two different slices then the data originating from slice A 410-1 will be delivered through a dedicated transport channel uniquely assigned to slice A 410-1.
Alternatively, in certain configurations, e.g., if the network slices 410 are associated to different carrier frequencies or cell layers, dedicated RRC entities may be instantiated which perform mobility and state control independently from each other, e.g., per-UE and per slice (which refer to the tuple (UE, slice) used above), or only loosely coupled via coordination information. In this case, each RRC entity maintains its own UE context and state information.
For each slice 410, an individual RRC security context may be maintained (see
More specifically, the following steps may be performed (assuming that the UE sent network attachment requests to the corresponding logical mobile networks) in an exemplary embodiment:
This ensures an isolation of individual slices 410 on a cryptographic level such that security breaches across slices are avoided. Alternatively, a default slice 410 may be identified and the security context of this default slice is used in order to derive the radio access network security information. In this case, all slices would have the same security context within the radio access network, which reduces the complexity and management overhead within the radio access network 420 but also reduces the isolation between individual slices 410 within the radio access network 420.
Each slice 410 may still set up its own multi-connectivity connection (see
Each radio subflow may be implemented by a different software module (such as an instantiation of the CTL logic 450-2). Similarly, the individual air interfaces as well as the individual logical and physical channels may be implemented using different software modules. The correct instantiation of the software modules and their parameterization may be performed according to the requirements of the respective mapped service flow. The different software modules would be instantiated by the RAN and exist within the RAN 420. Logical and physical channels are defined within the RAN and are understood by each RAT and the UE. It may be that each RAT has a different set of logical and physical channels. Further, the slices 410 may have different sets of physical and logical channels.
Turning to
In block 710, the slicing controller 481 determines one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks. In block 715, the slicing controller 481 sends information about the determined requirements to the MNC 470.
In block 720, the MNC 470 creates mapping 440 (based on subset of information/configurations) between the SFs 405 and the RSFs 465 in order to meet the requirements of the SFs 405. In block 730, the MN 470 configures RRC function 445 (e.g., based on subset of information/configurations) such that the RRC function 445 causes one or more RSFs 465 to satisfy the one or more requirements for the SFs 405. There are a number of ways for the MNC 470 to perform block 730. For instance, in block 740, the MNC 470 could actually configure RRC function 445. Alternatively (or possibly in addition), the MNC 470 could in block 750 send information to RRC function 445 that configures the RRC function 445 correctly.
Referring to
The RRC function 445 in block 810 implements and receives configuration and mapping 440 between the SFs 405 and the RSFs 465 in order to meet the service requirements of the SFs 405. In block 820, the RRC function 445 configures NCSs 430 with mapping 440. For instance, the RRC function 445 may send (e.g., individual) appropriate maps to each NCSs or otherwise configure each NCS 430 with appropriate mapping. In block 830, the NCSs then routes SFs 405 to RSFs 465 (and to radio legs 425) accordingly.
In block 840, the RRC function 445 maintains individual RRC security context such that each RRC connection (e.g., slice 410 and its SF 405 or its corresponding radio flow) uses a different security key. Block 840 may be performed in a number of ways, and one such exemplary implementation is illustrated by blocks 850-870. In block 850, the RRC function 445 requests security derivation functions and associated keys from all logical mobile networks to which the UE requests to connect. The RRC function 445 in block 860 derives individual keys (using the requested and received security derivation function) for each slice (e.g., each SF and corresponding NCS) using NAS security context. In block 870, the RRC function 445 encrypts user and control plane data originating from or destined to a particular logical mobile network using the key provided for the individual slice.
In block 910, the slicing controller 481 determines one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks. In block 920, the slicing controller 481 sends information for the determined one or more requirements to a multiple node controller to allow the multiple node controller to output information to enable configuration of radio resource control. The configuration causes the radio resource control to cause one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows. In the examples that follow, the flow in
Is should be noted that it would be possible that in some cases, DRBs (e.g., radio subflows) may need to be remapped to network slices. This might be true, for instance, in case of mobility from a base station to another base station which supports not the same slices as the first one.
In block 1010, the MNC 470 receives information corresponding to one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks. In block 1020, the MNC 470 configures radio resource control such that the radio resource control causes one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
Additional examples are as follows. The flow in
The method of example 2, wherein configuring further comprises providing the radio resource control with a set of policies, wherein in response to the policies being applied by the radio resource control, the policies cause the one or more radio subflows to satisfy the one or more requirements for the data flow.
The method of example 3, wherein the set of policies cover one or more of the following parameters:
radio access technology types;
geographical areas;
quality of service parameters;
protocol configurations;
base station identifications, cell identifications, and other identifications such as network slice IDs which can be used for network selection;
carrier frequencies;
multi-carrier configurations;
mobility information; and
access barring parameters and subscriber group information.
The method of any of examples 2 to 4, wherein the data flow comprises one of a service flow (SF) or an evolved packet system bearer, which both denote a logical end-to-end connection with specific service requirements.
The method of any of examples 2 to 5, wherein the different radio legs comprise one or more of the following: different air interface technologies; different physical radio access points; and different carrier frequencies.
The method of example 6, wherein the different physical radio access points use a same air interface technology or use different air interface technologies.
The method of any of examples 2 to 7, wherein each of the different logical instances of the mobile networks corresponds to a different logical radio access network and wherein the radio resource control implements a physical radio access network that communicates wirelessly with the user equipment.
The method of example 8, wherein at least two of the different radio access networks are controlled by different operators.
The method of any of examples 2 to 9, further comprising causing the data flow and the one or more radio subflows to be uniquely assigned to and flow through a network convergence sublayer instance.
The method of example 10, wherein:
there are a plurality of network convergence sublayer instances and multiple data flows for the user equipment, one data flow from each and only one of multiple logical instances of the mobile networks, and each data flow flows through only one of the plurality of network convergence sublayer instances;
receiving information further comprises receiving information for one or more requirements for each of the multiple data flows;
each data flow has a corresponding set of one or more radio subflows; and
configuring further comprises configuring the radio resource control such that the radio resource control causes each set of one or more radio subflows to satisfy the one or more requirements for the corresponding data flow.
The method of any of examples 2 to 11, further comprising maintaining individual RRC security context such that each logical instance of a mobile network uses a different security key and the one or more radio subflows corresponding to a logical instance of a mobile network are assigned a same key as used by the corresponding logical instance of the mobile network.
The method of any of examples 2 to 12, wherein configuring further comprises using mapping from logical instances and their associated service flows of the mobile networks to radio subflows in order to determine which one or more radio subflows correspond to which logical instances of the mobile networks.
The method of any of examples 2 to 13, further comprising causing the different radio legs to communicate the radio subflows to the user equipment.
The method of any of examples 2 to 14, performed by a multi-node controller that is located remotely from the radio resource control or co-located with the radio resource control.
In block 1110, the RRC function 445 receives mapping that maps different logical instances of mobile networks and their associated service flows to radio subflows that flow through different radio legs and to user equipment, wherein the radio subflows correspond to data flows between the user equipment and the logical instances of the mobile networks, and wherein each data flow has one or more requirements. In block 1120, the RRC function 445 causes one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
Additional examples are now presented. In these examples, the flow in
The method of example 16, wherein causing further comprises configuring network convergence sublayers to create the radio subflows from the network convergence layers to the different radio legs to satisfy the one or more requirements for the data flows.
The method of any of examples 16 or 17, wherein receiving further comprises receiving a set of policies, and wherein causing further comprises applying the policies to cause the one or more radio subflows to satisfy the one or more requirements for the data flow.
The method of example 18, wherein the set of policies cover one or more of the following parameters:
radio access technology types;
geographical areas;
quality of service parameters;
protocol configurations;
base station identifications, cell identifications, and other identifications such as network slice IDs which can be used for network selection;
carrier frequencies;
multi-carrier configurations;
mobility information; and
access barring parameters and subscriber group information.
The method of any of examples 16 to 19, wherein the data flow comprises one of a service flow (SF), or an evolved packet system bearer, or a PDU session, or a QoS flow, which denotes a logical end-to-end connection with specific service requirements.
The method of any of examples 16 to 20, wherein the different radio legs comprise one or more of the following: different air interface technologies; different physical radio access points; and different carrier frequencies.
The method of example 21, wherein the different physical radio access points use a same air interface technology or use different air interface technologies.
The method of any of examples 16 to 22, wherein each of the different logical instances of the mobile networks corresponds to a different logical radio access network and wherein the radio resource control implements a physical radio access network that communicates wirelessly with the user equipment.
The method of example 23, wherein at least two of the different radio access networks are controlled by different operators.
The method of any of examples 16 to 24, further comprising causing the data flow and the one or more radio subflows to be uniquely assigned to and flow through a network convergence sublayer, or a PDCP instance, and/or a SDAP instance.
The method of example 25, wherein:
there are a plurality of network convergence sublayer instances and multiple data flows for the user equipment, one data flow from each and only one of multiple logical instances of the mobile networks, and each data flow flows through only one of the plurality of network convergence sublayer instances;
receiving mapping further comprises receiving mapping for each of the multiple data flows;
each data flow has a corresponding set of one or more radio subflows; and
causing further comprises causing each set of one or more radio subflows to satisfy the one or more requirements for the corresponding data flow.
The method of any of examples 16 to 26, further comprising maintaining individual RRC security context such that each logical instance of a mobile network uses a different security key and the one or more radio subflows corresponding to a logical instance of a mobile network are assigned a same key as used by the corresponding logical instance of the mobile network.
The method of any of examples 16 to 27, wherein causing further comprises using the mapping in order to determine which one or more radio subflows correspond to which logical instances of the mobile networks.
The method of any of examples 16 to 28, further comprising causing the different radio legs to communicate the radio subflows to the user equipment.
The method of any of examples 16 to 29, performed by radio resource control.
An apparatus, comprising:
means for determining one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks; and
means for sending information for the determined one or more requirements to a multiple node controller to allow the multiple node controller to output information to enable configuration of radio resource control, the configuration causing the radio resource control to cause one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
An apparatus, comprising:
means for receiving information corresponding to one or more requirements for data flows though different logical instances of mobile networks, wherein the data flows are between user equipment and the logical instances of the mobile networks; and
means for configuring radio resource control such that the radio resource control causes one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
The apparatus of example 32, further comprising means for performing any of the methods of examples 3 to 15.
An apparatus, comprising:
means for receiving mapping that maps different logical instances of mobile networks to radio subflows that flow through different radio legs and to user equipment, wherein the radio subflows correspond to data flows between the user equipment and the logical instances of the mobile networks, and wherein each data flow has one or more requirements; and
means for causing one or more radio subflows, which flow through different radio legs and to the user equipment, to satisfy the one or more requirements for the data flows.
The apparatus of example 34, further comprising means for performing any of the methods of examples 17 to 30.
A communication system comprising at least one of the following: an apparatus of example 31; an apparatus of examples 32 or 33; and/or an apparatus of examples 34 or 35.
A computer program comprising program code for executing the method according to any of examples 1 to 30.
The computer program according to example 37, wherein the computer program is a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
An apparatus, comprising:
at least one processor; and
at least one memory including computer program code,
the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform the method of any of examples 1 to 30.
Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a “computer-readable medium” may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in
If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined.
Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.
It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.
The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:
This patent application is a U.S. National Stage application of international Patent Application Number PCT/EP2017/057935 filed Apr. 4, 2017, and claims priority to U.S. provisional application 62/318,406 filed Apr. 5, 2016, which are hereby incorporated by reference in their entireties.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2017/057935 | 4/4/2017 | WO | 00 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2017/174550 | 10/12/2017 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
20180337822 | Heimes | Nov 2018 | A1 |
20190141081 | Kunz | May 2019 | A1 |
20190246277 | Hamzeh | Aug 2019 | A1 |
20190258782 | Lerner | Aug 2019 | A1 |
Entry |
---|
3GPP TS 23.501 V0.3.1 (Mar. 2017), “3rd Generation Partnership Project; Technical specification Group Services and System Aspects; System Architecture for the 5G System; System 2 (Release 15)”, 97 pgs. |
3GPP TR 22.891 V1.3.1 (Feb. 2016), “3rd Generation Partnership Project; Technical specification Group Services and System Aspects; Feasibility Study on New Services and Markets Technology Enablers; Stage 1 (Release 14)”, 97 pgs. |
3GPP TR 23.799 V0.3.0 (Mar. 2016), “3rd Generation Partnership Project; Technical specification Group Services and System Aspects; Study on Architecture for Next Generation System (Release 14)”, 52 pgs. |
NGMN 5G White Paper, version 1.0, © 2015 Next Generation Mobile Networks Ltd., paras. 4.3.1, 5.3.3, and 5.5, 8 pgs. |
3GPP TR 22.951 V13.0.0 (Dec. 2015), “3rd Generation Partnership Project; Technical specification Group Services and System Aspects; Service aspects and requirements for network sharing (Release 13)”, 19 pgs. |
3GPP TS 23.251 V8.2.0 (Mar. 2010), “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network Sharing; Architecture and functional description (Release 8)”, 20 pgs. |
3GPP TR 32.851 V12.1.0 (Dec. 2013), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Study on Operations, Administration and Maintenance (OAM) aspects of Network Sharing (Release 12), 38 pgs. |
3GPP TS 23.401 V13.5.0 (Dec. 2015), “3rd Generation Partnership Project; Technical specification Group Services and Systems Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 13)”, 337 pgs. |
ETSI TS 136 300 V12.8.0 (Jan. 2016) (3GPP TS 36.300 V 12.8.0 Release 12), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); overall description stage 2”, 261 pgs. |
Number | Date | Country | |
---|---|---|---|
20190159024 A1 | May 2019 | US |
Number | Date | Country | |
---|---|---|---|
62318406 | Apr 2016 | US |