WO2016201690A1

WO2016201690A1 - Methods and apparatuses for pgw assisted local cache

Info

Publication number: WO2016201690A1
Application number: PCT/CN2015/081925
Authority: WO
Inventors: Huichun LIU; Xipeng Zhu; Bernard Gavin HORN
Original assignee: Qualcomm Incorporated
Priority date: 2015-06-19
Filing date: 2015-06-19
Publication date: 2016-12-22
Also published as: WO2016202091A1

Abstract

In one aspect, a method for a first network gateway includes receiving information associated with a CS proximate to a network node serving a UE, and initiating a tunnel between the CS and the network node for delivery of data to the network node directly from the CS. In another aspect, a method for a network node includes receiving a request for content from a UE, establishing a communication link with a CS proximate to the network node, receiving the content from the CS via the communication link, and sending the content to the UE. In another aspect, a method for a network entity includes receiving a first request for a location of content from a UE, determining identification information of a first network node associated with the UE, and sending the location of the content based on the identification information of the first network node.

Description

METHODS AND APPARATUSES FOR PGW ASSISTED LOCAL CACHE

BACKGROUND

Field

Various features relate to mobile networks, and more particularly to methods and apparatuses for a PGW assisted local cache.

Background

As the demand for content (e.g., movies, videos, and/or music) by users of wireless communication devices continues to rapidly increase, network access gateways (e.g., network nodes, base stations, evolved Node Bs (eNBs) , etc. ) serving such mobile communication devices are consuming large amounts of resources in the mobile network (e.g., backhaul resources) to meet user demand. However, such consumption of resources may cause network congestion, which typically results in degradation of performance (e.g., reduced content downloading/streaming rates) . Although mobile network operators may increase the amount of available resources to meet user demand, the cost of such increase is generally high. Therefore, there is a need for methods and devices that improve content delivery in a mobile network.

SUMMARY

In an aspect, a method of wireless communication for a first network gateway includes receiving information associated with a cache server (CS) that is proximate to a network node serving a user equipment (UE) , and initiating a tunnel between the CS and the network node for delivery of data to the network node directly from the CS.

In another aspect, a method of wireless communication for a network node includes receiving a request for content from a UE, establishing a communication link with a CS that is proximate to the network node, the CS configured to store the requested content, receiving the content from the CS via the communication link, and sending the content to the UE.

In another aspect, a method of wireless communication for a network entity includes receiving a first request for a location of content from a UE, determining identification information of a first network node associated with the UE, and sending the location of the content based on the identification information of the first network node.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a diagram of an architecture for content delivery in a mobile network with a packet data network gateway (PGW) cache.

FIG. 2 illustrates a diagram of an architecture for content delivery in a mobile network with a local cache.

FIG. 3 illustrates a diagram of an architecture for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure.

FIG. 4 illustrates a signal flow diagram of a signaling procedure in accordance with various aspects of the disclosure.

FIG. 5 illustrates a diagram of an architecture for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure.

FIG. 6 illustrates a signal flow diagram of a signaling procedure in accordance with various aspects of the disclosure.

FIG. 7 illustrates a signal flow diagram of a signaling procedure in accordance with various aspects of the disclosure.

FIG. 8 illustrates a diagram of an architecture for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure.

FIG. 9 illustrates a diagram of a local CS protocol stack and a network access gateway protocol stack in accordance with various aspects of the disclosure.

FIG. 10 illustrates a signal flow diagram of a signaling procedure in accordance with various aspects of the disclosure.

FIG. 11 illustrates a signal flow diagram of a signaling procedure to terminate a data forwarding tunnel in accordance with various aspects of the disclosure.

FIG. 12 illustrates a signal flow diagram of a handover procedure in accordance with various aspects of the disclosure.

FIG. 13 illustrates a signal flow diagram of content delivery to a mobile device after a handover procedure in accordance with various aspects of the disclosure.

FIG. 14 illustrates a diagram of an architecture for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure.

FIG. 15 illustrates a diagram of a mobile device (e.g., UE) protocol stack, a network access gateway (e.g., a network node, base station, eNB) protocol stack, and a local CS protocol stack in accordance with various aspects of the disclosure.

FIG. 16 illustrates a signal flow diagram of a signaling procedure in accordance with various aspects of the disclosure.

FIG. 17 illustrates a signal flow diagram of a handover procedure in accordance with various aspects of the disclosure.

FIG. 18 illustrates a diagram of an architecture for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure.

FIG. 19 illustrates a diagram of a Uu interface including a mobile device protocol stack and a network access gateway protocol stack in accordance with various aspects of the disclosure.

FIG. 20 illustrates a diagram of an interface between a network access gateway and a mobile device, which includes a network access gateway protocol stack and a local CS protocol stack in accordance with various aspects of the disclosure.

FIG. 21 illustrates a signal flow diagram of a signaling procedure in accordance with various aspects of the disclosure.

FIG. 22 illustrates a signal flow diagram of a handover procedure in accordance with various aspects of the disclosure.

FIG. 23 illustrates a signal flow diagram of content delivery to a mobile device after a handover procedure in accordance with various aspects of the disclosure.

DETAILED DESCRIPTION

In the following description, specific details are given to provide a thorough understanding of the various aspects of the disclosure. However, it will be understood by one of ordinary skill in the art that the aspects may be practiced without these specific details. For example, circuits may be shown in block diagrams in order to avoid obscuring the aspects in unnecessary detail. In other instances, well-known circuits, structures and techniques may not be shown in detail in order not to obscure the aspects of the disclosure.

The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any implementation or aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects of the disclosure. Likewise, the term “aspects” does not require that all aspects of the disclosure include the discussed feature, advantage, or mode of operation.

FIG. 1 illustrates a diagram of an architecture 100 for content (e.g., movies and/or music) delivery in a mobile network with a packet data network gateway (PGW) cache. An Internet content delivery network (CDN) generally includes a distributed system of servers deployed in multiple data centers across the Internet. A CDN is configured to serve content to end-users with high availability and high performance. CDN nodes are usually deployed in multiple locations, often over multiple backbones. A CDN may treat a mobile network as a black box and may cache content at the PGW or at a higher level. Although a network access gateway (e.g., a network node, base station, eNB) is considered the edge node of a cellular network, the PGW is actually the edge node from the perspective of the CDN. The content from the CDN is repeatedly transmitted to the network access gateway via the backhaul, which may require mobile network operators to either deploy more backhaul to accommodate the additional traffic, which typically leads to higher costs, or experience higher backhaul congestion.

