WO2017216510A1

WO2017216510A1 - Providing service data flow description

Info

Publication number: WO2017216510A1
Application number: PCT/GB2017/050511
Authority: WO
Inventors: Charles TURYAGYENDA; Paul Bucknell
Original assignee: Fujitsu Limited
Priority date: 2016-06-14
Filing date: 2017-02-27
Publication date: 2017-12-21
Also published as: GB201610343D0; GB2551485A

Abstract

In LTE, an eNB (12) Is unable lo distinguish between service data flows or IP packets, from different applications that have been mapped onto the same data radio bearer. To facilitate mobile edge computing at the eNB (12), a terminal (11) includes, in POOP PDUs, service flow related information such as an IP source and/or destination address, IP protocol being used, transport source port, transport destination pod, application: header fields and packet count Information, The eNB (12) can extract the Information which can then be used by a MEC server (13) provided at the eNB (12).

Description

Providing Service Date Flow Description

Field of the Invention This invention generally relates to a wireless communication system and in particular to a wireless communication system employing so-called Mobile Edge Computing (MEC).

Background of the Invention The worlds of Information Technology (IT) and Telecommunications Networking are converging bringing with them new possibilities and capabilities. A key transformation has been the emergence of the Mobile Edge Computing (MEC) paradigm, i.e. the ability to run IT based servers at the network edge and applying the concepts of cloud- computing to perform tasks that previously could not be achieved using traditional telecommunication networks, as proposed for example in ETSI MEC Industry

Specification Group, "Mobile-Edge Computing: introductory Technical White Paper", Issue 1, September 2014. The close proximity of MEC services to the end user devices considerably reduces latency, thus providing a platform to improve user experience and minimise congestion in other parts of the network.

The network topology in 3GPP Long Term Evolution (LTE) is illustrated in Figure 1. Each user device 11 (usually referred to in LTE as a user equipment or UE) connects over a wireless link via a radio interface to a base station eNB 12, and the network of eNBs is referred to as the E-UTRAN 10.

Each eNB 12 in turn is connected by a (usually) wired link using an interface called S1 to higher-level or "core network" entities, including a Serving Gateway (S~GW 22), and a Mobility Management Entity (MME 21 ) for managing the system and sending control signalling to other nodes, particularly eNBs, in the network. In addition, a PON or Packet Data Network Gateway (P-GW or PON GW 23) is present, separately or combined with the S-GW 22, to exchange data packets with any packet data network including the Internet. The core network 20 is called the EPC or Evolved Packet Core. Traditionally, as shown by the dashed line in Figure 1, there has been a functional split between the E-UTRAN 10 and the EPC 20. The E-UTRAN is responsible for the wireless interface with UEs and the EPC provides the "backhaul" needed to connect UEs with other networks (including the internet) and provide services desired by users.

Figure 2 shows how the radio protocol architecture for LTE can be separated into the control plane (used for signalling purposes), and the user plane (used for transporting user data traffic). Over the radio interface Uu (see Fig. 1) between the UE 11 and the eNB 12, user data traffic is transported using the user plane consisting of PDCP, RLC, MAC and PHY protocol layers as explained below, wherein data packets created by the application are processed by protocols such as TCP, UOP and iP. Meanwhile, in the control plane, the radio resource control (RRC) protocol creates signalling messages that are exchanged between the eNB and the UE. Similarly, the Non-Access Stratum (NAS) creates control signalling messages between the UE and the MME,

In both cases, the data and/or messages are processed by the packet data

convergence protocol (PDCP), the radio fink control (RLC) protocol and the medium access control (MAC) protocol, before being passed to the physical layer (PHY) for transmission- Packets received by a protocol layer are called Service Data Units

(SDUs) while the packet output of a protocol layer is called a Protocol Data Unit (PDU). PDUs each consist of a "header" with identifying and sequence information followed by a body or "payload " containing useful information. Below the terms "packet" and "PDU" are used equivalently.

Referring now to Figure 3, further explanation will now be given regarding uplink user plane traffic between the UE 11 and eNB 12. since this of relevance to the

embodiments to be described. Such traffic is created, in the form of application layer PDUs or service data flows, by a number of applications within the UE. The traffic is indicated by "IP Packets" in Figure 3.

The application layer PDUs are passed onto the transport layer that appends transport layer control information to the header to produce a transport layer PDU. Application layer PDUs in one transport layer PDU belonging to the same service, e.g. all http packets, will be packaged in similar transport layer PDUs. At the transport layer the packets belonging to different services are differentiated by transport source and destination port numbers. For example, hypertext transport protocol (http) uses port 80, simple mail transfer protocol (SMTP) uses port 25, and so forth. The transport protocol data units are passed onto the network layer that appends Internet Protocol (IP) addressing information in an IP header to produce a network layer protocol data unit. An uplink traffic flow template (UL-TFT), maintained in the UE 11 , maps packets onto bearers on the basis of header parameters such as: protocol identifier e.g.

Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), source iP address, destination IP address, source port number, destination port number, etc. The network layer protocol data units are passed onto the packet data convergence protocol (PDCP) that performs sequence numbering, header compression, ciphering and appends a PDCP header to produce a PDCP protocol data unit (PDCP data PDU). Each PDCP PDU is identified by a Sequence Number (PDCP SN), which is put in the header. This makes it possible to ensure in-sequence delivery of upper layer PDUs and to eliminate duplicated tower-layer Service Data Units (SDU) in case of handover for example.

