GB2448004A - Telecommunications device security - Google Patents

Abstract

In a mobile or cellular telecommunications network a single tunnel between nodes 7,11,15 and 19 of the network is established to transmit data on a plurality of bearers. Each bearer transmits data relating to a particular service. The respective bearers may be identified by identification data. The identification data may indicate the priority of the data in the particular bearer. The identification data may indicate the DiffServ Service Class, DSSC, as defined in RFC 4594.

Description

* DATA TRANSMISSION The present invention relates to a method of

transmitting data on a plurality of bearers in a cellular or mobile telecommunications network. The present invention also relates to a telecommunications network adapted to implement such a method.

To ensure competitiveness of the 3GPP systems in a time frame of the next 10 years and beyond, a Long-Term Evolution (LTE) of the 3GPP access technology is being studied. The Evolved packet System (EPS), previously known as Systems Architecture Evolution (SAE), is described in 3GPP TS 23.401, and TS 23.402 which are fully incorporated herein by reference. Important tasks of such long term evolution include reduced latency, improved system capability, reduced cost per bit, and higher user data rates. Increasing the economy of scale through complexity reduction and re-use of mechanisms and protocols already defined in the fixed Internet is an important element to achieve cost savings.

Key elements of an EPSILTE network, and its operation, will now briefly be described with reference to Figure 1.

Each eNode B 15 or base station corresponds to a respective set of cells of its cellular or mobile telecommunications network and receives calls/data from and transmits calls/data to a mobile terminal in that set of cells by wireless radio communication in the packet switched domain. Such a subscriber's mobile terminal (or User Equipment-LiE) is shown at 11. The mobile terminal may be a handheld mobile telephone, a personal digital assistance (PDA), a laptop computer equipped with a datacard, or a laptop computer with an embedded chipset containing the liE's functionality.

The RRC signalling with the mobile terminal 11 terminates at the eNode B 15, the eNode B comprising the Radio Access Network (RAN) of the EPS/LTE network.

The eNode B 15 performs the functions of both the Node B and a large part of the RNC of a 3G/IJMTS network. The network core of the EPSILTE network includes Packet Data Network Gateway (PDN GW) 7, serving gateway (Serving OW) 19 and also a Mobility Management Entity (MME) (not shown). A plurality of PDN-GWs are usually provided, although only one is shown.

Communications between the mobile terminal 11 and the network core can be considered to be split into a control plane and a user plane. The control plane performs the required signaling, and includes the relevant application protocol and the signaling bearer for transporting the application protocol messages. Among other things, the application protocol is used for setting up the radio access bearer in the radio network layer. The user plane transmits data traffic and includes data streams and data bearers for the data streams. The data streams are characterized by one or more frame protocols specified for that interface. Generally speaking, the user plane carries data for use by a receiving terminal -such as data that allows a voice or picture to be reproduced -and the control plane controls how the data is transmitted.

The QoS (Quality of Service) framework currently agreed in 3GPP is described in 3GPP TS 23.401 (which is fully incorporated herein by reference) and is shown in Figure 1. In this framework:- * Service Data Flows (SDF) 1,3 represent an IP flow characterising a particular application.

* * Downlink (DL) Traffic Flow Template (DL TFT) is a set of downlink packet filters. DL 1FF 5 in the PDN GW 7 binds service data flows (identified by packet filters) to EPS bearers in downlink direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple downlink packet filters in the DL TFT 5.

* Uplink (UL) Traffic Flow Template (UL TFT) is a set of uplink packet filters.

UL TFT 9 in the mobile terminal (UE) 11 binds service data flows (identified by packet filters) to EPS bearers in uplrnk direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple uplink packet filters in the UL TFT 9.

* A radio bearer 13 transports packets of an EPS bearer between the UE 11 and the eNode B 15 (and vice versa). There is a 1:1 mapping between radio bearer and EPS bearer.

* Si bearer 17 transports the packets of EPS bearers between the Serving GW 19 andeNodeBl5.

* S5/S8a bearer 21 transports the packets of EPS bearers between the Serving GW 19 and the PDN GW 7.

