Anycast-based content delivery with mobility support

A system may identify a first intermediary device responsible for delivering an anycast stream in a first service area associated with a first foreign agent, identify an active anycast stream, identify a second foreign agent associated with a mobility event, identify a second intermediary device responsible for delivering the active anycast stream in a second service area associated with the second foreign agent, receive an indication that the second intermediary device is different from the first intermediary device, establish a content tunnel between the first foreign agent and the second foreign agent, and route communications associated with the active anycast stream over the content tunnel.

BACKGROUND

Content delivery networks deliver content to end user devices using intermediary devices, such as cache servers or proxy servers. Different intermediary devices may be used to deliver content to different end user devices, such as end user devices located in different service areas. Often, content delivery networks aim to utilize the most efficient intermediary device when delivering content to end user devices, such as the intermediary device that is closest to the end user device.

Anycast is one of the approaches that can be used by content delivery networks to deliver content through the most appropriate intermediary device. Anycast is a network addressing and routing technique in which traffic is routed to the most appropriate node in a group of potential nodes identified by the same address, such as an Internet Protocol (“IP”) address.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Content delivery networks often utilize anycast addressing to route content streams through different intermediary devices depending on the service area of an end user device receiving the content stream. This may cause service disruptions to the content stream when an end user device moves from one service area to another service area and the content delivery network attempts to route communications associated with the content stream to and/or from a different intermediary device midstream.

Implementations described herein may prevent anycast content stream service disruptions associated with end user device mobility. This may be achieved by maintaining a route to and/or from an intermediary device when an end user device leaves a service area serviced by the intermediary device.

Anycast content, and anycast streams, as used herein, may refer to content and/or streams being routed using anycast addressing and routing techniques. Anycast content delivery and/or anycast stream delivery may include sending communications (e.g., packets and/or other information associated with anycast content and/or an anycast stream) uni-directionally or bi-directionally between devices. For example, anycast content and/or stream delivery may include sending communications from an intermediary device to a mobile device, and/or sending communications from a mobile device to an intermediary device. In one example, packets carrying a content request may be transmitted from a mobile device to an intermediary device. Packets carrying the requested content may be transmitted from the intermediary device to the mobile device. Packets acknowledging receipt of the packets carrying the requested content may be transmitted from the mobile device to the intermediary device.

FIGS. 1A and 1Bare diagrams that illustrate an overview100of an implementation described herein. As illustrated inFIG. 1A, mobile device110may be located in a service area (e.g., departure service area190) serviced by departure intermediary device120and a set of departure foreign agents130-1through130-N (N≥1). Departure intermediary device120may be associated with an anycast address, such as the illustrated anycast address, “192.168.0.1.” Mobile device110may receive anycast content transmitted over content delivery network140. The anycast content may be delivered via departure intermediary device120and departure foreign agents130, as illustrated by anycast stream170.

As illustrated inFIG. 1B, mobile device110may move to a different service area (e.g., arrival service area195) serviced by arrival intermediary device150and a set of arrival foreign agents160-1through160-M (M≥1). Arrival intermediary device150may be associated with the same anycast address as departure intermediary device120, as illustrated (e.g., “192.168.0.1”). The movement of mobile device110from departure service area190to arrival service area195may normally cause communications from mobile device110to the anycast address to be delivered to arrival intermediary device150(rather than departure intermediary device120), causing a service disruption. However, content tunnel180may be established to aid in delivering communications associated with anycast stream170from mobile device110to departure intermediary device120via arrival foreign agents160, content tunnel180, and departure foreign agents130. Additionally, or alternatively, content tunnel180may aid in delivering communications associated with anycast stream170from departure intermediary device120to mobile device110via departure foreign agents130, content tunnel180, and arrival foreign agents160. Delivering anycast content in this manner may prevent service disruptions to anycast streams.

FIG. 2is a diagram of an example environment200in which systems and/or methods described herein may be implemented. Environment200may include a mobile device210, a set of departure foreign agents220-1through220-N (N≥1) (hereinafter referred to individually as “DFA220” and collectively as “DFAs220”), a set of arrival foreign agents230-1through230-M (M≥1) (hereinafter referred to individually as “AFA230” and collectively as “AFAs230”), a departure intermediary device240(hereinafter referred to as “DID240”), an arrival intermediary device250(hereinafter referred to as “AID250”), a home agent260(hereinafter referred to as “HA260”), a content delivery network service processor270(hereinafter referred to as “CDN service processor270”), a content delivery network controller280(hereinafter referred to as “CDN controller280”), a content provider290, and a content delivery network295(hereinafter referred to as “CDN295”).

The number of devices and networks illustrated inFIG. 2is provided for explanatory purposes. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than are illustrated inFIG. 2. Furthermore, two or more of the devices of environment200may be implemented within a single device, or a single device may be implemented as multiple, distributed devices. Additionally, one or more of the devices of environment200may perform one or more functions described as being performed by another one or more of the devices of environment200. Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Mobile device210may include any computation or communication device, such as a wireless mobile communication device, that is capable of communicating with a network (e.g., CDN295) and/or other devices (e.g., FAs220/230, HA260, etc.). For example, mobile device210may include a radiotelephone, a personal communications system (“PCS”) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (“PDA”) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a smart phone, a laptop computer, a tablet computer, a camera, a personal gaming system, a mobile code reader, and/or another type of mobile computation or communication device. Mobile device210may send traffic to and/or receive traffic from any of the devices and/or networks illustrated in environment200, as well as other devices and/or networks (not illustrated).

DFAs220and AFAs230(hereinafter referred to individually as “FA220/230” and collectively as “FAs220/230”) may include one or more computation or communication devices that gather, process, search, store, and/or provide information in a manner described herein. FAs220/230may include one or more data processing and/or traffic transfer devices, such as a computer, a server (e.g., a proxy server, a cache server, a signaling server, etc.), a router, a bridge, a gateway, a modem, a firewall, a switch, a network interface card (“NIC”), a hub, an optical add-drop multiplexer (“OADM”), or some other device capable of processing and/or transferring traffic. FAs220/230may send traffic to and/or receive traffic from any of the devices and/or networks illustrated in environment200, as well as other devices and/or networks (not illustrated).