FIG. 2 illustrates a diagram of an architecture 200 for content delivery in a mobile network with a local cache. As shown in FIG. 2, by implementing a mobile CDN to cache content inside the mobile network (below PGW) , the backhaul waste may be avoided. Accordingly, user experience may be improved by achieving a shorter delay in the delivery of content and/or by reducing the probability of interruptions during the delivery of the content. In an aspect, the PGW in the mobile network may obtain the location of a mobile device (also referred to as a user equipment (UE)) at the radio access network (RAN) level. When the PGW receives a request from the global server load balance (GSLB) node, the PGW may provide the UE’s actual edge location to the GSLB node. The actual edge location of the UE may assist the Internet CDN to locate the suitable real edge local content server that is close to the UE. Once located, the local content server (also referred to as a local cache server (CS) ) may be used to serve the UE instead of the PGW.

PGW Assisted Local Cache

FIG. 3 illustrates a diagram of an architecture 300 for content delivery in a mobile network with a local CS in accordance with various aspects of the disclosure. As shown in FIG. 3, the architecture 300 includes a mobile device (e.g., UE) 302, a network access gateway (e.g., base station or eNB) 304, a local CS 306, a PGW 308, a local domain network system (DNS) server 310, a firewall 312, a DNS server 314, a CDN node 315, a GSLB node 316, and a backhaul 301.

In one aspect, when the PGW 308 receives a trigger (e.g., a query for the serving eNB from the GSLB node) , the PGW 308 determines the radio access network (RAN) level location of the mobile device (e.g., the serving network access gateway of the mobile device) and provides information indicating the RAN level location to the CDN node 315. A direct path may be established between the network access gateway 304 and the local CS 306 for downlink content transfer. In one aspect, such direct path may be tunnel based and may be set up by the PGW 308 for forwarding packets or may be set up by the network access gateway 304 to achieve an IP aware RAN tunnel via the network access gateway. In another aspect, the path may be IP based with network address translation (NAT) by the network access gateway 304 to achieve IP aware RAN NAT via the network access gateway 304.

The content fetch request may be transmitted to the local CS 306. If the requested content from the mobile device 302 has been cached in the local CS 306, the content may be sent to the mobile device 302 from the local CS 306 via the network access gateway 304 directly. If the content is not in the local CS 306, the local CS 306 may be responsible to fetch the content from an upper layer (e.g., CDN node 315) for the mobile device 302.

FIG. 4 illustrates a signal flow diagram 400 of a signaling procedure in accordance with various aspects of the disclosure. The signal flow diagram 400 includes a mobile device (e.g., UE) 402, a network access gateway (e.g., base station or eNB) 404, a local CS 406, a mobility management entity (MME) 407, a serving gateway 409, a packet data network gateway (PGW) 408, a local DNS server 410, a firewall (FW) 412, a DNS 414, and a GSLB node 416. In an aspect, the mobile device 402, network access gateway 404, local CS 406, PGW 408, local DNS 410, firewall 412, DNS server 414, and GSLB node 416 of FIG. 4 respectively correspond to the mobile device 302, network access gateway 304, local CS 306, PGW 308, local DNS 310, firewall 312, DNS server 314, and GSLB node 316 of FIG. 3.

As shown in FIG. 4, at operation 418, the mobile device 402 establishes an IP bearer (e.g., a PDN connection) with the PGW 408 and acquires an IP address or domain name from the PGW 408. The mobile device 402 sends DNS queries 420, 424, and 428 using an iterative approach. For example, when the mobile device 402 sends a DNS query 420 to the local DNS server 410, the local DNS server 410 may send a response 422 that refers the mobile device 402 to another server and allows the mobile device 402 to pursue the query. Therefore, in this approach, when the Internet CDN is deployed, the DNS server 414 may send a response 426 that includes a CNAME DNS response type. The CNAME DNS response type may serve as an indication to the mobile device 402 to proceed to send a query (e.g., DNS query 428) to the GSLB node 416.

It should be noted that a recursive DNS query approach may not be suitable in the configuration of FIG. 4 because with the recursive DNS query approach, the local DNS server 410 will pursue the query for the mobile device 402 at another server. Therefore, from the perspective of the GSLB node 416, the query IP is always the IP address of the local DNS server 410 and not the IP address of the mobile device 402. As a result, the GSLB node 416 may not locate the actual edge location of the mobile device 402.

A firewall (e.g., firewall 412) is typically configured between a PGW (e.g., PGW 408) and a GSLB node (e.g., GSLB node 416) . Therefore, the IP address of the mobile device 402 may be a PGW subnet IP address or a global IP address (e.g., an IPv6 address) . If the IP address of the mobile device 402 is a PGW subnet IP address, a NAT translation 430 will be performed across the firewall 412 before the DNS query 428 is sent to GSLB node 416. When the GSLB node 416 receives the DNS query 428, the incoming request source IP is a PGW configurable IP address after the network address translation or a global IP address of the mobile device 402.

As shown in FIG. 4, the GSLB node 416 sends a query 432 to the PGW 408 serving the mobile device 402. The query 432 may include the IP address of the mobile device 402 and may request information regarding the network access gateway (e.g., network access gateway 404) serving the mobile device 402. As shown in FIG. 4, the query 432 is sent to PGW 408 across the firewall 412. In an aspect, when a NAT operation is required, the firewall 412 needs to have the application layer gateway (ALG) function (or other application layer gateway function) to translate 434 the application layer information before sending the query (e.g., query 436) to PGW 408. For example, the firewall 412 may implement the ALG function to translate the NAT IP address and port of the mobile device 402 to the subnet IP address and port of the mobile device 402.

The PGW 408 receives the query 436 from the firewall 412 and sends a query 438 to the SGW 409. The SGW 409 may have information regarding the location of the mobile device 402 because the SGW 409 has an S1 connection setup with the network access gateway 404 serving the mobile device 402. The SGW 409 may send a response 440 that includes information indicating the network access gateway 404 serving the mobile device 402 to the PGW 408. The PGW 408 may forward the information indicating the network access gateway 404 serving the mobile device 402 to the GSLB node 416 across the firewall 412. In an aspect, when a NAT operation is required, the firewall 412 needs the ALG function to translate 444 the subnet IP address and port of the mobile device 402 to the global IP address and port of the mobile device 402.