GPRS Tunnelling Protocol-User Plane (GTP-U) has been chosen as tunnelling protocol over the Si and S5/S8a interfaces 17,21 (for the 3GPP EPS architecture for GPRS enhancement option). The current specifications of the GTP protocol (TS 29.060), defines the TEED (Tunnel Endpoint identifier) which is used to identify a single transport tunnel. The QoS framework specifications (TS 23.107) define a bearer approach for existing 2G and 3G systems where each IP flow with different QoS requirements is mapped to a different UMTS bearer service identified by a PDP Context. TS 23.107 (Figure 1) specifies how a UMTS bearer service is in turn provided by sub-layers such as Radio Access Bearer Service (in turn split into Radio Bearer Service and RAN Access Bearer Service) and CN S Bearer Service. Each Bearer Service (e.g. TS 25.413 for RAN) specifies how to perform a 1:1 association between a bearer and a transport tunnel identified by a GTP TEID (TS 29.060) * 5 As a result, a GTP Tunnel Endpoint Identifier (TEID) is used to identify a particular QoS flow of a particular UE 11. This paradigm is not efficient because typically a UE may want to establish several EPS bearers to have different QoS treatments for different types of services being accessed. This means that each QoS flow for a given UE requires a different tunnel. This is a source of major inefficiencies in terms of delay and signalling load in setting up (and tearing down) a new tunnel every time a new bearer has to be established (or released). In particular, the TEID has to be negotiated and communicated at both ends of the tunnel. This inefficiency is emphasised during handover, where all the tunnels related to a UE have to be torn down from the old base station and established on the new base station.

As shown in Figure 1, the GTP TEID used over Si can be different from the GTP TED used over S5/S8a, and the mapping between the two is maintained by the Serving GW 19.

A second problem with the current paradigm is the lack of QoS differentiation of these GTP tunnels from a transport point of view. Even though a different TED is assigned for each QoS flow, the TED to QoS mapping is only known at the end nodes (e.g. eNB 15, Serving GW 19 and PDN OW 7). For this reason the transport network carrying the traffic of Si and S5/S8a interfaces 17,21 cannot prioritise the traffic based on the TED. As a result, the transport networks (including both core and backhaul sections) have to be over-dimensioned to cope with busy hours demands because no quality of service differentiation is made on the IP packets encapsulating the different GTP tunnels.

In one aspect, the present invention provides a method of transmitting data on a I 5 plurality of bearers in a cellular or mobile telecommunications network, the method including establishing a single tunnel between nodes of the telecommunications network and transmitting the data on said plurality of bearers in said tunnel.

In the embodiment, each bearer transmits data relating to a particular service or QoS flow.

In the embodiment identification data is provided to identify the respective bearers within the tunnel. The identification data also indicates the priority of the data (i.e. QoS) in each bearer. The identification data may be indicative of a DiffServ Service Class, DSSC, as defined in RFC 4594. This provides a convenient mechanism, already known in the fixed IF world, for transmitting priority or QoS data.

In the embodiment, in a first mechanism, the identification data is transmitted in a tunnel end point identifier, TEID. The identification data comprises one part of the TEID, another part of the TEJD being common to all bearers in the said tunnel.

The common part of the 1'EID identifies the tunnel. Advantageously, this allows only one ID (the common part) to be negotiated between two tunnel end points (for example, a serving gateway and an eNB).

In the embodiment, in a second mechanism, the identification data is transmitted as a separate field from a tunnel end point identifier, TEID. The TEID is common to all bearers in the tunnel. The TEID identifies the tunnel. Only one ID (the TEID) is negotiated between the tunnel end points.

The mobile or the cellular telecommunications network may be a EPSILTE 1 5 network, and the nodes may comprise a mobile terminal (UE), eNode B, Serving Gateway and/or Packet Data Network Gateway. The invention is also applicable to other types of cellular or mobile telecommunications networks for transmitting data between nodes corresponding to these nodes.

In the embodiment only one tunnel is established between a mobile terminal and the network, the data being transmitted on a plurality of bearers in the tunnel.

The present invention also relates to a mobile or cellular telecommunications network as defined in the claims.

For a better understanding of the present invention, an embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:-Figure 1 shows schematically the elements of a telecommunications network including a mobile telecommunication terminal; and Figures 2 and 3 show alternative arrangements for indicating the QoS of a particular bearer; and Figure 4 shows schematically a single tunnel for a plurality of bearers.

In the drawings like elements are generally designated with the same reference numeral.

The embodiment now to be described addresses the two problems mentioned * 5 above by 1. Reducing the bearer setup delay and simplifying the bearer management framework, and 2. Simplifying the EPS Q0S model by leveraging as much as possible the existing IP QoS framework to be deployed by mobile operators regardless of EPS A single user plane mobility tunnel is used over the S 1 and S5/S8a interfaces 17,21 (GTP based) for each UE 11. With one single user plane mobility tunnel for all the possible flows (here considered as EPS bearers), there is a necessity to distinguish between the different flows within the same tunnel, in order to maintain the end-to-end EPS bearer concept.

