GB2546982A

GB2546982A - Traffic distribution for inter-cell carrier aggregation

Info

Publication number: GB2546982A
Application number: GB1601834.3A
Authority: GB
Inventors: Ortiz Rocio; Le Pezennec Yannick; Dominguez Romero Francisco
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2016-02-02
Filing date: 2016-02-02
Publication date: 2017-08-09
Also published as: GB201601834D0

Abstract

A method of distributing traffic for transmission by inter-cell carrier aggregation within a cellular network, which includes receiving a plurality of traffic packets at a node 70 (such as a Mobility Management Entity MME node) of the cellular network, analysing the plurality of traffic packets to categorise each of the plurality of traffic packets according to an application type associated with traffic of the respective traffic packet, and distributing the plurality of traffic packets between a plurality of cells (such as a master/primary eNB macro-cell 20 and a Secondary eNB small cell 30) for transmission by carrier aggregation to User Equipment 60, in accordance with the respective categorisation of each of the plurality of traffic packets. Analysing the plurality of traffic packets may comprise determining at least one transport layer protocol characteristic associated with the respective traffic packet, or may comprise one or more of: inspection of each of the plurality of traffic packets (light packet inspection); traffic pattern identification; heuristic packet analysis. Distributing the plurality of traffic packets may be performed in accordance with a categorisation indicated in DiffServ Code Point, DSCP, bits of each of the traffic packets.

Description

TRAFFIC DISTRIBUTION FOR INTER-CELL CARRIER AGGREGATION Technical Field of the Invention

The disclosure concerns a method of distributing traffic for transmission inter-cell carrier aggregation within a cellular network, particularly for network architectures based on Long Term Evolution (LTE) approaches. Also considered is a corresponding computer program and a cell controller.

Background to the Invention A conventional cellular network comprises a plurality of base stations or cells, each cell transmitting to one or more mobile or user terminals (each referred to as a respective User Equipment or UE) using at least one respective carrier. In particular, the Third Generation Partnership Project (3GPP) have specified Long Term Evolution (LTE) architectures, in which each cell or base station (called an eNodeB or eNB in this context) transmits downlink signals to UEs using one or more Orthogonal Frequency Division Multiplexed (OFDM) carriers. Each carrier occupies a frequency bandwidth and therefore defines a data rate capacity for delivering services to the UEs. A key desideratum for advanced radio access networks is the ability to support of downlink peak data rates of 1 Gbps. In accordance with 3GPP Release 8 or 9 standards, the LTE system supports a maximum carrier bandwidth of 20 MHz. In view of spectral efficiency limitations, this is inadequate to support such a peak data, even considering the highest order ΜΙΜΟ (Multiple-Input Multiple-Output) schemes. For these reasons, in 3GPP Release 10 (referred to as LTE-A) the concept of Carrier Aggregation (CA) has been introduced. CA enables a user terminal to utilize data transmission resources of more than one frequency carrier (called the component carrier, CC). As defined in the 3GPP Release 10 standard, CA allows a UE serviced by base station operating on more than one frequency carrier, to communicate with the base station on multiple CCs at the same time. For backwards compatibility, the UE is logically attached to only one CC at a time. This is called the Primary Component Carrier (PCC), which corresponds with the serving cell in line with the nomenclature of Release 8 or 9.

For a CA-supporting UE, one or more Secondary Component Carriers (SCC) can be configured by the eNodeB in addition to the PCC. Both the PCC and the SCC(s) are configured on a per UE basis. This means that one CC can be a PCC for one UE, but a SCC for a different UE. The CA operation is controlled per UE on the Radio Resource

Control (RRC) and Medium Access Control (MAC) layers. RRC signalling permits an eNodeB to control the CA feature for each UE and the RRC layer can control configuration, activation and deactivation of the SCCs for a UE. This is in addition to the RRC layer’s normal functionality. Once CA is activated for the UE, the MAC layer decides on allocation of radio resources from the PCC and the active SCC(s). At this stage, carrier load balancing and cross-carrier scheduling may be employed.

