GB2551485A - Providing service data flow description - Google Patents

Abstract

A terminal UE 11 capable of wireless communication sends packets to a base station (eNB) 12, which extracts a service data flow (SDF) description from the encapsulated packets header. A server 13 located proximal to the base station 12 subsequently processes the SDF description. SDF description may be included in the packet data convergence protocol (PDCP) protocol data unit (PDU) formats PDCP data PDU and PDCP control PDU, SDF description may include IP address, IP protocol, ports, application header fields, packet count or packet sequence information. The PDCP control PDU are distinguished by a PDU TYPE header field. The server 13 may provide a service, perhaps otherwise performed by the core network 20. The server may be installed or integrated at the base station 12. Other aspects include a computer program and method. The server 13 is also disclosed as a Mobile-edge computing, MEC server 13.

Description

Providing Service Data 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 dose 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 PDN or Packet Data Network Gateway (P-GW or PDN 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 protocoi 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 protocoi layers as explained below, wherein data packets created by the application are processed by protocols such as TCP, UDP and IP, Meanwhile, in the control plane, Ihe radio resource controi (RRC) protocoi 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 MfvlE. in both cases, the data and/or messages are processed by the packet data convergence protocoi (PDCP), the radio link controi (RLC) protocoi 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 wili now be given regarding uplink user piane 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 ΊΡ 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 mall 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 lower-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 only user plane data, but also certain kinds of control plane data, such as a MAC4 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 like 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. LIE provides header formats for a user plane PDCP data PDU with short PDCP SN (7 bits) as shown in Fig. 4A, a user piane PDCP data PDU with iong PDCP SN (12 bits) as shown in Fig. 4B, and a Control Plane PDCP data PDU. The one bit D/C field is set to Ό’ for PDCP control PDUs and T for PDCP data PDUs. The payload of the PDCP data PDU is the actual bearer or user data while the payload of a PDP control PDU is the control information. 3GPP 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 ‘GOG’ for PDCP status reports and Ό01 ’ 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 38.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 SDUs 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. uni-directional or bi-directional) 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 PDUs 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 PDUs 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 fP data packet flows at the eMB 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, deiay and bit error rate, etc. so as to enabie a given service or control function to be provided. Various types or levels of bearer can be estabiished at different protocol layers in the wireless communication system, For present purposes a so-calied 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, aiso known as Service Data Rows (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 downiink traffic is filtered using downlink traffic flow templates maintained at the packet gateway 23.

According to 3GPP IS 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-GSR), priority, packet delay budget {between UE and P-GW), and packet error ioss rate.