PDCP PDUs are of two basic kinds. PDCP data PDUs and PDCP control PDUs.

PDCP data PDUs are used to carry not oniy user plane data, but also certain kinds of control plane data, such as a MAO! field for SRBs (see below), as well as RRC and NAS messages. PDCP control PDUs are utilised to transmit control information between PDCP layer entities (PDCP peers), including things iike PDCP status reports and PDCP header compression information. This control information is used to guide the operation of the PDCP entity. Different header formats are defined for these PDCP PDUs. LTE provides header formats for a user plane PDCP data PDU with short PDCP SN (7 bits) as shown in Fig. 4A, a user plane PDCP data PDU with long PDCP SN (12 bits) as shown in Fig. 48, and a Control Plane PDCP data PDU. The one bit D/C field is set to '0' for PDCP control PDUs and T for PDCP data PDUs. The payload of the PDCP data PDU is the actual bearer or user data white the payload of a POP control PDU is the control information. 36PP TS36.323 (Release 12) defines PDCP control PDU formats for two control information elements, namely the interspersed robust header compression (ROHC) feedback packet and the PDCP status report, as shown in Figures 5A and 5B respectively. The three bit PDU Type field is set to 'ΟΟΟ' for PDCP status reports and '001' for the interspersed robust header compression (ROHC) feedback packet; with the remaining PDU Type values, i.e. 010 to 111 , reserved for potential future extensions.

Each radio bearer (RB) is associated with one PDCP entity (see 3GPP TS 36.323: Packet Data Convergence Protocol Specification (Release 12), V12.4.0, June 2015, incorporated by reference). Multiple PDCP entities at the PDCP layer are configured by the radio resource control (RRC) layer.

As indicated in Figure 3, the PDCP PDUs are passed onto the radio link control (RLC) layer that performs concatenation, segmentation, and re-assembly of RLC service data units (SDU), duplicate detection, automatic repeat request (ARQ) error correction and appends a RLC header to produce a RLC protocol data unit (RLC PDU). The process depends on the size of the packets, e.g. large packets for video or small packets for voice over IP, If an RLC SDU is large, or the available radio data rate is low (resulting in small transport blocks), the RLC SDU may be split among several RLC PDUs. if the RLC SDU is small, or the available radio data rate is high, several RLC SOUs may be packed into a single PDU. Details of this procedure are contained in 3GPP, TS 36.322; Radio Link Control Protocol Specification (Release 12), V12.2.0, March 2015, also incorporated by reference. Each PDCP entity is associated with one or two (one for each direction) RLC entities depending on the radio bearer (RB) characteristics (i.e. unidirectional or bi-directtonai} and RLC mode. RLC entities can perform data transfer in three modes, namely:

transparent mode (TM RLC), unacknowledged mode (UM RLC) and acknowledged mode (AM RLC). Transparent mode is used only for control plane signalling for a few RLC messages during the initial connection. Unacknowledged and acknowledged modes use the RLC header and indicate whether or not the ARQ mechanism is involved. Data radio bearers can only be configured to utilise either UM RLC or AM RLC entities.

The RLC POUs are passed to the medium access control layer (MAC in Figure 3) that performs multiplexing of MAC SDUs from different logical channels onto transport blocks, priority handling or scheduling between logical channels, error correction through hybrid ARQ (HARQ) and appends a MAC header to produce a MAC protocol data unit: see 3GPP, TS 36.321: Medium Access Control Protocol Specification

(Release 12), V12.6.0, June 2015, also incorporated by reference. There is a one to one mapping between radio bearers and logical channels at the MAC level. Finally, the MAC POUs are passed to the physical layer (PHY) that performs mapping of transport channels to physical channels, forward error correction (FEC) encoding and decoding, modulation and demodulation of physical channels, frequency and time synchronisation, multiple antenna processing, Radio Frequency (RF) processing and transmission, The PHY carries the user data in the form of transport blocks over the air interface, within radio frames of 10ms divided into subframes each of 1ms. The transport block size can vary based on bandwidth requirements, distance, power levels or modulation scheme.