The 3GPP Release 10 standard defines that the CA feature is to support aggregation of up to 5 CCs per UE, therefore providing up to 100 MHz in total bandwidth. The CCs can be allocated in the same frequency band (continuous or discontinuous aggregation) or in different frequency bands (discontinuous aggregation). Moreover, the coverage regions of the PCC and SCC(s) need not overlap, but the aggregation of carriers is only possible within common coverage areas of the CCs. General CA configurations are, however, restricted by the capabilities of the UE radio transceiver. The extended (Release 10) UE capabilities define: the maximum number of supported CCs (PCC and SCCs); supported frequency bands; and support for intra-frequency and inter-frequency band CA.

Developments in CA have allowed inter-site CA, which is especially advantageous for Distributed-Radio Access Network (D-RAN) implementations. Inter-cell CA, in which the CCs do not need to belong to the same base station (eNodeB), has also become possible. In 3GPP Release 12, Dual Connectivity has also been standardised, which permits user terminals to maintain simultaneous connections to two cells and share radio resources between eNodeBs on a common frequency. This has further facilitated inter-eNB carrier aggregation.

Referring first to Figure 1, there is shown a schematic diagram of a part of a known network architecture to permit inter-eNB carrier aggregation, particularly using an LTE architecture. A Master eNB 20 and a Secondary eNB 30 each communicate with a UE 60 using a respective Uu (air) interface 65. An Mobility Management Entity (MME) 70 interfaces with a Home Subscriber Server (HSS) 80 and the MME 70 communicates with the Master eNB 20 and the Secondary eNB 30 over respective S1 interfaces 75.

Moreover, the Master eNB 20 and the Secondary eNB 30 can communicate with each other over an Xn interface 50. The Xn interface allows the Master eNB 20 and the Secondary eNB 30 to exchange information and for the Master eNB 20 to control the Secondary eNB 30 if required. The Secondary eNB 30 may also make autonomous decisions. Typically (although not necessarily), the Master eNB 20 is a macro cell and the Secondary eNB 30 is a small cell. One generalised approach for inter-eNB carrier aggregation is discussed in WO2012/136256A1. Thus, a carrier may be aggregated at the UE 60, such that Master Base Station (MeNB) 20 transmits carrier frequency X to the UE and Secondary Base Station (SeNB) 30 transmits carrier frequency Y to the UE. The additional, aggregated carrier can be referred to as a Secondary Cell (SCell).

Transmission of data traffic to a single UE through carriers from different cells is not straightforward. In practice, the data traffic is split in one eNodeB and data allocated to another eNodeB is sent over the X2 interface, for transmission on a SCC. Deciding how to split the traffic between the cells presents a further difficulty.

One solution, proposed in W02013/138130A1, splits the data traffic into “traffic streams”. Each of these traffic streams has the same Quality of Service (QoS) requirement and in practice, the traffic stream is equivalent to a data radio bearer. Details of the Evolved Packet System (EPS) Bearer may be found in 3GPP TS 36.300. Then, the QoS Class Identifier (QCI) can be used to determine the QoS requirement. Each bearer is then mapped to a carrier that is best-suited to meet the QoS requirement. This approach is straightforward to implement and may improve resource allocation. However, it may not always be optimal, since data radio bearers are not designed for CA implementation and QoS requirements may be quite general in nature. Finding a more optimal technique for distributing traffic for inter-cell CA remains a challenge.

Summary of the Invention

Against this background, the present invention provides a method of distributing traffic for transmission by inter-cell carrier aggregation within a cellular network in accordance with claim 1. Also provided are a computer program in line with claim 14 and a cell controller according to claim 15. The invention may also be embodied in the form of programmable logic, firmware or other configurable system. Other preferred features are disclosed with reference to the claims and in the description below.