In an aspect, the GSLB node 416 may be configured to include or have access to a database regarding mapping information for the network access gateway 404 serving the mobile device 402 and suitable local CS information. For example, the mapping may be based on location information, load information, content hit or not, etc. After finding the suitable local CS (e.g., local CS 406) at operation 447, information regarding the local CS 406 is sent to PGW 408 via query acknowledgment (ACK) 448 across the firewall 412. In an aspect, when a NAT operation is required, the firewall 412 needs the ALG function to translate 450 the global IP address and port of the local CS to the subnet IP address and port of the local CS. The GSLB node 416 then sends a DNS response 454 to the mobile device 402 that includes the address of the local CS (e.g., local CS 406) .

SLB in 3GPP Network

FIG. 5 illustrates a diagram of an architecture 500 for content delivery in a mobile network with a local CS in accordance with various aspects of the disclosure. As shown in FIG. 5, the architecture 500 includes a mobile device (e.g., a UE) 502, a network access gateway (e.g., eNB) 504, a local CS 506, a PGW 508, a local DNS server 510, a firewall 512, a DNS server 514, a CDN node 515, a GSLB node 516, a server load balance (SLB) device 518, and a backhaul 501.

FIG. 6 illustrates a signal flow diagram 600 of a signaling procedure in accordance with various aspects of the disclosure. The signal flow diagram 600 includes a mobile device (e.g., UE) 602, an SGW 603, a PGW 608, an SLB 618, a local DNS server 610, a firewall 612, a DNS server 614, and a GSLB node 616. In an aspect, mobile device 602, PGW 608, SLB 618, local DNS server 610, a firewall 612, DNS server 614, and GSLB node 616 of FIG. 6 respectively correspond to the mobile device 502, PGW 508, SLB 518, local DNS 510, firewall 512, DNS server 514, and GSLB node 516 of FIG. 5.

As shown in FIG. 6, at operation 620, the mobile device 602 establishes an IP bearer (e.g., a PDN connection) with the PGW 608 and acquires an IP address or domain name from the PGW 608. The mobile device 602 sends a DNS query 622 to the local DNS server 610 via the PGW 608. The local DNS server 610 sends a DNS query 624 to the DNS server 614 and receives a DNS response 626 that includes a first canonical name (e.g., CNAME1 in FIG. 6) . The local DNS server 610 then proceeds to send a DNS query 628 that includes CNAME1 to the GSLB node 616 and receives a DNS response 630 that includes a second canonical name (e.g., CNAME2 in FIG. 6) .

In an aspect, with reference to the signals indicated as “Option A” in FIG. 6, the local DNS server 610 sends a DNS query 632 that includes CNAME2 to the SLB 618. The SLB 618 sends a DNS query 634 requesting the IP address of the mobile device 602 to the local DNS server 610. In one example, the DNS query 634 may include a certain domain name (e.g., requester_ [id] , where [id] is the value of the ID parameter in the DNS query 632) . In another example, private signaling may be defined between the SLB 618 and local DNS 610 for the query of the IP address of the mobile device 602. In another example, a reserved OPCODE may be used. The SLB 618 receives a DNS response 636 that includes the IP address of the mobile device 602. In another aspect, with reference to the signals indicated as “Option B” in FIG. 6, the local DNS server 610 sends a DNS query 638 that includes CNAME2 and the IP address of the mobile device 602 to the SLB 618. For example, the CNAME2 and the IP address of the mobile device 602 may be sent to the SLB 618 using private signaling between the SLB 618 and local DNS 610.

As show in FIG. 6, the SLB 618 sends a query 640 for information regarding the network access gateway serving the mobile device 602 to the PGW 608, where the query 640 includes the IP address of the mobile device 602. The PGW 608 sends the query 642 to the SGW 603 and receives information 644 regarding the network access gateway serving the mobile device 602. The PGW 608 sends the received information 646 to the SLB 618. In an aspect, the SLB 618 may be configured to include or have access to a database regarding mapping information for the network access gateway (e.g., network access gateway 504 in FIG. 5) serving the mobile device 602 and suitable local CS information. For example, the mapping may be based on location information, load information, content hit or not, etc. After finding the suitable local CS (e.g., local CS 506 in FIG. 5) at operation 648, information regarding the local CS is sent to the local DNS 610 in DNS response 650 and sent to PGW 608 via query ACK 652. The local DNS 610 then sends a DNS response 654 to the mobile device 602 via the PGW 608.

FIG. 7 illustrates a signal flow diagram 700 of a signaling procedure in accordance with various aspects of the disclosure. The signal flow diagram 700 includes a mobile device (e.g., UE) 702, an SGW 703, a PGW 708, an SLB device 718, a local DNS server 710, a firewall 712, a DNS server 714, and a GSLB node 716. In an aspect, mobile device 702, PGW 708, SLB 718, local DNS server 710, a firewall 712, DNS server 714, and GSLB node 716 of FIG. 7 respectively correspond to the mobile device 502, PGW 508, SLB 518, local DNS server 510, firewall 512, DNS server 514, and GSLB node 516 of FIG. 5.

As shown in FIG. 7, at operation 720, the mobile device 702 establishes an IP bearer (e.g., a PDN connection) with the PGW 708 and acquires an IP address or domain name from the PGW 708. The mobile device 702 sends DNS queries 722, 726, and 730 using an iterative approach. For example, when the mobile device 702 sends a DNS query 722 to the local DNS server 710, the local DNS server 710 may send a response 724 that refers the mobile device 702 to another server and allows the mobile device 702 to pursue the query. Therefore, in this approach, when the Internet CDN is deployed, the DNS server 714 may send a response 728 that includes a CNAME DNS response type. The CNAME DNS response type may serve as an indication to the mobile device 702 to proceed to send a query (e.g., DNS query 730) to the GSLB node 716.

The mobile device 702 sends a DNS query 734 that includes a second canonical name (e.g., CNAME2 in FIG. 7) to the SLB 718. The SLB 718 sends a DNS query 734 requesting information regarding the network access gateway serving the mobile device 702 to the PGW 708. For example, the DNS query 734 may include the IP address of the mobile device 702. The PGW 708 sends the query 736 to the SGW 703 and receives information 738 regarding the network access gateway serving the mobile device 702. The PGW 708 sends the received information 740 to the SLB 718. In an aspect, the SLB 718 may be configured to include or have access to a database regarding mapping information for the network access gateway (e.g., network access gateway 504 in FIG. 5) serving the mobile device 702 and suitable local CS information. For example, the mapping may be based on location information, load information, content hit or not, etc. After finding the suitable local CS (e.g., local CS 506 in FIG. 5) at operation 742, information regarding the local CS is sent to the PGW 708 via query ACK 744. The SLB 718 then sends a DNS response 746 to the mobile device 702.

