METHOD FOR PROCESSING CONTENT ON A SERVER, SELECTED BY THE LOCATION OF THE USER TERMINAL

Description

1. Scope of the invention

[0001] The invention lies in the field of communication networks and relates more particularly to a technique for accessing content hosted on a server which is selected according to the location of the user terminal. 2. Prior art

[0002] One evolution in telecommunications networks involves ensuring that content servers are as close as possible to the terminals wishing to access them. This is due to several reasons: On the one hand, content, increasingly composed of video, requires more and more bandwidth and therefore transmission capacity; On the other hand, particularly with regard to mobile infrastructures, operators seek to reduce network latency as much as possible, and one of the means of action to reduce this latency is to bring content servers closer to user terminals; Finally, and without the reasons given to explain this evolution of bringing content servers closer to users being exhaustive, the bandwidth used to carry the streams represents an investment and management cost.

[0003] These reasons explain, in particular, the development of infrastructure and cache servers within networks, known as Content Delivery Networks (CONs). Access to content via protocols such as HTTP (HyperText Transfer Protocol) is most often implemented through CDN servers managed by the communication network operator or an external entity. Bringing CDN server infrastructure closer to endpoints is a first step, but the challenge remains to select the CDN server best positioned relative to the user's endpoint when multiple CDN servers host, or are likely to host, the same content.

[0004] At the same time, communication networks themselves are evolving with the introduction of virtualized functions and architectures such as Mobile Edge Computing (MEC) or Fog Computing (a technique that involves hosting applications at the network edge, as close as possible to users). These two types of architecture share the common feature of distributing software applications and content as close as possible to users. This applies to a variety of functions, such as those related to caching, security, and mobility. By bringing functions and content closer to user terminals, these types of architectures differ from so-called "cloud" architectures, characterized by centralized functions and services, generally located remotely from user terminals. These new architectures (MEC, Fog...)These technologies represent a significant departure from currently deployed mobile network architectures. These mobile network architectures are characterized by content servers positioned beyond—that is, upstream in the downstream direction to the user—the GGSN (Gateway GPRS Support Node) or PDN-GW (Packet Data Network Gateway) gateways, which serve as the entry point to the mobile network and are therefore deployed between the packet networks where the servers reside and the mobile access networks. These gateways are themselves relatively centralized, and the content servers are thus quite far removed from the users. Options for the evolution of these mobile architectures, particularly within the framework of fourth- and fifth-generation networks, rely on a wider distribution of mobile gateways and, consequently, of the functions they support.

[0005] Furthermore, it should be noted that fixed and mobile architectures are quite distinct and currently have little convergence regarding functions and services related to addressing, naming, and content servers. Thus, a CDN server is most often specific to fixed or mobile access, but it is very rare for the same CDN server to be accessible by both a mobile user and a fixed user located close to each other. However, operators, with the aim of converging their offerings, are increasingly inclined to ensure that all types of content are accessible from any type of device connected to any type of access, and also to streamline their architectures by deploying common functions and services for different access types.

[0006] In current technologies, selecting a content server, such as an HTTP server in a CDN architecture, from a set of servers deployed across the network to bring content closer to users, is done via DNS (Domain Name Server) servers and / or HTTP request redirection. This allows for server selection based on the DNS architecture. More specifically, when a device wants to access content, it sends a DNS query to its primary DNS resolver. This resolver then contacts the authoritative DNS server that has information about the location of the requested content, either directly or through other DNS servers.The goal is to provide the terminal with the address of the content server closest to it. Current techniques for achieving this rely on the address of the primary DNS server requested by the terminal to access content. This information is sometimes insufficient or not precise enough, particularly if the primary DNS server is centralized or if the terminal uses a virtual private network (VPN) to access content, in which case its primary DNS server is located too far away. In these cases, the primary DNS server address provides inaccurate or insufficient information about the user's terminal location.

[0007] One possibility to solve this problem is to densify the DNS architecture and distribute the primary DNS servers more widely so that information about the primary DNS server is correlated with a better location of the terminal, which from an architectural point of view and for reasons of cost and network administration, proves to be a less relevant option.

[0008] Another alternative, offered by current technologies, involves using HTTP redirection and associating the selected content server with the IP address assigned to the terminal once the HTTP request reaches a centralized server. This centralized server's role, based on the IP address of the terminal requesting the content, is to transmit an "HTTP redirection" message to the terminal so that it can access the desired content by contacting the local server, located near the terminal, which was indicated by the centralized server in the HTTP redirection message.However, this method is not suitable for mobile networks where the IP address allocated to the terminal has no meaning in terms of geographical location, nor for private networks where the address allocated to the terminal is generally from a centralized address pool and therefore has no meaning in terms of location, which implies that the indicated content server will not necessarily be geographically close to the terminal.