Referring back to Figure 1 , this further shows a MEC server 13 integrated into the eNB 12 for the purpose of providing mobile edge computing services to UEs. Although this is one possibility for locating the MEC server, a MEC server could alternatively (or in addition) be located elsewhere such as in a Radio Network Controller (RNC, not shown) for controlling multiple eNBs, The following are some of the use cases that could benefit from mobile edge computing: distributed content and DNS caching, application-aware performance optimisation, active device tracking, augmented reality content delivery, video analytics, etc. Such services can be provided either by the MEC server 13 in conjunction with the EPC 20, or possibly by the MEC server exclusively without having to refer to the EPC 20. However, in order to fully exploit the potential of mobile edge computing, the MEC server requires information about the individual IP data packet flows at the eNB 12. The concept of "bearers" is important for providing services in a 3GPP~based network, in general, a "bearer" can be thought of as an information transmission path of defined capacity, delay and bit error rate, etc. so as to enable a given service or control function to be provided. Various types or levels of bearer can be established at different protocol layers in the wireless communication system. For present purposes a so-called EPS (Evolved Packet System) bearer is of particular interest. An EPS bearer is a virtual pipeline through which data traffic flows between the UE 11 and the P-GW 23.

According to the 3GPP Long Term Evolution (LTE) standard, user-plane IP data packets associated with the same service or application, also known as Service Data Flows (SDFs), are mapped onto EPS bearers. This mapping is performed using Traffic Flow Templates (TFT). A traffic flow template is a set of network configured packet filters that identify and map IP packets onto bearers on the basis of IP header parameters such as: protocol identifier e.g. Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), source IP address, destination IP address, source port number, destination port number, etc. Uplink traffic is filtered using uplink traffic flow templates (UL-TFT) maintained in the UE 11 while downlink traffic is filtered using downlink traffic flow templates maintained at the packet gateway 23. According to 3GPP TS 23.203: Policy and Charging Control Architecture (Release 13), V13.5.0, September 2015, also incorporated by reference, each EPS bearer is characterised by a Quality of Service (QoS) profile consisting of the following parameters: QoS Class Identifier (QCI), Allocation Retention Priority (ARP),

Guaranteed Bit Rate (GBR), and Maximum Bit Rate (MBR). The GBR parameter is only specified for GBR bearers while the MBR parameter is specified for non-GBR bearers. The ARP parameter defines the importance of a resource request. The QCI parameter is a reference to the following specific parameters: resource type (GBR or non-GBR), priority, packet delay budget (between UE and P-GW), and packet error loss rate.

Various QC! classes are defined on this basis, as listed below:

From the final column in the above table, it can be seen that different services can have the same QCI value. Therefore, it is possible for two transport layer PDUs to correspond to two different services but have the same QCI value. Figure 6 illustrates how packets, originating at the Application/Service Layer at the UE 11, are filtered by UL-TFTs onto one of two radio bearers for transmission on the uplink to an eNB 12, where S1 bearers convey them to a S-GW 22. Under the present architecture, the eNB 12 provides a one to one mapping between the radio bearers and the S1 -bearers by mapping each radio bearer identity (RB-ID) to an $1 tunnel endpoint identifier (S1-TEID). The S-GW in turn forwards the packets by use of S5/S8 bearers to the PON GW 23. The Application/ Service Layer at PDN GW 23 in turn creates packets which are filtered through DL-TFTs to either of the two bearers and transmitted on the downlink to the UE 11.

As indicated in Figure 7, there are individual bearers at different protocol layers which map to one another. The left side of the Figure represents the eUTRAN 10 with the EPC 20 occupying the middle part of the Figure. At the right-hand side, outside the LTE system as such, there is the internet 30. The vertical bars represent the main entities in the user plane, from the UE 12 to eNB 11 through to S-GW 22 and P-GW 23, terminating in a peer entity (such as an Internet web server 31) connected to the P-GW 23, To provide an end-to-end service between the UE 11 and Peer Entity 31 (as indicated by the upper horizontal band in the figure), the system sets up the bearers as shown. An EPS Bearer 41 represents the entire connection within the LTE system; It constitutes a QoS flow for a particular service. The connection continues outside the LTE system via an External Bearer 42.

The EPS Bearer 41 is made up. in turn, of a radio bearer (RB) 51 over the wireless link between the UE 12 and eNB 11 , and an $1 Bearer 52 (usually on a wired fink) between the eNB 11 and S-GW 22, A further Bearer (S57S8 Bearer 53) is set up between the S- GW 22 and P-GW 23. Each Bearer can be regarded as a "tunnel* in a given protocol layer for transport of packets, connecting the end points for the duration of a particular service or "session", e.g. voice call or download. Thus, the radio bearer 51 transports the packets of the higher-layer EPS Bearer 41 between the UE 12 and eNB 11 , and the S1 Bearer 52 transports the packets of the EPS Bearer 41 between the eNB 11 and S- GW 22. Bearer control through RRC, mentioned previously, includes the setting up of bearers for a particular session so as to ensure sufficient QoS, taking into account the resource situation in the E-UTRAN 10 and existing sessions already in progress, it also involves the modification and release of RBs.