Content Delivery (Packet Forwarding)

FIG. 8 illustrates a diagram of an architecture 800 for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure. As shown in FIG. 8, the architecture 800 includes a mobile device (e.g., a UE) 802, a network access gateway (e.g., a base station or eNB) 804, a local CS 806, a PGW 808, and an Over-the-Top (OTT) server 810. As shown in FIG. 8, the PGW 808 is in communication with the network access gateway 804 via the backhaul 812 and is in communication with the OTT server 810 via the backbone 814.

As shown in FIG. 8, the mobile device 802 may send a content request 816 to the network access gateway 804. The network access gateway 804 may send the content request via message 818 using GPRS Tunneling Protocol (GTP) to the PGW 808 indicating a destination IP address (also referred to as IP_Ain FIG. 8) . The PGW 808 may send the content request via an IP packet including the destination IP address to the local CS 806. The local CS 806 may send the requested content 822 directly to the network access gateway 804. The network access gateway 804 may forward the requested content 824 to the mobile device 802.

In the architecture 800, the local CS 806 is proximate to the network access gateway 804 and can serve a group of network access gateways. In some aspects, mobile network operators may deploy scalable local CSs to meet content acceleration requirements. For example, as the number of network access gateways served by one local CS increases, mobile network operators can avoid costs by deploying fewer local CSs and fewer storage devices for duplication of content at edge nodes. However, the local CSs may be subject to heavier usage and may experience a reduction in bandwidth, which may result in increased content response latency. Therefore, a tradeoff exists between the operating efficiency of a local CS and Mobile Content Delivery Network (MCDN) deployment cost.

The local CS 806 may communicate with upper layer entities, such as the OTT server 810, similar to communications with a CDN server. For example, when content requested by a mobile device is not in the local CS, the local CS may pull the content from the CDN server. Accordingly, when content requested by a mobile device 802 is not in the local CS 806, the local CS 806 may pull the content from OTT server 810.

The link between the local CS 806 and the network access gateway 804 may be a mobile device specific tunnel (e.g., a GTP tunnel) . In an aspect, the PGW 808 may trigger setting up of the tunnel. In such aspect, the PGW 808 may trigger an MME to request the network access gateway 804 to set up a downlink tunnel for receiving IP data packets. After the network access gateway 808 has configured the downlink tunnel, the PGW 808 may notify the local CS 806 regarding the configured downlink tunnel for the mobile device 802. Thereafter, all the downlink IP data packets containing content sent to the IP address of the mobile device 802 may be sent to the mobile device 802 via the configured downlink tunnel.

From the perspective of the network access gateway 804, the delivery of IP data packets via the configured downlink tunnel may be similar in operation to a handover scenario in a mobile network. For example, in a handover scenario, a target network access gateway may receive forwarded IP data packets from both a source network access gateway and a core network. However, in the configuration of FIG. 8, sorting of the IP data packets from the two paths may not be required.

FIG. 10 illustrates a signal flow diagram 1000 of a signaling procedure in accordance with various aspects of the disclosure. The signal flow diagram 1000 includes a mobile device (e.g., UE) 1002, a network access gateway (e.g., a base station or eNB) 1004, a local CS 1006, an MME 1005, an SGW 1007, a PGW 1008, a local DNS server 1011, a firewall 1013, a DNS server 1015, and a GSLB node 1017. In an aspect, mobile device 1002, network access gateway 1004, local CS 1006, and PGW 1008 of FIG. 10 respectively correspond to the mobile device 802, network access gateway 804, local CS 806, and PGW 808 of FIG. 8. As shown in FIG. 10, at operation 1014, the PGW 1008 assists in the location of a suitable local CS (e.g., local CS 1006) and the GSLB node 1017 directs the mobile device 1002 to the local CS 1006. The PGW 1008 receives a trigger regarding the local CS 1006 for the mobile device 1002 and proceeds to set up a separate tunnel between the network access gateway 1004 and the local CS 1006. For example, to set up a separate tunnel between the network access gateway 1004 and the local CS 1006, the PGW 1008 may send a request 1016 to the MME 1005 requesting a data forwarding tunnel. The MME 1005 may send a request 1016 to the network access gateway 1004 requesting a GTP-U. The network access gateway 1004 may establish a downlink tunnel for receiving IP data packets and may send a response 1020 to notify the PGW 1008. The MME 1005 may receive the response 1020 and may send the response 1022 to the PGW 1008. The MME 1005 may send a message 1024 to notify the local CS 1006 that a specific downlink tunnel has been established for the mobile device 1002. The mobile device 1002 may send the uplink content request 1026 across the core network, which may be routed to local CS 1006 via the PGW 1008 as content request 1028. The local CS 1006 may send the content 1030 requested by the mobile device 1002 if it has cached in its local storage or may fetch the requested content from an upper layer (e.g., a CDN node (s) ) if the local CS 1006 does not have the requested content. For example, the local CS 1006 may send the downlink IP data packets to network access gateway 1004 through the mobile device specific downlink tunnel between network access gateway 1004 and the local CS 1006. The network access gateway 1004 delivers the GTP-U packets from the local CS 1006 and SGW 1007/PGW 1008 to PDCP similar to data forwarding in a handover scenario. As shown in FIG. 10, the mobile device 1002 receives the requested content 1032 from the network access gateway 1004. The network access gateway 1004 then sends data volume information 1036 to the local DNS 1011.

Termination of a PGW initiated Packet Forwarding Tunnel

FIG. 11 illustrates a signal flow diagram of a signaling procedure to terminate a data forwarding tunnel in accordance with various aspects of the disclosure. For example, a PGW may determine to terminate a data forwarding tunnel due to expiration of a timer or other reasons. When the PGW determines to terminate the data forwarding tunnel between a local CS and a serving network access gateway (e.g., base station or eNB) , the PGW first sends a request to terminate the data forwarding tunnel to the local CS, and subsequently sends the request to terminate the data forwarding tunnel to the serving network access gateway via the MME.