Instead of splitting the traffic using streams or radio bearers, a more detailed analysis of the traffic packets is carried out. The traffic packets are normally Internet Protocol, IP, packets. This uses one or more of: packet inspection (preferably light, although deep packet inspection may be possible); traffic pattern identification; and heuristic packet analysis. Using these analytical tools, each of the packets is categorised according to an associated application type. Then, each of the packets is distributed to a respective cell for CA transmission, based on their categorisation. The analysis can take place at the node, for example in an LTE network, the node may be a base station, such as an eNodeB.

Categorising by application type, rather than by traffic streams, allows considerations other than QoS requirements to be taken into account. One particular issue relates to the need to transmit data from the node, which is preferably the master cell, to one or more secondary cells over the X2 interface. This can increase the latency of some of the packets. Moreover, certain packets may use transport control protocols that employ ordered delivery, such as Transmission Control Protocol (TCP). In this case, delivery of some packets over the X2 interface can cause these packets to arrive out of order, possibly even leading to a reduction in throughput compared with single carrier transmission. The approach of this invention can mitigate such issues.

In one approach, the packet inspection identifies a transport layer protocol characteristic, such as one or more of: the transport layer protocol in use; whether the transport layer protocol is connection-oriented; if the transport layer protocol provides ordered delivery of packets; if congestion control is in operation; whether flow control is used; and a networking port associated with the packet. These characteristics are indicative of application type. In particular, those packets using ordered delivery and/or flow control and preferably, those also using the same transport layer protocol, are distributed for transmission by the same cell. Other packets, especially those not using ordered delivery, may be distributed for transmission by any cell. Beneficially, those packets using the same associated networking port may also be distributed for transmission by the same cell. Meeting latency requirements may additionally be taken into account. Advantageously, the master cell (transmitting the PCC) is used when packets are distributed for transmission by the same cell. This may especially be beneficial, as latency may be lower for the master cell.

Traffic pattern identification and/or heuristic packet analysis can be beneficial approaches when some of the plurality of traffic packets comprise encrypted content. For example, if IPsec or HTTPS protocols are in use, packet inspection may not be possible. Therefore, these approaches may also allow identification and inter-cell distribution by application type, rather than simply by QoS requirements.

Brief Description of the Drawings

The invention may be put into practice in various ways, one of which will now be described by way of example only and with reference to the accompanying drawing in which:

Figure 1 shows a schematic diagram of a part of a known network architecture to permit inter-eNB carrier aggregation; and

Figure 2 depicts a flowchart of a method in accordance with the invention.

Detailed Description of a Preferred Embodiment

One aim of the invention is to split the data traffic in a smart way per carrier, as part of the inter-eNB Carrier Aggregation (CA) procedure, so as not to impact the throughput. Since CA is implemented individually for each UE, the traffic for each UE is split in the downlink.

Referring to Figure 2, there is depicted a flowchart of a method in accordance with the invention. In a first step 100, a plurality of traffic packets are received at a node of the cellular network. This node may be part of the core network or it may be part of the Radio Access Network (RAN), for example a cell such as an eNB and particularly a master cell such as the MeNB 20.

In a second step 110, the plurality of traffic packets are analysed. This is preferably performed by one or more of: packet inspection; traffic pattern identification; and heuristic packet analysis. As a result of the analysis step 100, each of the plurality of traffic packets is categorised according to an application type associated with traffic of the respective traffic packet. The second step 110 is typically performed at the node (for example, at the base station or eNB). The application type may indicate: the specific application; a transmission parameter of the application, for example a parameter, type or name of a transport layer protocol required by the application and/or a networking port used by the application (such as a TCP networking port); and a type of user traffic used by the application (such as voice, video, picture, text). The application type may also indicate a QoS requirement, but does not indicate the QoS requirement alone. A third step 120 then distributes the plurality of traffic packets between a plurality of cells for transmission by carrier aggregation. This distribution is performed in accordance with the respective categorisation of each of the plurality of traffic packets. The plurality of cells for transmission by carrier aggregation optionally comprise a primary (or master) cell and a secondary cell. The third step 120 is also typically performed at the node.

In this approach, the bearer in which each the traffic packet is carried may not be relevant. Traffic packets from one bearer may be distributed to different carriers. In some embodiments, traffic packets from different bearers are distributed to the same carrier.