Thus, as Figure 7 indicates, an EPS bearer maps onto (or is made up of) the Radio Bearer between the UE 11 and the eNB 12, the S1 bearer between the eNB 12 and the serving gateway S-GW 22 and the S5/S8 Bearer between the S-GW 22 and the P-GW 23. LTE defines two types of radio bearers, namely, Signalling Radio Bearers (SRB) and Data Radio Bearers (DRB). Signalling radio bearers are used for the transmission of Radio Resource Control (RRC) and Non Access Stratum (NAS) messages, white user plane application data is transported on data radio bearers. Radio bearers may be bidirectional (that is, defined on both uplink Ul and downlink DL) or unidirectional (e.g., downlink only).

The presence of the MEC server 13 in Figure 1 can affect the need for bearers.

Although some applications may continue to use all the bearers shown in Fig. 7 even when the MEC server is present, other applications (involving only content cached locally at the MEC server for example) would only need a radio bearer, and would no longer need the S1 bearer. $5/38 bearer and so forth. However, the above EPS Bearer Architecture is not optimally designed for mobile-edge computing. The continuous evolution of mobile networks, to support ever increasing data rates, coupled with the paradigm of open mobile operating systems have provided great impetus to the rapid evolution of mobile content, services and applications.

Different multimedia applications have different QoS requirements expressed in terms of parameters such as: end to end delay, latency, packet loss rate, jitter, data rate and reliability. For instance video streaming applications require higher data rates compared to voice applications that are more sensitive to latency and jitter.

However, the level of granularity for QoS control in the E-UTRAN 10 and EPC 20 is limited to the bearer level. Thus all service data flows mapped to the same EPS bearer receive the same packet forwarding treatment e.g. scheduling policy, queue

management policy, rate shaping policy, RLC configuration, etc. The limited number of bearers specified by the 3GPP LTE and LTE-Advanced standards, i.e. a maximum of eleven bearers, are not sufficient to provide differentiation among the numerous service data flows generated by the plethora of mobile applications and services. To facilitate mobile edge computing, the MEC server 13 needs information about the service flows, to enable it to provide certain services without referring to the P-GW 23, However, since the eNB 12 is only privy to bearer level information, the application of mobile edge computing at the eNB 12 is

constrained to bearer level processing; thus greatly limiting the mobile edge computing service differentiation capability and potential use cases for both present and future applications.

In the current architecture, the highest eNB protocol in the user-plane is the PDCP. Therefore the eNB has no access to transport or application layer information. The network layer information, i.e. source and destination IP addresses, are theoretically available to the eNB, however the eNB doesnt utilise this information because it encapsulates the entire network layer PDU into a GTP tunnel over the S1 Interface. In principle, the MEC server 13 in Figure 1 could be equipped with deep packet inspection tools in order to extract higher-layer information from the traffic passing through the eNB. However, this would be expensive and would only provide limited information on the service Hows.

Summary of the Invention

According to a first aspect of the present invention, there Is provided a terminal for use in a wireless communication system, the system comprising a base station arranged to wirelessly receive packets from the terminal, and a server in proximity of the base station and arranged for communication with the base station; wherein

the terminal is arranged to include in the packets a service data flow description for extraction by the base station and subsequent use by the server.

By being in proximity to the base station, the server can provide mobile edge computing (MEC) services. "Proximity" includes the server being co-located with the base station (for example in the same cabinet), or integrated with the base station. By "service data flow description" is meant information which in some way describes one or more service data flows, such that by the base station extracting the service data flow description, the server can know details of the service data fiow(s).

Preferably the service data flow description provides, to lower layer protocols of the wireless communication system, information about service data flows at Ngher protocol layers within a radio bearer, in this way, extracting the service data flow description allows the server to distinguish between service data flows from different applications that have been mapped onto the same radio bearer. The service data How description may include at least one of:

IP source address;

IP destination address;

IP protocol;

transport source port

transport destination port;

application header fields; and

packet count information.

Further preferably, the service data flow description is included in a packet data convergence protocol (PDCP) PDU, where as already mentioned "PDU" is equivalent to "packer.

As already mentioned, PDCP PDUs are of two kinds, data POUs and control PDUs. In one embodiment, the PDCP PDU includes a PDCP data PDU and the service data flow description is included in a header of the PDCP data PDU. In this case the service data flow description may provide information about at least one service data flow contained within a radio bearer to which the PDCP data PDU relates.

In another embodiment, the PDCP PDU includes a PDCP control PDU, the service data flow description is included in a payload of a PDCP control PDU, and the PDCP control PDU is distinguishable from other PDCP control PDUs by a PDU TYPE header field. In this case the service data flow description provides Information about multiple radio bearer data blocks that are referenced by respective PDCP sequence numbers. The terminal may be compliant with the set of 3GPP standards known as LTE/LTE-A, but is not restricted to this. According to a second aspect of the present invention, there is provided a wireless communication system comprising:

a terminal;

a base station arranged to wirelessly receive packets from the terminal; and a server in proximity of the base station and arranged for communication with the base station; wherein

the terminal is arranged to include in the packets a service data flow description, and the base station is arranged to extract the service data flow description and communicate the service date flow description to the server. In this system, preferably, the server is further arranged to provide a service to the terminal upon receiving the service data flow description from the base station.

