WO2013068415A1

WO2013068415A1 - Method and system for provisioning frequently requested content

Info

Publication number: WO2013068415A1
Application number: PCT/EP2012/072049
Authority: WO
Inventors: Tarik Taleb; Stefan Schmid
Original assignee: Nec Europe Ltd.
Priority date: 2011-11-07
Filing date: 2012-11-07
Publication date: 2013-05-16

Abstract

The present invention relates to a method for provisioning frequently requested content of user devices from one or more servers via a communication network, wherein the a) data of requested content is analysed, wherein b) based on a result of the analysed data common frequently requested content of user devices is identified, wherein c) based on the identified common frequently requested content a traffic reduction policy for the identified common frequently requested content is established, and wherein d) based on the traffic reduction policy, the identified common frequently requested content is provided to the user devices. The present invention relates also to a system for provisioning frequently requested content.

Description

METHOD AND SYSTEM FOR PROVISIONING

FREQUENTLY REQUESTED CONTENT

The invention relates to a method for provisioning frequently requested content of user devices from one or more servers via a communication network.

The present invention also relates to a system for provisioning frequently requested content of user devices from one or more servers via a communication network.

Although the present invention is applicable in general to any application running on user devices updating or requesting frequently content, the present invention will be described to applications with regard to social networks.

Many social network applications, for example relating to social network platforms like Twitter, Facebook, etc. or news tickers of broadcasting corporations or the like are based on a one-to-many communication paradigm: One entity posts a message/same content which is then received by many users that have "subscribed" to this message "feed". For example, popular social network applications, like Bijin-Tokei in Japan, enables users to receive a photo of girl holding a black-board that shows the current time. These photos are sent to all subscribers every one minute as photos need to be updated at the same frequency.

Further mobile web applications involving the delivery of the same content to multiple users are for example Foursquare, Facebook places, Gowalla, Brightkite, Yelp and Google Latitude. These mobile web applications allow a delivery of the same content to mobile users being in the same location providing location-based "check in" services, for example to check in at locations they visit as a way to find other friends, coordinate gatherings and exchange content of common interest among a "social network" of users. Other location based applications are for example instant messaging services such as Meeboo or mobile games, allowing users to play a game relevant to their current location and/or with other users in the same location, for example SCVNGR, Zynga or the like. Therefore content among a group of mobile users in the same neighborhood is frequently and dynamically exchanged. One of the drawbacks is, that every application of a user respectively user device establishes a point-to-point connection to the corresponding server to request the content. Content receiving only low attention, i.e. content in which only few users are interested, causes only low load in the communication network between the user devices and the server. However, for high-interest feeds, i.e. content comprising information that are "followed" by many users in real-time, duplicate load in the communication network between the applications running on the users devices and the corresponding server providing the content is induced.

Such a conventional situation is illustrated for a 3GPP evolved packet system in Fig. 1. A plurality of mobile user devices UD1 , UD2, ... are each connected via an evolved node B eNB, a serving gateway S-GW, a packet data network gateway P- GW, a corresponding packet data network PDN to a web server S providing content. The web server S provides same content being delivered to a large number of users respectively the user devices UD1 , UD2,... being in the same area/location. In Fig. 1 the "same area/location" corresponds to the coverage area of the same backhaul network or more precisely evolved node B eNB. This causes a high load in the backhaul network between the evolved node B eNB and the web server S. Each user device UD1 , UD2 with its own connection receives from the web server S a corresponding flow F1 , F2 destined to different user devices UD1 , UD2.

It is therefore an objective of the present invention to enable a reduction in usage of network resources for frequently updated content by a plurality of users. It is a further objective of the present invention to provide a method and a system which is easy to implement and cost-effective.

It is an even further objective of the present invention to alleviate congestion within the communication network between user devices and one or more servers. The present invention solves the aforementioned objectives by a method of claim 1 and a system of claim 18.

According to claim 1 the method is characterized in that

a) data of requested content is analysed, that

b) based on a result of the analysed data common frequently requested content of user devices is identified, that

c) based on the identified common frequently requested content a traffic reduction policy for the identified common frequently requested content is established, and that

d) based on the traffic reduction policy, the identified common frequently requested content is provided to the user devices. According to claim 18 the system is characterized in that a traffic detection entity is configured to analyse data of requested content and to identify based on a result of the analysed data common frequently requested content of user devices, and that a network entity is configured to establish based on the identified common frequently requested content a traffic reduction policy for the identified common frequently requested content and that to provide based on the traffic reduction policy the identified common frequently requested content to the user devices.