[0009] Another option is to include the subnet information contained in the client's assigned IP address in ONS queries, as specified in draft-ietf-dnsop-edns-client-subnet-06 (December 15, 2015). This allows the subnet information in the terminal's IP address to be used to select the content server. However, this option does not solve the content server selection problem because, in mobile networks or virtual private networks, this subnet information is insufficient to identify a content server close to the terminal.

[0010] US Patent 2015 / 0006615 A1 describes a method and device for enabling a terminal to transmit a content request to a server to which it has been redirected by a CDN selector based on a location attribute. The terminal has previously obtained the location attribute from a location server (paragraph 12). US Patent 2015 / 0154640 A1 describes a method and system for determining the location of an advertising server based on the geographic location of a user terminal (paragraph 14), with the terminal transmitting location information in a content access request.

[0011] Document CN 105 493 462 A describes a content delivery method where a terminal requests a content server selected based on location information, thereby reducing transmission time and improving the user experience (D3, paragraph [4]).

[0012] US patent 2015 / 281385 A1 describes a content delivery method in which a content delivery server maintains an association between URLs and location information. This server, based on location information received from a terminal, identifies a URL associated with that location information and transmits it to the terminal.

[0013] US document 2014 / 355542 A1 describes a method for a UE (User Equipment) to transmit a service request, obtain mobility information associated with the UE, select a service node from a plurality of service nodes, and transmit a response to the UE indicating the selected service node to contact to provide the required service (D5, abstract).

[0014] US patent 2012 / 0184258 A1 describes a method and equipment for identifying a mobile terminal type using information controlled from multiple means, such as passive control protocols and user plane protocols. This information is used to control data storage operations, select content to be delivered, and select alternative interfaces / networks if available (D6, abstract).

[0015] The present invention aims to remedy these drawbacks. 3. Description of the invention

[0016] The invention improves the situation with a method according to claim 1, a selection server according to claim 5, and a computer program according to claim 9. Additional embodiments are defined in the dependent claims.

[0017] According to previous techniques, selecting a content server closest to the user is most often based on IP address information. The IP address of the client's terminal or the DNS resolver is usually considered when selecting a geographically close content server. However, the IP address, used both to identify and locate a terminal, does not always accurately fulfill its locator role, particularly when IP addresses are not allocated according to a geographical organization, as is the case for most mobile operators, or when client terminals are connected via proxies or tunnels.Thanks to this invention, given that location information is transmitted to terminals via access networks, such as cellular or Wi-Fi, the goal is to use this information to select the most suitable content server. The selected content server must be geographically and topologically close to minimize access costs, reduce latency, and improve the user experience. It is conceivable that the terminal may receive multiple location signals from equipment on several access networks to which it is connected.In order to use this information, the terminal, once it has received location information from a device on at least one access network via the connection module to that access network, must first transfer it to the content request generation module. Indeed, in prior art, this location information is most often used solely for the mobility services characteristic of mobile architectures. In this invention, a location indication based on at least one received location piece of information is created and used for server selection and must therefore be transmitted to another module of the terminal, specifically the module responsible for generating content access requests. These requests can be HTTP requests, DNS queries, or any other type of protocol used during content exchange between a terminal and a server.Thus, when a terminal makes an HTTP or DNS request for a given service, it can add a location hint, based on at least one piece of location information, to the request, thereby enabling the use of this information. Once this information is added to the request, the terminal transmits the request, including the location hint, to the selection server, most often a DNS or HTTP server. The selection server then has a reliable piece of location information about the terminal, which can be used to select a content server relevant to the terminal's location.

[0018] According to a particular characteristic, the request to access content from the access process is an http type request.

[0019] The client uses a terminal connected to an access network and opens a browser to access HTTP content. According to the invention, the terminal has been informed of its location, via information transmitted by at least one access network, and constructs an HTTP request including the location indication based on location information obtained from at least one access network.

[0020] In the case of the http protocol, location information can be transmitted in the GET http message sent by the terminal to request the content server.

[0021] Depending on the terminal implementation, this may be the default behavior, in which case all HTTP requests include this location information, regardless of whether it is actually used by the requested HTTP server. Another option is to pre-configure the terminal to include this location information only for a limited list of content types where this information is actually used to select the most appropriate content server. This pre-configuration for dynamic implementation could involve the server requesting the content based on the requested content, for example, for a specific content provider or domain.

[0022] This location information transmitted in the HTTP request can be used, in particular, for HTTP redirects, where a content server sends redirection information to the user's terminal for various reasons, such as because content is available at another address or to distribute the load across multiple servers. Here, the location information can be used to determine a new content server, and the selection server can then send the HTTP redirection message to the user's terminal via an "HTTP redirect" message. Upon receiving this message, the user's terminal can access the desired content by requesting the content server whose address was sent by the selection server in the "HTTP redirect" message.