As already mentioned, the present invention relates to mobile edge computing (MEC). The wireless communication system may further comprise a core network, and the service provided by the server can take the place of a service which would otherwise be performed by referring to the core network, thereby reducing latency and improving the user experience. For MEC purposes, tile server may be installed at the base station itself (which can include sharing part or ail of hardware of the base station). The system may include any of the optional features referred to above with respect to the terminal.

According to a third aspect of the present invention, there is provided a wireless communication method wherein a terminal wirelessly transmits packets to a base station by including in the packets a service data flow description, whereby the base station can extract the service data flow description and communicate the service data flow description to a server provided in proximity of the base station. The method may include any of the optional features referred to above with respect to the terminal.

According to a further aspect there is provided a program which when loaded onto a terminal configures the terminal to carry out the method steps according to the third aspect, in general the hardware mentioned may comprise the elements listed as being configured or arranged to provide the functions defined. For example this hardware may include a receiver, a transmitter (or a combined transceiver), a processor, memory/storage medium, a user interface and other hardware components generally found in a terminal

The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can be implemented as a computer program or computer program product i.e., a computer program tangibly embodied in an information carrier, e,g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, one or more hardware modules. A computer program can be in the form of a stand- alone program, a computer program portion or more man one computer program and can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a data processing environment. A computer program can be deployed to be executed on one module or on multiple modules at one site or distributed across multiple sites on the vehicle or in the back-end system and interconnected by a communication network.

Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the Invention by operating on input date and generating output data.

The invention is described in terms of particular embodiments. Other embodiments are within the scope of the following claims. Brief pescriptioo of the Drawings

Reference is made, by way of example only, to the accompanying drawings in which:

Figure 1 shows a system architecture in an LTE wireless communication system wherein a MEC server is integrated into an eNB;

Figure 2 illustrates a user plane and a control plane in LTE;

Figure 3 shows processing of PDUs at various protocol layers in LTE;

Figures 4A and 4B show respectively a PDCP data PDU format for DRBs using 7-bit

SN and a PDCP data PDU format for DRBs using 12-bit SN;

Figures SA and 5B show respectively a PDCP control PDU format for an interspersed

ROHC feedback packet and a PDCP status report;

Figure 6 illustrates how traffic flow templates assign data packets to bearers in an LTE wireless communication system;

Figure 7 shows an EPS bearer architecture in LTE;

Figure 8 shows the first embodiment which modifies a PDCP data PDU format for DRBs using 7-bit SN;

Figure 9 shows the first embodiment which modifies a PDCP data PDU format for DRBs using 12-bit SN;

Figure 10 shows a proposed PDCP control PDU format in the second embodiment; Figures 11A and 11B show the flow of data packets and provision of service data flow descriptions according to the present Invention;

Figure 12 shows a UE suitable for use with embodiments of the present invention; and Figure 13 shows a base station and MEC server suitable for use with embodiments of the present invention.

Detailed Pescription

The invention is based on the recognition that the LTE eNB is unable to distinguish between service data flows or IP packets, from different applications that have been mapped onto the same data radio bearer; therefore the application of mobile edge computing at the eNB is constrained to bearer level processing. Mobile edge computing capability would be greatly enhanced by providing the eNB with additional information regarding the service data flows within a data radio bearer. Such service flow related information may include:

* IP source address.

* IP destination address.

* IP protocol.

* Transport source port.

* Transport destination port.

Application header fields.

* Packet count information

In general, unless otherwise stated the embodiments described herein are based on uplink user plane traffic between a User Equipment (UE) and a base station (eNB) in an LTE-based wireless communication system, where "LTE" is understood as including LTE-A (LTE-Advanced), which term Is used to denote LTE Release 10 and beyond.

First Embodiment - PDCP Data POU

In the first embodiment, the service data flow description is transmitted within a PDCP data protocol data unit. The present embodiment provides an extension to the PDCP data protocol data unit header to include new information elements that provide a description of the service data flow(s) contained within the radio bearers.

Figure 8 presents the proposed extension for a PDCP data PDU with a 7 bit sequence number, applicable to a data radio bearer configured to utilise an unacknowledged mode radio link control (UM RLC) entity. Figure 9 presents the proposed extension for a PDCP data unit PDU with a 12 bit sequence number, applicable to a data radio bearer configured to utilise either an unacknowledged mode radio link control (UM RLC) entity or an acknowledged mode radio link control (AM RLC) entity. Since a PDCP data PDU is involved, the D/C bit will always be 1". These Figures should be compared with the conventional PDCP PDU formats shown in Figures 4A and 48. As win be seen, the new formats differ from the conventional ones by addition of the additional lEs (Information elements) shown by shading. These lEs contain the information on the service flows.

The particular types of information to include will be implementation specific. Among the types of information listed earlier, a non-exclusive list of the most important parameters is: IP source address. IP destination address, IP protocol, Transport source port, and Transport destination port.

