The present invention relates to an apparatus, a method, and a computer program product related to radio communication networks. More particularly, the present invention relates to an apparatus, a method, and a computer program product related to traffic offloading.
The offloading of cellular data traffic to WiFi networks is currently of very high interest to mobile network operators. Operators are looking for ways to enable efficient and effective WLAN-3GPP network load balancing in order to increase system capacity, system utilization and improve the user experience. This operator interest has led to a specific new study item in 3GPP Radio Access Network working group 2 (3GPP RAN2) to investigate better mechanisms for WLAN/3GPP interworking that take dynamically changing cell load level into account in network selection.
Furthermore, 3GPP is working on a solution to make the network aware of cell congestion situations, and to enable it to react with traffic management actions (UPCON).
Recently, at Mobile World Congress 2013 (MWC 2013), Nokia Siemens Networks® (since August 2013: Nokia Solutions and Networks™) (NSN®) launched “Liquid Applications”. This provides a new Radio Applications Cloud Server (RACS), which is integrated with NSN's Flexi BTS. It leverages IBM's WebSphere Application Service Platform for Networks (ASPN) platform to provide a “standards-based cloud runtime environment” that enables localized processing, content storage, and access to real-time radio and network information in the base station. This technology can be used for several approaches. One application is to provide content nearer to the customer with local caches and other CDN functions. In MWC 2013, video optimization depending on cell load status was presented.
For traffic steering between different access networks several mechanisms are known to provide the routing information to the connection manager in the UE. These are e.g.:
It should be noted that with the gaining importance of Wi-Fi offload, operators may increasingly make use of these mechanisms for traffic routing for offloading.
In the area of Content Delivery Networks (CDN), various mechanisms have been developed to select the optimal content source for the user (resource selection). Mechanisms used are for example changed URLs (‘URL re-writing”), DNS manipulation or HTTP redirect (this one adds a round trip) for the content re-direction.
According to a first aspect of the invention, there is provided an apparatus, comprising monitoring means adapted to monitor a request received from a terminal device, wherein the request requests one of a first address of a first source of at least one file and the at least one file from the first source with the first address; determining means adapted to determine a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source of the at least one file, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; address providing means adapted to provide, in response to the request, the second address to the terminal device.
In the apparatus, the request may be one of a domain name service request and a hypertext transfer protocol request for the first address.
In the apparatus, the request may be the domain name service request, and the apparatus may further comprise address request forwarding means adapted to forward the request; extracting means adapted to extract the first address from a response received in response to the forwarded request.
In the apparatus, if the request requests the at least one file from the first source, the address providing means may be adapted to provide, to the terminal device, an instruction to request the at least one file from a second source with the second address.
The apparatus may further comprise: checking means adapted to check if the first address and the second address are the same; inhibiting means adapted to inhibit, if the first address and the second address are the same, the address providing means from providing the instruction to the terminal device; and file request forwarding means adapted to forward, if the first address and the second address are the same, the request to the first address.
In the apparatus, the determining means may be further adapted to determine the second address depending on at least one of a type of the at least one file and an application type to be applied to the at least one file.
According to a second aspect of the invention, there is provided an apparatus, comprising detecting means adapted to detect a first address in an address file, wherein the first address indicates a first source of at least one file to be fetched; determining means adapted to determine a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source from which the at least one file to be fetched may be downloaded, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; modifying means adapted to modify the address file by replacing the first address by the second address.
The apparatus may further comprise: triggering means adapted to trigger the detecting means to detect the first address in the address file if a request for the address file is received from a terminal device; and modification providing means adapted to provide the modified address file to the terminal device in response to the request.
The apparatus may further comprise: address file providing means adapted to provide the address file.
In the apparatus, the address file may be one of a manifest and a hypertext markup language page.
According to a third aspect of the invention, there is provided an apparatus, comprising monitoring means adapted to monitor a request received from a terminal device, wherein the request requests at least one requested address file from a first source with a first address; determining means adapted to determine a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source of the at least one requested address file, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; fetching means adapted to fetch at least one fetched address file from the second address; providing means adapted to provide, in response to the request, at least one provided address file to the terminal device, wherein the at least one provided address file is based on the at least one fetched address file.
In the apparatus, the at least one address file may comprise at least one of a manifest, a partial manifest, and a hypertext markup language page.
The apparatus according to any of the first to third aspects may further comprise identifying means adapted to identify at least one capability of the terminal device to access a respective one of the plural access networks; wherein the determining means is adapted to determine the second address additionally based on the identified capability.
According to a fourth aspect of the invention, there is provided an apparatus, comprising monitoring processor adapted to monitor a request received from a terminal device, wherein the request requests one of a first address of a first source of at least one file and the at least one file from the first source with the first address; determining processor adapted to determine a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source of the at least one file, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; address providing processor adapted to provide, in response to the request, the second address to the terminal device.
In the apparatus, the request may be one of a domain name service request and a hypertext transfer protocol request for the first address.
In the apparatus, the request may be the domain name service request, and the apparatus may further comprise address request forwarding processor adapted to forward the request; extracting processor adapted to extract the first address from a response received in response to the forwarded request.
In the apparatus, if the request requests the at least one file from the first source, the address providing processor may be adapted to provide, to the terminal device, an instruction to request the at least one file from a second source with the second address.
The apparatus may further comprise: checking processor adapted to check if the first address and the second address are the same; inhibiting processor adapted to inhibit, if the first address and the second address are the same, the address providing processor from providing the instruction to the terminal device; and file request forwarding processor adapted to forward, if the first address and the second address are the same, the request to the first address.
In the apparatus, the determining processor may be further adapted to determine the second address depending on at least one of a type of the at least one file and an application type to be applied to the at least one file.
According to a fifth aspect of the invention, there is provided an apparatus, comprising detecting processor adapted to detect a first address in an address file, wherein the first address indicates a first source of at least one file to be fetched; determining processor adapted to determine a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source from which the at least one file to be fetched may be downloaded, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; modifying processor adapted to modify the address file by replacing the first address by the second address.
The apparatus may further comprise: triggering processor adapted to trigger the detecting processor to detect the first address in the address file if a request for the address file is received from a terminal device; and modification providing processor adapted to provide the modified address file to the terminal device in response to the request.
The apparatus may further comprise: address file providing processor adapted to provide the address file.
In the apparatus, the address file may be one of a manifest and a hypertext markup language page.
According to a sixth aspect of the invention, there is provided an apparatus, comprising monitoring processor adapted to monitor a request received from a terminal device, wherein the request requests at least one requested address file from a first source with a first address; determining processor adapted to determine a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source of the at least one requested address file, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; fetching processor adapted to fetch at least one fetched address file from the second address; providing processor adapted to provide, in response to the request, at least one provided address file to the terminal device, wherein the at least one provided address file is based on the at least one fetched address file.
In the apparatus, the at least one address file may comprise at least one of a manifest, a partial manifest, and a hypertext markup language page.
The apparatus according to any of the fourth to sixth aspects may further comprise identifying processor adapted to identify at least one capability of the terminal device to access a respective one of the plural access networks; wherein the determining processor is adapted to determine the second address additionally based on the identified capability.
In the apparatus according to any of the first to sixth aspects, the dynamic status information may comprise at least one of a load, a failure status, and a link status.
In the apparatus according to any of the first to sixth aspects, the plural access networks may comprise at least a radio network according to a third generation partnership project standard and a wireless local area network or wireless fidelity network.
According to a seventh aspect of the invention, there is provided a method, comprising monitoring a request received from a terminal device, wherein the request requests one of a first address of a first source of at least one file and the at least one file from the first source with the first address; determining a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source of the at least one file, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; providing, in response to the request, the second address to the terminal device.
In the method, the request may be one of a domain name service request and a hypertext transfer protocol request for the first address.
In the method, the request may be the domain name service request, and the method may further comprise forwarding the request; extracting the first address from a response received in response to the forwarded request.
In the method, if the request requests the at least one file from the first source, the providing of the second address may comprise providing, to the terminal device, an instruction to request the at least one file from a second source with the second address.
The method may further comprise: checking if the first address and the second address are the same; inhibiting, if the first address and the second address are the same, the providing of the instruction to the terminal device; and forwarding, if the first address and the second address are the same, the request to the first address.
In the method, the determining may be further adapted to determine the second address depending on at least one of a type of the at least one file and an application type to be applied to the at least one file.
According to an eighth aspect of the invention, there is provided a method, comprising detecting a first address in an address file, wherein the first address indicates a first source of at least one file to be fetched; determining a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source from which the at least one file to be fetched may be downloaded, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; modifying the address file by replacing the first address by the second address.
The method may further comprise: triggering the detecting of the first address in the address file if a request for the address file is received from a terminal device; and providing the modified address file to the terminal device in response to the request.
The method may further comprise: providing the address file.
In the method, the address file may be one of a manifest and a hypertext markup language page.
According to a ninth aspect of the invention, there is provided a method, comprising monitoring a request received from a terminal device, wherein the request requests at least one requested address file from a first source with a first address; determining a second address depending on both the first address and a dynamic status information of at least one of plural access networks, wherein, according to a first stored relationship, the second address is of a second source of the at least one requested address file, and, according to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks; fetching at least one fetched address file from the second address; providing, in response to the request, at least one provided address file to the terminal device, wherein the at least one provided address file is based on the at least one fetched address file.
In the method, the at least one address file may comprise at least one of a manifest, a partial manifest, and a hypertext markup language page.
The method according to any of the seventh to ninth aspects may further comprise identifying at least one capability of the terminal device to access a respective one of the plural access networks; wherein the determining of the second address may additionally be based on the identified capability.
In the method according to any of the seventh to ninth aspects, the dynamic status information may comprise at least one of a load, a failure status, and a link status.
In the method according to any of the seventh to ninth aspects, the plural access networks may comprise at least a radio network according to a third generation partnership project standard and a wireless local area network or wireless fidelity network.
Each of the methods according to any of the seventh to ninth aspects may be a method of network selection.
According to a tenth aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any one of the seventh to ninth aspects. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer.
According to some embodiments of the invention, at least one of the following advantages may be achieved:
It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.
Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein
Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given for by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.
Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.
One objective in WLAN-3GPP offloading is effectively and efficiently making full use of both the 3GPP cellular and WLAN resources within a mobile operator's network. This requires an effective and efficient mechanism for traffic steering between the access technologies based on the current load situation and associated expected user experience.
More in detail, the problem to be solved may be seen as follows: Given an end system (UE) that consumes content from one or more servers, each of the server(s) may be reached by one or more, potentially different, access networks (such as cellular and WiFi). Congestion in one of the networks (e.g. the cellular one) leads to problems with delivering the service. In such case, traffic redirection via the other access network can reduce the load. Embodiments of the invention provide a procedure for such traffic redirection. In some embodiments, the redirection may start already before congestion occurs and, thus, may help to avoid cell congestion.
According to embodiments of the invention, one or more CDN mechanisms used for content source re-selection/re-direction may be used to steer user traffic between different access systems, such as a cellular network and a WiFi network. For that purpose CDN functions located in the operator network are enhanced with functions for access network selection/traffic steering.
An issue is that policies for traffic steering need to be aware of a lot of parameters like Content, Subscriber type, Access Network type, Device, Application, actual congestion, transport and interconnect costs, and numerous other criteria in order to make rational and customer-friendly policy decisions. Thus, traffic steering can easily become a very complex exercise for the network operator.
Embodiments of the invention provide a simple solution that uses existing building blocks (UE based traffic routing according to operator policies, MNO hosted CDN/Caching capabilities, Cell congestion indication from RAN to Core, RACS if available) and provides a mapping of different parameters to a limited number of policies and network configurations.
Current traffic steering methods are often applied to the complete UE traffic (i.e. all the traffic of an UE) or PDN connection, as according to MAPCON (Multiple Access PDN Connection) defined in 3GPP Release 10 specifications. Some proposed traffic steering methods may require new RAN/network based signalling, as currently investigated in RAN WG2 study. Those mechanisms where the RAN broadcasts an offload indication include the danger of mass toggling of UEs between the access systems (e.g. after RAN signals preference for Wi-Fi).
At least some of the embodiments of the invention avoid those drawbacks.
Solutions currently investigated in RAN WG2 for RAN—WiFi interworking require standardization for the RAN—UE interface and the UE behaviour. This leads to a time delay for deployments as first a significant number of UEs need to have the feature implemented. In contrast, embodiments of the present invention are based on features that have been already standardized for the UE side.
Embodiments of the invention may re-use e.g. ANDSF based policies and/or IP stack implemented routing policies as described above. In
Also, other existing mechanism and future coming mechanism for provisioning of the routing information may be used in embodiments of the invention.
Conventionally, the usage of traffic steering policies by the UE takes into account only rather static information like time of day or location but do not react on load status that typically changes more dynamically.
According to embodiments of the invention, an opportunity for finer granular and more dynamic operator controlled traffic steering is added.
The methods to select an optimal source of content are conventionally mainly used to find resources in the proximity of the user (reduced latency and transport costs) or to achieve load balancing among the content servers. They are not used for traffic steering of the UE/host.
An advantage of an RACS such as NSN's “Liquid Applications” is the possibility to make use of the base station's local parameters and status such as the knowledge of cell capacity utilization, especially due to the increasing number of video traffic operators who are interested in CDN solutions to optimize the network. Embodiments of the invention may be applied e.g. to the Liquid Applications solution presented by NSN. E.g., they may enhance the implementation presented at MWC 2013 in several points, in particular by a combination of cache and CDN management with traffic steering. In particular, implementing the below described CDN Proxy on the RACS server may help to reduce the signalling delay of the additional HTTP round trip in case of the HTTP redirect solution to a large extent.
In embodiments of the invention, different content locations may be distinguished by different IP address ranges, called “CDN domains”. CDN domains can contain replicated content, e.g. a mobile network operator may have content sources (CDN domain 1 (11) in
With conventional mechanisms such as those mentioned above, the UEs are provided with IP traffic routing policies that will force the UE to route traffic of e.g. CDN domain 1 to the cellular interface and traffic of CDN domain 2 to the WiFi network interface. As the policies are provided by the operator the operator can control what traffic goes to what access. In the Network Routing Policy Server Function, the operator management of the routing policies according to conventional mechanisms is combined with a function that provides traffic classification and routing policies to the CDN proxy function 2 according to embodiments of the invention. The Network Routing Policy Server Function (NRPSF 1) may have an i/f-3 to the ANDSF 3 to program the ANDSF 3 with the right policies that are downloaded to the UE 4 via i/f-4, and/or it may provide routing information to routers 21, 22 and DHCP servers via i/f-5.
The NRPSF 1 has an administrational function. Preferably, CDN proxy 2, and ANDSF 3 and/or the access router(s) 21, 22 are administered from a central point in order to ensure consistency of the rules provided to these network elements. However, in some embodiments, some or each of the CDN proxy 2, and ANDSF 3 and/or the access router(s) 21, 22 may be separately administered. In such a configuration, operator should ensure consistency of the implemented rules by himself.
An advantageous feature of embodiments of the invention is that the operator can control what content shall be offloaded to Wi-Fi. Furthermore the offloading can be triggered depending on the load status of the cellular network.
Embodiments of the invention may comprise one or more of the following features:
Table 1 shows an example of a policy table, indicating the respective highest priority CDN domain (CDNdn, n=1, 2, 3, . . . ) for different RAN cell load statuses and contents. In this example, routing priorities provided to the UE would link CDNd1 and CDNd3 access via RAN, CDNd2 and CDNd4 access via WiFi interface.
Another example shown in Table 2 uses a traffic classification and the CDN proxy comprises two tables (a content classification table shown on top and a redirection policy table shown at the bottom of Table 2):
The operator may try to cache a significant amount of content in the Core or RAN to avoid interconnection cost with other networks providers/ISPs. Such content may be considered as low- or medium value content, i.e. access to it can be redirected if there is congestion in the default access network (e.g. 3GPP network).
The network operator may also provide content via its own content servers, e.g. to take advantage of business opportunities from acting as content provider. From this point of view, operator content could be classified as “high value content” that should be delivered via own network resources and not redirected. Those servers might be located in a CDN-domain111 that is provided by a dedicated IP sub-network/IP address range and accessed via RAN.
With this arrangement, the access network and interface selection in the UE 4 can be steered by the operator by using existing mechanisms 1 and 2 mentioned in the prior art section.
In embodiments of the invention, the UE 4 may be provided with policies for intersystem routing (ISRP 1 in case of ANDSF 3), such that, for example, for traffic of CDN domain111 the interface to 3GPP network has highest priority, and for other CDN domains (e.g. 12) the WLAN interface has highest priority.
If in case of congestion of the 3GPP network the CDN proxy 2 will redirect the traffic from CDN domain111 to CDN domain 212, the UE 4 may automatically also redirect the traffic to the WLAN interface if the policies stored in the UE 4 require this. With this mechanism, the offload amount can be nicely adapted to the cell load status, and high load situations may be proactively avoided if the redirection will already start with cell load levels below overload.
The UE 4 with its connection manager CM 4a is connected to both the 3GPP network (via eNB 5) and the WiFi network (via AP 4) as access networks. These access networks are connected via respective routers 21, 22 and PGW 7 (for the 3GPP network) to CDN domain 111 and CDN domain 212, respectively. CDN proxy 2 is integrated with PGW 7.
The network routing policy server 1 provides policies and rules to ANDSF 3 via i/f-3, routers 21, 22 via i/f-5, and CDN proxy 2 via i/f-2. ANDSF 3 provides the policies to UE 4 via i/f-4.
eNB 5 knows about its load status. To transfer the load status between the eNB 5 and CDN proxy 2 on i/f-1, e.g. a mechanism under development in the 3GPP UPCON work item to transfer the load status between eNB 5 and P-GW 7 may be used. This i/f-1 signalling might involve other network elements not shown in the picture like SGW or PCRF and MME.
For example,
In another implementation shown in
The CDN proxy may apply one or more of the following redirection options:
The apparatus comprises monitoring means 10, determining means 20, and address providing means 30.
The monitoring means 10 monitors a request received from a terminal device (S10). In the request, a first address of a first source of a file may be requested and/or the file from the first source with the first address may be requested. The file may be a video file, an audio file, or any other type of file such as an image file, a PDF file, a word processor file etc.
The determining means 20 determines a second address depending on the first address and a dynamic status information of at least one of plural access networks (S20). According to a first stored relationship, the second address is an address of a second source of the file. According to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks. One or both of the first and second relationships may be stored in one or more data repositories which may be stored on the apparatus, or the apparatus may retrieve the one or both of the relationships from one or more external data repositories. The dynamic status information may comprise e.g. one or more of a load, a failure status, and a link status. The second address may be the same as the first address or different from the first address, depending at least on the dynamic status information.
The address providing means 30 provides, in response to the request, the second address to the terminal device (S30).
The apparatus comprises detecting means 110, determining means 120, and modifying means 130.
The detecting means 110 detects a first address in an address file for a terminal device (S110). The address file may be e.g. a manifest, a partial manifest, or a HTML page comprising the first address. The apparatus may assume that the first address is of a first source from which the terminal device may download at least one content file such as a video or an audio file, or any other type of file such as an image file, a PDF file, a word processor file, etc.
The determining means 120 determines a second address depending on the first address and a dynamic status information of at least one of plural access networks (S120). According to a first stored relationship, the second address is an address of a second source from which the terminal may download the at least one file. According to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks. One or both of the first and second relationships may be stored in one or more data repositories which may be stored on the apparatus, or the apparatus may retrieve one or both of the relationships from one or more external data repositories. The dynamic status information may comprise e.g. one or more of a load, a failure status, and a link status. The second address may be the same as the first address or different from the first address, depending at least on the dynamic status information.
The modifying means 130 modifies the address file by replacing the first address by the second address (S130). The modifying means 130 may also be the actual source of the manifest, e.g. in case the network operator is in control of the content or affiliated with the provider.
The apparatus comprises monitoring means 310, determining means 320, fetching means 330, and providing means 340.
The monitoring means 310 monitors a request received from a terminal device, wherein the request requests at least one requested address file from a first source with a first address (S310). The at least one requested address file comprises at least one address. Each of the requested address files may be e.g. a manifest or a partial manifest of HTTP streaming or a HTML page. The apparatus may assume that the first address is of a first source from which the terminal device may download at least one content file such as a video file or an audio file, or any other type of file such as an image file, a PDF file, a word processor file, etc.
The determining means 320 determines a second address depending on the first address and a dynamic status information of at least one of plural access networks (S320). According to a first stored relationship, the second address is an address of a second source of the at least one requested address file. According to a second stored relationship, each of the first address and the second address is related to a respective one of the plural access networks. One or both of the first and second relationships may be stored in one or more data repositories which may be stored on the apparatus, or the apparatus may retrieve the one or both of the relationships from one or more external data repositories. The dynamic status information may comprise e.g. one or more of a load, a failure status, and a link status. The second address may be the same as the first address or different from the first address, depending at least on the dynamic status information.
The fetching means 330 fetches one or more fetched address files from the second address (S330). If properly configured, the fetched address files at the second address may correspond to the address files at the first address which were requested by the terminal device.
The providing means 340 provides, in response to the request, one or more provided address files to the terminal device (S340). The one or more provided address files are based on the one or more fetched address files. In particular, the one or more provided address files may be the same as the one or more fetched address files. However, in some embodiments, the apparatus may modify the fetched address files somehow (e.g. by a format conversion) to obtain the provided files.
An apparatus according to an embodiment of the invention may be adapted to perform one or more of the methods of
Embodiments of the invention may be employed in a 3GPP network where offloading (e.g. to a WiFi network) is employed. They may be employed also in other networks with offloading like CDMA, EDGE, UMTS, LTE, LTE-A, WiFi networks, etc. A cell device may be a base station of the corresponding technology, such as a NodeB or eNodeB, or a part thereof serving a cell. It may also be a terminal which acts as a cell device for other terminals. A terminal (terminal device, user equipment) may be a mobile phone, a smart phone, a PDA, a laptop or any other terminal which may be attached to the respective network.
Embodiments of the invention are described, wherein the routing policy depends on the load in an access network. In some embodiments, the load of only one of the networks (e.g. 3GPP network) may be considered. In other embodiments, the loads of plural access networks may be taken into account. E.g., a rule may be to choose always the access network with the lowest relative load. Another rule may be that a first one of the access networks (e.g. 3GPP network) may be used in any case if its load is below a first threshold, and that the other network may be used if the load in the first access network (3GPP network in the above example) is above the first threshold and the load in the other network is below a second threshold.
Embodiments of the invention are described wherein a load is taken into account to decide on the routing policy. In some embodiments, instead or in addition to the load, other dynamic status information of the respective access network(s) may be taken into account such as a failure status of the access network, and/or a link status to the access network (link between UE and access network, and/or link between access network and CDN domain). In general, dynamic status information comprises information of some status of the network which typically cannot be precisely predicted when the network is in operation.
In some embodiments, CDN proxy may be aware of the capabilities of the UE to access a certain network. E.g. it may know whether a certain UE has a WLAN interface. Such information may be derived e.g. from the type of the UE and a pre-stored table showing which type of UE has which capabilities. The UE type may be transmitted to the CDN proxy over the interface i/f-1. If CDN proxy knows that a certain UE does not have the capability to access a certain network (e.g. WLAN), it may exclude this network from the routing decision. It should be noted that the proposed rerouting also works in many cases if the CDN proxy is unaware of the UE capabilities: Both the first and the second address can be accessed from each access interface of the device e.g. over the Internet and this way also in case the device supports only one access network interface. In case the device supports multiple access networks the stored relationship in the device of address with the access system guides the device to use the preferred access network.
One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.
Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.
If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on a different software, or some or all of the entities may be based on the same software.
According to the above description, it should thus be apparent that exemplary embodiments of the present invention provide, for example an address modifying device such as a CDN proxy device, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).
Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2013/076794 | 12/17/2013 | WO | 00 |