The term "frequently requested content" means preferably in the description, in particular in the claims a frequent and dynamic, in particular regular or periodic, update or request for the same content. "Same" content means preferably content being the same on a higher abstraction level, e.g. content representing current time with another background photo.

According to the invention it has been recognized that a mechanism for identifying in particular mobile web applications/services involving a dynamic and frequent transmission/reception of the same content by a group of users, preferably in the same neighborhood, is provided. According to the invention it has further been recognized that waste of communications networks resources is at least reduced.

According to the invention it has further been recognized that an efficient usage of multimedia broadcast multicast services (MBMS) is enabled.

According to the invention it has further been recognized that congestion in the communication network, in particular for a 3GPP mobile communication network at both evolved packet core as well as the radio access network, is alleviated by reducing load of duplicate content.

Further features, advantages and preferred embodiments are described in the following subclaims. According to a preferred embodiment the traffic reduction policy enforces a rerouting through a proxy and/or an offloading to an access network of data traffic for the identified common frequently requested content. Rerouting through a proxy enables an easy implementation as well as an efficient traffic reduction within the communication network. Proxies can be easily provided or established. One of the advantages of an offloading the data traffic to an access network which may be well-designated is that an even more efficient traffic reduction via the well- designated access network is enabled, since the access network may be in particular designed for purposes of routing of common frequently requested content. According to a further preferred embodiment the traffic reduction policy enforces provisioning of the identified common frequently requested content via multicast. One of the advantages is, that this enables a flexible reduction of congestion in the communication network via different entities along the communication path between the user devices and the one or more servers.

According to a further preferred embodiment multicast is provided by establishing a multicast group, preferably via the proxy, assigning the user device requesting the identified common frequently requested content to this multicast group and enforcing multicasting for the identified common frequently requested content for the assigned user device. This enables a dynamic and single assigning to and a deleting of user devices from the multicast group.

According to a further preferred embodiment an entity of the communication network along the communication path for requesting the content performs at least step a) and b). One of the advantages of an entity of the communication network for performing at least steps a) and b) is, that further upstream in the communication network, i.e. "closer" to the service provider respectively server the frequently requested content of more user equipment requesting the frequently requested content can be taken into account when analyzing the data. For illustration in case of 3GPP communication data traffic for frequently requested content of a plurality of different evolved node Bs may be taken into account when the entity is for example collocated with the packet data network gateway compared with the entity collocated with one evolved node B. In this way an even more efficient data traffic respectively load reduction within the communication network is enabled.

According to a further preferred embodiment a user device itself performs at least steps a)-c). By performing at least the steps a)-c) at the user equipment respectively user device, the user device itself may for example identify an application running on the user device which frequently requests content so that a more reliable identification of frequently requested content is provided. Further the user device itself may for example look into preferences of applications, for example stock tickers showing current prices of stocks. These usually have certain time intervals for updating the prices of certain stock exchanges laid down in the applications preferences Therefore a very easy identification of frequently requested content by the user device is possible, i.e. an identification on the application level. According to a further preferred embodiment a request frequency of the data of the requested content is determined, compared with a predetermined threshold and a result of the comparing is used for step b). By determining the request frequency of the data of the frequently requested content a reliable and easy-to-implement identification is enabled. Further only minimized resources for calculation of the frequency for the common frequently requested content are necessary.

According to a further preferred embodiment HTTP-GET-requests of the data of the requested content are used for analyzing according to step a). Using the HTTP-GET-requests enable on the one hand an easy identification of common frequently requested content as well as a reliable interception for example for a rerouting and/or offloading the data of the common requested content. According to a further preferred embodiment the predetermined threshold is dynamically configured. Dynamically configuring means, that for example the threshold can be updated depending on the time of the day, the location of user devices, load conditions in the communication network or the like enabling a very flexible adaption to certain boundary conditions like communication network conditions or the like.

According to a further preferred embodiment the request frequency is determined based on inter-arrival times of two consecutive content requests from the same user device and/or number of requests from the same user device during a pregiven time-limit. This enables an easy implementation as well as resource- minimized determination of the request frequency.