Normally, each header in Figures 4A and 4B will provide a description of the service data flows contained in the bearer data identified by the PDCP sequence number. However, it would be possible to convey the service description over multiple PDCP PDUs, provided an association is made between the description and a particular PDCP sequence number.

Second Embodiment - PDCP Control PDU

The second embodiment is iike the first embodiment except that the service data flow description is transmitted within a PDCP control PDU.

As noted earlier, the PDCP control PDU has a payioad in the form of the control information that is exchanged between PDCP entities. The second embodiment employs the same principle by conveying the service data flow information in the payioad of the PDCP control PDU, associating the service description with a PDCP sequence number.

Thus, this embodiment provides an additional PDCP control information element that provides service data flow description information for multiple radio bearer data blocks lhat are referenced by the respective PDCP sequence number assigned by the PDCP entity. Figure 10 presents the format of the proposed PDCP control PDU in this embodiment. The D/C bit will be "0", denoting a PDCP control PDU. The proposed control information element may be identified in the second field. PDU TYPE, by one of the currently-reserved PDU Type values, i.e. 010 to 111 - Next, the service flow information is provided as a sequence of sections each starting with the sequence number SN of the PDCP PDU concerned, then indicating the length (amount) of information which follows, and then the service flow information itself. The field marked £ is a one-bit extension field used to indicate the presence or absence of additional service flow descriptions, £«1 indicating predsence and E=0. absence.

Thus, it can be seen mat, in contrast to Figure 9, the format shown in Figure 10 can carry information relating to a plurality of PDCP PDUs using one PDCP control PDU and does so in the payload, rather than in the header. The same types of service information can be conveyed as listed in the first embodiment. Compared with the first embodiment, the second embodiment can provide more room for the service description, however, it requires tight coupling with the actual user data sent over the PDCP data PDU.

A practical implementation may select freely between the above first and second embodiments, depending on service requirements. Any service could use either kind of PDCP PDU. however, the first embodiment (PDCP data PDU) may be more applicable to services mat have small payioads e.g. text based services, while the second embodiment (PDCP control PDU) may be more applicable to services that have a larger payload, e.g. video.

Figures 11 A and 11 B presents a diagrammatic representation of the proposed invention, in which Figure 11B is a continuation of the flow begun in Figure 11 A. The traffic flow is shown schematically starting at the application layer 111, with a plurality of different applications labelled Application #1 , #2 and #3 and giving rise to Service Data Flows SDF#1 - SDF#3 respectively

At the Transport layer 112, a transport header is added to create packets (PDUs) which are passed to the Network/IP layer 113, As explained in the introduction with respect to Figure 6, a UL-TFT 116 maps the resulting packets onto bearers, in this example two bearers, bearer#1 and bearer #2 each with an associated PDCP entity 115.

The packet flow continues in Figure 118 with the PDCP entities 115 passing the PDCP PDUs to the corresponding RLC entities 116. The packet structure illustrated between 115 and 116 indicates (by the dark shading) that the novel header format according to Figure 8 or 9 has been used so as include service flow information in the header.

The RLC entities perform concatenation and segmentation on packets as outlined in the introduction, and the resulting RLC PDUs are supplied to the MAC layer 117 for forming into transport blocks. As illustrated under the MAC entity 117, the MAC payload includes a single SOU for bearer#l and two SDUs for bearer #2, these SDUs including service information on the respective services mapped onto those bearers, which information can be extracted by the MEC server 13.

It should be noted that the present invention has no impact on the TFTs and will work with the existing TFT structure. Consequently, one of the benefits of the invention is that it utilises the existing TFT structure. Also, it is not necessary to change the mapping of radio bearers to S1 bearers, illustrated in Figure 7. Service requests that can be met locally will be served by the MEC server, while services that cannot be provided locally will follow the normal bearer mapping. Therefore, another benefit of the present invention is that the existing bearer mapping structure can be re-used.

It should further be note that the UE can employ the novel PDCP header format without considering whether a MEC server is available, or whether the MEC server possess resources for the requested services. In this case the service description will be present at the eNB or MEC server, but will not be used.

Examples of how the MEC server could utilise the service description and improve the service to the user include: * Distributed content caching

Sy analysing application layer information, the MEC server can cache popular content locally. This will improve the round trip delay performance hence improving the user's experience, which is particularly relevant for video based services. Additionally, local caching can reduce the demand on the backhaul links of the operator,

* Application-aware performance optimisation Knowledge of the service data flows could be used by the MEC server to optimise the radio transmission to suit a given application or service, e.g. increase the bandwidth, increase scheduling priority, etc.

* Analytics

The service description could be used to perform (video) analytics at the edge to improve response times. Examples of such analytics include predicting services and applications that are popular or most likely to be demanded by users: grouping or clustering users based on the service description; and classifying users for example as "heavy" or "light* users of data.