The method may be implemented as a computer program, logic circuitry, programmable logic, firmware, or other electronic, optical or similar technology. A computer readable medium carrying the computer program may also be considered. A network entity, such as a cell controller, configured in accordance with the method may further be provided. The network entity may be configured to distribute traffic for transmission by inter-cell carrier aggregation. A cell comprising a cell controller in accordance with this approach may be further provided. A base station comprising such a cell may additionally be considered.

Typically, the plurality of cells are based on a Long Term Evolution (LTE) architecture. However, other architectures may be considered, where carrier aggregation is possible.

The second step 110 (analysing the plurality of traffic packets) may comprise categorising at least one traffic packet associated with a first application type separately from at least one traffic packet associated with a second application type. For example, this may occur if the traffic packets comprise data for multiple types of application. Then, the third step 120 (distributing the plurality of traffic packets) may comprise distributing the at least one traffic packet associated with the first application type to a first cell of the plurality of cells (typically a primary or master cell, such as MeNB 20); and distributing the at least one traffic packet associated with the second application type to a second cell of the plurality of cells (such as a secondary cell, for example SeNB 30). The primary and secondary cells are generally each a part of a different respective base station or eNB, although it may be possible for the primary and secondary cells to be part of the same eNB. Hence, the traffic packets may be split between the cells according to their application type. Examples of this approach will be discussed in more detail below.

Additionally or alternatively, the second step 110 (analysing the plurality of traffic packets) may comprise categorising at least some of the plurality of traffic packets as associated with a specific (such as a first) application type. Then, the third step 120 (distributing the plurality of traffic packets) may comprise distributing all of the at least some traffic packets associated with the specific application type to the same (first) cell from the plurality of cells. In other words, some particular application types may be distributed only a particular cell. Again, examples of this will be discussed below. A first approach in the second step 110 (of analysis) is to carry out packet inspection. This preferably takes place at a cell, such as the eNB. There are several levels of packet inspection and for this invention, the simplest one (light or ‘lite’ inspection, which may sometimes be termed Transport Protocol port inspection’) is preferably used. In the preferred embodiment, the second step 110 comprises determining at least one transport layer protocol characteristic associated with the respective traffic packet. A light packet inspection can allow information about the transport layer protocol used to be identified.

The at least one transport layer protocol characteristic advantageously comprises one or more of: the transport layer protocol in use; whether the transport layer protocol is connection-oriented; if the transport layer protocol provides ordered delivery of packets; if congestion control is in operation; whether flow control is used; and a networking port associated with the packet. The application type can then be categorised in accordance with the identified at least one transport layer protocol characteristic. A number of examples in line with this approach can be considered. For instance, the transport layer protocol characteristic associated with the each of the plurality of traffic packets may be that the transport layer protocol does not provide ordered delivery of packets and/or flow control. An example of such a transport layer protocol is User Datagram Protocol (UDP). Then, the third step 120 (of distributing the plurality of traffic packets) may comprise distributing the identified at least one of the plurality of traffic packets (those using UDP or another transport protocol without ordered delivery and/or flow control) to any of the plurality of cells. Since UDP packets can be sent without order, it is feasible to send then in any carrier of the carrier aggregation.

In another example, the transport layer protocol characteristic associated with the each of the plurality of traffic packets may be that the transport layer protocol provides ordered delivery of packets and/or flow control. For instance, Transmission Control Protocol (TCP) may be such a protocol for these purposes. Then, the identified at least some of the plurality of traffic packets may be categorising as being associated with the same application type. Beneficially, the identified at least some of the plurality of traffic packets also all use the same transport layer protocol. Then, the third step 120 (of distributing the plurality of traffic packets) may comprise distributing the identified at least some of the plurality of traffic packets (those using TCP or another transport protocol with ordered delivery and/or flow control) to the same (specific) cell from the plurality of cells. In this way, the ordering of the packets may be preserved when CA is used, without loss of efficiency. The TCP packets for the UE are thereby all sent in the same carrier. The specific cell selected is preferably a master cell in this case, particularly where the node is the master cell or has a low latency link to the master cell (in comparison with the link between the node and the one or more secondary cells).