According to a further preferred embodiment in step a) requested content sent to the user devices is analysed. This enables a more reliable identification of user devices receiving the requested content in contrast to considering content requests. For example if requests for content are used a server may deny these requests for some reasons, for example due to wrong authentication information for that content. Therefore considering the content requests would give an at least partly wrong picture of the number of user devices frequently requesting content as well as assumed network load within the communication network for the frequently requested content.

According to a further preferred embodiment the traffic reduction policy is revoked after a pre-given, preferably dynamically configurable, parameter is not fulfilled anymore, preferably in form of a pre-given time period and/or a pre-given number of user devices within the multicast group. This enhances the flexibility of the method, since for example imposed traffic reduction policies are revoked after certain time periods. If the time period is dynamically configurable this enhances further the flexibility, since for example depending on location, time of the day, etc. a revocation of the traffic reduction policy can be performed.

According to a further preferred embodiment user devices fulfilling a pregiven preference policy are used for performing steps a)-d). The term "preference" in the context of the term "policy" is preferably to be understood in a broad sense, in particular not limited to a preference of a user, an operator or the like. By using the user devices fullfiling a pregiven preference policy the number of user devices may be limited. For example user devices of a certain type of device (e.g. Machine- Type-Communication devices), of a certain connection to the server, etc. can be filtered by the preference policy for performing steps a)-c).

According to a further preferred embodiment the preference policy represents area and/or location information. This enables an easy adaption of the method to a mobile communication network. For example user devices connected to a certain evolved node B, i.e. within the coverage area of the evolved node B may be represented by the preference policy.

According to a further preferred embodiment the threshold and/or the time period are updated depending on a time, area and/or location information. This further enables in a very flexible way to adapt the thresholds and/or the time periods to certain boundary conditions.

According to a further preferred embodiment the traffic reduction policy is provided by an operator and preferably enforced by the user device. When the traffic reduction policy is provided by the operator, for example a centralized amendment and/or change of the traffic reduction policy is possible. Further a more optimized traffic reduction policy may be enabled, since an operator of the communication network may take into account more parameters, for example load in other branches of the communication network for deciding which traffic reduction policy is enforced for the frequently requested content. If preferably the traffic reduction policy is enforced by the user device are reliable traffic reduction directly at the user device is enabled. According to a further preferred embodiment the applied traffic reduction policy is dependent on the threshold. This enhances further flexibility. For example if the frequency of HTTP-GET requests exceeds a certain value then relevant data traffic may be offloaded to WiFi whereas if the frequency of the HTTP-GET requests is within a certain range a multicast group is joined by the user device and if the frequency of the HTTP GET requests is lower than a further value data traffic is routed as usual without offloading or being redirected through a proxy.

According to a further preferred embodiment of the system according to claim 18 the network entity is a server, preferably in form of a proxy, of an operator and/or the traffic detection entity is a gateway. In particular a proxy as well as a gateway enable a reliable as well as avoid a time consuming identification of common frequently requested content.

According to a further preferred embodiment of the system according to claim 18 a proxy is statically configured to provide requested content via multicast. Multicasting of the proxy enables a very efficient traffic reduction in the communication network.

According to a further preferred embodiment of the system according to claim 18 a user device is configured to integrate content provided by a multicast and content via unicast at an application layer of an application running on the user device. Thus the user using the user device does not see any change in his perception of the application when unicast and multicast content are presented to the user on an application layer. Distraction of the user is therefore avoided.

According to a further preferred embodiment of the system according to claim 18 a user device comprises a cache for caching frequently requested content provided via multicast and the user device is configured to check the cache prior to a request via unicast for a missing content part. This reduces the load respectively the data traffic within the communication network. Further the flexibility is enhanced: If the cache is configured to store any content that is received via multicast prior to request any missing content objects for the server the cache is checked if the content object already received via multicasting. If so and if the cached content object is still topical for example HTTP requests to the server are avoided and the cached content is used. This enables a server or proxy to push embedded content objects, for example images or other content types in addition to normally configured content, preferably XML/HTML content. If the content is not in the cache the content is requested as usual.

According to a further preferred embodiment the user device is configured to integrate the content provided via multicast by a multicast-plugin for the application at an application layer. This enables to use to system in particular for mobile communication networks and mobile user devices. A web browser for example enables an easy request of content and maybe easily upgraded with a multicast- plugin to reduce traffic within the communication network.