FIG. 12 illustrates a signal flow diagram 1200 of a handover procedure in accordance with various aspects of the disclosure. The signal flow diagram 1200 includes a mobile device 1202, a source network access gateway 1204, a target network access gateway 1206, a source MME 1208, a target MME 1210, a source SGW 1212, a target SGW 1214, a PGW 1216, and a local CS 1218.

As shown in FIG. 12, the local CS 1218 provides downlink data 1220 to the source network access gateway 1204. At operation 1, the source network access gateway 1204 may determine to initiate a handover of the mobile device 1202 from the source network access gateway 1204 to the target network access gateway 1206. At operation 2, the source network access gateway 1204 sends a handover required message to the source MME 1208. In an aspect, the handover required message may include the downlink GPRS tunneling protocol user plane (GTP-U) tunnel endpoint identifier (TEID) for the local CS 1218 to be set up by target network access gateway 1206. At operation 5a, if the target network access gateway 1206 also supports the TEID for the local CS setup, the target network access gateway 1206 will create a GTP-U tunnel TEID_CS to receive the forwarded downlink data from source network access gateways which originally come from the local CS 1218. At operation 6, a GTP-U tunnel TEID for local CS may also be set up in SGW if indirect data forwarding is needed. At operation 17, the PGW 1216 may notify the local CS 1218 to update the downlink GTP_U TEID to switch from source network access gateway 1204 to the target network access gateway 1206. The local CS 1218 may send an ACK with respect to the update notification at operation 17. Thereafter, the downlink data 1222 from local CS 1218 is sent directly from the local CS 1218 to the target network access gateway 1206, and from the target network access gateway 1206 to the mobile device 1202.

Service continue after handover complete-User Plane

FIG. 13 illustrates a signal flow diagram 1300 of content delivery to a mobile device after a handover procedure in accordance with various aspects of the disclosure. The signal flow diagram 1300 includes a mobile device 1302, a source network access gateway 1304, a target network access gateway 1306, a source SGW 1308, a target SGW 1310, a PGW 1312, and a local CS 1314.

After handover of the mobile device 1302 is completed, the mobile device 1302 may send a new content request to the local CS 1314 via the target network access gateway 1306. This is also applicable for those cases where data forwarding is not supported in handover, after an application layer timer out, the mobile device 1302 needs to re-send the content request to the local CS 1314 via the target network access gateway 1306. If the target network access gateway 1306 does not support the tunnel between the target network access gateway 1306 and the local CS 1314, the content fetch request will be sent to the local CS 1314 via the PGW 1312, and downlink content data from the local CS 1314 will be sent to the mobile device 1302 via the local CS 1314 to the PGW 1312, the target SGW 1310, and the target network access gateway 1306.

IP Aware RAN

A network access gateway may be configured with the ability to interpret IP layer information. The communication between the network access gateway and a local CS may be based on IP or a tunnel. For the IP based solution, the network access gateway may be configured to have a NAT translation function to change the mobile device subnet IP and port to the network access gateway IP and port. The communication between the content server and Internet CDN is based on IP. The content of the local CS may be pushed by the Internet CDN server or pulled from the Internet CDN server.

The network access gateway operates at IP level within a configurable list of IP addresses. Those IP addresses may be local CS IP addresses. For each uplink IP packet, if the target IP address is in the configured IP list of the network access gateway, the network access gateway will consider it as a special IP (e.g., a local CS) . The uplink IP packet request will be routed to the local CS via the established tunnel for the mobile device (e.g., tunnel by the network access gateway solution) or after NAT translation (NAT via network access gateway solution) . The content from local CS may be sent back to the target network access gateway directly, then to the mobile device.

The local CS may serve a group of network access gateways. This could avoid the duplication of same content at many CSs. When the mobile device moves to another network access gateway which is not configured as the mobile content server IP as its configured IP list, uplink content fetch request from the mobile device will be routed to Internet via normal GTP-U packets (e.g., UE<->eNB<->SGW<->PGW<->CS) and then to the CS. The content response will be sent back to mobile device along the same route in the reverse direction. For content not yet cached in local CS, the local CS may pull the content from the Internet CS for the mobile device.

NAT via Network Access Gateway

FIG. 14 illustrates a diagram of an architecture 1400 for content delivery in a mobile network with a local cache in accordance with various aspects of the disclosure. As shown in FIG. 14, the architecture 1400 includes a mobile device (e.g., a UE) 1402, a network access gateway (e.g., a base station or an eNB) 1404, a local CS 1406, a PGW 1408, and an OTT server 1410. As shown in FIG. 14, the PGW 1408 is in communication with the network access gateway 1404 via the backhaul 1412 and is in communication with the OTT server 1410 via the backbone 1414.

As shown in FIG. 14, the mobile device 1402 may send a content request 1416 to the network access gateway 1404. The content request may indicate the source of the request as the IP address of the mobile device 1402 and the destination of the request as the IP address of the local CS 1406. The network access gateway 1404 may send the content request via message 1418. The network access gateway may perform a NAT operation and indicate the source of the request as the IP address of the network access gateway 1404 (instead of the IP address of the mobile device 1402) and the destination of the request as the IP address of the local CS 1406. The local CS 1406 may send a response message 1420 that includes the requested content. The response message 1420 may indicate the source of the content as the IP address of the local CS 1406 and the destination of the content as the IP address of the network access gateway 1404. The network access gateway 1404 may receive the response message 1420 and perform a NAT operation on the response message 1420, such that the response message 1422 sent by the network access gateway 1404 indicates the source of the content as the IP address of the local CS 1406 and the destination of the content as the IP address of the mobile device 1402.

FIG. 15 illustrates a diagram of a mobile device (e.g., UE) protocol stack, a network access gateway (e.g., a base station or eNB) protocol stack, and a local CS protocol stack in accordance with various aspects of the disclosure.

FIG. 16 illustrates a signal flow diagram 1600 of a signaling procedure in accordance with various aspects of the disclosure. The signal flow diagram 1600 includes a mobile device (e.g., UE) 1602, a network access gateway (e.g., a base station or eNB) 1604, a local CS 1606, an SGW 1607, a PGW 1608, a local DNS server 1610, a firewall 1612, a DNS server 1614, and a GSLB node 1616. In an aspect, mobile device 1602, network access gateway 1604, local CS 1606, and PGW 1608 of FIG. 16 respectively correspond to the mobile device 1402, network access gateway 1404, local CS 1406, and PGW 1408 of FIG. 14.