DFAs220may transfer traffic to and/or receive traffic from devices located in a different service area than AFAs230. For example, mobile device210may depart a service area associated with DFAs220and may enter or arrive at a service area associated with AFAs230. FAs220/230may communicate with wireless network base stations to detect movement of mobile devices210from one service area to another service area. FAs220/230may keep track of the mobile devices210in their service area (e.g., via mobile device registration, Mobile IP, Regional Registration Mobile IP, etc.). FAs220/230may perform operations associated with mobility management and/or handing off mobile device210(e.g., from DFAs220to AFAs230). An FA220/230may tunnel traffic for delivery to mobile device210when mobile device210is outside of a service area associated with FA220/230.

DID240and AID250(hereinafter referred to individually as “intermediary device240/250” and collectively as “intermediary devices240/250”) may include one or more computation or communication devices that gather, process, search, store, and/or provide information in a manner described herein. Intermediary devices240/250may include one or more data processing and/or traffic transfer devices, such as a computer, a server (e.g., a proxy server, a cache server, etc.), a router, a bridge, a gateway, a modem, a firewall, a switch, a NIC, a hub, an OADM, or some other device capable of processing and/or transferring traffic. For example, intermediary devices240/250may include a caching appliance that stores content for delivery over CDN295. Intermediary devices240/250may receive content requests and/or deliver content in response to a content request. Intermediary devices240/250may send traffic to and/or receive traffic from any of the devices and/or networks illustrated in environment200, as well as other devices and/or networks (not illustrated).

Intermediary devices240/250may gather, process, search, store, and/or provide anycast content, such as an anycast stream (e.g., an anycast audio stream, an anycast video stream, an anycast audiovisual stream, etc.). Intermediary devices240/250may be associated with an anycast address, which may be a network address (e.g., anycast IP address 192.168.0.1, as illustrated). Mobile device210may request anycast content using an anycast address. The requested anycast content may be delivered by intermediary devices240/250, depending on the service area in which mobile device210is located.

HA260may include one or more computation or communication devices that gather, process, search, store, and/or provide information in a manner described herein. HA260may include one or more data processing and/or traffic transfer devices, such as a computer, a server (e.g., a proxy server, a cache server, etc.), a router, a bridge, a gateway, a modem, a firewall, a switch, a NIC, a hub, an OADM, or some other device capable of processing and/or transferring traffic. HA260may send traffic to and/or receive traffic from any of the devices and/or networks illustrated in environment200, as well as other devices and/or networks (not illustrated). HA260may service a particular service area, such as a home service area of mobile device210. HA260may tunnel traffic for delivery to mobile device210when mobile device210is outside of the home region (e.g., via FAs220/230). HA260may maintain location and/or service area information associated with a current location of mobile device210. For example, HA260may keep track of which FA220/230is currently providing service to mobile device210.

CDN service processor270may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. CDN service processor270may receive content requests and assign devices to deliver requested content. CDN service processor270may receive content requests, such as a request for anycast content, from mobile device210over CDN295. CDN service processor270may assign an intermediary device240/250to deliver the requested content, based on a service area (e.g. a particular geographic region) of mobile device210. CDN service processor270may assign content delivery to an intermediary device240/250that is closest to mobile device210, and/or may assign content delivery to an intermediary device240/250that is able to most efficiently deliver content to mobile device210.

CDN controller280may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner described herein. CDN controller280may gather, process, search, store, and/or provide information about anycast addresses associated with anycast streams. CDN controller280may send traffic to and/or receive traffic from any of the devices and/or networks illustrated in environment200, as well as other devices and/or networks (not illustrated). For example, CDN controller280may send anycast address information to mobile device210and/or FAs220/230.

In some implementations, CDN controller280may receive queries from FAs220/230that request information identifying active anycast addresses being used in a service area associated with the requesting FA220/230. CDN controller280may send information identifying active anycast addresses associated with a particular FA220/230to the particular FA220/230.

While shown as being integrated into and internal to CDN service processor270, CDN controller280may be implemented separately from and external to CDN service processor270.

Content provider290may include any type or form of content provider. For example, content provider290may include a website host (e.g., a provider of one or more websites, such as websites located at www.verizon.com, www.yahoo.com, www.nbc.com, etc.). Additionally, or alternatively, content provider290may include free television broadcast providers (e.g., local broadcast providers, such as NBC, CBS, ABC, and/or Fox), for-pay television broadcast providers (e.g., TNT, ESPN, HBO, Cinemax, CNN, etc.), and/or Internet-based content providers (e.g., YouTube, Vimeo, Netflix, Hulu, Veoh, etc.) that stream content from web sites and/or permit content to be downloaded (e.g., via progressive download, etc.). Content provider290may include on-demand content providers (e.g., video on demand providers, pay per view providers, etc.).

CDN295may include one or more wired and/or wireless networks. For example, CDN295may include a cellular network, a public land mobile network (“PLMN”), a second generation (2G) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, and/or another network. Additionally, or alternatively, CDN295may include a wide area network (“WAN”), a metropolitan area network (“MAN”), a telephone network (e.g., the Public Switched Telephone Network (“PSTN”)), an ad hoc network, an intranet, a fiber optic-based network (e.g., “FiOS”), and/or a combination of these or other types of networks.

FIG. 3is a diagram of example structural components of a device300. Device300may correspond to mobile device210, FAs220/230, intermediary devices240/250, HA260, CDN service processor270, CDN controller280, and/or content provider290. Additionally, or alternatively, each of mobile device210, FAs220/230, intermediary devices240/250, HA260, CDN service processor270, CDN controller280, and/or content provider290may include one or more devices300and/or one or more components of device300.

Device300may include a bus310, a processor320, a memory330, an input component340, an output component350, and a communication interface360. In some implementations, device300may include additional components, fewer components, different components, or differently arranged components than illustrated inFIG. 3.