According to a further preferred embodiment of the system according to claim 18 a proxy is configured to provide a multicast group for providing identified common frequently requested content via multicast and to issue a request to corresponding user devices for joining the multicast group to receive the identified common frequently requested content via multicast. This provides an easy-to-implement as well as flexible way to provide frequently requested content to a plurality of user devices while reducing the data traffic within the communication network.

According to a further preferred embodiment of the system according to claim 18 the server is configured to provide embedded requested content prior to non- embedded content. This further reduces the data traffic for the frequently requested content, since a client or browser does not request any missing content based on a regular request. Alternatively the application requesting the frequently requested content may wait for a configurable timeout for content objects that are related to content received via multicast. Only if the content is not received via multicast within the timeout limit a conventional request, for example a HTTP request is issued by the user device. There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claim 1 and patent claim 18 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the figure on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the figure, generally preferred embodiments and further developments of the teaching will we explained. In the drawings

Fig. 1 shows a schematic view of a conventional system;

Fig. 2 shows a system according to a first embodiment of the present invention;

Fig. 3 shows part of a method according to a second embodiment of the present invention;

Fig. 4 shows a method according to a third embodiment of the present invention and

Fig. 5 shows a system according to a fourth embodiment of the present invention.

Fig. 1 shows a schematic view of a conventional system.

In Fig. 1 a conventional situation is illustrated for a 3GPP evolved packet system in Fig. 1. A plurality of mobile user devices UD1 , UD2, ... are each connected via an evolved node B eNB, a serving gateway S-GW, a packet data network gateway P- GW, a corresponding packet data network PDN to a web server S providing content. The web server S provides same content being delivered to a large number of users respectively the user devices UD1 , UD2,... being in the same area/location. In Fig. 1 the "same area/location" corresponds to the coverage area of the same backhaul network or more precisely evolved node B eNB. This causes a high load in the backhaul network between the evolved node B eNB and the web server S. Each user device UD1 , UD2 with its own connection receives from the web server S a corresponding flow F1 , F2 destined to different user devices UD1 , UD2.

Fig. 2 shows a system according to a first embodiment of the present invention.

In Fig. 2 a 3GPP evolved packet system is shown wherein content in common with all relevant user devices is multicast from a web server or proxy server on top of UDP and received by a suitable plug-in at the user devices.

In Fig. 2 a web server S is connected via a communication network to different user devices UD1 , UD2, etc.. A communication network comprises a packet data network, a proxy server P located at the packet data network gateway P-GW which is further connected to a serving gateway S-GW. The serving gateway S- GW is connected to an evolved node B eNB. To the evolved node B eNB a plurality of user devices UD1 , UD2, etc. is connected.

The dotted lines between the different user devices UD1 , UD2 correspond to flows of non-duplicate content delivered in unicast on top of TCP between the web server S and the user devices UD1 , UD2. The non-dotted line corresponds to content in common with the user devices UD1 , UD2. This common content, which is frequently requested from the web server S is multicast from the proxy server P or web server S on top of UDP and received by corresponding plug-ins at the user devices UD1 , UD2, etc.. The user devices UD1 , UD2 are configured to execute a multicast plug-in for receiving multicast content from the proxy server P. The web server S and/or the proxy server P respond to any HTTP request of the user device for frequently requested content with a well defined content type and a multicast address. These information would upon arrival at a web browser of the user device UD1 , UD2 activate the multicast browser functionality and/or launch a respective web browser plug-in. The multicast plug-in then enforces joining of the user device UD1 , UD2 to the respective multicast address/group and starts listening for content messages via multicast. The content messages received via the multicast message would then be rendered according to XML/HTML format in the corresponding browser window.

Fig. 3 shows part of a method according to a second embodiment of the present invention.

In Fig. 3 a general message flow of web-based multicast content distribution is shown. In a first step T1 a web server S allocates a multicast address to specific frequently requested content feed CF. In a second step T2 the multicast content is provided in XML via UDP by the web server S. In a third step T3 a web client/browser of a user device UD issues a HTTP request, for example GET content-feed CF via TCP/IP. In a fourth step T4 the web server S responds to the HTTP responds message including multicast content type and multicast address via TCP/IP. In a fifth step T5a after receiving the response from the web server S the multicast browser plug-in is started and a further fifth step T5b the user device UD joins the multicast group according to the multicast address. The user device UD respectively the web client/browser is then configured to receive multicast content content-feed CF in XML via UDP in a sixth step T6. In a seventh step T7 the multicast content content-feed CF is rendered.