[0023] According to another particular characteristic, the request to access content from the access process is a DNS type request.

[0024] The location information can be advantageously used to enrich DNS queries sent by the terminal and relayed by intermediate DNS servers to the final or authoritative DNS server, which provides the IP address of the server to which the terminal must connect to access the requested content. The location information transmitted in the DNS query issued by the terminal allows the requested DNS server to associate a content server based on the location information transmitted in the query. This information, in one scenario, could be transmitted systematically with all DNS queries issued by the terminal, regardless of whether this information is supported and taken into account by the DNS servers.An alternative is to insert this location information only in certain DNS queries, for example for specific content, because the servers involved in name resolution are compatible and can effectively take advantage of the information inserted by a user terminal.

[0025] Based on the location information, the DNS server in charge of resolving the domain name related to the content requested by the terminal returns the address of the content server that the terminal must connect to in order to actually access the content.

[0026] According to another particular characteristic, the access process is implemented on a cellular type access network and the location information is based on a "Tracking Area" type parameter.

[0027] When a terminal is connected to a cellular network, such as a fourth-generation LTE (Long Term Evolution) network, the location information received from the LTE network consists of parameters that form the Tracking Area Identity (TAI). This information can be used to determine the terminal's geographic location. In an LTE network, the terminal is informed upon joining the network of the area identified as its Tracking Area, which may encompass several cells or several eNodeBs, depending on the network configuration set by the operator.To limit the number of Tracking Area updates sent by the terminal to the LTE network's Mobility Management Entity (MME) when the terminal is in motion, it is typically provided with a list of Tracking Areas using Tracking Area List (TAL). The terminal can then choose to use the TAI information, or one of its components such as the Tracking Area Code (TAC), or the TAL information to generate a location indicator in its content access request messages. For example, the terminal can insert the TAL list received from the LTE network, or only a subset of the Tracking Areas in the list, or even a TAL list identifier if this location indicator can be used by the selection server, into its HTTP, DNS, or other types of requests.This information, based on Tracking Areas, is already present and used in mobile networks, particularly for location purposes for mobility services. It can therefore be advantageously used for other purposes, such as selecting a suitable content server based on the terminal's location.

[0028] According to another particular characteristic, the access process is implemented on a Wi-Fi type access network and the location information is based on an SSID (Service Set Identifier) ​​type parameter.

[0029] When a device is connected to a WLAN, such as a Wi-Fi network, the location information received from that Wi-Fi network is the SSID. This information can be used to determine the device's geographic location, provided that the various SSIDs to which devices can potentially connect are referenced and can be associated with a sufficiently precise location to effectively select a content server close to the user connected to the Wi-Fi network. If the Wi-Fi network is managed by the operator or an entity affiliated with the operator that manages the selection server, the various SSIDs managed by the operator or entity can be used to select a content server near the user's device.In the case where a terminal is connected to several Wi-Fi networks simultaneously, the different SSID information received from the different Wi-Fi networks can advantageously be used to generate a location indication based on this different SSID information.

[0030] The use case described has the advantage of being applicable to non-cellular Wi-Fi devices. Furthermore, it allows for better performance as perceived by the user and more efficient use of network resources when switching between access points during a data session.

[0031] The various aspects of the access process that have just been described can be implemented independently of each other or in combination with each other.

[0032] Upon receiving a request to access a content server, the selection server, if it is the server responsible for the actual selection of the content service from which the terminal can access the content, selects a server based on the location information present in the request. If the server is accessible via an HTTP request, such as an HTTP server or a CDN server, it can use a table to map a location information to a content server, ultimately informing the user of the IP address of a nearby server, for example, by sending an HTTP redirect message containing the IP address of the selected content server.Similarly, if the resolution server is a DNS server, it will use location information to select, for example, an HTTP server, a CDN server or even an FTP server, close to the user's terminal and indicate the IP address of that server to the terminal that made the access request.

[0033] Since CDN and DNS infrastructures are most often deployed hierarchically, it is very common for a content access request to be routed hop-by-hop through intermediate servers until it reaches the final server, which is responsible for selecting the content server and informing the user's terminal. These intermediate selection servers do not themselves select specific content servers, but they must not filter, modify, or remove the location information when they receive and then forward the content request to another selection server. Therefore, when they receive a content access request that includes a location information, they must ensure that this request is forwarded with the location information to the next selection server.

[0034] According to a particular characteristic, the selection process further includes a step of consulting a table of correspondence between location indications relating to at least two types of access networks.