Bus310may include a path that permits communication among the components of device300. Processor320may include a processor, a microprocessor, and/or any processing logic (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that may interpret and execute instructions. Memory330may include a random access memory (RAM), a read only memory (ROM), or any type of dynamic or static storage device (e.g., a flash, magnetic, or optical memory) that may store information and/or instructions for use by processor320.

Input component340may include any mechanism that permits a user to input information to device300(e.g., a keyboard, a keypad, a mouse, a button, a switch, etc.). Output component350may include any mechanism that outputs information (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface360may include any transceiver-like mechanism, such as a transceiver and/or a separate receiver and transmitter, that enables device300to communicate with other devices and/or systems, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, communication interface360may include a mechanism for communicating with another device and/or system via a network, such as CDN295. Additionally, or alternatively, communication interface360may be a logical component that includes input and output ports, input and output systems, and/or other input and output components that facilitate the communication of data to and/or from other devices, such as an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a USB interface, or the like.

As described herein, device300may perform certain operations relating to mobility management for anycast content delivery. Device300may perform these operations in response to processor320executing software instructions contained in a computer-readable medium, such as memory330. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single storage device or space spread across multiple storage devices.

Software instructions may be read into memory330from another computer-readable medium or from another device via communication interface360. Software instructions stored in memory330may cause processor320to perform processes that are described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processed described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

FIG. 4is a diagram of example functional components of a device400. In some implementations, device400may correspond to FAs220/230. As illustrated, device400may include an anycast address identifier410and an intermediary device identifier420. Each of functional components410-420may be implemented using one or more components shown inFIG. 3. FAs220/230may individually include all of the components depicted inFIG. 4, or the components depicted inFIG. 4may be distributed singularly or duplicatively in any manner between the devices illustrated inFIG. 2. In some implementations, FAs220/230may include other functional components (not shown) that aid in mobility management for anycast content delivery.

Anycast address identifier410may receive and/or transmit anycast address data. Anycast address identifier410may identify one or more devices (e.g., CDN controller280) that may be queried in order to gather anycast address data. Anycast address data may include information associated with an anycast stream, including an anycast address (e.g., a network address, an IP address, etc.) associated with an anycast stream, active anycast addresses (e.g., anycast addresses currently in use, anycast addresses scheduled to be used, etc.), a CDN provider that provides anycast content associated with anycast addresses, and/or a CDN controller280that monitors anycast addresses. Anycast address identifier410may query and/or receive information from another device on a periodic basis, so that a list of active anycast addresses is kept up-to-date. Anycast address identifier410may store the anycast address data.

Anycast address identifier410may identify active anycast addresses associated with a particular FA220/230. Active anycast addresses may include an address that identifies an active anycast stream. Active anycast streams may include registered anycast streams, anycast streams that are being used, anycast streams associated with an anycast address that is being used, anycast streams that are being transmitted and/or received by a particular device (e.g., mobile device210, FAs220/230, intermediary devices240/250), anycast streams that are actively being transmitted and/or received, and/or anycast streams that are expected to be transmitted and/or received during a particular time period. Additionally, or alternatively, anycast address identifier410may identify active anycast streams associated with a particular service area, routing domain, and/or FA220/230. For example, anycast address identifier410may identify anycast stream being transmitted and/or received in a service area associated with a particular FA220/230.

FIG. 5is a diagram of an example data structure500that stores information associated with anycast addresses. Data structure500may be stored in a memory device (e.g., RAM, hard disk, etc.) associated with one or more components shown inFIGS. 2-4. For example, data structure500may be stored by mobile device210, FAs220/230, HA260, CDN controller280, memory330, anycast address identifier410, etc.

Data structure500may include a collection of fields, such as an anycast address field510, a CDN provider identifier (“ID”) field520, a CDN controller ID field530, and a time until next update field540. Data structure500includes fields510-540for explanatory purposes. In practice, data structure500may include additional fields, fewer fields, different fields, or differently arranged fields than are described with respect to data structure500.

Anycast address field510may store information that identifies an address associated with an anycast stream. For example, anycast address field510may store a network address (e.g., an IP address) from which anycast content can be accessed. The information stored in anycast address field510may be updated periodically so that only active anycast addresses are stored in data structure500.

CDN provider ID field520may store information that identifies a CDN provider that provides anycast content associated with the anycast address identified by anycast address field510. For example, information stored in CDN provider ID field520may include a name of a content provider providing anycast content, such as content provider290.

CDN controller ID field530may store information that identifies a CDN controller280that monitors the anycast address identified by anycast address field510. For example, information stored in CDN controller field530may include a network address (e.g., an IP address) and/or a host name of a CDN controller280.

Time until next update field540may store information that indicates when the information associated with the anycast address identified by anycast address field510should be updated. For example, time until next update field540may indicate an amount of time remaining until anycast address identifier410sends a query to and/or receives information from another device (e.g., CDN controller280) in order to update fields510-530of data structure500.

Information for a single anycast address is conceptually represented as a row in data structure500. For example, the first row in data structure500corresponds to an anycast address of “192.168.101.1,” which has a CDN provider ID of “CDN Provider A,” a CDN controller ID of “ccont1.cdnprovda.ny.net,” and a time until next update of “43:33,” corresponding to 43 minutes and 33 seconds. This row indicates that in 43 minutes and 33 seconds, anycast IP identifier410may send a query to and/or receive information from CDN controller280identified as “ccont1.cdnprovda.ny.net” in order to determine any active anycast addresses associated with this CDN controller280, as well as the name of the CDN provider providing the content associated with those active anycast addresses.

Returning toFIG. 4, intermediary device identifier420may receive and/or transmit intermediary device data. In some implementations, intermediary device identifier420may query another device (e.g., intermediary devices240/250) to request intermediary device data, and/or may receive intermediary device data from another device (e.g., intermediary devices240/250). Intermediary device data may identify an intermediary device240/250associated with an anycast address, such as an active anycast address. Additionally, or alternatively, intermediary device data may identify an intermediary device240/250responsible for delivering a particular anycast stream in a particular service area and/or routing domain, such as a service area associated with a particular FA220/230. Intermediary device identifier420may identify an intermediary device240/250by sending an identification query to an anycast address. Anycast routing may direct the query to the intermediary device240/250associated with the querying intermediary device identifier420(and, e.g., the querying FA220/230).

Intermediary device identifier420may query and/or receive information from another device on a periodic basis, so that a list of intermediary devices240/250associated with active anycast addresses is kept up-to-date. Intermediary device identifier420may store the intermediary device data.

FIG. 6is a diagram of an example data structure600that stores information associated with intermediary devices. Data structure600may be stored in a memory device (e.g., RAM, hard disk, etc.) associated with one or more components shown inFIGS. 2-4. For example, data structure600may be stored by mobile device210, FAs220/230, HA260, CDN controller280, memory330, intermediary device identifier420, etc.

Data structure600may include a collection of fields, such as a foreign agent ID field610, an anycast address field620, and an intermediary device ID field630. Data structure600includes fields610-630for explanatory purposes. In practice, data structure600may include additional fields, fewer fields, different fields, or differently arranged fields than are described with respect to data structure600.

Foreign agent ID field610may store information that identifies a foreign agent, such as FAs220/230. FAs220/230may be identified in any manner, such as by an identification number, an indication of whether FA220/230is a DFA220or an AFA230for a particular mobile device210, a host name, a network address, etc.

Anycast address field620may store information that identifies an address associated with an anycast stream, as described elsewhere herein with respect toFIG. 5and anycast address field510. Anycast address field620may store information identifying active anycast addresses that may be accessible via FA220/230identified by foreign agent ID field610.

Intermediary device ID field630may store information that identifies an intermediary device (e.g., intermediary devices240/250) responsible for processing, storing, transmitting, and/or delivering anycast content associated with the anycast address identified by anycast address field620via the FA220/230identified by foreign agent ID field610. For example, information stored in intermediary device ID field630may include a network address and/or a host name of an intermediary device, such as intermediary devices240/250.

Information for a single anycast address is conceptually represented as a row in data structure600. For example, the first row in data structure600corresponds to a foreign agent ID of “DFA-1,” an anycast address of “192.168.101.1,” and an intermediary device ID of “intdev1.cdnprovda.nj.net.” This row indicates that the intermediary device240/250associated with anycast address 192.168.101.1 is identified by intermediary device ID “intdev1.cdnprovda.nj.net” when mobile device210is receiving content routed through the FA220/230identified by the foreign agent ID of “DFA-1.”

Different FAs220/230may have different intermediary devices240/250associated with the same anycast address. For example, the first row in data structure600indicates that DFA220, identified as “DFA-1,” utilizes the intermediary device240/250identified as “intdev1.cdnprovda.nj.net” to deliver the anycast stream associated with anycast address “192.168.101.1.” The second row in data structure600indicates that AFA230, identified as “AFA-1,” utilizes a different intermediary device240/250, identified as “intdev2.cdnprovda.nj.net,” to deliver the anycast stream associated with the same anycast address of “192.168.101.1.”

FIG. 7is a diagram of an example process700for mapping anycast addresses to intermediary devices. In some implementations, one or more of the process blocks ofFIG. 7may be performed by one or more components of FAs220/230, and/or another device, such as mobile device210, HA260, CDN service processor270, CDN controller280, etc.

Process700may include detecting an update event (block710). In some implementations, anycast address identifier410may detect an update event. For example, anycast address identifier410may determine that a particular period of time has passed since the memory (e.g., data structure500and/or data structure600), which stores information associated with anycast addresses and/or intermediary devices, has been updated. The particular period of time may be associated with information stored in a memory, such as the time until the next update stored in next update field540of data structure500.

Process700may include sending an anycast address identification query (block720). In some implementations, anycast address identifier410may send an anycast address identification query to another device, such as CDN service processor270, CDN controller280, etc. The anycast address identification query may request a list of active anycast addresses, such as active anycast addresses associated with one or more CDN controllers280and/or FAs220/230.

Process700may include receiving an anycast address identification response (block730). In some implementations, anycast address identifier410may receive an anycast address identification response from another device, such as CDN service processor270, CDN controller280, etc. The anycast address identification response may include a list of active anycast addresses, such as active anycast addresses associated with one or more CDN controllers280and/or FAs220/230.

Process700may include sending an intermediary device identification query for active anycast addresses (block740). In some implementations, intermediary device identifier420may send an intermediary device identification query to another device, such as intermediary devices240/250. Additionally, or alternatively, intermediary device identifier420may send the query to any device identified by the anycast address, requesting identification of the device. Intermediary device identifier420may send an intermediary device identification query for each active anycast address.

Process700may include receiving an intermediary device identification response (block750). In some implementations, intermediary device identifier420may receive an intermediary device identification response from another device, such as intermediary devices240/250. Additionally, or alternatively, intermediary device identifier420may receive the response from any device identified by the anycast address, and the response may identify the device. Intermediary device identifier420may receive an intermediary device identification response for each active anycast address.

Process700may include mapping active anycast addresses to intermediary devices (block760). In some implementations, intermediary device identifier420may map each active anycast address to an intermediary device240/250responsible for delivering the anycast stream associated with the anycast address (e.g., intermediary devices240/250). The intermediary device240/250may be different for different FAs220/230. For example, DID240may be associated with DFAs220, and AID250may be associated with AFAs230. In some implementations, intermediary device identifier420may map each FA220/230in a particular service area to the particular intermediary devices240/250responsible for delivering a particular anycast stream in that particular service area.

FIG. 8is a diagram of example functional components of a device800. In some implementations, device800may correspond to mobile device210. As illustrated, device800may include an active stream tracker810, a mobility event detector820, and an impacted stream identifier830. Each of functional components810-830may be implemented using one or more components shown inFIG. 3. Mobile device210may individually include all of the components depicted inFIG. 8, or the components depicted inFIG. 8may be distributed singularly or duplicatively in any manner between the devices illustrated inFIG. 2. In some implementations, mobile device210may include other functional components (not shown) that aid in mobility management for anycast content delivery.

Active stream tracker810may track active anycast streams associated with mobile device210. Active stream tracker810may receive stream ID data that identifies a particular anycast stream. Stream ID data may identify a port receiving the anycast stream on mobile device210, a port transmitting the anycast stream from a device in the content delivery network, a network address of mobile device210receiving the anycast stream, a network address of a device in the content delivery network transmitting the anycast stream, and/or any combination of source and/or destination network addresses, ports, and/or other fields in a packet hearder that may be used to identify an anycast stream.

FIG. 9is a diagram of an example process900for mapping active anycast streams to intermediary devices responsible for delivering the active anycast streams. In some implementations, one or more of the process blocks ofFIG. 9may be performed by one or more components of mobile device210and/or another device, such as FAs220/230, HA260, CDN service processor270, CDN controller280, etc.

Process900may include detecting an active anycast stream (block910). In some implementations, active stream tracker810may detect an anycast stream that is being received by mobile device210. Active stream tracker810may automatically detect that a new anycast stream is being received, and/or active stream tracker810may periodically check to determine whether a new anycast stream is being received.

Process900may include sending a mapping request for an active anycast stream (block920). In some implementations, active stream tracker810may send a request to map an active anycast stream to an intermediary device240/250. In some implementations, active stream tracker810may send the mapping request to another component and/or device, such as intermediary device identifier420and/or FAs220/230. Intermediary device identifier420and/or FAs220/230may consult a memory (e.g., data structure600) to determine the intermediary device240/250associated with the active anycast stream. Additionally, or alternatively, intermediary device identifier420and/or FAs220/230may initiate a process to map the active anycast stream to an intermediary device240/250(e.g., via process700). Additionally, or alternatively, active stream tracker810may directly consult a memory (e.g., data structure600) to determine an intermediary device240/250that corresponds to the active anycast stream.

Process900may include receiving a mapping response for an active anycast stream (block930). In some implementations, active stream tracker810may receive a mapping response that identifies an intermediary device240/250responsible for delivering the active anycast stream. In some implementations, active stream tracker810may receive the mapping response from another component and/or device, such as intermediary device identifier420and/or FAs220/230, as described above with respect to block920.

Process900may include mapping an active anycast stream to an intermediary device (block940). In some implementations, active stream tracker810may update a mapping memory with information identifying active anycast streams and their associated intermediary devices240/250(e.g., using an intermediary device ID). In addition to adding active anycast streams to the mapping memory, active stream tracker810may remove inactive anycast streams from the mapping memory. Active stream tracker810may automatically detect that an anycast stream is no longer being received, and/or active stream tracker810may periodically check to determine whether an anycast stream is no longer being received.

FIG. 10is a diagram of an example data structure1000that stores information associated with active anycast streams. Data structure1000may be stored in a memory device (e.g., RAM, hard disk, etc.) associated with one or more components shown inFIGS. 2-4. For example, data structure1000may be stored by mobile device210, FAs220/230, HA260, CDN controller280, etc.

Data structure1000may include a collection of fields, such as a stream number field1010, a stream ID data field1020, an anycast address field1030, and an intermediary device ID field1040. Data structure1000includes fields1010-1040for explanatory purposes. In practice, data structure1000may include additional fields, fewer fields, different fields, or differently arranged fields than are described with respect to data structure1000.

Stream identifier field1010may store information that identifies an active anycast stream. For example, stream number field may store a character string used to identify an active anycast stream.

Stream ID data field1020may store source and/or destination information associated with the active anycast stream identified by the stream identifier in stream identifier field1010. For example, stream ID data field1020may store information that identifies a port receiving the active anycast stream on mobile device210(“MD Port”), a port transmitting the active anycast stream from a device in the content delivery network (“CDN Port”), a network address of mobile device210receiving the active anycast stream (“MD IP”), a network address of a device in the content delivery network transmitting the active anycast stream (“CDN IP”), and/or any combination of source and/or destination network addresses, ports, and/or other fields in a packet header that may be used to identify an active anycast stream.

Anycast address field1030may store information that identifies an address associated with an anycast stream, as described elsewhere herein with respect toFIG. 5and anycast address field510. For example, anycast address field1030may store information identifying a network address for the intermediary device240/250associated with the active anycast stream identified by the stream identifier in stream identifier field1010.

Intermediary device ID field1040may store information that identifies an intermediary device240/250that aids in delivering the active anycast stream identified by the stream identifier in stream identifier field1010. For example, intermediary device ID field1040may store a host name and/or network address of an intermediary device240/250.

Information for a single active anycast stream is conceptually represented as a row in data structure1000. For example, the first row in data structure1000corresponds to an active anycast stream with a stream identifier of “00191,” stream ID data of “MD Port=23001, CDN Port=80, MD IP=12.12.12.12, CDN IP=192.168.101.1,” an anycast address of “192.168.101.1,” and an intermediary device ID of “intdev1.cdnprovda.nj.net.” This row indicates that the active anycast stream identified by anycast address 192.168.101.1, MD Port 23001, CDN Port 80, MD IP 12.12.12.12, and CDN IP 192.168.101.1, has been given a stream identifier of 00191, and is associated with an intermediary device240/250with a host name of “intdev1.cdnprovda.nj.net.”

Returning toFIG. 8, mobility event detector820may detect mobility events. A mobility event may be a pending and/or completed transition by mobile device210from one service area (e.g., serviced by DFAs220and DID240) to another service area (e.g., serviced by AFAs230and AID250). In some implementations, mobility event detector820may detect a mobility event when mobile device210approaches, meets, and/or passes a border between two service areas. Additionally, or alternatively, mobility event detector820may detect the presence of a neighboring service area. In some implementations, mobility event detector820may detect mobility events using a physical layer of a device and/or an IP layer of a device.

Mobility event detector820may detect devices associated with a mobility event, such as FAs220/230and/or intermediary devices240/250. In some implementations, mobility event detector820may detect a mobility event by detecting signals associated with more than one FA220/230, more than one intermediary device240/250, and/or more than one wireless network base station.

In some implementations, mobility event detector820may detect a mobility event when mobile device210is about to or has already switched from one wireless network technology type to another wireless network technology type. Wireless network technology types may include Wi-Fi, Worldwide Interoperability for Microwave Access (“WiMAX”), 2G technology, 3G technology, 4G technology, 5G technology, Long Term Evolution (“LTE”) technology, etc.

In some implementations, mobility event detector820may detect a mobility event based on protocols supporting mobility management. For example, mobility event detector820may detect a Mobile IP registration request and/or a Mobile IP registration response.

Impacted stream identifier830may identify active anycast streams that are impacted by a mobility event. Impacted stream identifier830may identify an FA220/230, and/or an intermediary device240/250associated with a mobility event and an active anycast stream. Impacted stream identifier830may compare the intermediary device240/250associated with an active anycast stream in the departure service area (e.g., DID240) to the intermediary device240/250associated with an active anycast stream in the arrival service area (e.g., AID250). Impacted stream identifier830may determine that the active anycast stream is impacted by the mobility event when the intermediary devices240/250associated with the active anycast stream in the departure service area and the intermediary devices240/250associated with the active anycast stream in the arrival service area are different.

FIG. 11is a diagram of an example data structure1100that stores information associated with anycast streams impacted by a mobility event. Data structure1100may be stored in a memory device (e.g., RAM, hard disk, etc.) associated with one or more components shown inFIGS. 2-4. For example, data structure1100may be stored by mobile device210, FAs220/230, HA260, CDN controller280, etc.

Data structure1100may include a collection of fields, such as a stream number field1110, an anycast address field1120, a departure intermediary device ID field1130, an arrival intermediary device ID field1140, and an impacted stream indicator field1150. Data structure1100includes fields1110-1150for explanatory purposes. In practice, data structure1100may include additional fields, fewer fields, different fields, or differently arranged fields than are described with respect to data structure1100.

Stream identifier field1110may store information that identifies an active anycast stream. For example, stream identifier field may store a character string used to identify an active anycast stream.

Anycast address field1120may store information that identifies an address associated with an anycast stream, as described elsewhere herein with respect toFIG. 5and anycast address field510. For example, anycast address field1120may store information identifying a network address for the intermediary device240/250associated with the active anycast stream identified by the stream identifier in stream identifier field1110.

Departure intermediary device ID field1130(hereinafter, “DID ID field1130”) may store information that identifies an intermediary device240/250in the departure service area responsible for delivering the active anycast stream identified by the stream identifier in stream identifier field1110. For example, DID ID field1130may store a host name and/or network address of a departure intermediary device (e.g., DID240).

Arrival intermediary device ID field1140(hereinafter, “AID ID field1140”) may store information that identifies an intermediary device240/250in the arrival service area responsible for delivering the active anycast stream identified by the stream identifier in stream identifier field1110. For example, AID ID field1140may store a host name and/or network address of an arrival intermediary device (e.g., AID250).

Impacted stream indicator field1150may store information that indicates whether the active anycast stream identified by the stream identifier in stream identifier field1110is impacted by a mobility event. The impact of a mobility event on an active anycast stream may be determined by comparing the DID ID in field1130to the AID ID in field1140for a particular stream. If the DID ID in field1130is the same as the AID ID in field1140for a particular stream, then that particular stream is not impacted by the mobility event. However, if the DID ID in field1130is different from the AID ID in field1140for a particular stream, then that particular stream is impacted by the mobility event.

Information for a single active anycast stream is conceptually represented as a row in data structure1100. For example, the first row in data structure1100corresponds to an active anycast stream with a stream identifier of “00191,” an anycast address of “192.168.101.1,” a DID ID of “intdev1.cdnprovda.nj.net,” an AID ID of “intdev2.cdnprovda.nj.net,” and an impacted stream indicator of “YES.” This row indicates that the active anycast stream identified by stream identifier 00191 and anycast address 192.168.101.1 is delivered in the departure service area by DID240identified as “intdev1.cdnprovda.nj.net,” and is delivered in the arrival service area by AID250identified as “intdev2.cdnprovda.nj.net.” Stream 00191 is an impacted stream with an impacted stream indicator of “YES” because DID240is different from AID250for stream 00191.

FIG. 12is a diagram of example functional components of a device1200. In some implementations, device1200may correspond to FAs220/230. As illustrated, device1200may include a content tunnel establisher1210, an impacted stream classifier1220, and a content router1230. Each of functional components1210-1230may be implemented using one or more components shown inFIG. 3. FAs220/230may individually include all of the components depicted inFIG. 12, or the components depicted inFIG. 12may be distributed singularly or duplicatively in any manner between the devices illustrated inFIG. 2. In some implementations, FAs220/230may include other functional components (not shown) that aid in mobility management for anycast content delivery.

Content tunnel establisher1210may establish a content tunnel between DFA220and AFA230that aids in delivering anycast streams to mobile device210when mobile device210departs a service area associated with DFA220and arrives at a service area associated with AFA230. Content tunnel establisher1210may use the content tunnel to aid in delivering anycast streams impacted by the movement of mobile device210. For example, the content tunnel may be used to route communications (e.g., packets) associated with an impacted stream from mobile device210to DFA220and/or from DFA220to mobile device210.

Content tunnel establisher1210may use any tunneling protocol to establish a tunnel for routing impacted streams, including Generic Routing Encapsulation (GRE), IP in IP, Multiprotocol Label Switching (MPLS), and/or Layer 2 Tunneling Protocol (L2TP). Content tunnel establisher1210may create a content tunnel in advance of a detected mobility event and/or may create a content tunnel as the content tunnel is needed (e.g., in response to detecting a mobility event).

Content tunnel establisher1210may determine whether an existing content tunnel is adequate for transporting an active anycast stream between two FAs220/230. If content tunnel establisher1210determines that an existing content tunnel is adequate for transporting an active anycast stream, then content tunnel establisher1210may direct the active anycast stream over the content tunnel. If content tunnel establisher1210determines that an existing content tunnel is not adequate for transporting an active anycast stream, then content tunnel establisher1210may create a new content tunnel to transport the active anycast stream. Content tunnel establisher1210may also terminate idle tunnels (e.g., tunnels that have not been used to transport content for a particular period of time).

In some implementations, content tunnel establisher1210may establish multiple content tunnels to connect two particular foreign agents, such as DFA220and AFA230. For example, content tunnel establisher1210may establish multiple content tunnels to transport multiple anycast streams between DFA220and AFA230. In other implementations, content tunnel establisher1210may establish a tunnel that can transport multiple anycast streams between DFA220and AFA230.

In some implementations, content tunnel establisher1210may establish a series of content tunnels between three or more foreign agents. For example, mobile device210may move from a first service area serviced by DFA220to a second service area serviced by an intermediate foreign agent (“IFA”), and then to a third service area serviced by AFA230. In this example scenario, content tunnel establisher1210may establish a first content tunnel connecting DFA220to IFA, and may establish a second content tunnel connecting IFA to AFA230. Content may be routed through the first content tunnel and the second content tunnel in order to transport content from DFA220to AFA230.

In another implementation based on the above scenario, content tunnel establisher1210may establish a content tunnel between DFA220and IFA. Content may be routed from DFA220to IFA when mobile device220is in the second service area serviced by IFA. When mobile device220moves to the third service area serviced by AFA230, content tunnel establisher230may create a content tunnel directly connecting DFA220to AFA230, rather than routing content through two content tunnels and IFA. In this scenario, content tunnel establisher1210may terminate the content tunnel between DFA220and IFA.

Impacted stream classifier1220may classify impacted streams to aid in selecting the proper content tunnel over which to transport the impacted streams. Impacted stream classifier1220may classify impacted streams according to classification parameters, which may include a network address for a stream source (e.g., a source IP address), a network address for a stream destination (e.g., a destination IP address), an IP precedence value (e.g., Differentiated Service Code Point, or DSCP), an application type of the stream (e.g., audio, video, audiovisual, game, productivity, sports, etc.), and/or a mobile home network address (e.g, a mobile home IP address). Impacted stream classifier1220may determine whether a particular stream meets a set of one or more classification parameters in order to classify streams.

Content router1230may route content over a content tunnel. For example, content router1230may route communications (e.g., packets) associated with an impacted stream from mobile device210to DFA220and/or from DFA220to mobile device210. In some implementations, content router1230may select a content tunnel through which to route classified streams based on the classification parameters used to classify the streams. Content router1230may route content over a single content tunnel and/or multiple content tunnels.

FIG. 13is a diagram of an example process1300for routing anycast streams impacted by a mobility event. In some implementations, one or more of the process blocks ofFIG. 13may be performed by one or more components of mobile device210, FAs220/230, and/or another device, such as HA260, CDN service processor270, CDN controller280, etc.

Process1300may include detecting a mobility event (block1310). In some implementations, mobility event detector820may detect a mobility event, as described elsewhere herein. Mobility event detector820may detect whether the mobility event is pending or completed. Additionally, or alternatively, mobility event detector820may identify an FA220/230in the departure service area (e.g., DFA220), an FA220/230in the arrival service area (e.g., AFA230), a mobile device210associated with the mobility event, an active anycast stream on the mobile device210, an intermediary device240/250responsible for delivering the active anycast stream in the departure service area (e.g., DID240), and/or an intermediary device240/250responsible for delivering the active anycast stream in the arrival service area (e.g., AID250).

Process1300may include mapping active anycast streams to intermediary devices responsible for delivering the active anycast streams in the arrival service area (block1320). In some implementations, impacted stream identifier830may map active anycast streams to intermediary devices240/250responsible for delivering the active anycast streams in the arrival service area (e.g., AID250), as described elsewhere herein.

Process1300may include, for each active anycast stream, comparing the intermediary device responsible for delivering the active anycast stream in the departure service area (e.g., DID240) with the intermediary device responsible for delivering the active anycast stream in the arrival service area (e.g., AID250) (block1330). In some implementations, impacted stream identifier830may perform this comparison, as described elsewhere herein.

Process1300may include determining impacted streams (block1340). In some implementations, impacted stream identifier830may determine impacted streams, as described elsewhere herein. Impacted stream identifier830may determine that an active anycast stream is an impacted stream if the intermediary device240/250responsible for delivering the active anycast stream in the departure service area (e.g., DID240) is different from the intermediary device240/250responsible for delivering the active anycast stream in the arrival service area (e.g., AID250).

Process1300may include classifying impacted streams (block1350). In some implementations, impacted stream classifier1220may classify impacted streams, as described elsewhere herein. For example, impacted stream classifier1220may classify impacted streams based on a network address of the stream destination.

Process1300may include establishing a content tunnel (block1360). In some implementations, content tunnel establisher1210may establish a content tunnel to deliver impacted streams from AFA230to DFA220and/or from DFA220to AFA230. For example, content tunnel establisher1210may establish a content tunnel to deliver impacted streams classified based on a network address of the stream destination.

Process1300may include routing impacted streams over a content tunnel according to a classification (block1370). In some implementations, content router1230may route different anycast streams over different content tunnels based on classification parameters of the anycast stream.

FIG. 14is a diagram of an example activity flow1400for pending mobility events. A pending mobility event may include a mobility event in which mobile device210is transmitting traffic to and/or receiving traffic from DFA220in the service area that mobile device210is departing. Additionally, or alternatively, a pending mobility event may include a mobility event in which mobile device210is not yet transmitting traffic to and/or receiving traffic from AFA230in the service area that mobile device210is entering.

While activity flow1400is shown as occurring between certain devices (mobile device210, DFA220, and AFA230), these devices are shown for example purposes. In practice, activity flow1400may occur between additional devices, fewer devices, different devices, or differently arranged devices than are illustrated inFIG. 14. Furthermore, two or more of the devices illustrated inFIG. 14may be implemented within a single device, or a single device may be implemented as multiple, distributed devices. Additionally, one or more of the devices illustrated inFIG. 14may perform one or more functions and/or activities described as being performed by another one or more of the devices ofFIG. 14.

Activity flow1400may include transmitting and/or receiving a pending mobility event notification (item1410). In some implementations, mobile device210may notify DFA220of a pending mobility event. The pending mobility event notification may include an identification of an AFA230associated with the mobility event, an identification of active anycast streams associated with mobile device210, and/or an identification of DIDs240associated with the active anycast streams.

Activity flow1400may include transmitting and/or receiving an intermediary device mapping request (item1420). In some implementations, DFA220may request that AFA230send DFA220a list of AIDs250responsible for providing the active anycast streams associated with mobile device210.

Activity flow1400may include transmitting and/or receiving an intermediary device mapping response (item1430). In some implementations, AFA230may send DFA220a list of AIDs250responsible for providing the active anycast streams associated with mobile device210.

Activity flow1400may include transmitting and/or receiving a mobility event response (item1440). In some implementations, DFA220may transmit a mobility event response to mobile device210. The mobility event response may include an identification of AIDs250responsible for providing the active anycast streams associated with mobile device210.

Activity flow1400may include comparing a DID ID to an AID ID for each active anycast stream (item1450). In some implementations, mobile device210may compare the received identification of AID250responsible for providing an active anycast stream with a stored identification of a DID240that provides the active anycast stream (e.g., information stored in data structure1000and/or1100).

Activity flow1400may include determining impacted streams (item1460). In some implementations, mobile device210may use a result of the DID-to-AID comparison to determine impacted streams, as described elsewhere herein.

Activity flow1400may include sending a transport service request (item1470). In some implementations, mobile device210may notify DFA220of impacted streams, and may request that a content tunnel be established for the impacted streams.

Activity flow1400may include establishing a content tunnel (item1480). In some implementations, DFA220may establish a content tunnel between DFA220and AFA230in order to transport communications associated with impacted streams from mobile device210to DID240by way of AFA230, the content tunnel, and DFA220. Additionally, or alternatively, the established content tunnel may transport communications associated with impacted streams from DID240to mobile device210by way of DFA220, the content tunnel, and AFA230.

FIG. 15is a diagram of an example activity flow1500for completed mobility events. A completed mobility event may include a mobility event in which mobile device210is transmitting traffic to and/or receiving traffic from AFA230in the service area that mobile device210is entering. Additionally, or alternatively, a pending mobility event may include a mobility event in which mobile device210is no longer transmitting traffic to and/or receiving traffic from DFA220in the service area that mobile device210is departing.

While activity flow1500is shown as occurring between certain devices (mobile device210, DFA220, and AFA230), these devices are shown for example purposes. In practice, activity flow1500may occur between additional devices, fewer devices, different devices, or differently arranged devices than are illustrated inFIG. 15. Furthermore, two or more of the devices illustrated inFIG. 15may be implemented within a single device, or a single device may be implemented as multiple, distributed devices. Additionally, one or more of the devices illustrated inFIG. 15may perform one or more functions and/or activities described as being performed by another one or more of the devices ofFIG. 15.

Activity flow1500may include transmitting and/or receiving a completed mobility event notification (item1510). In some implementations, mobile device210may notify AFA230of a completed mobility event. The completed mobility event notification may include an identification of a DFA220associated with the mobility event, an identification of active anycast streams associated with mobile device210, and/or an identification of DIDs240associated with the active anycast streams.

Activity flow1500may include transmitting and/or receiving a mobility event response (item1520). In some implementations, AFA230may transmit a mobility event response to mobile device210. The mobility event response may include an identification of AIDs250responsible for providing the active anycast streams associated with mobile device210.

Activity flow1500may include comparing a DID ID to an AID ID for each active anycast stream (item1530). In some implementations, mobile device210may compare the received identification of AID250responsible for providing an active anycast stream with a stored identification of a DID240that provides the active anycast stream (e.g., information stored in data structure1000and/or1100).

Activity flow1500may include determining impacted streams (item1540). In some implementations, mobile device210may use a result of the DID-to-AID comparison to determine impacted streams, as described elsewhere herein.

Activity flow1500may include sending a transport service request (item1550). In some implementations, mobile device210may notify AFA230of impacted streams, and may request that a content tunnel be established for the impacted streams.

Activity flow1500may include establishing a content tunnel (item1560). In some implementations, AFA230may establish a content tunnel between DFA220and AFA230in order to transport communications associated with impacted streams from mobile device210to DID240by way of AFA230, the content tunnel, and DFA220. Additionally, or alternatively, the established content tunnel may transport communications associated with impacted streams from DID240to mobile device210by way of DFA220, the content tunnel, and AFA230.

Implementations described herein may prevent service disruptions of anycast streams due to mobile device mobility. Implementations described herein may prevent such service disruptions by establishing a content tunnel between foreign agents so as to maintain a route to, from, and/or through an intermediary device when a mobile device leaves a service area associated with the intermediary device.

While series of blocks have been described with regard toFIGS. 7, 9, and 13, the order of the blocks may be modified in some implementations. Further, non-dependent blocks may be performed in parallel.

While series of activities have been described with regard toFIGS. 14 and 15, the order of the activities may be modified in some implementations. Further, non-dependent activities may be performed in parallel.

Certain data structures have been presented with regard toFIGS. 5, 6, 10, and 11. These data structures are purely examples and merely serve to facilitate the description of the storage of information associated with anycast streams. When storing information in virtual memory, one or more fields of the data structures in these figures may be stored in virtual memory. Likewise, when storing information in physical memory, one or more fields of the data structures in these figures may be stored in physical memory. Although some data structures have been illustrated as separate, the data structures may be combined into a single data structure. Likewise, data fields illustrated as being part of a single data structure may be separated into multiple, distributed data structures.

While the data structures presented with regard toFIGS. 5, 6, 10, and 11are represented as tables with rows and columns, in practice, the data structures may include any type of data structure, such as a linked list, a tree, a hash table, a database, or any other type of data structure. The data structures may include information generated by a device and/or component. Additionally, or alternatively, the data structures may include information provided from any other source, such as information provided by one or more users, and/or information automatically provided by one or more other devices.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.