The web client/browser of the user device UD may be enhanced by an internal cache wherein the internal cache stores any content that is received via the multicast channel. Prior to request any missing content objects for the web server S the web client/browser of the user device UD checks if the content object has already received via the multicast channel. If so and if the cached content is still topical, it will omit the HTTP request to the web server S or the proxy server P to push embedded content objects, for example images or other content types, in addition to XML/HTML configured content. If the content object is not in the cache of the user device UD the web client/browser may request the content objects in a conventional manner. To avoid that the web client/browser requests any missing content based on a conventional HTTP request, the web server S/proxy server P delivers embedded contents prior to XML/HTML content. Alternatively the web client/browser may also wait for a configurable timeout for content objects that are related to previously content provided via multicast and only if the content is not received via multicast within the timeout limit, a conventional HTTP request would be issued. A content-feed may be declared "replacing" or "additive" for example by using adequate XML/HTML tags. When being declared as "replacing" a multicast content-feed update replaces the previously received content while when being declared as "additive" the content-feed update will be added at the end of the previously delivered content.

User devices UD receiving service may include content which is common to other user devices and other part of the content that is specific to each of the user devices UD. Content that is not common is delivered in unicast over TCP in a conventional manner. Common content may be delivered via multicast over UDP according to the present invention. At each of the user devices UD an application layer logic maybe provided integrating the two portions of the content, the one received unicast and the one received multicast.

Fig. 4 shows a method according to a third embodiment of the present invention.

In Fig. 4 user devices UD denoted with reference signs UE1 , UE2 and UE3 are connected via traffic detection function TDF and a mobile network proxy P to a server S. The server S provides content for the user devices UE1 , UE2, UE3. Each of the user devices UE1 , UE2, UE3 issues in a first step S1 a HTTP request to get a specific content feed and sends the HTTP request to the server S. In a second step S2 the server S responds with an HTTP responds message acknowledging the received request and providing the corresponding content. The user devices UE1 , UE2, UE3 further issue corresponding HTTP requests in steps S1 ' and S1 " to update the received content in the first step S1 . The server S responds with corresponding HTTP responses according to S2' and S2.