[0035] If the user terminal is connected to both a Wi-Fi network and a cellular network, it may receive both a Tracking Area and an SSID location information. In this case, the terminal can generate one location indication based on both, or two separate location indications, each based on the respective information. Specifically, a terminal can be simultaneously connected to at least two access networks and receive multiple location information simultaneously, from which it will generate one or more location indications. It is important to note that a cellular connection is not required to generate two location indications.In the case where the terminal has the ability to connect to a cellular network, with an active SIM (Subscriber Identity Module) card, and has previously connected to a cellular network, it has TA type information in memory even if it is not connected to the cellular network while connecting to the Wi-Fi network.

[0036] If the terminal is capable of connecting to a Wi-Fi or LTE network, it's also possible to automatically build a lookup table between SSID information and TA (Tracking Area) information, interfaced with the content selector. In one scenario, any terminal connected to a Wi-Fi network would send its Wi-Fi access SSID in its content request. The content server selection would then be based on the SSID-TA lookup, which could be generated from the TA and SSID information transmitted by terminals capable of connecting to Wi-Fi and cellular networks. Another possible use of this lookup would be an evolution of Wi-Fi access whereby Wi-Fi access points broadcast these TAI and TAL parameters, currently broadcast exclusively on cellular networks, to terminals.Thus the location identifier would be identical between cellular and Wi-Fi networks, for simpler server selection management and homogenization between Wi-Fi and LTE architectures.

[0037] The creation and updating of the lookup table can be carried out in several ways. Specifically, the operator or lookup table provider could create and maintain a lookup table based on a map of the geographic coordinates of the equipment providing location information, such as SSID and TAI. This table could also benefit from information derived from cellular radio coverage maps. Alternatively, the lookup table could be created and updated using a machine learning method, where location data collected from terminals and supplemented with other information such as the terminal ID, session ID, and GPS coordinates would be recorded to populate the lookup table. These proposed methods are not mutually exclusive and could also be used in combination.

[0038] The invention also relates to a content access system comprising at least one selection server and at least one terminal.

[0039] In another embodiment, the invention relates to one or more computer programs comprising instructions for the implementation of at least one method as described above, when this or these programs are executed by a processor.

[0040] This program can use any programming language, and be in the form of source code, object code, or code somewhere between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0041] The invention also relates to a computer-readable information carrier, comprising instructions for a computer program as mentioned above.

[0042] The information medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk drive.

[0043] On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be uploaded to a network such as the Internet.

[0044] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the processes in question. 4. List of figures

[0045] Other features and advantages of the invention will become apparent from the detailed description below of particular embodiments, given by way of non-limiting examples, and the accompanying figures in which: There figure 1 This schematically illustrates a content access system involving a user terminal connected to at least one access network and a selection server. The selection server can be a DNS server, an HTTP server, or any other type of server. figure 2 illustrates the different stages of the access process according to an embodiment of the invention where the selection server is a DNS server. figure 3 illustrates the different stages of the access process according to another embodiment of the invention where the selection server is an HTTP server. figure 4illustrates the different stages of the selection process according to another embodiment of the invention where the terminal is successively connected to two different access networks. figure 5 illustrates the structure of a user terminal implementing the different stages of the access process according to a particular embodiment. figure 6 illustrates the structure of a content selection server implementing the different stages of the selection process according to a particular implementation method. 5. Detailed description of at least one embodiment of the invention

[0046] We refer first to the figure 1 which schematically illustrates a content access system involving a user terminal connected to at least one access network, as well as a selection server.

[0047] This figure shows a user terminal 10 connected to an access device 20. The user terminal 10 can be a mobile device, a computer, a home gateway, or any other device capable of communicating with the access device 20 using a wired or wireless connection 30. Also shown in this figure are content servers 50-1, 50-2, 50-3, and 50-4 deployed at different locations within the communications network, which consists of the access infrastructure 60 and the transport infrastructure 40. These access infrastructure 60 and transport infrastructure 40 can be either wireless or wired networks. figure 1 Furthermore, a selection server 110 is presented, which is involved in the process of selecting a content server from among those deployed 50-1, 50-2, 50-3, 50-4 within the communications network. On this figure 1DNS servers are also represented. One of these servers, called the primary DNS server 100, is the one to which terminal 10 connects by default for name resolution. Another, called global DNS server 120, is considered here to be the authoritative server that ensures the actual resolution of the name of the content server that terminal 10 needs to access. This figure 1 This illustrates one particular embodiment, and other embodiments could include more DNS servers, more selection servers, and more content servers. Furthermore, the terminal could be simultaneously connected to multiple access devices, possibly using different access technologies.

[0048] We now refer to the figure 2 which illustrates the different stages of the access process according to one embodiment of the invention.

