Abstract:
A mobile telecommunications network includes: a core network ( 2020 ) having content processing means ( 2055 ) operable to provide a core network service relating to content, and a radio access network ( 700, 2003 ) having radio means for wireless communication with a terminal ( 10 ) registered with the telecommunications network, wherein the radio access network ( 700, 2003 ) includes a local source of content ( 1100 ), wherein the telecommunications network is arranged to provide the content processing means ( 2055 ) core network service in relation to the content of the local source ( 1100 ), and wherein synchronisation means is provided to synchronise the provision of core network service in relation to the content of the local source ( 1100 ) with communications with the terminal ( 10 ).

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to a mobile telecommunications network including a core network having content processing means operable to provide a core network service relating to content, and a radio access network having radio means for wireless communication with terminals registered with the network, wherein the radio access network includes a local source of content. The present invention also relates to a corresponding method. 
       BACKGROUND 
       [0002]    Recently, a dramatic rise in sales of both smart-phones and laptop data cards has resulted in a substantial increase in the amount of data communications passing through mobile telecommunications networks. This volumetric increase can also be attributed to enhancements made to the capabilities of the networks. In fact it has been reported that mobile data growth grew 30 percent over the course of the second quarter of 2009. The most popular use for mobile data was HTTP browsing, although usage of HTTP streaming is growing considerably. Other mobile data uses include HTTP downloading and Peer-to-Peer (P2P) activities such as file sharing. 
         [0003]    This ability to use the cellular networks for mobile data services, such as Internet browsing is resulting in subscribers treating their mobile networks in much the same way as they treat their fixed networks. That is, users are tending to expect the same service from the Internet, irrespective of their access method. However, mobile networks have a more restricted capacity and are more costly to operate, as compared to fixed networks. 
         [0004]    In this regard, from the network operator&#39;s viewpoint, as the mobile broadband traffic volume carried over 2G, 3G, HSPA (High Speed Packet Access) and 4G networks continues to grow, the cost of supporting this data volume is becoming more and more expensive based on the current network architecture and deployments. This cost differential is exacerbated by one of the current business models being utilised, whereby operators charge a flat rate for unlimited amounts of data. 
         [0005]    The increased usage is also unfortunately likely to result in an increase of data traffic jams, and hence a degradation of service for mobile users if not properly managed. 
         [0006]    It has been proposed to control data-heavy users by “choking” the bandwidth available to them when a maximum data volume limit is exceeded. Whilst this addresses the problem on an individual level, it does not address the network capacity problem as a whole. 
         [0007]    It is therefore apparent that mobile broadband is at a crossroads as networks and business models are strained by bandwidth demand that is unmatched by revenue generation. 
         [0008]    These problems will only get worse with moves to position mobile data as a replacement for fixed DSL (Digital Subscriber Line) access and with the advent of higher radio access speeds with 4G LTE/SAE (Long Term Evolution/System Architecture Evolution) network. A large percentage of this traffic will consist of data which is destined for the public Internet, a significant proportion of which mobile operators will not be able to add value to, despite carrying the data on their own backhaul transport, core transport or cellular core infrastructure. 
         [0009]    In addition to the problems discussed above, conventional mobile telephone communications networks have architectures that are hierarchical and traditionally expensive to scale. The hardware and software implementation of many network elements, such as the BTS, routers, BSC/RNC etc are proprietary: devices of one manufacturer often do not interface with devices from another manufacturer. This makes it difficult to introduce new capabilities into the network as a different interface will be required for devices from each manufacturer. Further, conventional base stations are not capable of intelligent local routing or processing. Furthermore, the capacity of existing networks is not always used effectively. For example, many cell sites are under used, whilst others are heavily used. 
         [0010]    The current cellular network architecture has the following disadvantages:—
       Hierarchical and expensive to scale   Backhaul is a major problem   Proprietary platforms: BTS, BSC/RNCetc   Closed nodes and interfaces   Very limited application or customer awareness (except for QoS priority)   No intelligent local routing or processing   Inefficient use of installed capacity       
 
         [0018]    There is therefore a need to overcome or ameliorate at least one of the problems of the prior art. In particular there is a need to address the needs of both the network operators and the users in improving the provision of mobile broadband data services. 
         [0019]    EP2315412 describes the introduction of a novel platform at the network edge. To open the radio access part a “General Purpose Hardware Platform” may be implemented at the network edge. This may allow operators to split the functions of an Radio Network Controller (RNC) and/or a (e)NodeB between hardware and software. As a consequence operators have the capability to place applications and content directly at the edge of the network. 
         [0020]    Despite the capability to place content and applications at the edge, such as games, M2M, CDN or cached content, mandatory core network functions, such as Lawful Intercept (LI), Adult Content Filter (ACF), charging or others, must still be supported in the core network. 
         [0021]    As content and applications located at different radio locations require the same services and functions located in the core network, the mobile operator has to offer a service parity if a user or machine gets served e.g. content from the e.g. (e)NodeB or the core network. This is seen as one of the major issues in bringing content and applications to the radio locations. The proposed solution should preferably offer functions and services offered also by the core and Gi networks to the customers. 
         [0022]    A key capability such network enhancements could provide is data caching; when pushed to the edge of the network, data caching capabilities can reduce network traffic, and improve latency of data for terminal devices such as mobile handsets. 
         [0023]    Core network services require access to network data to perform, e.g., Lawful Interception (LI), and charging or billing. LI is obtaining communications network data pursuant to lawful authority for the purpose of analysis or evidence. Such data can consist of signalling or network management information, or the content of the communications. When intelligence is pushed to the edge of the network, access to this network data becomes difficult as some data will only move between network components at the edge. In this scenario, some network data will never enter the core of the network where monitoring for such services is traditionally done. Therefore a solution is required to support core services at the edge of the network. 
         [0024]    Core network services often have other requirements that need to be taken into consideration. For example, avoiding detection of LI is a mandatory requirement to meet legal obligations. LI detection must not be possible by anyone, including end users or compromised employees, with or without direct or indirect access to relevant data. Some details of LI requirements can be found in the following documents, which are fully incorporated herein by reference:
       3GPP TS 33.106, 3G security; Lawful Interception requirements   3GPP TS 33.107, 3G security; Lawful interception architecture and functions   3GPP TS 33.108, 3G security; Handover interface for Lawful Interception (LI)       
 
         [0028]    It is understood that LI warrants require intercept related information (IRI) by Law Enforcement Agencies (LEA&#39;s). An object of an embodiment provides core network services such as LI with access to the original or cached IRI content; the flow of data such as content communication (CC) in LTE and 3G Core Control Plane may be unchanged with the introduction of edge-based intelligence in the communications network. 
         [0029]    The following know arrangements are disclosed in EP2315412. 
         [0030]    Key elements of a 3G mobile telecommunications network, and its operation, will now briefly be described with reference to  FIG. 1 . 
         [0031]    Each base station (e.g. (e)NodeB  1  or Femto  2 ) corresponds to a respective cell of the cellular or mobile telecommunications network and receives calls from and transmits calls to a mobile terminal (not shown) in that cell by wireless radio communication in one or both of the circuit switched or packet switched domains. Here NodeB (3G) or eNodeB (4G-LTE) have been considered but should be just called NodeB for harmonisation. The mobile terminal may be any portable telecommunications device, including a handheld mobile telephone, a personal digital assistant (PDA), machine to machine device (M2M) or a laptop computer equipped with a network access datacard. 
         [0032]    The NodeB  1  or Femto  2  can be considered to comprise two main parts: a radio frequency part (radio unit) and a baseband part. The radio frequency part handles the transmission of radio frequency signals between the antenna of the NodeB  1  or Femto  2  and the mobile terminal, and for converting radio frequency signals into digital baseband signals (and vice versa). The baseband part is responsible for controlling and managing the transmission of the baseband signals to other components of the mobile telecommunications network. 
         [0033]    In a macro 3G network, the Radio Access Network (RAN) comprises NodeBs and Radio Network Controllers (RNCs). The NodeB is the function within the 3G network that provides the physical and transport radio link between the mobile terminal (User Equipment, UE) and the network. The NodeB performs the transmission and reception of data wirelessly across the radio interface, and also applies the spreading codes that are necessary to define carriers in a WCDMA system. The RNC is responsible for control the Node Bs that are connected to it. The RNC performs Radio Resource Management (RRM), some of the mobility management functions and is the point where encryption is done before user data is sent to and from a mobile terminal. The RNC connects to the Circuit Switched Core Network through a Media Gateway (MGW) (or MSC/MSS in case of R4 architecture) and to an SGSN (Serving GPRS Support Node)  5  in the Packet Switched Core Network. In  FIG. 1 , Node B  1  is controlled by RNC  3  across the lub interface. An RNC may control more than one node B. For LTE the following nodes have to be considered: MME, S-GW, PDN-GW). 
         [0034]      FIG. 1  also illustrates a Femto 3G RAN, with Femto  2  operating as the base station. Femto  2  is connected to an Access Gateway (AGW) (a.k.a Concentrator)  4  via an luh interface. Femto is an abbreviation of “femto-cells”, and many other different names have been used, including home access points (HAPs), access points (APs) and femto-base stations, but all names refer to the same apparatus. 
         [0035]    The radio link between the Femto  2  and the mobile terminal uses the same cellular telecommunication transport protocols as Node B  1  but with a smaller range—for example 25m. The Femto  2  appears to the mobile terminal as a conventional base station, so no modification to the mobile terminal is required for it to operate with the Femto  2 . The Femto  2  performs a role corresponding to that of Node B  1  in the macro 3G RAN. 
         [0036]    The Femto  2  would typically be configured to serve a home or office, in addition to GSM/UMTS/LTE networks. The WLAN could belong to the subscriber of the mobile terminal, or be an independently operated WLAN. The owner of Femto  2  can prescribe whether it is open or closed, whereby an open AP is able to carry communications from any mobile device in the GSM/UMTS/LTE network, and a closed AP is only able to carry communications from specific pre-assigned mobile devices. 
         [0037]    Conventionally, in a 3G network (macro or Femto), the RANs are controlled by a mobile switching centre (MSC) and an SGSN (Serving GPRS Support Node)  5  of the core network. The MSC supports communications in the circuit switched domain, whilst the SGSN  5  supports communications in the packet switched domain—such as GPRS data transmissions. The SGSN is responsible for the delivery of data packets from and to the mobile terminals within its geographical service area. It performs packet routing and transfer, mobility management (attach/detach and location management), logical link management, and authentication and charging functions. A location register of the SGSN stores location information (e.g., current cell, current VLR) and user profiles (e.g., IMSI, address(es) used in the packet data network) of all mobile terminals registered with this SGSN. In  FIG. 1 , since the embodiment is concerned with data transmission, only the SGSN is illustrated as being in communication with RNC  3  and AGW  4 , across the lu interface. The RNC  3  typically has a dedicated (not shared) connection to its SGSN  5 , such as a cable connection. 
         [0038]    Communications between the AGW  4  and the SGSN  5  are preferably IP based communications, and may be, for example, transmitted over a broadband IP network. Further, the connection between the Femto and the AGW  4  may use the PSTN (Public Switched Telephone Network). Typically a DSL cable connects the AGW to the PSTN, and data is transmitted there-between by IP transport/DSL transport. The Femto or AGW converts the cellular telecommunications transport protocols used between the mobile terminal and the Femto  2  to the appropriate IP based signalling. The luh interface is similar to lu with some Femto extensions. 
         [0039]    The femto  2  may be connected to the AGW by means other than a DSL cable and the PSTN network. For example, the femto  2  may be connected to the AGW by a dedicated cable connection that is independent of the PSTN, or by a satellite connection. 
         [0040]    The SGSN  5  is in communication with the GGSN  6  (Gateway GPRS Support Node) across the Gn interface. The GGSN is responsible for the interworking between the GPRS network and external packet switched networks, e.g. the Internet. The GGSN enables the mobility of mobile terminals in the networks. It maintains routing necessary to tunnel the Protocol Data Units (PDUs) to the SGSN that service a particular mobile terminal. The GGSN converts the GPRS packets coming from the SGSN into the appropriate packet data protocol (PDP) format (e.g., IP or X.25) and sends them out on the corresponding packet data network. In the other direction, PDP addresses of incoming data packets are converted to the mobile network address of the destination user. The readdressed packets are sent to the responsible SGSN. For this purpose, the GGSN stores the current SGSN address of the user and their profile in its location register. The GGSN is responsible for IP address assignment and is the default router for the connected mobile terminal. The GGSN also performs authentication and charging functions. Other functions include IP Pool management and address mapping, QoS and PDP context enforcement. 
         [0041]    In turn the GGSN  6  may route data via any applicable Value Added Service (VAS) equipment  7 , before data is forwarded towards its intended destination via the Internet  8 . As an example of the functionality of the VAS equipment, the traffic may be inspected for adult content before reaching the end-user if this user is under 18 years of age. 
         [0042]    For billing purposes in particular, a PCRF (Policy and Charging Rules Function) apparatus  9  is also provided, in communication with the GGSN  6 . 
         [0043]    The SGSN  5 , GGSN  6 , VAS  7  and PCRF apparatus  9  comprise the core network of the mobile telecommunications network. The core also comprises further elements, such as the HLR is missing. 
         [0044]    Mobile telecommunications networks have an active state of communication with their mobile terminals and an inactive/idle state of communication with their terminals. When in the active state, as the mobile terminals move between different cells of the network, the communication session is maintained by performing a “handover” operation between the cells. In the inactive/idle state, as a mobile terminal moves between different cells of the network the mobile terminal performs “cell reselection” to select the most appropriate cell on which to “camp” in order that the mobile terminal can be paged by the network when mobile terminating data is destined for that mobile terminal. 
         [0045]    Conventionally, the mobile terminal or network determines whether a handover/cell reselection procedure should be triggered in dependence upon measurements of the radio signals of the cells in the region of the mobile terminal. A filter is applied to the signals (either by the network or by the mobile terminal) which calculates an average (e.g. arithmetical mean) value of these signals over a particular time period. The filtered/average values of the cells are then compared with each other or with a threshold value. In dependence upon these comparisons, cell reselection/handover related procedures are triggered. This cell reselection/handover process generally comprises taking radio signal measurements of neighbouring cells and comparing these to each other and to the radio signal of the current cell to determine which cell provides the best signal strength/quality. Handover/reselection to the best cell can then occur. 
         [0046]    Generally calculations to determine whether to perform a handover from one base station to another base station are performed by the network, whereas calculations whether to perform cell reselection are performed by the mobile terminal. 
         [0047]    Data in a mobile telecommunications network can be considered to be separated into “control plane” and “user plane”. The control plane performs the required signalling, and includes the relevant application protocol and signalling bearer, for transporting the application protocol messages. Among other things, the application protocol is used for setting up the radio access bearer and the radio network layer. The user plane transmits data traffic and includes data streams and data bearers for the data streams. The data streams are characterised by one or more frame protocols specific for a particular interface. Generally speaking, the user plane carries data for use by a receiving terminal—such as data that allow a voice or picture to be reproduced—and the control plane controls how data are transmitted. 
         [0048]    In addition to the elements and functions described above, mobile telecommunications networks also include facilities for transmitting SMS messages. SMS messages are transmitted over the control plane only (and not the user plane). 
         [0049]    This architecture is what currently is being used to carry all packet data to and from mobile terminals. That is, in today&#39;s implementation of the Packet data architecture, user plane traffic traverses across all the network elements shown between the Node B or Femto on which the user is camped and the internet. That is, all data is directed from the applicable RAN through the core network components SGSN, GGSN and VAS before reaching the internet. All PS traffic accordingly follows the same path and therefore has the same network costs. All applications are processed on the client (on the mobile device) or on the server (which is connected to the internet), and the network core therefore acts like a bit-pipe in the current architecture. For data, where the mobile network operator cannot add any value by carrying it on its own backhaul transport, core transport or cellular core infrastructure (the core network), such as data destined for the public internet without required intervention from the core network, there is no benefit to routing this data via the core network. 
         [0050]    However, a large percentage of this traffic can be handled in a more intelligent manner for example through content optimisation (Video &amp; Web), content caching, or locally routed or directly routing content to the public Internet. All these techniques reduce the investment required by a mobile operator to carry the data on its own backhaul and core transport or cellular core infrastructure. 
         [0051]    In order to offer low cost packet data, to support new services and to manage customer expectation, a step-change reduction in the end-to-end cost per bit is required. 
         [0052]    Mobile operators want to reduce their packet data handling costs through alternate network architectures based on commoditised IT platforms, breaking away from the traditional architecture based on their voice legacy. These new network architectures overcome the Access architecture issues of today 
         [0053]    In order to successfully offer cheap packet data and be able to compete with the fixed broadband offers (flat fee) a solution is proposed which focuses on the reduction of the end-to-end cost per bit, especially for Internet access service. 
         [0054]    This enables mobile operators to reduce packet data handling costs by means of an alternative network cost model architecture, which breaks out of the traditional network architecture and nodes and utilises lower cost transport networks to optimise the data flow. 
         [0055]    In this regard,  FIG. 2  shows a high level description of the architecture that may be adopted to deploy this on a 3G network. Such an architecture is described in EP2315412. Note: The proposed solution is also valid for 4G (LTE) networks. 
         [0056]    According to this arrangement, novel “platforms” (control units/means, also referred to as “SAVi”)  24 ,  25 ,  26  for performing functions such as caching, routing, optimisation and offload/return decision functionality are integrated into the network. This decision functionality may be incorporated in the radio architecture. In this regard, the platforms  24 ,  25 ,  26  may be incorporated into the NodeBs  1  ( 25 ), RNCs  3  ( 26 ) or exist as separate physical entities ( 24 ). It is these platforms  24 ,  25 ,  26  that, for example, determine the path of communications originating from the mobile terminals. 
         [0057]    The exact placement of the platform  24 ,  25 ,  26  is not essential, and, for a macro 3G network, it can be placed at or between the Node Bs and the RNCs, and also between the RNCs and the SGSNs (or any combination thereof). It would also be possible to place the platform  24 ,  25 ,  26  close to the GGSN or P-GW. 
         [0058]    In the 3G Macro network, the aim is to offload a high percentage of the macro network traffic from the core and transport (luPS, Gn, etc) by diverting specific traffic type for certain user(s) class directly to the Internet. 
         [0059]    Where the platform  24 ,  25  is located in the Node Bs (or on the lub interface), it may be possible to redirect the data from all the remaining mobile network elements (e.g. the RNC, SGSN, GGSN and VAS for macro 3G), and sending the data directly to the Internet  8  if LI is not mandatory required. In a similar manner, where the platform  26  is located at the RNC (or on the lu interface), it becomes possible to redirect the data from the SGSN  5 , GGSN  6  and the VAS  7 . The alternative data route is preferably a DSL using ADSL. 
         [0060]    It is also preferable to aggregate the alternative data routes for each cell, where applicable. In this regard, each cell will have at least one RNC  3  and a plurality of NodeBs, so where the decision blocks are situated at or in the vicinity of the Node Bs, for instance, there will be a plurality of links which should ideally be aggregated before being passed to the Internet  8 . At the point of this aggregation  42 , there is preferably a further decision block which enables data to be returned to the legacy route. For instance, a new policy rule may have been implemented, which requires or enables previously offloaded data to be returned to the core network route. This new policy rule may be communicated to the return decision module by the core network policy module. In  FIG. 2 , this returning of data is only shown to the VAS  7 , but the data may be returned to one or more of the other core network elements. 
         [0061]    Each of the NodeBs  1  is connected to the mobile network core through a Point of Concentration (PoC)  27 . All traffic from the NodeBs  1  which is to be routed through the core mobile network is routed to the PoC  27 . This includes both user plane and control plane data. On the control plane level, the PoC  27  routes data to and from the SGSN  5  and the GGSN  6 . Control data is also sent to and from other core network components, including the Lawful Interception Database (LI DB)  30 , DNS Server  32 , Policy Server  9  (including Charging rules and IT Network  9 A) and Home Location Register/Home Subscriber Server (HLR/HSS)  36  (which contains subscriber and device profile and state information). 
         [0062]    User plane data is transmitted by the PoC  27  to the SGSN  5  and the GGSN  6 . From the GGSN  6 , data is routed across a VAS  7  node to the Internet  8 . In 3G this is the standard data path from the mobile terminals to the Internet. 
         [0063]    To implement an advantageous feature, an alternative path on which to re-route certain data to the internet  8  is provided, whereby, each NodeB  1  and Femto  2  may be connected to a fixed line connection  40  (e.g xDSL) which is directly connected to the internet  8 . These xDSL connections may be made directly to the NodeB and/or Femto or made to the NodeB/Femto via other components, such as the PoC  27 . In  FIG. 2 , the xDSL Network  40  may be a third party network or may be a network owned or controlled by the owner of the mobile telecommunications network. By using such an alternative path, radio capacity, backhaul transport resource, core transport resource, cellular core network resources could be saved as well as improving performance and enhancing revenue for the mobile network operator in case Charging and LI are not needed. 
         [0064]    As each Node B  1  and/or PoC  27  is associated with a platform  24 ,  25 ,  26 , for each data packet request originating from a mobile terminal, a decision at the platform  24 ,  25 ,  26  is made as to whether the traffic may bypass the core mobile network entirely or may be passed into the core mobile network. The location at which the traffic is routed towards the internet is preferably at the platform  24 ,  25 ,  26 ; however, it may alternatively be routed out from the core network towards the internet at a different component. Traffic offloaded from the macro network is routed by the platform  26  to the xDSL network  40  by link  44  (the decision to offload this traffic may have been made at platform  24 ,  25  or  26 . 
         [0065]    In case Offload is e.g. legally allowed it would be preferably the Offload/Return decision is dependent upon the type of data or user. To exemplify this feature of the embodiment,  FIG. 3  is a flow diagram showing the steps taken when deciding how to route the traffic in the architecture of  FIG. 2 . For instance, consider a NodeB receives a request to set up a data call from a user device which is camped on the NodeB at  300 . Once the NodeB has identified the request as a data call and the type of traffic/user, rather than automatically routing the data traffic to the core network, the data request is held at the NodeB at  310  until a decision has been made as to how to route the data, in particular whether to offload the traffic directly to the internet or whether to return the data through the core mobile network. The signalling (control plane) for the connection may continue through the normal route while the user data traffic will be held at the NodeB, this is possible by virtue of the separate user and control planes, as shown in  FIG. 2 . 
         [0066]    The decision as to whether or not to use the Core mobile Network to route the data traffic can be based on various aspects, particularly relating to the properties of the data being routed and/or status of the user routing the data. 
         [0067]    The Mobile Network may add value to traffic by providing a number of services, such as compressing the user data to speed-up the data transfer while downloading (if this functionality is not already supported by the platforms  24 ,  25 ,  26 ). These different services can be broken up into groups and provided by different entities (e.g. this enables greater flexibility in the provision of the services, such as the mandated Internet Watch Foundation—IWF—requirement, which can only be supported by the mobile operator). The platforms  24 ,  25 ,  26  therefore make a decision on whether to service the data locally through caching, fetch the data from other node or from the internet via offload functionally or whether to route the traffic through the core network, based on the applicability of one or more of the services to the traffic. That is, platform  24 ,  25 ,  26  decides when data traffic requires one or more of the services and when it can do without them. 
         [0068]    It should also be noted that these services are ones that could be provided without using the core network. These are services that add value to the customer, and which subscribers will pay for (explicitly or implicitly). 
         [0069]    Referring again to  FIG. 3 , the platform  24 ,  25 ,  26  decides at  320  what to do with the traffic (from coming for the network/internet or orientated by the device). This decision may be made by interrogating certain servers or databases stored centrally within the core network which can compare the type of service, type of user etc with criteria which identifies the type of action shall be considered, e.g whether the traffic is suitable for offloading directly to the internet (at  330 ) from the NodeB or whether the traffic should be routed through the core (at  340 ). Examples of some of the considerations used in influencing the decision of whether to offload the traffic are discussed below in more detail. The implementation of this data offload technique needs to be carefully considered, as it places additional constraints on the network design. 
         [0070]    The following is a non-exhaustive list of examples of challenges that have to be considered when implementing the data offload technique:
       a) maintaining Customer Services provided by the core network or otherwise;   b) maintaining Network Services (e.g. Charging Rate Limiting/application control); and   c) maintaining Regulatory Services (e.g. to enable Lawful Interception and Regulatory Content Filtering).       
 
         [0074]    Some specific examples of Customer Services that can be taken into account by the offload decision module include:
       i) Parental Control: A service which customers subscribe to that filters content in order to shield children from unwanted websites and programs. Whether traffic from a given user needs to be filtered can be determined by a Common User Repository (CUR) lookup, where the CUR stores user profile information, such as whether the user is an adult or a child etc. If traffic needs to be filtered, then either the traffic cannot be offloaded or it may need to be filtered somewhere other than the core network.   ii) Traffic Optimisation: Optimisation may be advantageous, especially for low bandwidth connections (2G). By looking at the Radio Access Type (RAT) and the International Mobile Equipment Identity (IMEI) it can be determined whether or not a subscriber needs these services. Where traffic optimisation is not required, the traffic may be offloaded   iii) Marketing Proposition: The mobile network is typically setup to provide full mobility with acceptable Quality of Service (QoS). A further option could be to offer best effort QoS without guaranteed full mobility. As an example, for when a heavy user has exceeded their fair usage limit, their traffic could be designated as low priority traffic and offloaded.       
 
         [0078]    The Network Services that can be taken into account by the offload decision module are typically those that the network operator needs to manage its network. Some examples include:
       i) Charging: The charging plan that a user subscribes to can be used to determine whether or not to offload that user&#39;s data. For instance, it is most easily avoided when the customer has a flat rate plan. That is, users on flat rate plans do not need their usage tracked for charging purposes in real time and so can be offloaded onto the alternative route. For users who are roaming or whose charging plan depends upon usage, then, the operator/supplier needs to track their total usage in real-time, and so their data needs to be maintained on the core network route so that rate-limits and data usage can be accurately tracked and alarms/alerts activated when usage exceeds allowances. This is because, if this is not avoidable then Call Data Records (CDRs) need to be generated by the module for the real time charging.   ii) Rate-limiting/application control: This is currently used to manage the traffic flow according to a certain usage policy. Excessive bandwidth usage or controlling P2P applications are common reasons to rate limit users. Therefore, where a user transmitting data is determined to be under a rate restriction (i.e. throttling) or the data they are transmitting has an application restriction (i.e. the application is blocked), then that data can be offloaded. This exceeded allowance information would typically be communicated to the decision module ( 24 ,  25 ,  26 ) by the HLR/HSS. This traffic management enables the total traffic volume to be reduced and is typically fully managed by the network operator.   iii) QoS: The network uses QoS to manage traffic during high load situations and to support marketing propositions. To enable QoS considerations to be enforced by the offload decision module, a connection is established between the offload module and the Policy and Charging Rules Function (PCRF) entity. This enables decision criteria to be dynamically fed to the offload module, for instance to maintain high priority users on the core network path and/or high priority application types, such as VoIP. It is to be appreciated that the connection to the PCRF is not essential, and alternatively, static or semi-static rules, pre-stored with the offload module, can be considered.   iv) Mobility: Mobility, such as cell handover, is an issue that needs to be managed by the core network. Therefore, terminals that are in motion might not be offloaded. The mobility of a mobile terminal could be determined by querying the Node B. Some users could be provided with a contract that allows only fixed or limited mobility use, so that the service provided was equivalent to a fixed broadband package. Different charging tariffs could be applied depending on whether a user was at a fixed location or mobile. Two ways the offload decision module can handle a mobile terminal&#39;s mobility are as follows:
           1. The offload decision module can have the capability to characterise the radio link between the device and the network by monitoring the number of handovers implemented for the mobile terminal. If a certain number of handovers occur over a fixed duration, the mobile terminal can be classified as in motion, and any data from the mobile terminal can thereafter be routed back into the core network to avoid any further packet data delay. This of course assumes that the mobile terminal had been designated for data offload on the bypass link.   2. The offload decision module is situated on the IuPS for the 3G network (i.e. between the RNC and the SGSN) or S1 for the LTE (i.e. between the eNode B and the PoC), and checks the lur or X2 signalling information (i.e. between a set of RNCs controlled by a given 3G SGSN and between a corresponding set of eNode Bs for LTE). If this monitoring shows that a mobile terminal is hopping between cells one of which is not connected to (and therefore managed by) the offload decision module, any data from the mobile terminal can thereafter be routed back to the legacy path through the core network.   
               
 
         [0085]    Regulatory Services are services that are mandated by legislation, and are typically provided to all traffic. Some specific examples of Regulatory Services that can be taken into consideration by the offload decision module include:
       i) Lawful Interception (LI): The ability to provide Lawful interception will be maintained in any offload or local breakout plans. The options for offload are:
           Maintain the evaluation of LI in the core network, and not offload users whose traffic needs to be intercepted (e.g. where the user has been tagged by the police for communication interception). Since the LI functionality is handled by the core network, the core network accordingly cannot be bypassed;   Add LI capability to the offload decision module, which will require a local LI interface with a dedicated database identifying the users to be intercepted. With this option, upon identifying traffic from a user on the list, a copy of the data can be made at the local LI interface and the traffic offloaded. The copied data can then be reported to the appropriate authorities; or   Alternatively, LI may be performed at the Internet Service Provider (ISP). With this option, since LI is considered at the ISP it is not a consideration at the offload decision engine, and so the data may be offloaded, where possible. However, to effect this option, a Service Level Agreement (SLA) with relevant ISP providers may need to be amended in order to include the support of LI in the ISP network rather than in the mobile network infrastructure.   
           ii) Regulatory Content Filtering (e.g. for Internet Watch Foundation (IWF)):
 