Meanwhile the traffic detection function TDF analyses (reference sign S1 ") a frequency of the HTTP requests for the requested content to the same server S and the number of user devices UE1 , UE2, UE3 requesting the same content. When for example issuing a certain number of HTTP requests in a certain time period the traffic detection function intercepts in a third step S3 the identified frequently requested content and forwards the corresponding requests for that content to the mobile network proxy P, located in the communication path between the traffic detection function TDF and the server S. In a fourth step S4 the mobile network proxy P allocates multicast addresses to specific content feeds. In a fifth step S5 the mobile network proxy P responds to the user devices UE1 , UE2, UE3 with the corresponding HTTP response messages including a corresponding acknowledgement and multicast content type information and a multicast address or multicast addresses. In a sixth step S6 each of the user devices UE1 , UE2, UE3 starts a corresponding multicast plug-in upon receiving HTTP response message according to a fifth step S5 and joins the corresponding multicast group. In a seventh step S7 the user devices UE1 , UE2, UE3 receive relevant, i.e. requested content delivered in multicast via UDP from the mobile network proxy P.

In an eight step S8 each of the user device UE1 , UE2, UE3 integrates multicast content with unicast content if applicable at the application layer for presenting the content to the user.

In Fig. 4 the server S does not belong to a mobile operator or does not run a mobile networks multicast plug-in. In summary according to Fig. 4 a number of user equipment UE1 , UE2, UE3 send HTTP request messages asking for a particular content from the same web server S. The traffic detection function TDF initially analyzes a request frequency of these HTTP requests and the number of requesting user devices UE1 , UE2, UE3. If they satisfy particular conditions the traffic detection function TDF intercepts new HTTP requests to the same web server S and forwards them to a proxy server P owned by a mobile network operator. This applies in case the web server S is not owned by the mobile network or the application server does not run the mobile network's plug-in for multicasting common content. The proxy server P then allocates a multicast address to the specific content feed and sends back a HTTP response to the relevant user devices UE1 , UE2, UE3 indicating the multicast content type and the multicast group address.

For further optimization in a mobile communication network the mobile communication operator gateway, for example in form of a packet data network gateway P-GW or a GGSN and/or the proxy server P may trigger an establishment of a Multimedia Broadcast Multicast Service session over which the common requested content can be transmitted efficiently. In this case necessary information for the different user devices UE1 , UE2, UE3 to join the MBMS session may also be delivered via the initial HTTP response.

Upon receiving these HTTP responses from the proxy server P the different user equipment UE1 , UE2, UE3 launch their multicast plug-ins and join the corresponding multicast group. Services that are received by the user devices UE1 , UE2, UE3 may had content that is common to each of the user devices UE1 , UE2, UE3 and other part of the content that is specific to each user devices UE1 , UE2, UE3. The uncommon content is delivered in unicast using TCP from the server S. The content in common is then delivered in multicast using UDP to each of the user devices UE1 , UE2, UE3. The content received via multicast may either be received by proxy server P caching the information locally or a proxy server P may request it from the server S and immediately relay to the different user devices UE1 , UE2, UE3 in multicast. The user devices UE1 , UE2, UE3 integrate the content delivered in multicast and the content delivered in unicast at the application layer.

In Fig. 5 an embodiment of a system based on an eMBMS service is shown. Such a multimedia broadcast multicast service MBMS is shown in the standard 3GPP TS 23.246. In a first step R1 the user device UD denoted also with reference sign UE places a web request. In a second step R2 a traffic detection function TDF which may be collocated on the packet data network gateway or standalone on an SGi, re-routes Web-requests from the user device UD potentially subject to multicasting via a web-proxy function co-located with a Broadcast/Multicast Service center BM-SC server.

In a third step R3 the number of user devices UD requesting the content is checked and if the number is high enough to benefit from multicasting the web proxy will trigger an establishment of an MBMS session for that requested content and provide the required information for the user device UD to join the MBMS session via a HTTP response to the user device UD. In a fourth step R4 upon receipt of the HTTP response with the MBMS session information, the web browser of the user device UD will trigger the user device UD to join the respective MBMS session and listen for content updates via this session. The traffic detection function TDF may be either co-located with the packet data network P-GW or sit as a standalone box on the SGi interface according to TS 23.401 . Further the web- proxy server may be either co-located with a broadcast/multicast service center BM-SC or provided as a standalone function. When providing as a standalone function a standardized or proprietary interface between the web proxy and the broadcast/multicast service center BM-SC may be provided for the web proxy to dynamically establish a MBMS session.

In summary the present invention provides in particular mechanisms or techniques to identify emerging mobile web applications that may waste mobile networks scarce resources. A further advantage is, that the present invention makes efficient usage of available MBMS technology and alleviates congestion at both the evolved packet core EPC and the radio access network RAN by reducing the load of duplicate content. The present invention further enables a dynamic traffic data identification enabling identification of an application/session as an "application/session with frequently and dynamically updated content" based on a frequency at which its content or part of its content is delivered to user devices. This frequency may be based on inter-arrival times between two consecutive HTTP GET requests from a user device or set of user devices. If this frequency is shorter than a certain threshold and/or the number of HTTP GET requests from a user device or a set of user device issued during a time interval exceeds a certain value or if the traffic delivered over a session exceeds a certain data volume threshold then the corresponding application is identified as "application/session with frequently and dynamically updated content" by a traffic detection function.

Further the present invention for example provides a server which may dynamically instantiate a multicast group and/or MBMS session/channel for content that is frequently sent to many user devices and returns to the user device in the response the necessary information to join the multicast group or MBMS session/channel and for the application for example a web browser to listen to the relevant port/channel. Multicast content may either be received by the user device via a proxy server caching the information locally or proxy server receiving it from the web server and immediately will relay to the user device via multicast. Further the present invention enables a user device to integrate the content delivered in multicast and the content delivered in unicast belong to the same mobile application at the application layer. The web client/browser of a user device or any corresponding application may receive and render the content in the application in a transparent way to corresponding users. Further the web content maybe encoded in standard marker languages, for example HTML or XML.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. A method for provisioning frequently requested content of user devices from one or more servers (S) via a communication network, characterized in that a) data of requested content (S1 , S2, S1 \ S2') is analysed (S12), that b) based on a result of the analysed data common frequently requested content of user devices (UD!, UD2) is identified, that

c) based on the identified common frequently requested content a traffic reduction policy for the identified common frequently requested content is established (S12') and that

d) based on the traffic reduction policy, the identified common frequently requested content is provided to the user devices (UD1 , UD2).