[0049] In this embodiment, the selection server 210 is a DNS server that informs terminal 10 about the 50-1 content server to reach.

[0050] During step E1, the user terminal 10 connects to an access device 20. This access device 20, depending on the embodiment, can be an access gateway to a cellular network such as LTE, UMTS, or any other mobile infrastructure, for example, a Packet Data Network Gateway (PDN-GW), a Wi-Fi access device such as an access point, or a fixed network access device such as a Broadband Remote Access Server (BRAS) or a Broadband Network Gateway (BNG). During this connection step E1 to the access device 20, the terminal 10 is configured with an IP address and can also obtain information, including the IP address of the primary DNS server 100 to contact in order to access the name resolution service.

[0051] During this connection step to the access equipment 20, the terminal 10 also receives information about its current location relative to the network topology. If it is a connection to an LTE network, this information will be the Tracking Area (TA) information sent by a mobile network device, enabling the terminal to be located within such a network. If it is a UMTS or GPRS network, the location information will be of the Location Area (LA) and / or Routing Area (RA) type. Any location information or even network identifier obtained by the user terminal of the access network can be used to implement the access process. For the sake of simplicity, the connection step E1 does not show the various successive phases that can occur when a terminal 10 connects to an access device 20.Particularly in the case of an LTE access network, this E1 connection stage can be broken down into radio attachment phases, network access control phases, and a network connection phase involving various LTE architecture components, including eNodeBs, Serving Gateways (S-GWs), Packet Data Network Gateways (PDN-GWs), Mobility Management Entities (MMEs), Home Subscriber Servers (HSSs), and even Policy and Charging Rules Function (PCRFs) and Authentication Authorization Accounting (AAAs) servers. Tracking Area information will be transmitted by the MME in the LTE architecture via messages from the Non-Access Stratum (NAS) layer, which is part of the E1 connection stage described here.Similarly, the connection of terminal 10 to a Wi-Fi, ADSL, or optical access device is reduced to the E1 connection step but encompasses several exchanges between the terminal and the access network equipment. This invention, regardless of the embodiment, assumes that information relating to its location is sent to terminal 10 by an access device 20 during the E1 connection step.

[0052] During step E2, the location information transmitted by the access equipment during step E1 is forwarded to the terminal 10 so that it generates access requests for content containing a location hint based on the location information received from an access equipment 20. One embodiment involves the terminal generating an access request containing the location information received during step E1. Another embodiment involves determining a location hint based on one or more received location hints. If the terminal 10 is simultaneously connected to several different access equipment, for example, Wi-Fi and LTE networks, it will receive multiple location hints from the different access equipment on the networks.In this case, it will be able to generate a location indication based on this location information, by selecting one of these pieces of information to generate the location indication, or by generating an indication based on the different location information received from the access equipment according to the chosen embodiment.

[0053] During step E3-1, the terminal contacts its primary DNS server 100, which in turn queries the authoritative DNS server 120 for the hostname of the content server 50-2. This server can then provide the IP address of the server hosting the content that terminal 10 wishes to access. During step E3-2, the authoritative DNS server 120 returns a response via the primary DNS server 100 to the query transmitted during step E3-1.

[0054] During step E4, terminal 10 sends an access request to a 50-2 content server. In this embodiment, the access request is an HTTP request to a 50-2 HTTP server whose address the terminal obtained via DHCP configuration or during the exchanges in steps E3-1 and E3-2. The access request issued during step E4 includes the location information generated by terminal 10 during step E2 from at least one received location piece of information. During step E5, the 50-2 HTTP server returns a response message with information about the CDN server to contact—for example, in the form of a URL (Universal Resource Locator)—so that terminal 10 can access the requested content.

[0055] In this embodiment, the selection server is a DNS server. This server resolves the name of the CDN server it selected to respond to the request sent by terminal 10 during step 4.

[0056] Based on this information about the CDN server to contact, terminal 10 sends a DNS query during step E6 to the authoritative DNS server 210 of the CDN server indicated in the response message sent during step E5. This DNS query may optionally be sent via terminal 10's primary DNS server 100 and includes the location hint generated by terminal 10. Upon receiving the DNS query, server 210 selects, during step E14, a 50-1 content server close to terminal 10 based on the location hint. During step E7, DNS server 210 returns to terminal 10 the IP address of the 50-1 content server that the terminal must connect to in order to access the content. DNS server 210, having used the location hint passed in the DNS query issued during step E6, selects content server 50-1, which is geographically and / or topologically closest to terminal 10.

[0057] During step E8, terminal 10 requests the 50-1 content server by sending an HTTP access request. In response, during step E9, the 50-1 server transmits the requested content via an HTTP content delivery request to terminal 10.