This required functionality blocks illegal websites. This functionality could easily be added to the offload decision module as it is not processor intensive. An http proxy server, for instance, could be used to support this functionality. Otherwise, the traffic will be returned back to a dedicated core node(s).
       
 
         [0091]    A further criterion that the platform ( 24 ,  25 ,  26 ) module may consider is the priority of the customer. In this regard, a network operator may wish to prioritise traffic across its network based on the priority level of the customer. For example, a high value customer (e.g. a corporate customer or a subscriber with on a high tariff contract) may be given priority over a low value customer. In this situation, a network may decide to offload lower value customers directly to the internet. This is related to the QoS criterion mentioned above, although the QoS criterion is generally linked to traffic management to maintain a balanced network, whereas the priority referred to can be used to ensure subscribers get a level of service commensurate with their service agreement. 
         [0092]    The embodiment of  FIG. 2  is in relation to a 3G network. Embodiments of the invention are equally applicable to 4G (LTE/SAE) networks. 
         [0093]    The LTE/SAE macro network includes eNode Bs which make up the RAN. The eNode Bs effectively combine the functionality of the node B and the RNC of the 3G network. These eNodeBs are the network components which communicate with the mobile communication devices. It is envisaged that the eNodeBs will be arranged in groups and each group controlled by a Mobility Management Entity (MME) and a User Plane Entity (UPE). UPE is also known as a serving gateway (S-GW). 
         [0094]    The MME performs many of the mobility functions traditionally provided by the SGSN. The MME terminates the control plane with the mobile device. It is responsible for terminating NAS (Non Access Stratum) Signalling such as MM (Mobility Management) and SM (Session Management) information as well as coordinating Idle Mode procedures. Other responsibilities of the MME include gateway selection inter MME Mobility and authentication of the mobile device. 
         [0095]    The UPE manages protocols on the user plane such as, storing mobile terminal contexts, terminating the Idle Mode on the user plane, and PDP context encryption. 
         [0096]    The platforms would operate in the same manner as described in relation to the 3G network. The platforms may be located at many different locations in the 4G network. 
         [0097]    A more specific example of how the platform  24 ,  25 ,  26  may be implemented is described in relation to  FIG. 4 .  FIG. 4  is a flow diagram illustrating a preferred method for deciding whether to offload data traffic to the internet. The decision structure is composed in a hierarchical form in order that certain types of user or data are always directed through the core network. The example of  FIG. 4  is described for a 3G network but it will be clear to those skilled in the art that these decisions could be applied to any type of radio access technology. 
         [0098]    Once a PS HSPA data call (or other connection) is made and received at the Node B at  600 , a primary consideration by the platform  24 ,  25 ,  26  at  610  is whether the device is operating on its home network or whether it is roaming. If the device is roaming then all traffic is automatically routed through the core network. The reason for this is that the home network would want to guarantee the security and accurate billing (due to different charging principle between home and visited operator) of the user&#39;s traffic. The platform  24 ,  25 ,  26  at  610  will also consider other factors, such as what application types running on the mobile terminal require connections. If the mobile device is operating on its home network at  610 , or if the applications do not require a connection to the core network, the platform  24 ,  25 ,  26  considers secondary offloading criteria at  620 . Examples of secondary criteria may include the functions required by the device, the radio bearer currently used by the device, the APN, or the priority level of the customer identified, for example, through IMSI, IMEI or the target subscriber. If the offloading criteria are met at  620 , the decision moves to the tertiary criteria, otherwise, the traffic is not offloaded. 
         [0099]    At  630 , the system checks the mobility of the user. If the user is moving, he is considered not suitable for offload due to an expected interruption delay of the user data when moving between source and target cell. 
         [0100]    Finally, at  640  the system conducts a contents and policy check to confirm whether the user is suitable for offload. If it is determined that the user is suitable for offload to the internet, the eNodeB offloads the traffic to the internet at  650 . If it is determined that the user is not suitable for offloading to the internet at  640  then the procedure returns “home” at  660 . A connection is provided by a network core in a conventional way and the tests of the flowchart shown in  FIG. 4  are repeated periodically to determine whether offloading directly to the internet becomes possible subsequently. 
         [0101]    If the device is determined to be roaming at step  610 , then the device is not offloaded directly to the internet, but remains connected via the network core in a conventional way at  670 . Similarly, if the offloading criteria are not met at steps  620 , the mobile device remains communicating via the network core in the conventional way, again at  670 . 
         [0102]    The hierarchical decision method is useful because it reduces the number of challenges across the network. It will be evident to those skilled in the art that different hierarchical structures will be appropriate for different networks, different conditions etc and that the example of  FIG. 4  is just one way the decision could be made. 
         [0103]    For instance, whilst arrangements have chiefly been described in relation to transmitting data traffic from a mobile terminal to a data network, the principles may also be applied to transmissions from a data network towards a mobile terminal. 
         [0104]    In the arrangements described above the decision regarding the route is said to be made at call set-up. However, it should be appreciated that a decision to change the routing of data may be made at the beginning of a communication session (for example establishment of a PDP context), or during a communication session. The routing of data may change several times during a single communication session. For example, when a communication session is initiated it may be detected that the user is not moving, in which case a decision will be made to offload the data over the alternative data route. Subsequently it may be detected that the user is moving, and at this point a decision may be made to beginning routing data for the communication session via the mobile network. During the communication session, the mobile terminal may become stationary for a prolonged period of time again, and at this time a further decision may be made to send subsequent data during the communication session via the alternative data route. Subsequently again, the user may then attempt to access age-restricted content, and it will be detected that parental control is required. In response for the requirement for parental control, a decision may be made to redirect subsequent data during the Communication session via the core network so that core network parental controls can be applied. 
         [0105]    It is to be appreciated that the present embodiments of the invention are to be distinguished from HSDPA offload, a technique used on the lub interface between the Node B and the RNC. HSDPA offload which serves to separate data traffic from voice traffic, so that non-real time data traffic is sent down a less expensive backhaul to complement or replace the expensive E1/T1 TDM backhaul link between the two. Once this diverted traffic reaches the RNC, however, it is returned to the cellular and transport core networks and there is no differentiation made based upon data traffic type. 
         [0106]    In the arrangement described above the platform  24 ,  25 ,  26  primarily handles data offload decisions. As will be described below, the platform can perform may other functions. 
         [0107]    Arrangements in which the Radio Access Network controls the use of resources by mobile terminals will now be described. 
       Platform Architecture 
       [0108]    As discussed above, a mobile telecommunication network is modified by the introduction of a “platform”  24 ,  25 ,  26 . Such a platform (or control unit/means, also referred to as “SAVi”) is shown in more detail at  700   FIG. 5  and which includes three principal parts: soft nodes  702  (physical/transport layer), network functions  704  and services  706  (application layer). 
         [0109]    The platform  700  communicates with the radio frequency/RF part (radio unit) of a base station, such as a NodeB  1 . The soft nodes  702  of the platform  700  comprise components such as a soft NodeB  708 , soft BTS  710 , soft eNodeB  711  and soft RNC  712  and soft SGSN/GGSN  714 . The soft nodeB  708  provides functions equivalent to the baseband part of a conventional NodeB in a 3G telecommunications network. The soft BTS  710  provides baseband functions equivalent to the baseband functions of a BTS in a conventional 2G mobile telecommunications network. The soft enodeB  711  provides baseband functions equivalent to the baseband functions provided by a conventional enodeB in a 4G mobile telecommunications network. The platform  700  may therefore communicate with the radio frequency part of a 2G, 3G or 4G base station and provide appropriate baseband services for 2G, 3G or 4G technologies (or indeed for other technologies). A 3G mobile terminal that wishes to obtain telecommunication services from the mobile telecommunications networks connects wirelessly to the radio frequency part of a NodeB. Baseband functions may be provided either by a baseband part of the conventional NodeB or by the soft NodeB  708  forming an element of the soft node part of the platform  700 . For example, the soft NodeB  708  may receive radio measurements from the radio frequency part of the NodeB to which it is connected, and may provide these radio measurements to other elements of the platform  700 . 
         [0110]    The network functions part  704  of the platform  700  includes modules for performing functions similar to those performed by the core network of a mobile telecommunications network, such as billing  720 , location tracking  722  and the radio resource management (RRM)  724 . The network functions may further comprise an offload decision module  726  that performs a function similar to the offload decision modules  24 ,  25  and  26  described above. The network functions part  704  may further comprise a caching function  728  and Content Delivery Network function  730 . 
         [0111]    The network functions part  704  of the platform  700  provides an Application Programming Interface (API) framework to the services part  706  of the platform  700 . The services part  706  of the platform supports a plurality of applications  740 ,  742  etc. 
         [0112]    The network functions fall into three main categories, those that enable the network operation (e.g. charging, O&amp;M), those that support service operation (e.g. Location) and those that optimise the usage of the network by certain applications and services (e.g. Caching, Video Optimisation). 
         [0113]    The applications supported on the Platform  700  are the entities that supply or demand the flow of data on the network, akin to a server on the internet, e.g. gaming server, navigation server. 
         [0114]    The API is implemented by a software program running on the network function part  704  which presents a novel standardised interface for the applications  740 ,  742  etc of the services part  706 . The novel standardised API provides a consistent interface, defining communication protocols, ports etc. Full details of the API may be published to allow a multiplicity of applications to be developed for the platform  700  by multiple developers. This should be contrasted with prior art arrangements where each component of a mobile telecommunications network (such as BTS, BSC/RNC, SGSN etc) is proprietary and tends to have a unique interface, meaning that a different application must be written for each node of a conventional network. 
         [0115]    The applications  740 ,  742  etc may provide services to users of the telecommunications network by co-operating with other parts of the platform  700 . 
         [0116]    The details of the use of each application used by a user of the mobile telecommunications network are stored in an application context/container. The Application context contains application names, protocol used to carry such application, their characteristics that are measured/reported over period of time and some statistical information about these applications (volume, number of users using these applications, etc.). 
         [0117]    As shown in  FIG. 6 , a platform  700  may be provided at each base station of the mobile network (where it is connected to the radio frequency part of the base station—NodeB  1  in  FIG. 2 ), forming an access node  800 . Platform  700  may also be provided at the RNC (item  3  in  FIG. 2 ) where it forms a gateway  802 . The access node  800  and the gateway  802  are both configured to communicate directly with the network core  804  (for example, comprising the SGSN  5 , GGSN  6  and VAS  7  (as shown in  FIG. 4 )). The access node  800  and gateway  802  may also be connected to the internet  8  for direct internet access via direct links  806  and  808 , respectively, such that at least a portion of the core network  804  is bypassed in the manner described above. 
         [0118]    The following are examples of access technologies that can be provided within the access node  700 : 
       3GPP: GSM/GPRS, UMTS/HSPA &amp; LTE 
       [0119]    IEEE: 802.11 family &amp; 802.16 family 
       ITU: DSL, ADSL, VDSL, VDSL2 
     Allocation of Functions to Platforms 
       [0120]    The steps performed when a mobile terminal is activated at a NodeB, at the Femto or at the Access Point (AP) of the network which includes the novel platform  700  will now be described with reference to  FIG. 7 . At step  9 A the mobile terminal (UE) is activated within the coverage area of a particular NodeB, at the Femto or at the AP. The access part of the NodeB, at the Femto or at the AP communicates information from the mobile terminal to the platform  700  associated with the NodeB, at the Femto or at the AP. At step  9 B the platform  700  then allocates the baseband NodeB, at the Femto or at the AP function and the RNC or BRAS (Broadband Remote Access Server) function either at access node  800  at the NodeB at the Femto or at the AP site or at the gateway  802  at the RNC or BRAS site of the network or even from neighbouring nodes that have spare resources to pull. The decision as to whether the RNC or BRAS function is allocated at the platform  700  of access node  800  or the gateway node  802  may be made depending on various criteria, including:
       The device type—for example this decision can be based on the radio access capabilities that the mobile terminal indicates upon activation, such as whether it is operating in the circuit switched or packet switched domains.   The location of the mobile terminal. If the mobile terminal is near the edge of the cell (which can be determined by network power measurements or neighbour cell measurements from the mobile terminal, within a plus or minus 3 dB range for the RACH).   The establishment cause of the connection request: such that the NodeB can filter the unnecessary signalling information from the mobile terminal which is not critical—for example periodic routing area update messages.       
 
         [0124]    Upon allocating the baseband NodeB at the Femto or at the AP and the RNC or BRAS function, the NodeB at the Femto or at the AP may allocate the mobile terminal to a particular carrier dedicated to the RNC or BRAS function. 
         [0125]    Once the RNC or BRAS function is allocated to either the access node  800  or the gateway  802  at step  9 C, other functions performed by the platform  700  at the access node  800  (or other access node) and the gateway  802  (or other gateway) are allocated to the mobile device. All other platform functions may be provided by the platform where the RNC or BRAS function is allocated to the mobile terminal. However, a platform at a different location to that which provides the RNC or BRAS function to the mobile terminal may provide some or all other functions. 
         [0126]    At step  9 D the platform which is allocated the RNC or BRAS function is provided with a Common ID message from the core network  804 . 
         [0127]    At step  9 E, this message is used by the platform  700  to look up the complete subscription information for the mobile terminal, as well as the resource requirements (QoS) of the services required and negotiated PDP context, this information being provided by the core network  804 . 
         [0128]    The subscription information relating to the device that is obtained from the central nodes (e.g, core network)  804  is used to allocate the other functions at access node  800  and/or the gateway  802  in dependence upon various factors, including:
       Detailed information regarding the mobile terminal type obtained from the core network.   The subscription characteristics of the mobile terminal.   The applications previously used most frequently by the mobile terminal.   The characteristics of the applications previously used by the mobile device and the performance requirements thereof.   The historic mobility of the mobile terminal (speed, connection, distance travelled etc).   The location of the mobile terminal and the likely destination of traffic from the mobile terminal based on historic usage patterns.   The load of the NodeB providing RF services to the mobile terminal, and the historic traffic trends at that NodeB at Femto or at AP.   The characteristics of the NodeB at the Femto or at the AP providing RF services (for example, the location, what other devices are connected through the NodeB at the Femto or at the AP, the number of machine to machine devices being attached and served by the NodeB, etc).       
 
         [0137]    As mentioned above, a single mobile terminal may have platform functions/applications allocated on a plurality of platforms. Generally, when a mobile terminal is near-stationary it is most efficient for its functions/applications to be served from an access node  800  (i.e. distributed), whereas mobile terminals with greater mobility (or lower anticipated cell hold times) will be most efficiently served by having fewer or no functions/applications served from the access Node  800 , and more or all functions/applications served from a gateway  802  (i.e. centralised). The assignment of functions/applications to a mobile terminal between an access node  800  and a gateway  802  will also depend upon the characteristics of the service type provided by the application (for example, the average IP session duration, the popularity of the particular application, the average mobility of mobile terminal using the service provided by the application etc). 
         [0138]    Traffic management may be performed at the access node  800 , where there is access to real-time radio information from the radio frequency part of the NodeB, the Femto or the AP serving the mobile device. 
         [0139]    Centralised Radio Resource Management (RRM) may be provided at the gateway  802 , and maintains performance across different access modes  800 , which may have different radio access technologies, frequency bands, coverage etc. The RRM function  724  of the platform  700  of the gateway  802  may obtain information regarding radio traffic management from each access node  800  to dynamically position subscribers to particular radio technology. This technique will be used to allocate network resources based on the resource availability, application used and user mobility, For example, the traffic management information may be provided by the soft NodeB  708 , Femto or AP of the platform  700  at the access node  800 . This soft NodeB  708  obtains radio information relating to the mobile terminal from the radio frequency part of the NodeB to which the mobile terminal is wirelessly connected. 
         [0140]    For a particular mobile terminal, functions provided by an access node  800  and gateway  802  may be coordinated to work together in an advantageous manner (i.e. a hybrid or distributed arrangement). For example, the gateway  802  may set operating limits or ranges within which functions performed by the access node  800  may be performed, without reference to the gateway  802 . When the functions move outside the ranges set, control of those functions may be passed to the gateway  802 . 
         [0141]    Further, the access node  800  and the gateway  802  may cooperate to advantageously optimise content delivery to a mobile terminal. 
         [0142]    The optimisation of content delivery will now be described with reference to  FIG. 8  of the drawings. Content may be optimised at gateway  802  and at an access node  800 . The gateway  802  may serve multiple access nodes  800 , and may distribute content to those multiple access nodes  800 , for onward transmissions from each of those access nodes  800  to a mobile terminal via the radio frequency part of NodeB, the Femto or the AP serving that node. Radio quality measurements are reported by the mobile terminal to the access node  800  at regular intervals, such as 2 millisecond intervals. Radio quality measurement relating to that mobile terminal are transmitted between the radio frequency part of the NodeB, the Femto or the AP serving the mobile terminal to the access node  800  at regular intervals, such as between 2 and 10 millisecond intervals. These radio measurements are received at the soft nodes  702  and are passed to functions  704  (e.g. to QoS function  732  for analysis). These radio frequency measurements from the mobile terminal and the NodeB are reported by the access node  800  to the gateway  802  (e.g. to QoS function  732  of the gateway  802  for analysis) at regular intervals, such as intervals of between 1 and 10 seconds. The gateway  802  may receive radio information from multiple access nodes  800 . The radio measurements received by the gateway  802  may be analysed over a relatively long period, such as between 1 and 2 minutes. The radio quality measurements may be averaged (for example, the arithmetical mean of the radio quality maybe determined) over this time period. The transmission of content from the gateway  802  may then be optimised according to this calculation. Where the content is distributed by the gateway  802  to a plurality of access nodes  800 , the content distribution will be based on the analysis of the radio quality indicators from all of the access nodes  800 . The analysis may consider the maximum or peak radio performance over the time period of between 1 and 2 minutes. 
         [0143]    When the content is received by each access node  800 , the access node  800  then distributes the content to each mobile terminal. This distribution is optimised based on real-time network mode and mobile terminal specific radio link quality, as determined over a period of, for example, between 1 and 10 milliseconds. That is, content delivered to a mobile terminal that has high radio link quality may be optimised in a different manner to a mobile terminal that had poor radio link quality. 
         [0144]    The co-operation between access nodes  800  and gateways  802  may further enhance the distribution of content in a manner now to be described with reference to  FIG. 9 . 
         [0145]    When a mobile terminal requests a particular content item, this request is transmitted to the access node  800  serving that mobile terminal, assuming that this is the first request for this content item to the access node  800 , the access node  800  passes this request to the gateway  802  serving the access node  800 . Assuming that this is the first request for this content item from the gateway  802 , the gateway  802  retrieves the content from a content server. The content is then provided by the content server to the gateway  802 , and from there is distributed to the access node  800 , and onwardly to the requesting mobile terminal. Advantageously, the gateway  802  maintains a record of content items that are requested frequently. When a content item is determined by the gateway  802  to be requested frequently, this is stored in a cache  1110  associated with the gateway  802  (which may be the cache  728  of the platform  700 ). Subsequent requests for that content item from access nodes  800  to the gateway  802  can then be serviced by retrieving the content item from the cache  1110  and distributing the content item to the requesting access node  800 , and thus avoiding the need to request the content from the content server. 
         [0146]    The gateway  802  may be further configured to identify popular content items that are likely to be requested by a large number of access nodes  800 . When it is determined that a content item is popular, the gateway  802  may push these content items to each of the access nodes  800  associated therewith (so that this content is hosted at the access node  800 , using Content Delivery Network (CDN) function  730  of the network functions  704  of the gateway  802  and the access node  800 ). The content is then available at the access node  800  for transmission to any mobile terminal that requests it, without having to retrieve this content from the gateway  802  or the content server. Advantageously, the distribution of such content items is performed in a manner which takes into account the capacity or the congestion of the link between the mobile terminal and the gateway  802  and the nature of the content. For example, typically a link between a mobile terminal and the gateway  802  may experience very little usage and congestion in the early hours of the morning. The content item can be advantageously transmitted in between the gateway  802  and the access node  800  at this time, when there is spare capacity. The gateway  802  will determine whether the content item is suitable for transmission on this basis, for example, by taking into account a number of times that the content item has been requested, the size of the content item and the storage space at the access node  800 . If a content item is relatively small and is time-critical, such as news headlines, then such a content item may be distributed frequently throughout the day, as such content is not suitable for transmission once a day at early hours of the morning, as it becomes quickly out of date. 
       Relocation of Mobile Terminal 
       [0147]    The procedures performed when a mobile terminal moves between cells in the mobile telecommunications network will now be described with reference to FIG.  10 . In the conventional manner at step  12 A, when the mobile terminal moves to the edge of its current serving cell, the radio measurements reported from the mobile terminal and the radio frequency part of the NodeB, the Femto or the AP serving that mobile terminal are used by the core network to determine when to perform a handover and to which target cell the handover should be performed. When the best target cell has been identified, handover to that target cell from the serving cell it is performed at  12 B in a conventional manner. 
         [0148]    At step  12 C selected platform functions may be relocated from the source access node (that served the old cell) to the destination access node (that serves the new target cell). 
         [0149]    When the source and destination access nodes are served by the same gateway, only base station function (such as soft NodeB functions  708 ) may be relocated to the destination access node. 
         [0150]    The relocation of functions of the access nodes is performed independently to the radio handover, so for some time after the radio handover, the source access node continues to serve content to the mobile terminal through the destination access node. The routing of data packets for the 3G network between the destination and the source access nodes may be performed using an lu interface between the RNC or BRAS function  712  of the destination access node and the SGSN/GGSN function  714  of the source access node. Alternatively, the routing of data packets between the destination and the source access nodes can be completed by the SGSN/GGSN function  714  of the destination access node connecting directly to functions of the source access node through an IP interface. 
         [0151]    After handover has been completed at step  12 B, the access node controlling the mobile terminal may be relocated from the source access node to the destination access node in coordination with the gateway, the standardised handover decisions (mainly based on coverage, quality, power, interference, etc.) for 2G, 3G, LTE &amp; fixed network are used to move the mobile from one node or system to another. However, the platform  700  introduces new opportunity to make the handover decision based on type or characteristics of the certain application, type of user and the QoS requirements. 
         [0152]    The timing of the relocation of access node functions from the source to destination platform may be dependent on the following:
       the duration of the current connection/communication of the mobile terminal   the speed of movement of the mobile terminal   the characteristics of the applications being used by the mobile device, the quality of service, the predicated type and amounts of transmission ongoing.   The radio resource allocations status at the mobile terminal   The respective node of the source and destination and access nodes.       
 
         [0158]    At step  12 D, optionally, some functions will be reallocated from the access nodes to the gateway. For example, if the destination access node is heavily loaded and is congested, or has a lower capability then the source access node, or the mobile terminal is determined to be very mobile, it may be advantageous to transfer functions to the gateway. Functions are reallocated from the access node to the gateway by, for example, a Serving Radio Network Subsystem (SRNS) relocation between the RNC function  712  of the access node and the gateway. Alternatively the functions may be reallocated by performing a radio reconfiguration of user connection to the mobile terminal. 
         [0159]    The reallocation of functions from an access node to the gateway may be performed at call/communication sessions set-up. At call/communication session set-up, further subscriber information will be provided, which may be used by the access node or gateway to be determine whether it would be advantageous to reallocate functions from the access node to the gateway. Reallocation of functions from the access node  800  to the gateway  802  may be performed during an active connection when a requirement of the communication sessions has been modified, or where the required resource is not available at the access node  800 . 
         [0160]    According to the same principles, applications, like fast caching, may be (re)located (or distributed) between access nodes  800  and for gateways  802  to provide optimised application delivery/best use of the communication resources. 
         [0161]    As mentioned above, information about each application used by the user at the mobile terminal is stored in an application context. The application context is shared between each access node  800  and gateway  802  that control the user connection for that mobile terminal. One of the access nodes  800 /gateways  802  will be the “master” for that particular application, and that will also be the master of an application specific record in the application context. The application context is advantageously periodically synchronised between the access node  800  and the gateway  802 . 
         [0162]    The application information is the application context specific to a particular mobile terminal, and this is passed between access nodes and gateways during reallocation for a mobile terminal, enabling the application to be seamlessly passed access nodes/gateways, avoiding impacts to the user experience. 
         [0163]      FIG. 11  shows the transfer of application information between access nodes and gateways. 
       Tailoring Bandwidth to Application 
       [0164]    Radio measurements received from the radio frequency part of the NodeB, the Femto or the AP serving the mobile terminal are passed to the soft nodes  702  of the platform  700  (of the access node  800  or gateway  802  serving the mobile terminal), and are passed to the network functions  704  of the platform  700 , which then distributes the measurements to where necessary within the platform  700 . The platform  700  has access to the subscriber information from the core network, which allows the network functions  704  to deliver data traffic in a manner that is optimised for radio conditions as indicated by the radio measurements. The data traffic may also be optimised according to the subscription of the user of the mobile terminal available radio resource, mobile terminal capability, and/or for the class of the terminal (e.g. access technologies used). This optimisation allows bandwidth usage to be balanced with customer experience. The subscriber information may include information about the price plan of the user of the mobile terminal. The mobile network operator may track the type of application used by the user, the total data usage of the user, and may differentially target radio resources the highest data value stream of users. 
         [0165]    By hosting applications  740 ,  742  in the services part  706  of the platform the access node  800  (or at least the gateway  802 ), the point of the network that is aware of the application being used by the user of the mobile terminal closer in the link between the mobile terminal and the core network to the NodeB serving the mobile terminal. This enables the sharing of network resources to the most appropriate data streams, such as the most profitable data streams. Such awareness of the application to which a request for data transmission relates allows the use of low value data streams, such as peer-to-peer file sharing, to be allocated only limited bandwidth, so that remaining bandwidth can be targeted to particular users. In the uplink, transmission of data can be controlled by the access node  800  (or gateway  802 ) hosting the application to control data flow appropriately before data is onwardly transmitted towards the core of the network (which was not possible with conventional arrangements). 
       Application Programming Interface (API) 
       [0166]    As mentioned above, a novel API is provided which defines the language that each of the software modules  740 ,  742  of the platform  700  use to communicate to coordinate to optimise application delivery to users. The platform  700  negotiates which each application  740 ,  742  the specific resource and performance requirements based on the application characteristics, allowing the application to directly communicate the scheduling performance requirements, rather than using a predefined set of quality of service parameters. This negotiation between the platform  700  and the applications  740 ,  742  is facilitated by the API. 
         [0167]    The API may also facilitate the provision of radio link quality information (e.g. from QoS function  732 ) to applications  740 ,  742 . 
         [0168]    The API may further enable the platform  700  to control use of the applications  740 ,  742 —e.g. to allow, disallow or adapt the applications. 
         [0169]    By way of example, the application  740  may be a Voice over IP (VoIP) application. The nature of Voice over IP communications is that there is a virtually continuous succession of small data packets in which voice data is communicated. The voice data must be communicated with no or minimal latency in order that a two-way conversation can be performed successfully. The Voice over IP application  740  is able to compress voice data before transmission using a variety of techniques/CODECs. The compression techniques/CODECs may range from a relatively low compression technique, which provides high quality voice reproduction but requires a large bandwidth, to a much higher compression technique which provides reduced voice quality and which requires a much lower bandwidth. 
         [0170]    The API is operable to provide details of the application characteristics to the network functions part  704  of the platform  700 . This makes the network functions part  704  of the platform aware of the characteristics of the application. In the present example, as the application is a Voice over IP application, the network functions part  704  may be made aware that the application will tend to transmit continuous successions of small data packets that require transmission with no or low latency. The network function  704  may then be configured appropriately. 
         [0171]    The API may further be operable to allow the network functions part  704  to communicate radio link quality information to the application  740 . For example, when the network functions part  704  received information regarding the application characteristics (via the API), it may allocate radio link resources to that application  740 . This allocation of radio link resources may be communicated by the network functions part  704  to the application  740  (via the API). The application  740  may then select an appropriate compression technique/CODEC in dependence upon the radio link quality available. During a Voice over IP call, the available radio link quality may be communicated regularly from the network functions part  704  to the application  740  (via the API) to allow the application  740  to vary the compression technique/CODEC used in accordance with changes to the radio link quality. 
         [0172]    The network functions part  704  may control how the applications  740 ,  742  work (via the API). The network functions part  704  may allow, disallow or adapt the applications  740 ,  742  hosted in the services part  706  of the platform  700 . For example, the network functions part  704  may require the Voice over IP application  740  to use a particular compression technique/CODEC if radio link bandwidth is restricted. 
         [0173]    Another example of how the network functions part  704  may advantageously provide radio link quality information to an application (via the API) is when the application  742  is a gaming application used by several users. If the radio link quality information received by the application  742  indicates that bandwidth is restricted, the application  742  may adapt is communications to the users such that latency of the communications is increased uniformly for all of the users (so that they all experience the same delay), in order that each of the users is provided with the same gaming experience. 
         [0174]    In the arrangements described, the devices that connect to the platforms  700  are mobile devices that connect to the platforms via the radio access network of a mobile/cellular telecommunications network. It should be appreciated that non-mobile (fixed) devices may be connected to the platforms  700 , for example by a wired or cable connection. 
       Allocation of Services 
       [0175]    The control means is responsible for allocating the service instance for each UE, based on the UE locations and the control means capacity, capability and available resources to host another instance of a service. The UE is using service but the User (MSISDN) gives access to specific services. 
         [0176]    For certain low popularity services or where the available serving control means capacity or capability is limited, the service can be hosted from a central control means, or from a neighbouring distributed control means. 
         [0177]    For some services/functions, where the source and destination client applications are in the same geographical region, being served by the same site (e.g. BTS location) or site cluster (e.g. finite number of sites), the access node  800 /gateway  802  ensures that the server for the service is located close to both users, and the traffic is routed between the users within the site. 
         [0178]    The arrangement described above in relation to  FIGS. 1 to 11  is the subject-matter of EP2315412. Such an arrangement deals with LI and other core network functions by always routing traffic that must be subject to LI and other core network functions through the core network, or by providing LI and other core network functions functionality at the network edge. 
         [0179]    An alternative known representation of the platform  700  is shown in  FIG. 12 . The platform  700  includes a platform core  1000  which communicates based on two sets of APIs:
       Application APIs  1010 —which, as discussed above, offers standardised hosting environment for applications providing communication to Service Software  741 ,  742  and Network Functions Software  1015 ,  1016  hosted on the platform  700 .   Network APIs  1017 —which provide control and connectivity to network nodes  1030  through a vendor specific Adaptors  1020 ; Network API defines standardised communication between core  1000  and the Adaptors  1020 ; Communication between Adaptor  1020  network nodes and 3GPP/LTE node, such as (e)NodeB  1 , BBU  1032 , RNC  3 , SGSN  5 , GGSN  6 /P-GW and MME  1040 , remains proprietary       
 
         [0182]    The Platform  700  includes common network functions Software  1015 ,  1016  such as Scheduling, Routeing, Billing/accounting, security and Policy functions, which allow the architecture to offer seamless experience across the network. 
         [0183]    The Adaptors  1020  translate the Vendor specific implementation on the 3GPP/LTE nodes  1030 , such as eNB, BBU, RNC, SGSN, GGSN/P-GW and MME, to common and open interface to the environment of platform  700 . 
         [0184]    The Adaptor  1020  for each 3GPP/LTE node  1030 , such as eNB, BBU, RNC, SGSN, GGSN/P-GW and MME, is responsible for ensuring communication between the Network API  1017  and 3GPP node is secure. 
         [0185]    The Platform  700  provides the capability for some Applications  741 ,  742  hosted in the Platform  700  to be contacted remotely from the platform  700 . 
         [0186]    Logically control and data traffic interfaces (control plane and user plane) between the physical manifestations of the platforms  700  exist independent of the underlying 3GPP/LTE network nodes  1030 . These interfaces will require to be made secure through functionality included within each platform  700 . 
         [0187]    The Platform  700  may also provide the capability for hosted Network  1015 ,  1016  and Service Applications  741 ,  742  on different platforms  700  to communicate and pass data in a secure manner without mandating security to be provided by the application  741 ,  742 ,  1015 ,  1016 . 
         [0188]    In contrast to the arrangements described above, in this implementation the platform  700  may handle both control and data traffic interfaces (control plane and user plane), rather than just the data traffic/user plane. Further, in contrast to the arrangements described above the nature of the gateway  802  may be different. In the implementation described hereinafter, the gateway  802  may be located other than at the RNC. For example, the gateway  802  may be located at the SGSN  5 , GGSN  6 , VAS  7  or PCRF apparatus  9 , or in any part of the network core or RAN. In the implementation described hereinafter, the gateway  802  may be considered to be an interface between the platforms  700  at the access node ( 800 ) and the core network, rather than part of the “control means”. 
         [0189]    When the platform  700  environment is introduced into a mobile network it means that traffic can be inserted, hosted or created in the data path between GGSN  6  and UE, potentially impacting the operation of existing core systems (such as charging, policy enforcement &amp; LI from other core network components (Charging rules and IT Network  9 A, Policy Server  9  and including the Lawful Interception Database (LI DB)  30 —see  FIG. 2 ) which need to be replicated. 
       SUMMARY OF THE INVENTION 
       [0190]    In one aspect the present invention provides a mobile telecommunications network including:
       a core network having content processing means ( 2055 ) operable to provide a core network service relating to content, and   a radio access network having radio means for wireless communication with a terminal registered with the telecommunications network, wherein the radio access network hosts a local source of content,   wherein the telecommunications network is arranged to provide the content processing means core network service in relation to the content of the local source, and   wherein synchronisation means is provided to synchronise the provision of core network service in relation to the content of the local source with communications with the terminal.       
 
         [0195]    The network may be operable to provide the content processing means with a copy of the content of the local source. 
         [0196]    The radio access network may be operable to copy a request for content that is used by the terminal ( 10 ) to request content from the local source, and to forward this to the core network for use in obtaining the copy of the content of the local source. 
         [0197]    The copy of the content may obtained from a primary content source (e.g. to be authorised by a node gateway, such as a P-GW, by the use of an agreed pre-configured IP addresses) from where the content of the local source may have also been obtained. 
         [0198]    The network may include a content buffer between the primary content source and the content processing means, and synchronisation means operable to withhold providing the service relating to the content until receipt of the local content from the radio access network has been acknowledged by the terminal. 
         [0199]    The network may include means for providing the synchronisation means with an indication of data transmission events in the radio access network. Network events are exposed to trigger re-anchoring. The events may for example be handover or mobility events. 
         [0200]    The Access or Core network can decide to re-anchor content delivery sourced at the core from the radio access network triggered by exposed network events in order to support lossless handover and mobility. This can be extended to cover roaming use cases. 
         [0201]    The buffer may provide the copy of the content to a gateway node ( 2020 ) of the network, such as a GGSN, P-GW or SAE-GW. This may allow support of inter-RAT handover, mobility, to a plurality of RATs 2G, 3G and wifi as well as LTE. 
         [0202]    The core network may be operable to discard the copy of the content after provision of the continent processing means core network service thereon. 
         [0203]    The core network may include a database synchronised with the local source of content such that the core network is aware of the content available at the radio access network. 
         [0204]    Mobility, ideally lossless handover, is a key function that is required to be maintained for edge services where the challenge is that content may not be available or is difficult or cannot be seamlessly referenced on a handover target cell. Traditionally content is hosted beyond the core where it acts as an anchor point during handover but at the access edge this is not easily achieved. The concept of referencing or copying data back to a central point, gateway support function, or central cache where a flow can be re-anchored during mobility is the proposed solution. 
         [0205]    TCP congestion control, where TCP slow start is one algorithm, attempts to avoid congestion collapse and to achieve high performance. Low latency or throughput is a side-effect of congestion and in particular during mobility events, connectivity can suffer from a gap or pause which can mimic congestion. If handover pauses are long periods of time due to signalling delays or connectivity issues or if there are frequent handover events, quite common in cellular networks, then this can have a detrimental impact on the connection speed or end user experience. 
         [0206]    Using a packet buffer with synchronised flows after a mobility event can improve and optimise end user experience through faster and more reliable connection speeds. 
         [0207]    The solution of the embodiment also solves LI and Charging issues for content served at the edge. By allowing a synchronised flow which can re-anchor, all packets received by the subscriber are transparently referenced and or sent through the P-GW or S-GW and dropped. This allows LI and Charging systems to operate without change on P-GW or S-GW. 
         [0208]    The solution of the embodiment supports mobility from 3G or LTE to multiple access technologies (2G, 3G, LTE and wifi). It can also support mobility during roaming use cases. 
         [0209]    The solution of the embodiment also allows the downlink backhaul transport to be more efficient. Through the serving of content from the access edge, no packets are sent to the eNode-B, freeing up the last mile transport link. Efficiencies in the last mile transport, when congested or heavily loaded, can improve the end user available bandwidth and therefore data speed and experience. 
         [0210]    In a “reference ID” arrangement, the copy of the content is not obtained making by a copy of the content of the local source. Rather, the copy is obtained from another source, but is generally identical to the content of the local source—i.e. it is a copy or duplicate of the content of the local source (even though it is obtained independently from the local source). 
         [0211]    The copy of the content may be obtained from a primary content source such as the Internet. The copy of the content may be obtained from a primary content source such as a central (Gi) cache. 
         [0212]    The core network may be operable to discard the copy of the content after provision of the content processing means core network service thereon. The copy of the content does not need to be delivered to the terminal as the content from the local source (e.g. cache, CDN) has been delivered to the terminal from the local source of content. 
         [0213]    The telecommunications network may be operable to provide content from the local source of content to the mobile terminal immediately (after verification or by method of implication that the cached content on SAVi NodeB is the same as the one in the Gi Cache or the Internet), in response to a request for that content. In the embodiment, the telecommunications network is operable to send the content from the local source of content to the terminal before the content processing means provides the core network service relating to the content. This is to be contrasted with an arrangement where it is required that core network services must be applied to the content (or a copy thereof) before the content can be delivered to the terminal. The user experience is therefore improved by the embodiment. 
         [0214]    The telecommunications network may be operable to determine whether the user of the terminal requires content filtering. Information of whether content filtering is required for the user will be send to the SAVi Platform during the registration process. If no content filtering is required this makes the embodiment particularly suitable for use. If content filtering is required, an alternative content delivery scheme may be used. If content filtering is required, this may be performed in the radio access network. If content filtering is required, prohibited content may be flagged so that this is not delivered by the radio access network. 
         [0215]    The telecommunications network may be arranged to deliver the content from the local source of content to the terminal as a content item comprising a plurality of packets, and to send to the core network the indication of the content item delivered from the local source of content to the terminal. For example the content item might comprise a move clip or a music track. This should be contrasted with arrangements where each packet of content data is identified to the core network separately. 
         [0216]    The indication may enable the content item to be identified and retrieved from the primary content source. 
         [0217]    The telecommunications network services may include, for example, Lawful Interception (LI) and/or charging. Other network services are also contemplated, as discussed in the detailed embodiments. 
         [0218]    The telecommunications network may be a cellular network, such as a 2G, 3G or 4G network. 
         [0219]    The present invention also relates to a corresponding method. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0220]    Embodiments of the present invention will now be described in more detail with reference to the accompanying Figures in which: 
           [0221]      FIG. 1  illustrates known a high level packet data network architecture, useful for explaining the prior art and embodiments of the present invention; 
           [0222]      FIG. 2  illustrates the introduction of a functional “platform” in a 3G network; 
           [0223]      FIG. 3  illustrates a flow chart of an example offload decision process as implemented in the 3G network of  FIG. 2   
           [0224]      FIG. 4  illustrates a flow chart of an example offload decision making process that may be implemented by a redirection module 
           [0225]      FIG. 5  shows the novel “platform” in more detail provided in the Radio Access Network in accordance with an embodiment of the invention; 
           [0226]      FIG. 6  shows possible locations of the platform within a mobile telecommunications network; 
           [0227]      FIG. 7  is a flow chart showing the steps performed when a mobile terminal is activated; 
           [0228]      FIG. 8  shows the optimisation of content delivery to a mobile terminal; 
           [0229]      FIG. 9  shows a further optimisation of content delivery to a mobile terminal; 
           [0230]      FIG. 10  is a flow chart showing the procedures performed when a mobile terminal moves within the network; 
           [0231]      FIG. 11  shows the transfer of information between platforms; 
           [0232]      FIG. 12  shows a modified version of the “platform”; 
           [0233]      FIG. 13  shows a system architecture for illustrating the general operation 
           [0234]      FIG. 14  shows the steps performed and the signal flows in accordance with the general operation; 
           [0235]      FIG. 15  shows a reference pointer in accordance with the first embodiment of the invention; 
           [0236]      FIG. 16  shows integrated system architecture for illustrating the operation of an embodiment of the invention; 
           [0237]      FIG. 17  shows the steps performed and the signal flows in accordance with a first embodiment of the invention; 
           [0238]      FIG. 18  illustrates the fast caching mechanism with SAVi Packet Buffer proxy synchronisation architecture; 
           [0239]      FIG. 19  is a basic mechanism flow diagram, showing Flag and Sync of fast caching packets; 
           [0240]      FIG. 20  illustrates the use case for mobility re-anchor from edge to primary content source during mobility; 
           [0241]      FIG. 21  illustrates the use case for mobility to non-SAVi eNB via re-anchoring for UL ACK sent to new Target eNB; 
           [0242]      FIG. 22  illustrates the use case for S1 mobility to non-SAVi eNB via MME re-anchoring for UL ACK sent to new Target eNB; 
           [0243]      FIG. 23  illustrates the use case for X2 mobility to SAVi eNB via source eNB triggered re-anchoring for the case UL ACK sent to original source eNB; 
           [0244]      FIG. 24  illustrates the use case for S1 mobility to SAVi eNB via MME re-anchoring for the case UL ACK sent to original source eNB; and 
           [0245]      FIG. 25  illustrates the use case for mobility to non-SAVi eNB via re-anchoring for the case UL ACK sent to original source eNB. 
       
    
    
       [0246]    In the figures, like elements are generally designated with reference numbers. 
       DETAILED DESCRIPTION 
       [0247]    An improved arrangement for providing core network services such as LI will now be described. This arrangement uses many of the principles described in relation to  FIGS. 1 to 12  above, and these form part of the embodiments to be described. 
         [0248]      FIG. 13  shows the system architecture of certain elements of the network. The platform  700  is provided at the network edge and provides (e)NodeB functions to the mobile terminal (user entity, UE)  10  by wireless communication. The platform  700  includes a cache  1100 . The cache  1100  stores content for delivery of this content to the UE  10  when required. The content may be delivered to the cache  1100  by any suitable mechanism, such as those described above. For example, the content may be delivered via the core network or may be delivered via a direct connection  2005  to the internet, which bypasses the core network. The cache  1100  may correspond to the cache  728  of  FIG. 5 . 
         [0249]    The platform  700  further includes an application  741  which may generate content for supply to the UE  10 . In practice, a plurality of applications are likely to be hosted on the platform  700 . 
         [0250]    It should be understood that, even when content is available at the network edge, a significant amount of content that the UE  10  wishes to consume is likely to be located elsewhere, and this content will be obtained in the conventional manner via the core network. 
         [0251]    As discussed above, when content is provided to a UE  10  from the network edge, core network services will be bypassed. This is often unsatisfactory as some core network services, such as content filtering and LI, are mandatory in some jurisdictions. The below arrangement provides a solution to this problem. 
         [0252]    The platform  700  is connected via an S1 interface to the core network, which comprises a gateway  2020  (e.g. enhanced GGSN/P-GW/SAE-GW) and a packet buffer/function  2040 . The gateway  2020  facilitates the provision of core network functions  2055 , such as content filtering and LI, by LI function  2060 , content filtering by content filtering function  2065 , and charging, by charging function  2070 . 
         [0253]    The gateway  2020  receives content from a primary content source  2030 , typically via the Internet. The primary content is delivered from the primary content source  2030  via Gi LAN  2050 . This content may be received by the packet buffer/function  2040  before delivery to the gateway  2020 . 
         [0254]    Due to mandatory functions which are only located in the core like Lawful interception, Charging, Policy control, etc. it is required that all the content delivered to a user needs to pass the core network first In this case the content will be requested from the primary content source (internet or from the central Gi Cache or CDN)  2030  and routed via the gateway (e.g. GGSN, SAE-GW)  2020  to the mobile device  10 . 
         [0255]    This method uses the standard data flows and will be no improvement in the delivery rate of content located in the RAN (at the cache  1100 ) to the user because the content cannot be delivered until the content has been obtained and processed by the core network. 
         [0256]    Therefore time to deliver content to a user still depends on the time the content passes the different network nodes. Before the content could be delivered it is needed to fulfil mandatory functions in the core network like e.g. LI. The effective time to deliver the content cached at the SAVi (e)NodeB will be faster when cached also in the Gi but the flows will still be the same. 
         [0257]    The embodiment now to be described seeks to provide faster delivery of locally cached content to a user. 
         [0258]    An example of the signalling between network elements will now be described with reference to  FIG. 14 . The mechanism allows core network services such as LI and charging to be performed for local served content in the cache  1100  at the SAVi access network edge. UE  10  Uplink data requests are handled by the Cache  1100  towards the Core, where the cached data flow is adopted from/emulated by the Internet/SAVi primary content source  2030  towards the gateway (e.g. SAE Gateway)  2020 . 
         [0259]    The following steps shown in  FIG. 14  outline the signal flow:
       1. User  10  requests content located in the Internet or cached in the Gi (e.g. from Primary Content source (e.g. Web Server)  2030 ). In this case it is assumed that the content is also locally cached at SAVi Platform  700  cache  1100 . In case of sending the request directly to the gateway (e.g. SAE-GW, GGSN)  2020  the request will be sent first to the Cache  1100 . In more detail, the UE  10  requests content by issuing an uplink packet content request message, which is transmitted to the eNodeB  2003  at the platform  700  with which the UE  10  is currently registered and in connected mode. The eNodeB  2003  then forwards the content request in a GPRS Tunnelling Protocol (GTP-U) message to the cache  1100 .   2. The Cache  1100  sees (as user traffic has to pass SAVi Platform  700 ) that this is a HTTP content request. By communication with the SAVi Platform  700 , the cache  1100  is made aware that the user has an “adult” subscription and therefore does not require adult content filtering. Therefore the request to the Cache application  1100  located on the SAVi Platform  700  could be executed.   3. As the content is already stored on the Caching application  1100  the application  1100  delivers the content in a downlink (DL) packet GTP-U message to the eNB  2003 .   4. The GTP-U DL packet gets sent via the eNodeB  2003 , from where the content is delivered to the UE  10 . The content is delivered immediately to the UE  10  from the local cache  1100  without delay (without waiting for any relevant core network functions to be completed). This improves the user experience (and is referred to herein as “fast caching”). The Caching application  1100  creates a reference pointer and sends this via the gateway (e.g. SAE-GW  2020 ) to the SAVi Packet Buffer Proxy  2040 . Details of the reference pointer are shown in  FIG. 15 . In parallel the request will be sent to the primary content source (e.g. internet or the central caching application or Web Server)  2030 . Therefore also the uplink content could be served by the gateway  2020  (e.g. SAE-GW) e.g. for LI, or charging. The content is requested from the primary content source (e.g. Internet or Cache at Gi/Primary Content Web Server)  2030 .   5. The content will be sent by the primary content source (e.g. central cache or Primary Content Web Server)  2030  back to the SAVi Packet Buffer Proxy  2040 . As the SAVi Packet Buffer Proxy  2040  has buffered the request it marks the response and sends it to the gateway (e.g. SAE-GW, GGSN)  2020 . Therefore the SAVi Packet Buffer Proxy  2040  has also the capability to verify with the reference pointer and the content if the content has already been delivered to the UE  10 .   6. The gateway (e.g. SAE-GW, GGSN)  2020  receives the content and handles in the defined way to manage LI, charging, policy management etc. As the content is marked the gateway (e.g. SAE-GW)  2020  will pass the content to the SAVi Packet Buffer Proxy  2040 . As the SAVi Packet Buffer Proxy  2040  exactly knows which content has been transmitted to the UE using information from the received reference pointer it will delete all the content that was already transmitted to the user from the cache  1100 . To do this in a way that it is acceptable for the LI authorities the reference pointer is important as is discussed in the following.       
 
         [0266]    Within this scenario an additional node the SAVi Packet Buffer Proxy  2040  is required to manage the required functions and to handle the traffic served from the access edge. Further a new function in the Gateway  2020  is required to route the traffic to the SAVi Packet Buffer Proxy  2040 . Further it is required that the SAVi Cache  1100  and the SAVi Packet Buffer Proxy need to terminate the GTP-U traffic directly. This has implication on other service e.g. in case of service chaining (such as processing of data by multiple applications) and in the area of security. Applications on the SAVi Platform may be developed by third party vendors and they might not have enough knowledge how to handle GTP-U traffic. In case of a failure of the GTP-U handling the network could be affected. Therefore it is recommended to terminate the GTP-U in a special function in the SAVi Platform and in Gateway. 
         [0267]    To address this difficulty, embodiments use a Client and Director Model and the possibility to use the inband signalling (see for example U.S. application Ser. Nos. 14/086,781, 14/137,249, 14/137,221 and 14/137,210 each of which are incorporated by reference). 
         [0268]    As shown in  FIG. 16 , the arrangement and the embodiment to be described use two special functions where one function is located in the SAVi platform  700  (here the (e)NodeB  2003 )—the so-called SAVi CN Client (SCNC)  2000 —and the second function—the SAVi CN Director (SCND)  2010 —is part of the GGSN/P-GW/SAE-GW  2020  or close by the GGSN/P-GW/SAE-GW  2020 . 
         [0269]    The SAVi director  2010  communicates with SAVi CN Client  2000  (located on the SAVi platform  700 ) via a communication API to, e.g., send polices or collect data. 
         [0270]    The SAVi Director  2010  is located on the GGSN/PGW/SAE-GW  2020  to get user information/triggers in real time. 
         [0271]    To support a secure and trusted communication between the SAVi CN Client  2000  and the SAVi Director  2010  the following functions are preferably supported by the SAVi Director  2010 :
       Securely authenticate with SAVi CN Client  2000 .   Establishment of a secure communication between SAVi CN Client  2000  and SAVi Director  2010 .   SAVi Director  2010  also is able to exchanges information with the SAVi CN Client  2000  to support a seamless user experience to the customer.       
 
         [0275]    The SAVi CN Client  2000  is located on the SAVi platform (e)NodeB or RNC and may support the following functions:
       Authenticate with the SAVi Director  2010 .   Inform the SAVi Director  2010  about new user sessions.   Informs the SAVi Director  2010  about content and application used by a specific user.   Steers the content flow based on the SAVi Director  2010  settings pushed to the SAVi CN client  2000  per user and per application.       
 
         [0280]    The gateway  2020  further includes a SAVi core network supporting function (SCNSF)  2015 . The SCNSF  2015  is a function located in the mobile packet core (CN) providing additional support to operate SAVi. For example, when content is modified by the SCNC  2000 , the SCNSF  2015  function may provide supporting functionality for charging, lawful intercept and other mandatory core functions, and/or SCNSF  2015  may support functionality to aid in mobility management. 
         [0281]    These lists are non-exhaustive. 
         [0282]    The “client”  2000  in the SAVi Platform  700  at RAN side (here (e)NodeB but it is not limited thereto) communicates with a core network Director  2010  which shares e.g. subscriber identities, policies and service access information with the Client  2000 . 
         [0283]    The director module  2000  hosted in the mobile packet core retrieves user identities, policies, etc. and communicates these to the aforementioned client  2000 . The director  2010  is also responsible to manage functions and services in the core. 
         [0284]    Signalling between the Client  2000  and Director  2010  may be inband signalling. 
         [0285]    To reduce the complexity of Fast Caching and to avoid the introduction of a new Packet Buffer node ( 2040 ) the needed functions may advantageously be introduced into the SAVi Platform  700  and the GGSN/PGW  2020 . Of course it is possible to realise the SAVi Packet Buffer  2040  and or Cache List functions outside the gateway  2020  on a support function (G), director ( 2010 ) or within the Gi LAN ( 2050 ). These of course requires modifications within the existing flows and allows with some additional messages (e.g. acknowledge message) to support more features for e.g. LI and Mobility. 
         [0286]    Further the use of the user plane for signalling reasons (see for example U.S. application Ser. Nos. 14/086,781, 14/137,249, 14/137,221 and 14/137,210 each of which are incorporated by reference) may be used to add further simplifications while improving the user experience. 
         [0287]    The use of client, director and the inband signalling will allow a more efficient way to deal with this scenario as the client will be the endpoint of the GTP-U. 
         [0288]    A direct connection like  2005  in  FIG. 13  may be provided. 
         [0289]    An example of the signalling between network elements of  FIG. 16  will now be described with reference to  FIG. 17 . The mechanism allows core network services such as LI and charging to be performed for local served content in the cache  1100  at the SAVi access network edge. UE  10  Uplink data requests are handled by the Cache  1100  towards the Core (CN), where the cached data flow is adopted from/emulated by the Internet/SAVi primary content source  2030  towards the gateway (e.g. SAE Gateway)  2020 . 
         [0290]    The following steps shown in  FIG. 17  outline the signal flow:
       1. User  10  requests content located in the Internet or cached in the Gi (e.g. from Primary Content source (e.g. Web Server)  2030 ). In this case it is assumed that the content is also locally cached at SAVi Platform  700  cache  1100 . In case of sending the request directly to the gateway (e.g. SAE-GW, GGSN)  2020  the GTP-U request will be sent first to the SAVi Core Network Client  2000  and the IP UL request will be send to the Cache  1100 . In more detail, the UE  10  requests content by issuing an uplink packet content request message, which is transmitted to the eNodeB  2003  at the platform  700  with which the UE  10  is currently registered and in connected mode. The eNodeB  2003  then forwards the content request in a GPRS Tunnelling Protocol (GTP-U) message to the SCNC  2000  and after this the IP based request (e.g. HTTP Get) to the SAVi Cache  1100 .   2. The Cache  1100  sees (as user traffic has to pass the SCNC  2000 ) that this is a HTTP content request. As the SCNC  2000  is aware that the user has an “adult” subscription and therefore does not require adult content filtering. Therefore the SCNC  2000  forwards the request to the Cache application  1100  located on the SAVi Platform  700 .   3. As the content is already stored on the Caching application  1100  the application  1100  delivers the content in a downlink (DL) packet to the SCNC  2000 . The SCNC  2000  sends it via a GTP-U message to the eNB  2003 .   4. The GTP-U DL packet gets sent via the eNodeB  2003 , from where the content is delivered to the UE  10 . The content is delivered immediately to the UE  10  from the local cache  1100  with minimum delay (without waiting for any relevant core network functions to be completed). This improves the user experience. The Caching application  1100  or the SCNC  2000  creates a reference pointer and sends this via SCNC  2000  (inband signalling or via standard GTP-U messages to keep the PDP content) and via the gateway (e.g. SAE-GW  2020 ) to the SCND  2010 /SCNSF  2015  (SAVi Core Network Director and SAVi Core Network Supporting Function). Details of the reference pointer are shown in  FIG. 15 . In parallel the content request will be sent via the Gateway functions to the primary content source (e.g. internet or the central caching application or Web Server)  2030 . Therefore also the uplink content could be served by the gateway  2020  (e.g. SAE-GW) e.g. for LI, or charging. The content is requested from the primary content source (e.g. Internet or Cache at Gi/Primary Content Web Server)  2030 .   5. The content will be sent by the primary content source (e.g. central cache or Primary Content Web Server)  2030  back to the SCND  2010 /SCNSF  2015 . The SCND  2010 /SCNSF  2015  have buffered the request and the Reference Pointer. As the content has been identified as delivered from the SAVi Platform directly the SCND  2010 /SCNSF  2015  marks the response and sends it to the gateway (e.g. SAE-GW, GGSN)  2020 . Therefore SCND  2010 /SCNSF  2015  have also the capability to verify based on the the reference pointer if the content has already been delivered to the UE  10 .   6. The gateway (e.g. SAE-GW, GGSN)  2020  receives the content and handles in the defined way to manage LI, charging, policy management etc. As the content is marked, the gateway (e.g. SAE-GW)  2020  will pass the content to the SCND  2010 /SCNSF  2015 . As the SCND  2010 /SCNSF  2015  exactly knows which content has been transmitted to the UE  10  using information from the received reference pointer it will delete all the content that was already transmitted to the user via the SCNC  2000  from the cache  1100 . To do this in a way that it is acceptable for the LI authorities the reference pointer is important as is discussed in the following.       
 
         [0297]    This action reduces use of last mile transport link capacity. In this way, a copy of each of the downlink packets provided to the UE  10  is made available at the gateway (e.g. SAE gateway)  2020  so that core network functions can be applied to the data packet. As indicated, such core network functions  2055  may be LI functions, performed by an LI module and/or charging functions performed by a charging module. Thus, the core network functions are performed on downlink data that is a copy of the downlink data provided to the UE  10  from the cache  1100 . After the core network functions have been applied to the copy downlink data, the downlink data is no longer required (as it has already been provided to the UE  10  directly from the cache  1100 ), and the downlink data can then be discarded by the SCND  2010 /SCNSF  2015 —there is no requirement for it to be forwarded through the network to the mobile terminal  10  as this downlink data has already been provided to the UE  10  directly from the cache  1100 . 
       Reference Pointer 
       [0298]    As mentioned above the reference pointer, created by the cache  1100  application, will be delivered between cache  1100  application and SCND  2010 /SCNSF  2015 . The reference pointer will be responsible to indicate the exact content delivered to the user. 
         [0299]    As shown in  FIG. 15  there is the need that the Reference Pointer reports the exact amount of content delivered to the end user and the nature/identity of the content including all needed Meta data. The reference pointer is important for LI to make sure that the content delivered to the user  10  could be handled in the most efficient way. Therefore additional information should be added like e.g. APN, IP addresses, bearer, etc. A final list of information part of the Reference Pointer may be agreed with the legal authorities. The reference pointer enables the delivery of the local content directly to the UE  10  from the cache  1100  application. Further, the Reference Pointer could be used in case of mobility together with the Proxy Buffer (e.g. now a logical function of the SCNSF  2015 ) so it knows exactly the content delivered to the user and in case of mobility the new content will not be deleted anymore. It will be send to the new (e)NodeB which does not need to be SAVi compliant. 
         [0300]    The exchange of the Reference Pointer could be done e.g. per packet or only when the user or the system stops the transmission based on legal requirements (e.g. so that the start end of the content are identified). 
         [0301]    However, the final implementation of the reference pointer also depends on the content or the requirements of the MNO (Mobile Network Operator) or LEA (Law Enforcement Agency). As mentioned above the e.g. full content of a movie or software update of an operating system located at the cache  1100  application could be sliced in different containers (C1, C2, C3, . . . ). In this case the container size could differ from e.g. one TCP packet, the amount of packets of a TCP acknowledge window, or any acceptable size to the MNO or LEA. See  FIG. 15 . 
         [0302]    This can ensure that generally only the content of a container will be delivered to the LEA or charging system which has been sent to the customer. E.g. if a C1 is successfully delivered the reference pointer will be sent to SCND  2010 /SCNSF  2015 . If C2 fails (is not successfully delivered) then the reference pointer of that container will be sent out but C3 will not be sent to SCND  2010 /SCNSF  2015  before C2 has been successfully delivered as C3 has to wait for C2 to be successfully delivered. Therefore the SCND  2010 /SCNSF  2015  could temporarily store the content from the primary content source (e.g. Internet or the Gi Cache)  2030  when not delivered already to the UE  10 . 
         [0303]    The size of the cached content on the SAVi NodeB  2003  and the content in the Internet or in the primary content source (e.g. Gi cache)  2030  are the same. Further the container size must also be the same. 
         [0304]    Therefore the maximum size of one container could be delivered to the gateway (e.g. SAE-GW)  2020  in case of a failure of the connection between the UE and the eNodeB  2003 . 
         [0305]    Other use cases not shown in the flow of  FIG. 17   
         [0000]    Some exceptions are discussed in the following.
 