Figure 12 is a block diagram illustrating an example of a UE 11 to which the present invention may be applied. The UE 11 may include any type of device which may be used in a wireless communication system described above and may include cellular (or cell) phones {including smartohones), personal digital assistants (PDAs) with mobile communication capabilities, laptops or computer systems with mobile communication components, and/or any device that is operable to communicate wireiessly. The UE 11 includes transmitter/receiver uniti» 804 connected to at least one antenna 802

{together defining a communication unit) and a controller 806 having access to memory in the form of a storage medium 808. The controller 806 may be, for example, a microprocessor, digital signal processor (DSP), application-specific integrated circuit (ASiC), field-programmable gate array (FPGA). or other logic circuitry programmed or otherwise configured to perform the various functions described above. In particular, the controller wilt need to be configured to employ the novel PDCP formats shown in Figures 8 to 10. For example, the capability of the UE to employ the novel PDCP header or PDCP PDU format to indicate service data flow information may be embodied in the form of a computer program stored in the storage medium 808 and executed by the controller 806, The transmission/reception unit 804 is arranged, under control of the controller 806, to exchange user data with the eNB 12 and so forth as outlined above.

Figure 13 is a block diagram illustrating an example of equipment suitable for use as an eNB 12 and a MEC server 13. The eNB 12 includes transmitter/receiver unit(s) 904 connected to at least one antenna 902 (together defining a communication unit) and a controller 908. The controller may be, for example, a microprocessor, DSP, ASIC, FPGA, or other logic circuitry programmed or otherwise configured to perform the functions referred to above, such as extracting service data flow description from PDCP PDUs and passing on the extracted information to the MEC server. For example, the various functions described above may be embodied in the form of a computer program stored in the storage medium 908 and executed by the controller 906. The transmission/reception unit 904 is responsible for transmission of the control messages and so on under control of the controller 906. The MEC server 13 includes a communications interface 930 for exchanging data with the eNB 12, a processor 932 for processing data including data for the purposes of providing a service to a user; and a storage medium 934 for storing programs, cached content and results of processing. Although the MEC server is shown as a distinct hardware unit, it will be understood thai in some implementations the eNB 12 and MEC server 13 may share at least some of the same hardware.

To summarise, this invention (when applied to LTE) proposes a method to identify and describe service data flows at the LTE eNB for uplink data radio bearers through a modification of the PDCP LTE layer 2 radio protocol. Features in embodiments include the following:

Identification and description of service data flows in uplink data radio bearers through a modification of the PDCP LTE layer 2 radio protocol. Definition and description of the proposed extension to PDCP data PDU format for data radio bearers.

* Definition and description of the proposed new PDCP Control PDU format.

Provision of aggregated higher layer protocols' information to lower layer LTE radio protocols, i.e. IP source address, IP destination address, IP protocol, transport source port, transport destination port and application header fields.

* Provision of packet count information, at the eNB, that may be utilised for charging, billing and accounting. Various modifications are possible within the scope of the present invention.

The above description has used LTE as an example, employing the term eNB for a base station of such a system. Various forms of base station type device are possible in a wireless communication system (for example, a Home eNB in LTE) as well as relay stations, and the term "base station" is intended to cover ail such possibilities. Any of the embodiments and variations mentioned above may be combined in the same system. Whilst the above description has been made with respect to LTE and LTE A the present invention may have application to other kinds of wireless communication system also. Accordingly, references in the claims to "terminal" are intended to cover any kind of subscriber station, mobile device, MTC device and the like and are not restricted to the UE of LTE.

The above embodiments focussed on upiink data. This invention is not easily applicable to downlink communication from the eNB to the UE, because the UE can support higher layer protocols, unlike the base station which terminates at layer 3. Therefore, including service date flow descriptions on the downlink is usually redundant. However, applying service data flow descriptions by the PDCP layer in DL radio bearers is possible in certain circumstances, such as where the application terminates in the eNB. Specific bearers for location services (to provide accurate UE positioning) would be an example.

The principle of the invention can be applied to other wireless cellular communications systems such as UMTS and CDMA2000. Accordingly, references in the claims to a terminal are intended to cover any kind of user device, subscriber station, mobile terminal and the tike and are not restricted to the UE of LTE.

Whilst a single MEC server and single eNB are shown, there is not necessarily a 1:1 correspondence between eNBs and MEC servers. For example, a MEC server couid be provided at a macro cell eNB and be used for providing mobile edge computing services to users in other cells, such as small cells within a coverage area of the macro eNB. What is needed is that the eNB, with which a user is in wireless communication, can extract service data flow information and to route it to a MEC server which in network terms is proximate to the eNB {and thus to the user) compared with the P-GW conventionally used.

Also, the MEC server need not be a single entity but couid be distributed e.g. among base stations within a local area.

Although Figure 1 shows a MEC server 13 installed at an eNB 12, this location is not essential. The present invention is is equally applicable to UMTS or WCDMA where the RNC is effectively in charge of multiple base stations, so that the RNC would be a natural choice of network node for placing the MEC server.