As shown in FIG. 16, at operation 1618, the PGW 1608 assists in the location of a suitable local CS (e.g., local CS 1606) and the GSLB node 1616 directs the mobile device 1602 to the local CS 1606. At operation 1, the network access gateway 1604 receives an uplink IP packet with a destination IP address that is within a configurable list of IP addresses (e.g., local CS IP addresses) . At operation 2, the network access gateway 1604 performs a network address translation for the IP packet by translating the source IP address and port of the mobile device 1602 to the IP address and port of the network access gateway 1604. At operation 3, the network access gateway 1604 sends the HTTP request over IP to the local CS 1606. At operation 4, the network access gateway 1604 receives the downlink packet over IP from the local CS 1606. At operation 5, the network access gateway 1604 performs a network address translation for the IP packet by translating the destination address from the IP address and port of the network access gateway 1604 to the IP address and port of the mobile device 1602. The network access gateway 1604 then sends the IP packet to the mobile device 1602 at operation 6 and sends data volume information to the PGW 1608 at operation 7. Therefore, in this aspect, the network access gateway 1604 serves as a proxy for mobile device 1602.

FIG. 17 illustrates a signal flow diagram 1700 of a handover procedure in accordance with various aspects of the disclosure. The signal flow diagram 1700 includes a mobile device 1702, a source network access gateway 1704, a target network access gateway 1706, a source MME 1708, a target MME 1710, a source SGW 1712, a target SGW 1714, a PGW 1716, and a local CS 1718.

As shown in FIG. 17, the local CS 1718 provides downlink data 1720 to the source network access gateway 1704. At operation 1, the source network access gateway 1704 may determine to initiate a handover of the mobile device 1702 from the source network access gateway 1704 to the target network access gateway 1706. When a handover operation is performed, the ongoing downlink data 1720 from CS will be forwarded to target network access gateway 1706 from source network access gateway 1704. After the mobile device 1702 connection to target network access gateway 1706 has been established, the mobile device 1702 sends an uplink IP packet 1722 of HTTP request to the local CS 1718 through the target network access gateway 1706. If the IP address of the local CS 1718 is also in the target network access gateway 1706 work list, the target network access gateway 1706 will perform network address translation by translating the source IP address from the IP address of the mobile device 1702 IP to the IP address of the target network access gateway 1706. The target network access gateway 1706 may send the IP packets to the local CS1718. The downlink data 1724 from the local CS 1718 may be sent to target network access gateway 1706. After network address translation by target network access gateway 1706, the IP packet may subsequently be sent to the mobile device 1702. It should be noted that the NAT based routing mechanism may be blocked by "anti-spoof" features found in various routers. Therefore, "anti-spoof" feature should be disabled for this aspect.

Tunnel by Network Access Gateway

FIG. 18 illustrates a diagram of an architecture 1800 for content delivery in a mobile network with a local CS in accordance with various aspects of the disclosure. As shown in FIG. 18, the architecture 1800 includes a mobile device (e.g., a UE) 1802, a network access gateway (e.g., a base station or eNB) 1804, a local CS 1806, a PGW 1808, and an OTT server 1810. As shown in FIG. 18, the PGW 1808 is in communication with the network access gateway 1804 via the backhaul 1812 and is in communication with the OTT server 1810 via the backbone 1814.

As shown in FIG. 18, the mobile device 1802 may send a content request 1816 to the network access gateway 1804. The content request may indicate the source of the request as the IP address of the mobile device 1802 and the destination of the request as the IP address of the local CS 1806. The network access gateway 1804 may send the content request via message 1818. The network access gateway 1804 may indicate the source of the request as the IP address of the mobile device 1802 and the destination of the request as the IP address of the local CS 1806. The local CS 1806 may send a response message 1820 that includes the requested content. The response message 1820 may indicate the source of the content as the IP address of the local CS 1806 and the destination of the content as the IP address of the mobile device 1802. The network access gateway 1804 may receive the response message 1820 and may generate and transmit a response message 1822 that includes the requested content. The response message 1822 may indicate the source of the content as the IP address of the local CS 1806 and the destination of the content as the IP address of the mobile device 1802.

FIG. 19 illustrates a diagram of a Uu interface 1900 including a mobile device protocol stack and a network access gateway protocol stack in accordance with various aspects of the disclosure.

FIG. 20 illustrates a diagram of an interface 2000 between a network access gateway and a mobile device, which includes a network access gateway protocol stack and a local CS protocol stack in accordance with various aspects of the disclosure.

FIG. 21 illustrates a signal flow diagram 2100 of a signaling procedure in accordance with various aspects of the disclosure. The signal flow diagram 2100 includes a mobile device (e.g., UE) 2102, a network access gateway (e.g., a base station or eNB) 2104, a local CS 2106, an SGW 2107, a PGW 2108, a local DNS server 2110, a firewall 2112, a DNS server 2114, and a GSLB node 2116. In an aspect, mobile device 2102, network access gateway 2104, local CS 2106, and PGW 2108 of FIG. 21 respectively correspond to the mobile device 1802, network access gateway 1804, local CS 1806, and PGW 1808 of FIG. 18.

At operation 2118, the PGW 2108 assists in the location of a suitable local CS (e.g., local CS 2106) and the GSLB node 2116 directs the mobile device 2102 to the local CS 2106. At operation 1, the network access gateway 2104 receives an uplink IP packet with a destination IP address that is within a configurable list of IP addresses (e.g., local CS IP addresses) . Since the network access gateway 2104 knows that this IP packet is directed to a local CS, the network access gateway 2104 may determine whether or not a tunnel has been established for the mobile device 2102. If no tunnel has been established for the mobile device 2102, then at operation 2, the network access gateway 2104 will trigger a tunnel setup between network access gateway 2104 and the local CS 2106 by sending a tunnel request message. At operation 3, the network access gateway 2104 may receive a response message. At operation 4, the network access gateway 2104 may send an uplink packet (e.g., HTTP request) via the tunnel directly to the local CS 2106. At operation 5, the network access gateway 2104 may receive an HTTP response over the tunnel from the local CS 2106. The network access gateway 2104 then sends the downlink content received from the local CS 2106 to the mobile device 2102 at operation 6 and sends data volume information to the PGW 2108 at operation 7.

FIG. 22 illustrates a signal flow diagram 2200 of a handover procedure in accordance with various aspects of the disclosure. The signal flow diagram 2200 includes a mobile device 2202, a source network access gateway 2204, a target network access gateway 2206, a source MME 2208, a target MME 2210, a source SGW 2212, a target SGW 2214, a PGW 2216, and a local CS 2218.