General flow
       1. User  10  requests content which is also stored at the SAVi cache  1100     2. The Time to Live from the content is valid (Cached content has an indication how long it could be cached and when the cached content is too old its “Time to Live” becomes invalid).
           a. The transparent cache application  1100  starts to deliver the content to the user  10 .   b. In parallel the cache  1100  sends a reference pointer via the SCNC  2000  to the SCND  2010 /SCNSF  2015  and at the same time the SCNC  2000  sends the content request to the primary content source (e.g. Primary Content Web Server or internet location)  2030  of that content.   c. The content owner platform (or the central Gi cache) starts sending back the content.   d. The gateway (e.g. SAE-GW, GGSN)  2020  receives the content and sends it to the SCND  2010 /SCNSF  2015  after all mandatory functions and services have seen the content.   e. After this the content will be routed to the SCND/SCNSF which deletes the content based on the reference pointer it got from Cache  1100 .   
               
 
         [0313]    User stops the request or in case of mobility
       3. User  10  stops the request (or moves to a different eNode B). This will be signalled via the SCNC  2000  to the caching application  1100 . The caching application  1100  (or the SCNC  2000 ) will stop sending and creates a final Reference pointer.   4. Cache  1100  sends via SCNC  2000  the cancel request and the Reference pointer to the SCND  2010 /SCNSF  2015  (Note: In case the mobile  10  will be no longer available on that SAVi Platform  700  (e.g. mobility) the final Reference Pointer will be sent via inband signalling of another active session.)
           a. SCND  2010 /SCNSF  2015  will send the cancel request based on the Reference pointer information available to make sure that content owner&#39;s platform or Gi cache  2030  stops sending at the same time the caching application  1100  stopped sending. Further it does not deliver any further content to the gateway (e.g. SAE-GW)  2020 .   b. Therefore the same content reaches the gateway (e.g. SAE-GW, GGSN)  2020  to fulfil functions like e.g. LI, Policy or ACF and SCND  2010 /SCNSF  2015  will delete the content.   
               
 
         [0318]    Content is not available anymore on the Gi Cache or in the primary content source (e.g. Primary Content Web Server or Internet)  2030 
       5. As the cache  1100  at the SAVi Node  700  sends via the SCNC  2000  the content to the user  10  without delay it has to be considered that the content is not available anymore from the primary content source (e.g. Gi cache Internet)  2030 . However, as the Time to Live from the content was still valid it is expected that this is sufficient for the LI and the content could be delivered to the end user
           a. If an error message from the content owner comes back that the content is not available any more, the SCND  2010 /SCNSF  2015  sends immediate a message via the SCNC to the Cache  1100  to stop sending the content.   b. Cache  1100  stops sending to the user  10  and will not allow that anyone else could receive the content
               i. In case needed the Cache  1100  could send via SCNC  2000  the Reference pointer and the content back to the SAE-GW. With proposal also mandatory legal functions like e.g. LI could be managed   
               c. This should be an exception as the Time to Live was still valid   
               
 
       Summary of FIG.  17  Embodiment 
       [0324]    The proposed solution/architecture shows that the SCND  2010 /SCNSF  2015  located as software on the gateway (e.g. SAE-GW, GGSN)  2020  and the corresponding functions SCNC  2000  and Cache  1100  on the SAVi Platform  700  (RAN) allows improving the quality of experience regarding caching. 
         [0325]    With this scenario it is possible to deliver the content immediately from the RAN cache  1100  to the customer UE  10  while knowing exactly the amount of content sent to the customer. 
         [0326]    This arrangement may have the following advantages:
       Low latency for edge content delivery.   Low system impact, with the re-use of existing LI systems.   Fulfils LI detection mitigation requirements.   Reduces last mile transport capacity in the downlink transmission.       
 
       General GGSN/PGW Functions 
       [0331]    The gateway (e.g. SAE-GW GGSN)  2020  needs to have SCND  2010 /SCNSF  2015  functions to handle UL and DL content. All functions listed below may be supported as these functions will not be affected.
       GTP/PDP handling in case of PDP context inactivity       
 
         [0333]    Other functions may work without any limitation, such as:
       IP Address registration from GGSN/P-GW pool (NAT44, Firewalls, . . . )   Core pooling   Evolution story towards LTE   Different APN handling:   Registration e.g. on HLR/HSS per service (how to make sure that a customer does not get access to services booked.   HTTP header enrichment &amp; encryption       
 
       Content Filtering or Adult Content Filter 
       [0340]    As the flow is passing the gateway (e.g. GGSN)  2020  all the content will touch all the Gi LAN  2050  and gateway (e.g. GGSN)  2020  functions and therefore also all core network filter functions may be supported without any change. However, the Cache  1100  needs to know that a specific content can be delivered to the UE  10 . Therefore the content under Adult Filter should be marked, and should not send to the user  10 . 
       Charging 
       [0341]    As all content which is cached or stored in a primary content source (e.g. Cache)  2030  will pass all Gi LAN  2050  and GGSN  2020  functions, the charging for this content can be performed in the conventional manner using core network functions. 
         [0342]    Further it is needed if a user only downloads part of the cached content  1100  and not all of it to get an indication about the amount of data transmitted to UE  10 . Here the SAVi Platform  700  obtains delivery time and amount of data delivered as a minimum. Further information which may be obtained might include, e.g., if a download of content is free of charge for the customer, such as free Facebook access.
       Online Charging   Offline Charging   Service based Charging (packet inspection)       
 
         [0346]    If a customer has exceeded his monthly amount of data and further data transmission needs to be throttled it is recommended that the customer will only be served from the Core Network (i.e. content will not be provided by the cache  1100 ). Reason would be the limited capacity on the SAVi platform  700  regarding processing power and memory. Due to this also an indicator is provided when someone should not be served by the SAVi platform  700  at all.
       Fair usage policy       
 
       PCC (Policy and Charging Control) 
       [0348]    The listed requirements below should be supported in the Core Network currently due to the limited capabilities on the SAVi platform  700 . Therefore the SAVi Platform  700  advantageously obtains the information about such customer classifications and reacts.
       Policy enforcement (policing, shaping, DSCP marking, Customer classes Gold/Silver/Bronze etc.)   Heuristic classification (VoIP—P2P etc.)   Traffic steering—redirection       
 
       Mobility, Seamless Service Mobility 
       [0352]    In case of UE  10  mobility the gateway (e.g. GGSN/PGW)  2020  receives information that a user is requesting content from a different (e)NodeB (with or without SAVi). Further the SAVi Packet Buffer Proxy  2040  knows the content downloaded from the cache at a SAVi NodeB  700 . The source eNB controls handover, and SAE GW oversees the path switch. This may be performed in the following scenarios:
       SAVi node to SAVi node or SAVi node to non SAVi node   Content stored in SAVi node and content not stored on SAVi node.   Handover to and from different radio technologies (3G/4G/WLAN)   Subscriber mobility state or other attributes known by the access or core network       
 
         [0357]    Detailed mobility scenarios are described later in the fast caching mechanism with SAVi packet buffer synchronisation description. 
       Optimisation and Other Gi LAN Relevant Functions 
       [0358]    It is expected that all optimisations are handled in the core and therefore no impact is expected. This is also likely as the LI must generally be fulfilled on the content shared with customer. LI is done in the Core and therefore optimisation needs to be there for the time being. 
         [0359]    Content optimisation may relate to Video or Web content. 
         [0360]    The solution/architecture of this embodiment shows that the Packet Buffer located in the gateway  2020  (as a logical function of the SNCSF  2015 ), and placing a Caching  1100  on the SAVi platform  700  fulfils provides many advantages. The solution therefore gives an operator the capability to fulfil the legal requirements and also various Core Network and Gi LAN related functions. 
         [0000]    Fast Caching Mechanism with SAVi Packet Buffer Synchronisation
 
Detailed Solution Descriptions of SAVi Packet Buffer synchronisation
 
         [0361]    The following section provides a detailed description of the (1.0) basic mechanism (2.0) how it can be extended to support mobility with alternative solutions (2.1, 2.2 and 2.3). 
         [0000]    1.0 Fast Caching Mechanism with SAVi Packet Buffer Synchronisation 
         [0362]    The fast caching mechanism enables the performance of LI and Charging for locally served content and applications at the SAVi access network edge. UE Uplink data requests are repeated by the Client  2000  towards the Core, where the data flow delivered at the access network edge is emulated by a matched content source towards the SAE Gateway (called “SAVi primary content source  2030 ” in the figures described below). 
         [0363]    For the copied uplink data flows from the SAVi client  2000 , the Support Function  2015  initiates interception of TCP and UDP Uplink and Downlink flows to ensure UL packet acknowledgements are synchronised and sequenced to co-ordinate and match downlink packets to avoid packet disorder and support re-anchoring to a higher layer cache or application source. This mechanism is implemented through the Client  2000 , Director  2010  and SAVi Packet Buffer Functions. 
         [0364]    This mechanism avoids complex synchronising with content on the Target-eNB, where out-of band signalling will be required to forward information related to the TCP state of the Source-eNB at handover. For example, source &amp; destination IP address and port addressing as well as other TCP parameters, would be required to synchronise. 
         [0365]      FIG. 18  shows an example architecture for a fast caching mechanism with SAVi Packet Buffer proxy synchronisation. 
         [0366]      FIG. 19  shows a basic mechanism flow diagram, with Flag and Sync of fast caching packets. 
         [0367]    The following steps outline the signal flow of the SAVi Packet Buffer proxy synchronisation mechanism of  FIG. 19 :
       1. User  10  requests content that is in the cache or application  1100  at the access network edge, that is also available in the primary content source located in the SAVi Primary Content  2030  based on pre-configured IP address range which is both routable on the SAVi Platform  700  and on the Gi-LAN. In this case it is assumed the content is also synchronised with the cache or application  1100  at SAVi Platform  700  beforehand via the Primary Content source. This request is routed to the SAVi Cache/application  1100  via the Client  2000  where content is delivered to the user  10 .   2. Then the Client  2000  generates a copy of the request for content and sends this to the SAE-Gateway which is routed to the primary content source via the Director  2010  and Support Packet Buffer Function  2040 .   3. The SAVi primary content  2030 , which is identical to content held in the SAVi Cache/application  1100 , responds with a downlink packet which are sent to the SAVi Packet Buffer function  2040  and waits for the next UL ACK from the Director  2010 .   4. Next the corresponding UL ACK from the user  10  from Step-1 is received by the Client  2000  and a copy of the UL ACK is generated by the Client  2000  and sent to the SAVi Packet Buffer function  2040 .   5. The SAVi Packet Buffer function  2040  uses the UL ACK as a successful receipt of the previous downlink packet. Next the SAVi Packet Buffer  2040  forwards the DL packet to the Director  2010  with the same source IP address as the SAVi Cache/application  1100 . The Director  2010  modifies this DL packet by inserting a configurable FLAG (optionally a TEID length number of TCP Headers to train the SAE Gateway  2020 ).   6. The SAE GW  2020  receives this DL packet and punctures the FLAG out of the TCP Headers or as configured and then processes these packets to support LI and Charging sub-functions. Finally the DL packet(s) are forwarded back to the Director  2010  to be dropped out of the system.       
 
         [0374]    Today content is hosted in the Gi LAN  2050  which does not allow content to be Served directly in the Access Network where the round trip time is longer due and can be subject to last mile transport congestion which impacts the served bandwidth. 
         [0375]    The passing of Reference pointer is one solution, but this relies on applications to potentially recover and subsequently trigger a TCP slow start during mobility events. 
         [0376]    TCP congestion control, where TCP slow start is one algorithm, attempts to avoid congestion collapse and to achieve high performance. Low latency or throughput is a side-effect of congestion and in particular during mobility events, connectivity can suffer from a gap or pause which can mimic congestion. If handover pauses are long periods of time due to signalling delays or connectivity issues or if there are frequent handover events, quite common in cellular networks, then this can have a detrimental impact on the connection speed or end user experience. 
         [0377]    Using a packet buffer with synchronised flows after a mobility event can improve and optimise end user experience through faster and more reliable connection speeds. 
         [0378]    This solution also solves LI and Charging issues for content served at the edge. By allowing a synchronised flow which can re-anchor, all packets received by the subscriber are transparently referenced and or sent through the P-GW or S-GW and dropped. This allows LI and Charging systems to operate without change on P-GW or S-GW. 
         [0379]    This solution supports mobility from 3G or LTE to multiple access technologies (2G, 3G, LTE and wifi). It can also support mobility during roaming use cases. 
         [0380]    This solution also allows the downlink backhaul transport to be more efficient. Through the serving of content from the access edge, no packets are sent to the eNode-B, freeing up the last mile transport link. Efficiencies in the last mile transport, when congested or heavily loaded, can improve the end user available bandwidth and therefore data speed and experience. 
         [0000]    2.0 Support of Mobility with the SAVi Packet Buffer Function
       In this section two mobility use cases are examined for intra-LTE cases where SAVi Client are present on both source and target eNode-B. In particular the signalling procedures that occur before and after mobility handover supervised by the SAE-Gateway. In these cases it is assumed that a handover requires that a user will need to access content from the central primary content source via the target eNodeB.       
 
         [0382]    A mobility arrangement for supporting of lossless handover and mobility with the SAVi Packet Buffer Function  2030  will now be described.  FIG. 20  shows an arrangement for performing mobility re-anchor from edge to primary content source during mobility. 
         [0383]    During handover from source eNB  2003 A to target eNB  2003 B, source client  2000 A signals to director  2010  to re-anchor content by forwarding (1) UL Packet ACK (2) UL Packet GET under the conditions:
       a. eNB performs a successful handover procedure   b. Selective ACK is not accepted   c. Edge content is not available at target eNB   d. Subscriber is fast moving based on API information from the target or source eNB   e. Content delivery changes anchor from Client to Director.       
 
         [0389]    In the case of Director to Client re-anchor: SAVi Packet Buffer Proxy  2040  synchronises UL and DL sequence numbers and packets bytes between SAVi platform  700  and primary content source  2030 . 
         [0390]    For this mobility arrangement, Fast Caching Mobility with UL ACK sent to target eNB  2003 B will now be described.  FIG. 21  shows the signalling to provide mobility to (e.g. non-SAVi) eNB via re-anchoring for UL ACK sent to new Target eNB by the following stages: 
         [0000]    1). In this use case the DL packet and UL ACK is delivered to the source eNB  2003 A after the handover procedure. Next the Director  2010  and Client  2000 B are aware of the new handover with the change in TEID. The Client  2000 B sends this UL ACK packet to the SAVi Cache  1100 B as normal routing for this packet where a number of conditions are possible (a) it is unaware of this new flow and cannot synchronise without information with the source eNB cache  1100 A or (b) there is no content matching or finally (c) subscriber is identified as a fast mobile. Under these conditions the data flow is discontinued by the Client  2000 B. The Client  2000 B now assumes that no content (based on a timer, additional signalling or rely on subscriber UL ACK retransmission) is stored locally and all future data flows are re-routed, re-anchored, to the SAVi primary source  2030  via the SAE Gateway  2020  instead. Next the UL ACK is sent to the SAE Gateway where the Client  2000 B and Director  2010  determine the TEID and exchange the policy for this subscriber  10 .
 