[0058] We now refer to the figure 3 which illustrates the different stages of the selection process according to another embodiment of the invention. In this embodiment, the selection server 340 is an HTTP server that informs the terminal about the content server 50-1 to access via an HTTP redirection message.

[0059] Steps E1 to E5 are strictly identical to those described for the figure 2During step E11, terminal 10 queries the DNS server 310 of the CDN server whose name it received in the message sent during step E5 by the content server 50-2. During this step E11, the location information is not included in the DNS query sent to the DNS server 310. This information, if included in the DNS query, for example for ease of implementation, will not be interpreted by the DNS server 310, and the latter will not determine a suitable content server. This embodiment differs from the embodiment described in the figure 2Because DNS server 310 does not perform the selection server function and only supports the standard DNS server functions, in response to the DNS query sent by terminal 10 via its local DNS server 100, DNS server 310, which resolves the name of server 340, sends the IP address of server 340 back to terminal 10 in a message during step E12. This message can optionally be sent by the primary DNS server 100 using a caching mechanism. In this case, the message from step E11 did not need to be relayed from server 100 to server 310.

[0060] Upon receiving the DNS message indicating the IP address of the 340 server to contact to access the content, terminal 10 sends an HTTP access request message to the IP address of the 340 selection server during step E13. This HTTP access request includes the location information. Upon receiving the access request, server 340 selects, during step E14, a 50-1 content server close to terminal 10 based on the location information. During step E15, server 340 sends an HTTP redirection message containing a URL indicating to terminal 10 the 50-1 content server from which terminal 10 can access the desired content.

[0061] A DNS resolution step for this URL is necessary (between steps E15 and E8) but is not presented here as a step for ease of reading. Steps E8 and E9 of the figure 3Following on from step E15 described above, are identical to steps E8 and E9 of the figure 2 .

[0062] We now refer to the figure 4 which illustrates the different stages of the selection process according to another embodiment of the invention, in which the user terminal 10 connects successively to two different access networks. In this embodiment, the first stages from stage E1 to stage E9 of the figure 4 , including step E14, are identical to the corresponding steps of the figure 2 and are therefore not described again. In the embodiment described in the figure 4Once the terminal accesses the content hosted on the content server 50-1, terminal 10 connects to another access device 80 and is no longer connected to the access device 20 to which it was previously connected to access the content. Terminal 10 may not have moved and may be geographically in the same location, but it is connected to a different access device. Several reasons can explain this connection to a different access device. Access device 20 may be unavailable, an operator policy may force a connection to a specific network, or terminal 10's configuration may prioritize a connection to access device 80 over access device 20. This can occur in certain configuration options if access device 80 is a Wi-Fi gateway while access device 20 is an LTE network gateway.If the two access devices provide access to networks using different technologies, it is very likely that, firstly, the IP address allocated to terminal 10 will change when it is successively connected to two different access networks, and secondly, the CDN servers may not be the same. The consequence of this change in terminal 10's connection also results in an initial denial of access to the content hosted on server 50-1 if content server 50-1 performs access control based on terminal 10's IP address. Terminal 10 can no longer access the content on server 50-1 after connecting to access device 80, and the content access request sent during step 21 is rejected, resulting in a connection loss between terminal 10 and content server 50-1 during step E22.If the content server 50-1 does not respond, or if the content server returns an access denial message to terminal 10, terminal 10 requests content from the default content server during step E23, either after user intervention or not, in order to restart the application. The IP address of this default content server, in this example content server 50-2, can be obtained after a new query to the global DNS server 120, or it can be stored by terminal 10 or by the primary DNS server 100 during the DNS queries and responses of steps E3-1 and E3-2, respectively.

[0063] During step E24, the 50-2 content server sends information about the CDN server to terminal 10 so that it can access the desired content.

[0064] Using this information, which may consist of a URL providing access to the CDN server hosting the content, as in step E5, terminal 10 queries the selection server 210, which in this embodiment is the authoritative DNS server of the CDN server. In step E25, similarly to step 6, terminal 10 sends a DNS query including the location information from the location information sent by the access device 80 when terminal 10 connected to it, to the authoritative DNS server 210 of the CDN server. Based on the location information, this DNS server 210 selects the 50-1 content server closest to the terminal in step E30 and sends the IP address of this server in step E26.