2. The method according to claim 1 , characterized in that the traffic reduction policy enforces a rerouting through a proxy (P) and/or an offloading to an access network of data traffic for the identified common frequently requested content.

3. The method according to one of the claims 1 -2, characterized in that the traffic reduction policy enforces provisioning of the identified common frequently content via multicast.

4. The method according to one of the claims 1 -3, characterized in that multicast is provided by establishing a multicast group, preferably via the proxy (P), assigning the user device (UD1 , UD2) requesting the identified common frequently requested content to this multicast group, and enforcing multicasting for the identified common frequently requested content for the assigned user device (UD1 , UD2).

5. The method according to one of the claims 1 -4, characterized in that an entity (TDF, P-GW) of the communication network along the communication path for requesting the content performs at least step a) and b).

The method according to one of claims 1-5, characterized in that a user device (UD1 , UD2) itself performs at least steps a)-c).

The method according to one of the claims 1 -6, characterized in that a request frequency of the data of the requested content is determined, compared with a predetermined threshold and a result of the comparing is used for step b).

The method according to one of the claims 1 -7, characterized in that HTTP GET requests of the data of the requested content are used for analysing according to step a).

The method according to claim 7, characterized in that the predetermined threshold is dynamically configured.

10. The method according to one of the claims 7-9, characterized in that the request frequency is determined based on inter-arrival times of two consecutive content requests from the same user device (UD1 , UD2) and/or a number of requests from the same user device (UD1 , UD2) during a pre-given time-limit.

1 1. The method according to one of the claims 1 -10, characterized in that in step a) requested content sent to the user devices (UD1 , UD2) is analysed.

12. The method according to one of the claims 1 -1 1 , characterized in that the traffic reduction policy is revoked after a pre-given, preferably dynamically configurable, parameter is not fulfilled anymore, preferably in form of a pre- given time period and/or a pre-given number of user devices within the multicast group.

13. The method according to one of the claims 1 -12, characterized in that for performing steps a)-d) user devices (UD1 , UD2) fulfilling a pre-given preference policy are used.

14. The method according to claim 13, characterized in that the preference policy represents area and/or location information.

15. The method according to claims 9 and/or 12, characterized in that the threshold and/or the time period are updated depending on time, area and/or location information.

16. The method according to one of the claims 1 -15, characterized in that the traffic reduction policy is provided by an operator and preferably enforced by the user device (UD1 , UD2).

17. The method according to one of the claims 1 -16, characterized in that the applied traffic reduction policy is dependent on the threshold.

18. A system for provisioning frequently requested content of user devices (UD1 , UD2) from one or more servers (S) via a communication network, preferably for performing with a method according to one of the claims 1 -17, characterized in that a traffic detection entity (TDF, P-GW) is configured to analyse data of requested content and to identify based on a result of the analysed data common frequently requested content of user devices (UD1 , UD2), and that a network entity (S, P) is configured to establish based on the identified common frequently requested content a traffic reduction policy for the identified common frequently requested content and to provide based on the traffic reduction policy the identified common frequently requested content to the user devices (UD1 , UD2).

19. The system according to claim 18, characterized in that the network entity is a server (S), preferably in form of a proxy (P), of an operator and/or the traffic detection entity is a gateway (P-GW).

20. The system according to one of the claims 18-19, characterized in that a proxy (P) is statically configured to provide requested content via multicast.

21. The system according to one of the claims 18-20, characterized in that a user device is configured to integrate content provided via multicast and content provided via unicast at an application layer of an application running on the user device (UD1 , UD2).

22. The system according to one of the claims 18-21 , characterized in that a user device (UD1 , UD2) comprises a cache for caching frequently requested content provided via multicast and that the user device (UD1 , UD2) is configured to check the cache prior to a request via unicast for a missing content part.

23. The system according to one of the claims 21 -22, characterized in that the user device (UD1 , UD2) is configured to integrate the content provided via multicast by a multicast-plugin for the application at the application layer.

24. The system according to one of the claims 18-23, characterized in that the proxy (P) is configured to provide a multicast group for providing identified common frequently requested content via multicast and to issue a request to corresponding user devices (UD1 , UD2) for joining the multicast group to receive the identified common frequently requested content via multicast.

25. The system according to one of the claims 22-24, characterized in that the server is configured to provide embedded requested content prior non- embedded content.