Various GCI 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 QC! value. Therefore, it is possible for two transport iayer PDUs to correspond to two different services but have the same GCI 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 (R84D) to an S1 tunnel endpoint identifier (S1-TESD). The S-GW in turn forwards the packets by use of S5/S8 bearers to the PDN GW 23. The Application/ Service Layer at RDM 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 ίο 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 S1 Bearer 52 (usually on a wired link) between the eNB 11 and S-GW 22. A further Bearer (S5/S8 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 particuiar service or ’‘session", e.g. voice calf or downioad. 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 GoS, 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 eMB 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, while 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 MEG server is present, other applications (involving oniy content cached locally at the SVIEC server for example) would oniy need a radio bearer, and would no longer need the S1 bearer, S5/S8 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 GoS requirements expressed in terms of parameters such as: end to end deiay, 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 GoS control in the E-UTRAN 10 and ERG 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, Le. 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 faciiitate mobile edge computing, the MEG 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 ievel 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 doesn't utilise this information because it encapsulates the entire network layer PDU into a GTP tunnel over the S1 Interface. In principle, the MEG 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 flows.

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 (MEG) services. “Proximity” includes the server being co-iocated 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 higher 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 flow 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 “packet”.

As already mentioned, PDCP PDUs are of two kinds, data PDUs 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 data How 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 mobiie edge computing (MEG). 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 MEG purposes, the 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/siorage 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 standalone program, a computer program portion or more than one computer program and can be written in any form of programming language, including complied or interpreted languages, and it can be deployed in any form, including as a stand-aione program or as a module, component, subroutine, or other unit suitabie 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 data and generating output data.

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

Brief Description 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 LIE 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 Sayers 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 5A 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 controi 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 Description

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 PDU

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 fiow(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 contra! (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 4B. As will be seen, the new formats differ from the conventional ones by addition of the additional IBs (Information elements) shown by shading. These IBs 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 like 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 payload of the PDCP control PDU, associating the service description with a PDCP sequence number.

Thus, this embodiment provides an additionai PDCP control information element that provides service data flow description information for multiple radio bearer data blocks that 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 "G’\ 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 vaiues, 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 E is a one-bit extension field used to indicate the presence or absence of additional service flow descriptions, E-1 indicating predsence and E=G, absence.

Thus, it can be seen that, 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 that have small payloads 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 11A and 11B 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 iayer 113.

As explained in the introduction with respect to Figure 6, a UL-TFT 118 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 11B 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 novei 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 biocks. As illustrated under the MAC entity 117, the MAC payload includes a single SDU for bearer#1 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 wiil 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 iocaiiy wiii 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 novei 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

By anaiysing application iayer 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 iilustrating 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 celi) phones {including smartphones), personal digital assistants (PDAs) with mobile communication capabilities, laptops or computer systems with mobiie communication components, and/or any device that is operable to communicate wirelessly. The UE 11 includes transmitter/receiver unit(s) 804 connected to at least one antenna 802 (together defining a communication unit) and a controller 808 having access to memory in the form of a storage medium 808. The controiler 808 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 wii! need to be configured to employ the novel PDCP formats shown in Figures B to 10. For example, the capability of the UE to empioy 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 808. The transmission/reception unit 804 is arranged, under controi of the controller 808, 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 controiier 908. The transmission/reception unit 904 is responsible for transmission of the controi messages and so on under control of the controiier 906. The MEC server 13 includes a communications interface 930 for exchanging data with the eN8 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 wiii be understood that 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 iayer 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 uplink 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 data 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 CDMA20GG. Accordingly, references in the claims to a terminal are intended to cover any kind of user device, subscriber station, mobile terminal and the like and are not restricted to the UE of LIE.

Whiist 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 could be provided at a macro cell eNB and be used for providing mobile edge computing services to users in other celis, such as smaii ceiis 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 fv1EC 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 could 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 data 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 (LIRA) 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 for 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 LIE bearer level QoS framework thus providing a platform to exploit the full potential of mobile edge computing (MEG).

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 Node 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 LIPA Local IP access LIE Long Term Evolution MAC Medium Access Control MBR Maximum Bit Rate MEC Mobile Edge Computing UME Mobility Management Entity NAS Non-Access Stratum PDCP Packet Data Convergence Protocol PDU Protocol Data Unit P-GW Packet Data Gateway PHY Physicai Layer GCI QoS Class Identifier

QoS Quality of Service RB Radio Bearer RB-iD 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 Identity SDF Service Data Flow SDU Service Data Unit S-GW Serving Gateway SIPTO 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 (14)

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 ciaim 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 ierminai according to any preceding ciaim wherein the service data flow description is included in a packet data convergence protocol, PDCP, protocoi data unit, PDU.

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

8. The ierminai according to claim 5 wherein the service data flow description provides information about at least 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 payload of the PDCP control PDU, and the PDCP 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.

9. 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 data flow description to the server.

10. The wireless communication system according to ciaim 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 ciaim 1Q 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 ciaim 9,10 or 11 wherein the server is installed at the base station.

13. A wireless communication method wherein a terminal wirelessly transmits packets to a base station by including in the packets a service data fiow description, whereby the base station can extract the service data fiow 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.