[0065] To select a 50-1 content server close to the user's terminal, regardless of the access network to which that terminal connects, the DNS 210 server can use a lookup table between location hints from different access networks. For example, in the use case of the figure 4Access devices 20 and 80 transmit location information specific to the access network technology. This can be the TAI (Target Area Identification) information if device 20 is an LTE network device, and the SSID (Signal Service Identifier) ​​if device 80 is a Wi-Fi network device. When DNS server 210 receives a query containing the location information based on the data transmitted by device 80 (specifically, the SSID), it can deduce from its lookup table that the received information corresponds to the information received in the query containing the location information based on the data received from device 20 (the LTE network's TAI). This table can also include, for example, a user terminal identifier or even a session identifier. In the example shown, the server maps the SSID information to the TAI information.Thus, DNS server 210 can select the same content server regardless of whether terminal 10 is connected to access equipment 20 or access equipment 80. This table also allows content servers to be selected based on the location information of a single technology, such as TAI. The table ensures the mapping between location information specific to other technologies, such as Wi-Fi, and the technology information used for selection—the LTE network information in this example. Another advantage of a location information mapping table for a terminal is that it connects to the same content server even if it connects successively to two access networks within the same geographic area. This effectively maintains access contexts, leverages a cache already populated with the content being delivered, and preserves the state of application sessions.This allows for optimal use of CDN and Fog computing in mobile environments (when the user terminal changes access networks) with a gain for the user in latency and for the operator on network costs.

[0066] The following steps, E27 and E28, are identical to steps E8 and E9 described previously. These steps involve terminal 10 accessing the desired content hosted on a content server 50-1 located near the terminal. In this embodiment, the content server selected by the selection server 210 is the same when terminal 10 connects to access equipment 80 as when terminal 10 is connected to access equipment 20. In this embodiment, terminal 10 has not moved far enough to justify changing the content server, and it is logical that the selected content server 50-1 remains the same when terminal 10 changes its connection.

[0067] Information exchanges between the content server 50-2, the local server 50-1 and the access equipment 20 and 80 not shown in this figure, particularly related to access authorizations, allow the content server 50-1 to accept the connection of the terminal 10, whose IP address was allocated when it connected to the access equipment 80.

[0068] This invention thus makes it possible to select common content servers as closely as possible to users across the different access networks to which a terminal is likely to connect in a given environment. It also makes it possible to maintain access to the same content server when the terminal changes access networks during a session, but without changing location, thereby preserving context, such as the terminal's use of an application. In another embodiment, HTTP messages could be transmitted during additional steps, particularly in cases where DNS servers are not selection servers. These messages, in the same way as described in the figure 3 , would be an HTTP request message to the content server, in this case an HTTP server, to which the latter would respond with an HTTP redirection message in accordance with the E13 and E15 request messages of the figure 3 These HTTP servers can also interface with location hint lookup tables as described for the case where the selection server is a DNS server.

[0069] We now refer to the figure 5 which illustrates the functions of a user terminal arranged to accomplish the different steps of the content access process according to a particular implementation mode.

[0070] For example, the terminal 10 includes a processing unit 106, equipped for example with a microprocessor µP, and controlled by a computer program 105, stored in a memory 107. At initialization, the code instructions of the computer program 105 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 106. The terminal includes a message sending interface 11 and a message receiving interface 12.

[0071] Such a user terminal also includes the following modules: a module 101 capable of processing a message received from the access equipment containing information relating to the location of said user terminal; a generator 104 of a content access request containing a location indication obtained on the basis of the information extracted from the message; a module 102 capable of processing a message sending the generated access request to a server 110 capable of selecting a content server; a module 109 capable of processing a message containing an address of the selected content server.

[0072] This user terminal could, for example, be a mobile terminal. This mobile terminal can connect to access networks of the type 802.11, GPRS, UMTS (Universal Mobile Telecommunications Systems), HSPA (High Speed ​​Packet Access), LTE or any other network based on WLAN (Wireless Local Area Network) or cellular technology, and can access content hosted on a server close to its location, thus reducing the time and cost of accessing the content from this terminal.

[0073] We now refer to the figure 6 which illustrates the functions of a selection server arranged to accomplish the different stages of the selection process according to a particular embodiment.

[0074] For example, the selection server includes a processing unit 1130, equipped for example with a microprocessor µP, and controlled by a computer program 1100, stored in a memory 1120. At initialization, the code instructions of the computer program 1100 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 1130.

[0075] Such a selection server includes the following modules: a receiver 1101 of a message requesting access to content from a user terminal 10, including an indication of the location of said user terminal; a content server selection module 1104 50-1 based on the location indication; a message sender 1102 of a message including an address of said content server to the user terminal 10

[0076] Optionally, the selection server also includes a lookup table (1106) where location information relating to at least two types of access networks is recorded, among other things.

[0077] A selection server could, for example, be a DNS server or an HTTP server, and could advantageously implement the selection process in such a way as to return to the user's terminal the information needed to connect to a content server—hosting the content requested by the user's terminal—located near the user's terminal. The location information can thus be used by the selection server as an additional criterion for selecting a content server, in cases where the server already uses other criteria for selecting content servers, typically for load balancing.