Most of the mobile network operators are undergoing initiatives to converge their transport network from Asynchronous Transfer Mode (ATM) and Time Division Multiplex (1DM) towards a unified IP-based infrastructure. These initiatives typically cover both the core network (including roaming connectivity) and backhaul networks from the core network to the eNB 15. These IP networks are "DiffServ" capable. DiffServ or Differentiated Services is described in RFC 2474 (which is fully incorporated herein by reference), and specifies a simple, scalable and coarse-grained mechanism for classifying, managing network traffic and providing Q0S guarantees on modern [P networks. The QoS marking specified in the Type of Service (ToS) field of an IP header can be mapped to the QoS mechanism used in the specific transport network, such as Multi-Protocol Label Switching (MPLS). However, the tunnelling mechanisms currently agreed in 3GPP do not mandate any mapping of the type of service transported by each tunnel (identified in the form of Labels) to the outer IF header in terms of Diffserv Code Point (DSCP) values. *5

The embodiment proposes two mechanisms, that can be used either in isolation or in conjunction.

According to the first mechanism, the GPRS TEID is modified. Conventionally, the GPRS TED space is an unstructured 32 bit field in the GTP header.

According to the first mechanism, the TEID space is split into two fragments, as shown in Figure 2. The first fragment (TEJD-UE) 30 is used to identify the UE 11 and comprises 24 bits. The second fragment (TEID-QF) 32 identifies the QoS flow (which represents an EPS bearer in the case of 3GPP EPS described in TS 23.401, or a PDP Context in the case of previous 3GPP packet switched systems described in IS 23.060) for the UE 11 and comprises 8 bits. However, the first fragment may instead be 26 bits and the second fragment 6 bits.

The new format of the TEID allows to have only one tunnel per UE 11. This tunnel is identified by the first 24/26 bit fragment (TEID-UE) of the GTP TEID field. The last 8/6 bit fragment (TEID-QF) of that field identifies the EPS bearer.

Importantly, only one ID (which will be the first 24/26 bit fragment (TEID-UE) per LiE 11 was to be negotiated between the Serving OW 19 and the eNB 15 (or between any two tunnel endpoints). In the prior art versions of GTP discussed above, each bearer had to negotiated a new TEID. In the first mechanism there are as many TEIDs per LiE 11 as the number of EPS bearers established by the UE 11, but all these TEDs have the first 24bits (or 26bits) in common.

S As specified in TS 23.401, each EPS bearer is associated with two QoS parameters called Label and Allocation and Retention Priority (ARP).

A Label is a scalar that is used as a reference to access node-specific parameters 5 that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.). Together with the Allocation and Retention Priority, a Label identifies uniquely the EPS bearer of a UE 11. The Label in 3GPP EPSILTE context is not different and does not carry different semantic from DiffServ Service Classes (DSSC) defined in RFC 4594.

For this reason the DiffServ Service Classes can be used for the second fragment 32 to identify a particular EPSILTE bearer associated with a UE 11. The DSSC may be indicated by setting the second fragment to have a DSCP value corresponding to the DSSC, as shown in the table below.

Service Class Name Application Examples DSCP Name DSCP Value

DSSC

etwork letwork routing S6 110000 Control felephony rp Telephony bearer (VoJP) F 101110 ignalling! Telephony signalling S5 101000 4ultimedia 1.323 / V2 video.F41, AF42 100010, 100100 onferencing onferencing (adaptive) %F43 100110 teal-time Video conferencing & S4 I 00000 Enteractive interactive gaming 4ultimedia Streaming video &audio on.F31, AF32, )11010, 011100, * Streaming lemand 4F33)11110 3roadcast 3roadcast TV & live events S3)1 1000 Video ow Latency lient / server transactions F21, AF22 100l0, 010100 * Lata Web-based ordering F23,10110 DAM DAM&P S2)10000 Eligh Store &forward applications %F11, AF12, )01010, 001100, ftroughput F13)01110 )ata Standard Jndifferentiated applications)F, (CSO) )00000 ow Priority ny low that has no BW S1)01000 ata ssurance Where CS = Class Selector, DF = Default Behaviour (e.g. Best Effort), AF = Assured Forwarding, and EF = Expedited Forwarding.

The table below shows DiffServ Service Class characteristics Service Class Tolerance to Traffic Name -Loss Delay Jitter Characteristics

DSSC