The above description has referred to providing service information as an aid to mobile edge computing, but this is not the only possible application. Service date flow information such as packet counts may be utilised for charging, billing and accounting at the eNB. This is particularly relevant for traffic offload technologies such as local IP access (UPA) and selected IP traffic offload {SIPTO). in any of the aspects or embodiments of the invention described above, the various features may be implemented in hardware, or as software modules running on one or more processors. Features of one aspect may be applied to any of the other aspects.

The invention also provides a computer program or a computer program product for carrying out any of the methods described herein, and a computer readable medium having stored thereon a program tor carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium, or it may, for example, be in the form of a signal such as a downloadable data signal provided from an internet website, or it may be in any other form. it is to be understood that various changes and/or modifications may be made to the particular embodiments just described without departing from the scope of the claims. industrial Applicability

The invention achieves better service differentiation than the current LTE bearer level QoS framework thus providing a platform to exploit the full potential of mobile edge computing (MEC), Glossary of Abbreviations

3GPP 3rd Generation Partnership Project

ARP Allocation Retention Priority

ARQ Automatic repeat request

DL Downlink

DL-TFT DL Traffic Flow Template

DNS Domain Name Server

DRB Data Radio Bearer

eNB Evolved Mode B

EPC Evolved Packet Core

EPS Evolved Packet System

E-RAB E-UTRAN Radio Bearer

E-UTRAN Evolved UTRAN

FEC Forward Error Correction

GBR Guaranteed Bit Rate

HARQ Hybrid automatic repeat request

IP internet Protocol

IT Information Technology UPA Local IP access

LTE Long Term Evolution

MAC Medium Access Control

MBR Maximum Bit Rate

MEC Mobile Edge Computing

MME Mobility Management Entity

NAS Non-Access Stratum

PDCP Packet Data Convergence Protocol

PDU Protocol Data Unit

P-GW Packet Data Gateway

PHY Physical Layer

QCf QoS Class Identifier

QoS Quality of Service

R8 Radio Bearer

RB-IO Radio Bearer identity

RF Radio Frequency

RLC Radio Link Control

RRC Radio Resource Control

RRM Radio Resource Management

S1-TEID S1 Tunnel End point Identity

S5/S8-TEID S5/S8 Tunnel End point idem

SDF Service Data Flow

SDU Service Data Unit

S-GW Serving Gateway

S1PTO selected IP traffic offload

SRB Signalling Radio Bearer

TCP Transmission Control Protocol

TFT Traffic Flow Template

UDP User Datagram Protocol

UE User Equipment

UL Uplink

UL-TFT Uplink TFT

Claims

1. A terminal for use in a wireless communication system, the system comprising a base station arranged to wirelessly receive packets from the terminal, and a server in proximity of the base station and arranged for communication with the base station; wherein

the terminal is arranged to include in the packets a service data flow description for extraction by the base station and subsequent use by the server. 2. The terminal according to claim 1 wherein the service data flow description provides, to lower layer protocols of the wireless communication system, information about service data flows at higher protocol layers within a radio bearer.

3. The terminal according to claim 2 wherein the service data flow description includes at least one of:

IP source address;

IP destination address;

IP protocol;

transport source port:

transport destination port,

application header fields; and

packet count information.

4. The terminal according to any preceding claim wherein the service data flow description is included in a packet data convergence protocol, PDCP, protocol data unit, PDU.

5. The terminal according to claim 4 wherein the PDCP PDU includes a PDCP data PDU, and the service data flow description is included in a header of the PDCP data PDU.

6. The terminal according to claim 5 wherein the service data flow description provides information about at ieast one service data flow contained within a radio bearer to which the PDCP data PDU relates. 7. The terminal according to claim 4 wherein the PDCP PDU includes a PDCP control PDU, the service data flow description is included in a payioad of the PDCP control PDU, and the POCP control PDU is distinguishable from other PDCP control PDUs by a PDU TYPE header field. 8. The terminal according to claim 7 wherein the service data flow description provides information about multiple radio bearer data blocks that are referenced by respective PDCP sequence numbers.

Θ. A wireless communication system comprising:

a terminal;

a base station arranged to wireless!y receive packets from the terminal; and a server in proximity of the base station and arranged for communication with the base station; wherein

the terminal is arranged to include in the packets a service data flow description, and the base station is arranged to extract the service data flow description and communicate the service data flow description to the server.

10. The wireless communication system according to claim 9 wherein the server is further arranged to, upon receiving the service data flow description from the base station, provide a service to the terminal.

11. The wireless communication system according to claim 10 further comprising a core network, wherein the service provided by the server takes the place of a service which would otherwise be performed by referring to the core network.

12. The wireless communication system according to claim 9, 10 or 11 wherein the server is installed at the base station.

13. A wireless communication method wherein a lerminai wireless ly transmits packets to a base station by including in the packets a service data flow description, whereby the base station can extract the service data flow description and communicate the service data flow description to a server provided in proximity of the base station.

14. Computer program code which, when executed by a processor of a terminal, performs the method of claim 13.