[0078] The invention is not limited to the above-described and illustrated embodiments and covers other embodiments.

[0079] The address of the content server returned to the terminal may be an IP address, of type IPv4 or IPv6, or it may be any other means allowing the terminal to reach the content server indicated in the response sent by the selection server, including a URL, or even a name of type for example FQDN (in English Fully Qualified Domain Name).

[0080] Furthermore, in the presented embodiments, the selection server is a DNS server or an HTTP server, but it is also possible for the selection server to be an FTP (File Transfer Protocol) server if the terminal opens an FTP connection to a content server, or any other type of server. In particular, in other deployment methods, the selection server can be a dedicated server whose sole purpose is to select a content server located near the user. To select a content server near the user, the selection server could advantageously use a database from which it can identify the appropriate content server based on at least one location information received from a terminal.This database will be able to incorporate criteria other than location indications to implement a selection of content servers taking into account different criteria including at least one location indication.

[0081] A selection server database, configured to store content servers and location information received in access request messages, can itself be shared among different selection servers to limit the number of databases and allow the communication network's selection servers to have a single database or at least a limited number of databases. This database, as specified for the lookup table, can incorporate location information from different access networks, both fixed and mobile, so that the terminal, regardless of the access network to which it is connected, can benefit from a nearby content server.

Claims

1. Method implemented by a selection server (110) comprising: - receiving, from a user terminal (10), a content access request message containing a location indication indicating the location of said user terminal, said location indication being a Wi-Fi access identifier of said user terminal, said identifier being an SSID parameter, SSID being the abbreviation of Service Set IDentifier, - selecting, from a set of content servers, the content server (50-1) closest to the user terminal according to the location indication, said selection being made by the selection server by means of consultation of a lookup table containing a correspondence between location indications of SSID type and location indications of TA type, TA being the abbreviation of Tracking Area, and by means in addition of a correspondence between the location indications of TA type and content servers, - and sending a message containing an address of said selected content server to the user terminal (10).

2. Method according to Claim 1, wherein the content access request is an HTTP request, HTTP being the abbreviation of HyperText Transfer Protocol.

3. Method according to Claim 1, wherein the selection server is a DNS server, DNS being the abbreviation of Domain Name Server.

4. Method according to any one of Claims 1 to 3, further comprising the following steps implemented by the user terminal, said user terminal being connected to an equipment (20) of a Wi-Fi access network (60): - receiving at least one message from the equipment, the at least one message containing location-related information relating to the location of said user terminal, the location-related information being an SSID parameter, - generating the content access request, it containing the location indication obtained based on the information extracted from the message, - sending said generated request to the selection server, - receiving the message containing the address of the selected content server.

5. Selection server comprising the following modules: - a receiver (1101) configured to receive, from a user terminal (10), a content access request message containing a location indication indicating the location of said user terminal, said location indication being a Wi-Fi access identifier of said user terminal, said identifier being an SSID parameter, SSID being the abbreviation of Service Set IDentifier, - a selection module (1104), configured to select, from a set of servers, the content server (50-1) closest to the user terminal according to the location indication, said selection being made by the selection server by means of consultation of a lookup table containing a correspondence between location indications of SSID type and location indications of TA type, TA being the abbreviation of Tracking Area, and by means in addition of a correspondence between the location indications of TA type and content servers, - a sender (1102), configured to send a message containing an address of said selected content server to the user terminal (10).

6. Selection server according to Claim 5, wherein the content access request is an HTTP request, HTTP being the abbreviation of HyperText Transfer Protocol.

7. Selection server according to Claim 5, wherein the selection server is a DNS server, DNS being the abbreviation of Domain Name Server.

8. Content access system comprising a selection server according to any one of Claims 5 to 7 and a user terminal (10), said user terminal (10) being connected to an equipment (20) of a Wi-Fi access network (60), the terminal comprising the following modules: - a receiver, configured to receive a message from the equipment, the message containing location-related information relating to the location of said user terminal (10), the location-related information being an SSID parameter, - a generator, configured to generate the content access request, it containing the location indication obtained based on the information extracted from the message, - a sender, configured to send said generated access request to the selection server, - a receiver, configured to receive a message containing the address of the selected content server.

9. Computer program comprising instructions that, when the program is executed by a selection server, cause the latter to implement the steps of the method according to any one of Claims 1 to 3.

10. Computer program according to Claim 9, further comprising instructions that, when the program is executed by a system comprising a selection server and a user terminal, cause it to implement the steps of the method according to Claim 4.

11. Recording medium on which the code instructions of a computer program according to Claim 9 are stored.

12. Recording medium on which the code instructions of a computer program according to Claim 10 are stored.