etwork Variable size packets, mostly ow..ow es ontrol inelastic short messages, but raffic can also burst (BGP) felephony ixed size small packets, constant Very Low Very Low Very mission rate, inelastic and low ow ate flows Signalling Variable size packets, some what ow ow es S)ursty short lived flows vlultimedia Variable size packets, constant Low to Very Low Low Conferencin, ransmit interval, rate adaptive, vIedium eacts to loss S Real-time TP/UDP streams, inelastic, Low Very Low bow Enteractive nostly variable rate vlultimedia Variable size packets elastic with..ow to t'es 4edium treaming iariable rate vtedium roadcast onstant and variable rate, Very Low 'Iedium ow Video inelastic, non bursty flows ow Latency Variable rate, bursty short lived bow..ow to (es Data elastic flows 4edium )AM Variable size packets, elastic & Low vledium Yes inelastic flows ugh Variable rate, bursty long lived ow to 4edium es fhroughput lastic flows 1igh Data Standard bit of everything Tot Specified bow Priority 4on real-time and elastic Iigl1High Yes )ata The usage of DSSC in the second fragment enables both the identification of each particular flow (EPS bearer) as well as QoS enforcement on a transport layer whenever an IP-based DiffServ capable transport network is deployed. The latter is provided because the DSSC used in the second fragment can be copied (without requiring any mapping) to the outer IP header Diffserv Code Point (DSCP) field.

When UE 11 attaches to the network, the S-GW 19 and eNB 15 each allocate a TEID-IJE and a value for TEID-QF that identifies a default Q0S profile. As a result, and as in the current GPRS system, a pair of 32 bit TEIDs are allocated.

Any downlink packets that are received by the eNode B 15 with the UE il's TELD-IJE, but with an unallocated TEID-QF, can be handled with the default QoS (or by some other predetermined rule). The S-GW 19 can apply similar handling to upi ink packets.

By grouping all of the QoS flows for UE 11 under the same TELD-IJE, then in the Attach, Service Request, and other procedures, the eNodeB 15 can allocate its TEID-UE at a very early stage in the procedure. Then (using the treatment indicated in the preceding paragraph), user data flow can start earlier than in the current procedures described in TS 23.401 (fully incorporated herein by reference). In addition, the early assignment of TEID avoids complexity at the S-GW 19 (caused by the need to buffer uplink packets while waiting for assignment of the eNodeB 15 downhnk TEID).

When the IJE ii moves from one S-GW 19 area to another S-GW area, in the prior art arrangement each dedicated bearer requires a separate message to be sent to the PDN-GW 7 and to the eNB 15. According to the first mechanism, just one message, carrying the TEID-UE can be used to switch the default bearer, along with all its associated dedicated bearers.

In a modification of the first mechanism the GTP-U header includes a new field 36 in addition to the existing 32-bit TEID 34, as shown in Figure 3. The QoS flow is indicated in the new field 36, and may comprise 6 or 8 bits and may be set to a particular DSCP value, as in the Figure 2 arrangement. Practically, the splitting of the TEID field in two would be translated in a different interpretation of the TEID

field itself by the tunnel endpoints.

The new format of the TEED in Fig. 3 allows to have only one tunnel per UE 11.

* 5 The tunnel is identified by the first 32 bits of the GTP TEED field (the TEID 34).

The last 8 bits of that field (new field 36) identifies the EPS bearer. Only one ID (which will be the first 32 bits, TEED 34) per UE 11 has to be negotiated between the Serving GW 19 and the eNB 15 (or between any two tunnel endpoints). In contrast, in the prior art version of GTP discussed above each bearer had to negotiate a new TELD. In the second mechanism there are as many TEIDs per UE 11 as the number of El'S bearers established by the UE 11 but all these TEJDs will have the first 32bits in common.

The second mechanism maps the Q0S Label (identifying the EPS bearer) to a value consistent with the DSCP Service Classes dictated by IETF in RFC 4594.

These values could be copied to the ToS field of the outer IP header (i.e. the one carrying the GTP payload).

In both the first and second mechanisms, the value of the QoS Label should be communicated to the end node (i.e. eNodeB 15 in case of Si and Serving GW 19 in case of S5/S8a) using the signaling plane during the bearer establishment process. The mechanisms proposed enable the implementation of the one user plane tunnel solution per liE ii without sacrificing the possibility of having multiple EPS bearers per each liE with different QoS treatments.

Figure 4 shows schematically the single tunnel 40 for liE 11 for three EPS bearers 42A,42B and 42C. The TEED of each bearer includes the DSSC of each bearer 42A,42B and 42C. In the downlink the eNB 15 receives the EPS bearers 42A,42B and 42C from the single tunnel 40 and transmits the data on respective radio bearers 44A,44B and 44C.