2). The Director  2010  informs the SAVI Packet Buffer function  2040  of the change in TEID due to handover and enters a wait state. It then forwards the UL ACK packet to the SAVI Packet Buffer function  2040 . Next the Director forwards the UL ACK towards the SAVi Packet Buffer function  2040 .
 
3). The SAVi Packet Buffer function  2040 , now re-anchors the TCP flow and sends the DL packet to the Director  2010 . The Director  2010  routes this towards the SAE-Gateway  2020 , this time with no FLAG, where LI and Charging functions are handled as a normal flow. The gateway  2020  then forwards the DL packet to the target Enb  2003 B.
 
         [0391]      FIG. 22  shows the signalling if policy is provided via the MME—SI Mobility to non-SAVi eNB via MME re-anchoring for UL ACK sent to new target eNB. 
         [0000]    2.2 Fast Caching Mobility with UL ACK Sent to Source eNB 
         [0392]      FIG. 23  shows signalling for X2 Mobility to SAVi eNB via source eNB triggered re-anchoring for the case UL ACK sent to original source eNB 
         [0393]    In this use case it is assumed that S11 interface messages cannot be exposed to the P-GW, an alternative solution is based on exposing eNode-B X2 messages to indicated handover point. 
         [0394]    The following replaced steps are performed:
       1. Handover preparation procedure starts from Source eNB  2003 A to Target eNB  2003 B, packets are forwarded via X2. After Target eNB  2003 B sends a Path Switch Request message to the MME  2006  a Modify Bearer Request is sent to the S-GW  2020 A. In order to assist re-ordering of packets, S-GW  2020 A sends one or more GTP-U End Marker packet, with no data, to the Source eNB  2030 A. At this point packets are now path switched and sent to the Target eNB  2003 B.   2. The SAVi platform sees this GTP-U End Marker packet and forwards to the       
 
         [0397]    P-GW  2020 B to inform of a handover. It is assumed at this point that the Target eNB  2020 B has not sent to the Source eNB  2003 A the UE Context Release, which is after the Path Switch Request Acknowledge, which precipitates the release of resources.
       3. The P-GW  2020 B informs the SAVI Packet Buffer Function  2040  of this event and re-anchors the downlink flow.       
 
         [0399]    Note that procedure will also cover the handover use cases: source eNB with a SAVi platform to target eNB without a SAVi platform. 
         [0400]      FIG. 24  below describes the case if policy is provided via the MME—S1 Mobility to SAVi eNB via MME re-anchoring for the case UL ACK sent to original source eNB 
         [0000]    2.3 Alternative Fast Caching Mobility with UL ACK Sent to Source eNB 
         [0401]      FIG. 25  shows Mobility to non-SAVi eNB via re-anchoring for the case UL ACK sent to original source eNB. The following steps are performed:
       1. In this use case the DL packet and UL ACK is delivered to the source eNB  2000 A, and not the target eNB  2000 B, before the handover procedure completes. Since no policy exists at the target eNB  2000 B and there is no simple mechanism to determine if the content is available on the target eNB  2000 B SAVi cache  1100 B the system needs to re-anchor at a higher layer, the SAVi Packet Buffer function  2040 .   2. The SAE-Gateway  2020 A exposes GTP-Control information (Modify Bearer request response S-GW to MME or GTP-u End Marker at switch DL path) to inform the Director  2010  of the handover event with a corresponding change in TEID for the target eNB  2000 B. This involves (1) the Director  2010  to be aware of an on-going flow and to identify the associated Bearer (2) SAE GW  2020 A to trap and forward GTP-c messages from MME  2006  pertaining to this Bearer to the Director  2010 . (3) The Director  2010  to associate this event and bearer with the original source TEID and data flow.   3. Next the Director  2010  informs the SAVI Packet Buffer function  2040  of the change in bearer due to handover and at this point resumes sending DL packets. The SAVi Packet Buffer function  2040  now is in a wait state for the next UI ACK, re-anchors the TCP flow and sends the DL packet to the Director  2010  with no FLAG. The Director  2010  routes this packet towards the SAE-Gateway  2020 A where LI and Charging functions are handled as a normal flow. The gateway  2020 A then forwards the DL packet to the target eNB  2003 B.   4. UL ACK returns to the SAVi primary source  2030  as normal where the Client  2000 B pulls policy from the Director  2010  at the new target eNB  2003 B.       
 
         [0406]    The mobility arrangements described with reference to  FIGS. 19 to 25  provide:
   1) A simple and accurate method of synchronising IP flow within existing user plane interfaces during handover, or other event, by a method of re-anchoring to a higher layered cache source, the SAVI Packet Buffer  2040 , to support edge content and application hosting.   2) The elaborated method involves buffered UL ACK&#39;s and delaying, injecting, identifying and puncturing downlink packets back into the downlink chain in order to re-use LI and Charging functions defined in the SAE Gateway  2020  before being dropped.   3) A proposal to trap and expose GTP control events and information between the MME, SAE Gateway  2020 , Director  2010  &amp; SAVi Packet Buffer function  2040  in order to inform, associate, translate and forward downlink packets timely in order to (a) to synchronise TCP flows during mobility handover and (b) make re-anchoring decisions based on the type of services being used and the type of target cell, i.e. a high or low powered cells. Detailed solutions describe the use of the following network events: Modify Bearer request response S-GW to MME ( FIG. 22, 24, 25 ) or GTP-u End Marker at switch DL path ( FIG. 23 ) or change in TEID exposed by Director ( FIG. 21 ). Importantly the director exposing TEID can be applied in a roaming subscriber use case.   4) A proposal to ring fence and control content and applications that are delivered at the edge, rather than directly from the internet where synchronising content will not be reliable, by tightly integrating the MME, SAE Gateway  2020 , Director  2010 , Client  2000 , SAVi Cache  1100  and Support functions (SAVi Packet Buffer Function  2040  and importantly the SAVi primary content  2030  and hosted applications platform) together for the purpose of delivering higher customer experience, higher reliability of services, and re-using LI and charging functions. With this approach other LI and Charging solutions can operate in parallel from different content sources.   
 
         [0411]    The benefits of SAVi Packet Buffer Function include:
       1. Fast caching at the eNode-B with low latency and reduced last mile backhaul capacity.   2. Supports TCP based content and applications.   3. Supports mobility under different use cases compared to Reference ID.   4. Elaborate UL ACK mechanism is more accurate than Reference ID for charging and LI.   5. Higher reliability and less complex Support Function than Reference ID. No need to support out of band signalling.   6. Application support possible.   7. UDP based content support possible.       
 
       REFERENCES 
       [0419]    The content of the following documents is fully incorporated herein by reference:
   3GPP TS 33.106, 3G security; Lawful Interception requirements   3GPP TS 33.107, 3G security; Lawful interception architecture and functions   3GPP TS 33.108, 3G security; Handover interface for Lawful Interception (LI)   3GPP TS 36.423, E-UTRAN; X2 application protocol (X2AP)   3GPP TS 36.300, E-UTRAN; E-UTRA Overall description; Stage 2   RFC 1072   RFC2018