The table below provides a brief comparison of different transport protocols. The characteristics of any of these protocols may be used as an indication of how to categorise the packets according to application type and therefore which carrier may be used for their transmission.

(Feature Name ]UDP |UDP Lite |TCP |Multipath(SCTP jDCCP IRUDP

In some embodiments, the at least one transport layer protocol characteristic comprises an associated networking port. Then, at least some of the plurality of traffic packets that have the same associated networking port may be identified by the second (analysis) step 110. The identified at least some of the plurality of traffic packets (with the same associated networking port) may thereby be categorised as being associated with the same application type. This may work especially well with TCP packets. Each port is generally representative of a different application. In other words, packets of the same transport layer protocol (such as TCP) and same networking ports are advantageously sent over the same carrier. Conversely, even packets of the same transport layer protocol but with different networking ports may be sent over different carriers. For example, other characteristics of the traffic packet (for instance QoS requirements) may be taken into account to determine which specific carrier to use. In one approach, TCP packets with high sensitivity to latency (less than a threshold latency level) may be distributed to a specific cell, selected on the basis of a latency performance. The selected cell is preferably a master cell in this case, particularly where the node is the master cell or has a low latency link to the master cell (in comparison with the link between the node and the one or more secondary cells). The sensitivity to latency may be determined based on the application type, such as HTTP.

In general, the method of Figure 2 could comprise a further step: determining that a QoS requirement associated with the respective traffic packet is at least a threshold level. Then, the third step 120 (distributing the plurality of traffic packets) may comprise distributing each of the plurality of traffic packets determined to have an associated QoS requirement that is at least the threshold level, to a cell selected from the plurality of cells on the basis of an associated cell QoS performance. For example, the QoS requirement may be sensitivity to latency and the cell QoS performance may be a latency performance. This distribution on the basis of QoS requirement is in addition to distribution on the basis of application type. The packets, within the same application type, may be allocated according to their associated QCI (as defined by 3GPP TS 23.203). Those packets with the most demanding QoS requirements may be sent through the master cell (MeNB 20) and those with the lowest QoS requirements may be sent through a secondary cell (such as SeNB 30 or another eNB). In another approach, the higher throughput packets can be sent through the master cell (MeNB 20).

In the foregoing, it has generally been assumed that the node carries out the third step 120 as well as the first step 100 and the second step 110. However, this need not be the case. For example, even if the node is not a RAN node (for instance, at least a part of or connected to a base station, cell or eNB), the second 110 and/or third 120 steps may be carried out at a RAN node, such as an eNB or a node connected to an eNB. In such an example, the node may be at the core network. Then, a further step of the method (not shown) may comprise indicating, for each traffic packet, the categorised application type associated with the traffic of the respective traffic packet, in DiffServ Code Point (DSCP) bits of the respective traffic packet. Then, the third step 120 (distributing the plurality of traffic packets) may be performed in accordance with the categorisation indicated in the DSCP bits of each of the plurality of traffic packets. This third step 120 may be performed by a second node (different from the node that performed the preceding steps), which may be a RAN node such as a cell (or a RAN node linked to a cell). Preferably the second node is the master cell (such as MeNB 20). The second node can identify the different packets by reading the DSCP bits. Traffic packets with the same DSCP value may be carried over the same carrier.

Although specific embodiments have now been described, the skilled person will understand that various modifications and variations are possible. Also, combinations of any specific features shown with reference to one embodiment or with reference to multiple embodiments are also provided, even if that combination has not been explicitly detailed herein.

The skilled person will understand that alternatives to (or additional steps with) packet inspection may include traffic pattern identification and/or heuristic packet analysis. These may be used to determine application type. They may be particularly advantageous when at least some of the plurality of traffic packets comprise encrypted content (using IPsec or HTTPS for instance).

Claims

1. A method of distributing traffic for transmission by inter-cell carrier aggregation within a cellular network, comprising: receiving a plurality of traffic packets at a node of the cellular network; analysing the plurality of traffic packets to categorise each of the plurality of traffic packets according to an application type associated with traffic of the respective traffic packet; and distributing the plurality of traffic packets between a plurality of cells for transmission by carrier aggregation, in accordance with the respective categorisation of each of the plurality of traffic packets.

2. The method of claim 1, wherein the step of analysing the plurality of traffic packets comprises categorising at least one traffic packet associated with a first application type separately from at least one traffic packet associated with a second application type; and wherein the step of distributing the plurality of traffic packets comprises: distributing the at least one traffic packet associated with the first application type to a first cell of the plurality of cells; and distributing the at least one traffic packet associated with the second application type to a second cell of the plurality of cells.

3. The method of claim 1 or claim 2, wherein the step of analysing the plurality of traffic packets comprises categorising at least some of the plurality of traffic packets as associated with a first application type; and wherein the step of distributing the plurality of traffic packets comprises: distributing all of the at least some traffic packets associated with the first application type to the same first cell from the plurality of cells.

4. The method of claim 2 or claim 3, wherein the plurality of cells for transmission by carrier aggregation comprise a primary cell and a secondary cell and wherein the first cell is the primary cell.

5. The method of any preceding claim, wherein the step of analysing the plurality of traffic packets comprises determining at least one transport layer protocol characteristic associated with the respective traffic packet.

6. The method of claim 5, wherein the at least one transport layer protocol characteristic comprises one or more of: the transport layer protocol in use; whether the transport layer protocol is connection-oriented; if the transport layer protocol provides ordered delivery of packets; if congestion control is in operation; whether flow control is used; and a networking port associated with the packet.

7. The method of claim 5 or claim 6, wherein the step of determining at least one transport layer protocol characteristic comprises identifying at least some of the plurality of traffic packets that use ordered delivery and/or flow control and categorising the identified at least some of the plurality of traffic packets as being associated with the same application type.

8. The method of claim 7, wherein the step of identifying at least some of the plurality of traffic packets further comprises identifying the at least some of the plurality of traffic packets that use the same transport layer protocol with ordered delivery and/or flow control and categorising the identified at least some of the plurality of traffic packets as being associated with the same application type.

9. The method of any one of claims 5 to 8, wherein the step of determining at least one transport layer protocol characteristic comprises identifying at least some of the plurality of traffic packets that have the same associated networking port and categorising the identified at least some of the plurality of traffic packets as being associated with the same application type.

10. The method of any preceding claim, further comprising: determining that a sensitivity to a QoS requirement associated with the respective traffic packet is at least a threshold level; and wherein the step of distributing the plurality of traffic packets further comprises distributing each of the plurality of traffic packets determined to have an associated sensitivity to the QoS requirement that is at least the threshold level, to a cell selected from the plurality of cells on the basis of an associated cell QoS performance.

11. The method of any preceding claim, wherein the step of analysing the plurality of traffic packets is by packet inspection at a core network part of the cellular network, the method further comprising: indicating, for each traffic packet, the categorised application type associated with the traffic of the respective traffic packet, in DiffServ Code Point, DSCP, bits of the respective traffic packet; and wherein the step of distributing the plurality of traffic packets is performed in accordance with the categorisation indicated in the DSCP bits of each of the plurality of traffic packets.

12. The method of any preceding claim, wherein the step of analysing the plurality of traffic packets comprises one or more of: inspection of each of the plurality of traffic packets; traffic pattern identification; heuristic packet analysis.

13. The method of any one of claims 12, wherein: the step of analysing the plurality of traffic packets comprises light packet inspection; or wherein the step of analysing the plurality of traffic packets comprises traffic pattern identification and/or heuristic packet analysis and wherein at least some of the plurality of traffic packets comprise encrypted content.

14. A computer program, configured when operated by a processor to perform the method of any preceding claim.

15. A cell controller, configured to distribute traffic for transmission by inter-cell carrier aggregation in accordance with the method of any one of claims 1 to 13.