Using the DSSC (DiffServ Service Classes) as 3GPP EPS QoS Labels simplifies the EPS QoS model. Being defined on an IETF concept, the DSSC is expected to become a universal "service class" identifier ensuring that QoS is enforced across heterogeneous IP-based systems (3GPP, non-3GPP and transport) in consistent manner. This mapping will relieve 3GPP from having to specify yet another set of parameters to differentiate different QoS classes. In addition, QCI (QoS Class Identifiers) specified for GPRS Rel-7 (pre-LTE) should again be mapped to DSSC.

Given this, DSSC (as defined in RFC 4594) could be used to identify an EPS bearer within the UE's GTP-U tunnel identified by the TEID. The same DSSC value could be configured in the outer IP header to enable Q0S differentiation in the transport network. This will in turn be reflected in considerable cost savings because of the reduced capacity to be provisioned for such transport networks.

Note that this DSCP needs to be copied from the outer IP header into any additional IPSec encapsulating IP header between the Serving GW 19 and the eNB 15. This procedure must be performed by the Serving GW 19 for the DL (down link) traffic and by the eNodeB 15 for the UL (up link) traffic. The same principles apply on the interface 21 between the PDN GW 7 and the Serving GW 19.

The embodiment described simplifies the currently agreed 3GPP EPS Q0S framework by deploying a one user plane mobility tunnel (GTP-U) solution per Ut (over Si and S5/S8a) and re-using the semantic of IP DiffServ Service Classes to characterise the different QoS classes in 3GPP systems.

These enhancements will produce: * a simpler mobility management solution for 3GPP EPS with only one mobility tunnel per UE to manage, decreasing the system complexity and 1 hence resulting in lower equipment cost * reduced bearer setup delay resulting in increased responsiveness of service access * the ability to enforce QoS over IP DiffServ enabled transport networks

Claims (22)

1. * CLAIMS 1. A method of transmitting data on a plurality of bearers in

   a cellular or mobile telecommunications network, including establishing a single tunnel between nodes of the telecommunications network and transmitting the data on said plurality of bearers in said tunnel.
2. 2. The method of claim 1, wherein each bearer transmits data relating to a particular service.
3. 3. A method of claim 1 or 2, including providing identification data to identify the respective bearers.
4. 4. The method of claim 3, wherein the identification data indicates the priority of the data.
5. 5. The method of claim 3 or 4, wherein the identification data is indicative of a DiffServ Service Class, DSSC, as defined in RFC 4594.
6. 6. The method of claim 3,4 or 5, wherein the identification data is transmitted in tunnel end point identifier, TEID.
7. 7. The method of claim 6, wherein the identification data comprises a part of the TED, another part of the TED being common to all bearers in said tunnel.
8. 8. The method of claim 3,4 or 5, wherein the identification data is transmitted as a separate field from a tunnel end point identifier, TED.

   I
9. 9. The method of claim 8, wherein the 1'EJD is common to all bearers in said tunnel.
10. 10. The method of claim 3,4 or 5, wherein the identification data is transmitted I 5 in an outer IP header.
11. 11. A cellular or mobile telecommunications network including means for establishing a single tunnel between nodes of the telecommunications network and for transmitting data on a plurality of bearers in said tunnel
12. 12. The telecommunications network of claim 11, wherein each bearer transmits data relating to a particular service.
13. 13. The telecommunications network of claim 11 or 12, including means for providing identification data to identify the respective bearers within the tunnel.
14. 14. The telecommunications network of claim 13, wherein the identification data indicates the priority of the data.
15. 15. The telecommunications network of claim 13 or 14, wherein the identification data is indicative of the DiffServ Service Class, DSSC, as defined in RFC 4594.
16. 16. The telecommunications network of claim 13,14 or 15, wherein the identification data is transmitted in a tunnel end point identifier, TEID.
17. 17. The telecommunications network of claim 16, wherein the identification data comprises one part of the TEID, another part of the TEID being common to all bearers in said tunnel.
18. 18. The telecommunications network of claim 13,14 or 15, wherein the identification data is transmitted as a separate field from a tunnel end point identifier, TEIID.
19. 19. The telecommunications network of claim 18, wherein the TEID is common to all bearers in said tunnel.
20. 20. The telecommunications network of claim 13,14 or 15, wherein the authentication data is transmitted in an outer IP header.
21. 21. A method of transmitting data on a plurality of bearers in a cellular or mobile telecommunications network, substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.
22. 22. A cellular or mobile telecommunications network substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.