In operation 2, in the handover required message, the source network access gateway may include the downlink GTP-U TEID for the local CS 2218 to be setup by target network access gateway. At operation 5, if the target network access gateway 2206 also support the TEID for CS setup, the target network access gateway will create a GTP-U tunnel TEID_CS to receive the forwarded downlink data from source network access gateway originating from the local CS 2218. The GTP-U tunnel TEID for the local CS 2218 may also be set up in the target SGW 2214 if indirect data forwarding is needed. In operation 2222, after the mobile device 2202 has established a connection with the target network access gateway 2206, the source network access gateway 2204 will notify the local CS 2218 to update the downlink GTP_U TEID to switch from source network access gateway 2204 to the target network access gateway 2206. Thereafter, the data from the local CS 2218 is sent directly from the local CS 2218 to the target network access gateway 2206, and then to the mobile device 2202.

FIG. 23 illustrates a signal flow diagram 2300 of content delivery to a mobile device after a handover procedure in accordance with various aspects of the disclosure. The signal flow diagram 2300 includes a mobile device 2302, a source network access gateway 2304, a target network access gateway 2306, a source SGW 2308, a target SGW 2310, a PGW 2312, and a local CS 2314.

As shown in

operations

1 and 2, when a handover to a target network access gateway is performed, on-going transfer of content may be forwarded from the source network access gateway 2308 to the target network access gateway 2306 if packet forwarding is supported. As shown in

operations

3 and 4, if data forwarding in handover is not supported, UE application layer can start request for the missing content again. A new content request, same as the source network access gateway 2304, may be routed from target network access gateway to the MCS directly by IP packet. In operations 5 to 8, if the IP address of the local CS 2314 IP is not in the IP list of the target network access gateway 2306, the new request may be routed via EPS bearer GTP-U to the local CS 2314. The content may be sent back from the local CS 2314, GTP-U EPS bearer, target network access gateway 2306, and then to UE 2302.

In both the packet forwarding approach and the IP aware RAN approach, from the serving network access gateway perspective, there will be two downlink data flows. For example, one data flow may be received by the serving network access gateway from an SGW, while another data flow may be received from a local CS. The serving network access gateway combines the data flow from the local CS into the bearer in which the mobile device sends the uplink content request. This may be similar to the operation of a target network access gateway in a handover scenario with data forwarding. The serving network access gateway may add a PDCP number to data packets according to the packet arrival order and may then deliver the data packets to mobile device in the air interface.

In an aspect, the serving network access gateway may not have IP aware capability in the packet forwarding approach. However, the serving network access gateway B may have IP aware capability in the IP aware RAN approach. For example, the serving network access gateway may be capable of interpreting the IP layer.

In an aspect, in the packet forwarding solution, the PGW may trigger the direct tunnel setup between local CS and the serving network access gateway in addition to providing information associated with the serving network access gateway of the mobile device. In the IP aware RAN approach, the PGW may not set up a separate tunnel between the serving network access gateway and the local CS. In such case, the data packets are sent from/to the serving network access gateway to/from the local CS via NAT IP packets or a tunnel which is set up by the serving network access gateway.

For uplink packets (e.g., sent from a mobile device to a local CS) received at the serving network access gateway, in the packet forwarding approach, the uplink content fetch request is routed to the PGW via the legacy EPS bearer, then routed to the local CS. In the IP aware RAN approach, all the uplink packets targeted to the configured IP address will be routed to local CS directly by the serving network access gateway.

For downlink packets (e.g., from a local CS to a mobile device) sent from the serving network access gateway, in the packet forwarding solution, the downlink packets containing the content from the local CS may be transmitted to the mobile device via a mobile device specific direct tunnel between the serving network access gateway and the local CS. In the IP aware RAN approach, the downlink packets are sent back to the mobile device via the legacy IP routing (NAT approach) or tunnel (tunnel approach) .

As disclosed herein, the gateway of 3GPP network (e.g. PGW for LTE) may assist GSLB in selecting a CDN cache server for the mobile device. This is particularly useful when caching nodes are deployed below the PGW level (e.g., proximate to the serving network access gateway) , which is also referred to as a mobile CDN (MCDN) configuration. The MCDN may either work standalone or as a further acceleration of Internet CDN in a hierarchal type configuration.

Although some aspects herein are described in the context of Long Term Evolution (LTE) and LTE related entities (e.g., how a PGW may provide assistance in determining the local CS of a serving network access gateway) , it should be understood that the aspects disclosed herein may be equally adaptable in networks supporting protocols other than LTE. Therefore, it can be appreciated that the principles described herein may be generally applicable to other cellular networks, such as 3G or 5G networks.

As previously described, the assistance provided by the PGW may have two aspects: how to locate a local CS for a mobile device and how to deliver the content requested by the mobile device from the content server to the serving network access gateway directly. Two example network architectures and associated procedures for location of the local CS may involve the ALG NAT and the SLB in 3GPP network. To enable SLB in a 3GPP network option, the DNS may be configured with DNS protocol enhancement/extension to enable the DNS to know the querying UE’s IP address in a recursive querying case.

With respect to content delivery from a local CS to a serving network access gateway directly, two example approaches include packet forwarding and IP aware RAN. Because NAT is widely used in mobile Internet, the aspects disclosed herein take NAT into consideration. If NAT is not implemented, the approached described herein may be used by simply excluding operations and functions related to NAT. In comparison to the SIPTO/L-GW + Internet CDN approach, the aspects described herein do not expose the network access gateway to the Internet. Therefore, the aspects described herein may have reduced costs in IP security and networking.

It is noted that the aspects of the present disclosure may be described as a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.

Moreover, a storage medium may represent one or more devices for storing data, including read-only memory (ROM) , random access memory (RAM) , magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine-readable mediums and, processor-readable mediums, and/or computer-readable mediums for storing information. The terms “machine-readable medium” , “computer-readable medium” , and/or “processor-readable medium” may include, but are not limited to non-transitory mediums such as portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instruction (s) and/or data. Thus, the various methods described herein may be fully or partially implemented by instructions and/or data that may be stored in a “machine-readable medium” , “computer-readable medium” , and/or “processor-readable medium” and executed by one or more processors, machines and/or devices.

Furthermore, aspects of the disclosure may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage (s) . A processor may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

The various illustrative logical blocks, modules, circuits, elements, and/or components described in connection with the examples disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.

Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

The various features of the invention described herein can be implemented in different systems without departing from the invention. It should be noted that the foregoing aspects of the disclosure are merely examples and are not to be construed as limiting the invention. The description of the aspects of the present disclosure is intended to be illustrative, and not to limit the scope of the claims. As such, the present teachings can be readily applied to other types of apparatuses and many alternatives, modifications, and variations will be apparent to those skilled in the art.

Claims

A method of wireless communication for a first network gateway comprising:

receiving information associated with a cache server (CS) that is proximate to a network node serving a user equipment (UE) ； and

initiating a tunnel between the CS and the network node for delivery of data to the network node directly from the CS.
The method of claim 1, further comprising:

receiving, from a network entity, a first request for identification information associated with the network node serving the UE, the first request comprising an identifier associated with the UE；

determining the identification information associated with the network node； and

sending the identification information associated with the network node to the network entity.
The method of claim 2, wherein determining the identification information associated with the network node comprises:

sending a second request to a second network gateway , the second request being for the identification information associated with the network node； and

receiving the identification information associated with the network node from the second network gateway.
The method of claim 2, wherein the network entity is a global server load balancing (GSLB) device comprised in a content delivery network (CDN) .
The method of claim 2, wherein the network entity is a server load balancing (SLB) device.
A first network gateway, comprising:

a wireless communication circuit configured to communicate with a network node；

a processing circuit coupled to the wireless communication circuit, the processing circuit configured to

receive information associated with a cache server (CS) that is proximate to a network node serving a user equipment (UE) ； and

initiate a tunnel between the CS and the network node for delivery of data to the network node directly from the CS.
A first network gateway, comprising:

means for receiving information associated with a cache server (CS) that is proximate to a network node serving a user equipment (UE) ； and

means for initiating a tunnel between the CS and the network node for delivery of data to the network node directly from the CS.
A non-transitory processor-readable storage medium having one or more instructions operational in a first network gateway, which when executed by one or more processors causes the one or more processors to:

receive information associated with a cache server (CS) that is proximate to a network node serving a user equipment (UE) ； and

initiate a tunnel between the CS and the network node for delivery of data to the network node directly from the CS.
A method of wireless communication for a network node, comprising:

receiving a request for content from a user equipment (UE) ；

establishing a communication link with a cache server (CS) that is proximate to the network node, the CS configured to store the requested content；

receiving the content from the CS via the communication link； and

sending the content to the UE.
The method of claim 9, further comprising sending the request for content to a network gateway using an Evolved Packet switched System (EPS) bearer.
The method of claim 9, wherein the communication link comprises a tunnel established using a general packet radio service tunnel protocol (GTP) , and wherein the content is received directly from the CS via the tunnel in one or more GTP user plane (GTP-U) packets.
The method of claim 9, wherein sending the content to the UE comprises forwarding the content to the UE using a Packet Data Convergence Protocol (PDCP) .
The method of claim 9, wherein the request for content from the UE is comprised in a first Internet Protocol (IP) data packet, further comprising:

determining whether a destination IP address in the first IP data packet corresponds to an IP address of the CS；

performing a first NAT operation on the first IP data packet by changing a source address of the first IP data packet from an IP address of the UE to an IP address of the network node； and

sending the first IP data packet to the CS.
The method of claim 13, wherein the content received from the CS via the communication link is comprised in one or more second IP data packets, further comprising:

performing a second NAT operation on the one or more second IP data packets by changing a destination address of the one or more second IP data packets from the IP address of the network node to the IP address of the UE； and

sending the one or more second IP data packets to the UE.
The method of claim 9, wherein establishing the communication link comprises establishing a tunnel between the network node and the CS, wherein the content from the CS is received directly from the CS through the tunnel.
A network node, comprising:

a wireless communication circuit configured to communicate with a user equipment (UE) ；

a processing circuit coupled to the wireless communication circuit, the processing circuit configured to

receive a request for content from the UE；

establish a communication link with a cache server (CS) that is proximate to the network node, the CS configured to store the requested content；

receive the content from the CS via the communication link； and

send the content to the UE.
A network node, comprising:

means for receiving a request for content from a user equipment (UE) ；

means for establishing a communication link with a cache server (CS) that is proximate to the network node, the CS configured to store the requested content；

means for receiving the content from the CS via the communication link； and

means for sending the content to the UE.
A processor-readable storage medium having one or more instructions operational in a network node, which when executed by one or more processors causes the one or more processors to:

receive a request for content from a user equipment (UE) ；

establish a communication link with a cache server (CS) that is proximate to the network node, the CS configured to store the requested content；

receive the content from the CS via the communication link； and

send the content to the UE.
A method of wireless communication for a network entity, comprising:

receiving a first request for a location of content from a user equipment (UE) ；

determining identification information of a first network node associated with the UE； and

sending the location of the content based on the identification information of the first network node.
The method of claim 19, wherein determining the identification information of the first network node associated with the UE comprises:

sending a second request to a second network node； and

receiving, from the second network node, a response including the identification information of the first network node associated with the UE.
The method of claim 19, wherein the second request includes an Internet Protocol (IP) address of the UE, an International Mobile Subscriber Identity (IMSI) of the UE, or information that identifies the UE to the second network node.
The method of claim 19, wherein the identification information of the first network node associated with the UE is an actual identification (ID) , an ID configured for the first network node to indicate an optimal CS, or an Internet Protocol (IP) address of the first network node.
The method of claim 19, wherein the network entity is a global server load balance (GSLB) device or a server load balance (SLB) device.
The method of claim 19, wherein the first network node is a base station serving the UE or a network gateway associated with the UE.
A network entity, comprising:

a wireless communication circuit configured to communicate with a network node；

a processing circuit coupled to the wireless communication circuit, the processing circuit configured to

receive a first request for a location of content from a user equipment (UE) ；

determine identification information of a first network node associated with the UE；and

send the location of the content based on the identification information of the first network node.
A network entity, comprising:

means for receiving a first request for a location of content from a user equipment (UE) ；

means for determining identification information of a first network node associated with the UE； and

means for sending the location of the content based on the identification information of the first network node.
A non-transitory processor-readable storage medium having one or more instructions operational in a network entity, which when executed by one or more processors causes the one or more processors to:

receive a first request for a location of content from a user equipment (UE) ；

determine identification information of a first network node associated with the UE；and

send the location of the content based on the identification information of the first network node.