WO2016201411A1 - Reducing the http server load in an http-over-icn scenario - Google Patents

Abstract

Methods and systems are provided for receiving a first ICN packet comprising an encapsulated first HTTP request which includes a first URL. In response to receiving the first ICN packet, an ICN device may transmit a second HTTP request to a server identified by the URL of the first HTTP request and receive a corresponding HTTP response. The received corresponding HTTP response may be published and a second ICN packet comprising an encapsulated third HTTP request may be received which comprises a second URL. If the first URL and the second URL are identical, meaning the two ICN packets comprise requests for identical content, the third HTTP request may be suppressed, thereby reducing traffic to and from an HTTP server. In an embodiment, the HTTP server may be an MPEG DASH video server.

Description

REDUCING THE HTTP SERVER LOAD

IN AN HTTP-OVER-ICN SCENARIO

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application

Serial No. 62/174,992 filed June 12, 2015, the contents of which are hereby incorporated by reference herein.

SUMMARY

[0002] Methods and systems for enabling hypertext transfer protocol

(HTTP) communication between a first internet protocol IP-only device and a second IP-only device over an information-centric networking (ICN) network. Methods and systems are further disclosed for removing unnecessary HTTP requests and responses in an ICN network access point (NAP). The HTTP requests and responses may originate from either the first IP-only device or the second IP-only device.

[0003] Methods and systems are disclosed for receiving a first ICN packet comprising an encapsulated first HTTP request which includes a first universal resource locator (URL). In response to receiving the first ICN packet, an ICN device may transmit a second HTTP request to a server identified by the URL of the first HTTP request and receive a corresponding HTTP response. The received corresponding HTTP response may be published and a second ICN packet comprising an encapsulated third HTTP request may be received which comprises a second URL. If the first URL and the second URL are identical, meaning the two ICN packets comprise requests for identical content, the third HTTP request may be suppressed, thereby reducing traffic to and from an HTTP server. In an embodiment, the HTTP server may be a Motion Picture Experts Group Dynamic Adaptive Streaming over HTTP (MPEG DASH) video server.

[0004] The HTTP response may be transmitted to a plurality of quasi- synchronized requestors using a multicast transmission format. The methods and systems disclosed herein may be applicable to operation at the L3 application layer. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0006] FIG. lAis a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0007] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;

[0008] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

[0009] FIG. 2 is a network diagram illustrating a client and server inside an information-centric networking (ICN) network;

[0010] FIG. 3 is a network diagram illustrating a client inside an ICN network with server outside the ICN network; and

[0011] FIG. 4 is a flowchart illustrating an exemplary hypertext transfer protocol (HTTP) request suppression method.

DETAILED DESCRIPTION

[0012] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. [0013] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like. Each of the WTRUs may execute software which implements an HTTP client. An HTTP client may be a commercial application such as an internet browser. Alternatively or in combination, an HTTP client may be a lightweight application which implements a client side HTTP protocol. An HTTP client may be part of an operating system or sold separately from an operating system.

[0014] The communications systems 100 may also include a base station

114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0015] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a articular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0016] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0017] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may estabhsh the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0018] In another embodiment, the base station 114a and the WTRUs 102a,

102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may estabhsh the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0019] In other embodiments, the base station 114a and the WTRUs 102a,

102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0020] The base station 114b in FIG. 1A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0021] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location -based services, pre-paid calhng, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0022] The core network 106 may also serve as a gateway for the WTRUs

102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0023] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0024] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display /touchp ad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0025] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0026] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0027] In addition, although the transmit/receive element 122 is depicted in

FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0028] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0029] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display /touchp ad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0030] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0031] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0032] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0033] FIG. 1C is a system diagram of the RAN 104 and the core network

106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0034] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0035] Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0036] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0037] The MME 142 may be connected to each of the eNode-Bs 140a, 140b,

140c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0038] The serving gateway 144 may be connected to each of the eNode Bs

140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0039] The serving gateway 144 may also be connected to the PDN gateway

146, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0040] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0041] Other network 112 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may contain gateway functionality. The access router 165 may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router 165 andAPs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102d.

[0042] Information-centric networking (ICN) constitutes a new paradigm in which content may be exchanged by way of information addressing. ICN connects appropriate networked entities that are suitable to act as a source of information toward a networked entity that requested content.

[0043] Architectures have been proposed in this space, each requiring the partial replacement of current network infrastructure in order to realize the desired network-level functions of these architectures. Some migration scenarios foresee that the new proposed architectures could be realized as an overlay over existing architectures, for example, IP- or local Ethernet-based networks . Such migration, however, would still require the transition of a user equipment (UE) to an ICN-based solution. With IP -based applications providing a broad range of Internet services already in use, transitioning all of these applications may easily be viewed as a much harder task than the pure transition of the network-level functionality, for example, protocol stack implementation, in a UE since it also requires the transition of the server-side components, for example, e-shopping web-servers and the like. Hence, it is assumed that IP -based services, and with it purely IP-based UEs, will continue to exist for some time to come.

[0044] The transition to ICN at the network level, on the other hand, may provide for several improvements including increased efficiency through the usage of in-network caches, a spatial and temporal decouphng of a sender and receiver, and a utilization of software defined networking (SDN) upgrades for better flow management, among other things.

[0045] Embodiments disclosed in co-pending PCT Application Number

PCT/US2016/015713, herein incorporated by reference, outline a method for providing HTTP -level services over an ICN network, mapping HTTP request and response methods into appropriate ICN packets, and publishing those packets toward appropriate ICN names. The mapping may be performed at the Network Attachment Point (NAP) of the client and server, respectively. The mapping may also be performed at the ICN border gateway (BGW) for cases of HTTP methods being sent to and from peering networks. The implementation of the mapping at the NAP comes, however, with a drawback. Consider a video over HTTP scenario where a group of viewers are watching the video in a quasi-synchronized manner, for example, within the same timeframe but slightly out of sync. Due to the coincidence nature of having requested the same video chunk at a quasi-similar point in time, this group of viewers may be referred to as a "coincidental multicast group". The size and nature of such group may change for every response being considered for sending. One or more methods disclosed in copending PCT Application Number PCT/US2016/015713 allow for utilizing the inherent ICN multicast capabilities for the HTTP response methods. For example, the video chunks in the quasi-synchronized scenario described above, by publishing the responses to the group of viewers that have requested the chunk at the very point in time when the response is sent from the server NAP. The size of this group, herein named s, varies and depends on the degree of synchronization among a subset of viewers within a given time interval t. Time interval t may be determined from the various delays from the incoming HTTP request method to the moment of sending the first HTTP response. For all viewers in this group, the response may be delivered via multicast, leading to significant savings compared to the inevitable unicast delivery in the case of HTTP-over-IP networks. However, the server NAP will still receive s-1 HTTP response methods from the server, since s HTTP request methods have been sent in total to the server, one from each member of the coincidental multicast group. Hence, while co-pending PCT Application Number PCT/US2016/015713 discloses reducing the load on the ICN network by utilizing its multicast capabilities; it does not disclose how to reduce the load on the server-NAP link. This is due to all requests, and therefore all corresponding responses, being sent on the server- NAP link. Disclosed herein is a system and method that minimizes unnecessary HTTP request/response messages being sent over the server-NAP link for HTTP- over-ICN systems.

[0046] In one embodiment, the NAP may provide a standard IP network interface toward the IP-enabled device and may encapsulate any received HTTP requests into an appropriate ICN packet. The ICN packet may then be pubhshed as an appropriately formed named information item. Conversely, the NAP subscribes to any appropriately formed named information items where the information identifier represents any HTTP-exposed service that is exposed at any IP-level device locally connected to the NAP. Any received ICN packet may then be forwarded to the appropriate local IP device after being appropriately de- encapsulated, thereby recovering the original HTTP request. Additionally, an ICN BGW may receive ICN packets from NAPs in its network that are destined to an HTTP-level service outside of its network and forward these packets toward the appropriate IP networks. Conversely, any received HTTP request at the BGW may be forwarded to the appropriate IP-based device in its local ICN network. Furthermore, group management solutions may be utilized that build on information provided by the ICN rendezvous point. These solutions may allow for a determination to be made regarding the current size of a group of subscribers of a particular information item.

[0047] FIG. 2 is a network diagram illustrating a client 240A and server

240B inside an ICN network 210. In an example, client 240A is an HTTP compliant client and server 240B is an HTTP compliant server. An HTTP client may incorporate all or a portion of an internet browser application which executes on a UE or a WTRU. An HTTP client may also be a component of a special purpose application or mobile application. In one embodiment, an HTTP client implements a full HTTP client side protocol stack. An HTTP server may be a server which implements all or a portion of a server side HTTP protocol. An HTTP server may run a commercial web server application or an open-source web server application. In a scenario, both the client and server are attached to the ICN network 210 respectively through client network attachment point (cNAP) 230 A and server network attachment point (sNAP) 230B. A rendezvous point 220 is located inside the ICN network 210.

[0048] FIG. 3 is a network diagram illustrating a client 350 inside an ICN network 310 with a server 360 outside the ICN network 310. In this scenario, an ICN border gateway 370 may be provided between server 360 and the rendezvous point 330. A remote network 320 may connect ICN network 310 to server 360 over ICN border gateway 360 and border gateway 370. Client 350 may be in communication with ICN network 310 through cNAP 340.

[0049] A number of methods, which are disclosed herein, may be used to suppress unnecessary HTTP requests sent to a server and therefor also suppress the reception of unnecessary HTTP response methods received from a server at the server NAP.

[0050] FIG. 4 is a flowchart illustrating an exemplary hypertext transfer protocol (HTTP) request suppression method. In one embodiment, after sending an HTTP request 402 and receiving an HTTP response from the server 404, the server NAP checks the number of subscribers to the appropriate ICN name for the URL provided in the HTTP response 406. In one embodiment, the number of subscribers is checked by subscribing to the appropriate group size metadata information at the rendezvous point and receiving a notification with the current size of the subscriber group. In another embodiment, the number of incoming HTTP request messages to the same URL are counted and the number of subscribers to the HTTP response is estimated using this count.

[0051] The server NAP may send the HTTP response 408 in accordance with the methods outlined in co-pending PCT Application Number PCT/US2016/015713. The server NAP stores the URL of the HTTP response in an internal table, together with the count. [0052] A cNAP to which a specific IP-based client wanting to retrieve a content named URL is connected, may publish HTTP packets of the IP -based clients to an information item, while the sNAP, which the device exposing a service under a given fully qualified domain name (FQDN), may subscribe to the information item. The response to any HTTP level communication may be sent by the sNAP which the server is connected, towards the information item named response CID (rCID), which may be determined through hashing of the URL, to which the cNAP of the client in turn may subscribe to.

[0053] With HTTP responses to information requests, any response of the server to the information request received having name CID may be published by the server as an information item named rCID (which may be determined by hash(URL)). The cNAP to which an IP-based client is connected may subscribe to the information item named rCID and may therefore receive any HTTP response for the information exchange pertaining to the HTTP-level communication towards the URL.

[0054] In an example, an entity may indicate interest in an appropriate

ICN name. A publish-subscribe model may be the underlying semantic for the ICN network. For example, ICN information items may be published by a first ICN entity and retrieved by subscribing to the first ICN entity at another ICN entity. The interest indication may be removed from the ICN network by unsubscribing from the ICN name. HTTP packets may be encapsulated in ICN packets. The ICN packets may assume a very generic ICN packet format, comprising the ICN name, a possible options header and the payload. Accordingly, the encapsulation of IP packets may insert the appropriate ICN name into the appropriate packet header, set any appropriate options in the options header and then copy the entirety of the HTTP packet into the payload of the ICN packet. In a further example, an ICN packet may be fragmented into multiple smaller chunks and this operation may be transparent to the encapsulation of the HTTP packet.

[0055] The server NAP may receive additional incoming HTTP request messages 410 from the ICN network and may perform a check to determine if the corresponding URL matches any URL stored in its internal table 412. If the URL is not found, the HTTP request message may be handled again 422 in accordance with the methods disclosed in co-pending PCT Application Number PCT/US2016/015713. If the URL is found, the HTTP request message is suppressed 414 and not forwarded to the server. The count in the corresponding table entry is lowered by one 416. If the count has reached zero 418, the table entry is removed 420. If the count has not yet reached zero, the modified count is stored in the appropriate table entry.

[0056] The methods disclosed may be realized similarly at the ICN border

GW in scenarios where the server resides in a peering IP network as shown in FIG. 3. In this case, the 'server' as used above may be replaced by a 'peering IP network'.

[0057] In one embodiment, removing unnecessary HTTP requests is optional and may be realized in the NAP on a domain name basis. For example, for an advertisement-driven website, the removal of an HTTP request might lead to reduced 'eyeballs', for example, page hits. In the case of a Motion Picture Experts Group Dynamic Adaptive Streaming over HTTP (MPEG DASH) video server, the removal of HTTP requests for the transmission of the same video may lead to a reduction of server load and is therefore desirable. Hence, the NAP may differentiate the incoming HTTP requests based on the above considerations and the settings stored within the NAP, make a determination to implement the HTTP request removal or not implement the HTTP request removal.

[0058] In another embodiment, the removal process is part of a special server NAP offering, for example, toward a specific video service, such as Amazon Prime Video. Here, authorization and other user specific transactions are handled via normal HTTP transactions. In this embodiment, since the removal of all unnecessary HTTP requests leads to a desirable server traffic reduction, the entire domain of the server attached to the NAP may utilize the HTTP request removal.

[0059] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

^• * *

Claims

1. A method for use in an information centric network (ICN) device, the method comprising:

receiving, from a first HTTP client via an ICN, a first ICN packet comprising an encapsulated first hypertext transfer protocol (HTTP) request, wherein the first HTTP request includes a first universal resource locator (URL); transmitting a second HTTP request to a server identified by the URL of the first HTTP request;

receiving, from the server, a first HTTP response corresponding to the second HTTP request;

encapsulating the received first HTTP response into a second ICN packet and transmitting the second ICN packet to the first HTTP client via the ICN; receiving a third ICN packet from a second HTTP client, wherein the third ICN packet comprises an encapsulated third HTTP request comprising a second URL; and

on a condition that the first URL and the second URL are identical: suppressing the third HTTP request by not transmitting a corresponding HTTP request to the server; and

transmitting the second ICN packet to the second HTTP client via the ICN.

2. The method of claim 1, wherein the second ICN packet comprising the encapsulated first HTTP response is transmitted to a plurality of quasi- synchronized HTTP clients via the ICN.

3. The method of claim 2, wherein the second ICN packet is transmitted to the first HTTP client or the second HTTP chent using a multicast transmission.

4. The method of claim 1, further comprising:

on a condition that the first URL and the second URL are identical, decrementing a count corresponding to a number of subscribers.

5. The method of claim 4, further comprising:

on a condition that the count corresponding to the number of subscribers is equal to zero, removing a table entry in a database, wherein the table entry corresponds to the first URL.

6. The method of claim 1, further comprising:

on a condition that the first URL and second URL are not identical: transmitting a fourth HTTP request to a second server identified by the second URL;

receiving, from the second server, a second HTTP response corresponding to the fourth HTTP request; and

encapsulating the received second HTTP response into a third ICN packet and transmitting the third ICN packet to the second HTTP client via the ICN.

7. The method of claim 1, wherein the first URL is an address of a file stored on a Motion Picture Experts Group Dynamic Adaptive Streaming over HTTP (MPEG DASH) video server.

8. An information centric network (ICN) device, comprising:

a transceiver configured to receive a first ICN packet comprising an encapsulated first hypertext transfer protocol (HTTP) request from a first HTTP client via an ICN, wherein the first HTTP request includes a first universal resource locator (URL);

the transceiver is further configured to transmit a second HTTP request to a server identified by the URL of the first HTTP request; the transceiver is further configured to receive a first HTTP response corresponding to the second HTTP request;

circuitry configured to encapsulate the received first HTTP response into a second ICN packet and instruct the transceiver to transmit the second ICN packet to the first HTTP chent via the ICN;

the transceiver is further configured to receive a third ICN packet from a second HTTP chent, wherein the third ICN packet comprises an encapsulated third HTTP request comprising a second URL; and

circuitry configured to, on a condition that the first URL and the second URL are identical:

suppress the third HTTP request, wherein a corresponding HTTP request to the server is not transmitted; and

transmit the second ICN packet to the second HTTP client via the

ICN.

9. The ICN device of claim 8, wherein the second ICN packet comprising the encapsulated first HTTP response is transmitted to a plurality of quasi-synchronized HTTP clients via the ICN.

10. The ICN device of claim 9, wherein the second ICN packet is transmitted to the first HTTP client or the second HTTP chent using a multicast transmission.

11. The ICN device of claim 8, further comprising:

circuitry configured to, on a condition that the first URL and the second URL are identical, decrement a count corresponding to a number of subscribers.

12. The ICN device of claim 11, further comprising:

circuitry configured to, on a condition that the count corresponding to the number of subscribers is equal to zero, remove a table entry in a database, wherein the table entry corresponds to the first URL.

13. The ICN device of claim 8, further comprising:

the transceiver is further configured to, on a condition that the first URL and second URL are not identical:

transmit a fourth HTTP request to a second server identified by the second URL;

receive, from the second server, a second HTTP response corresponding to the fourth HTTP request; and

encapsulate the received second HTTP response into a third ICN packet and transmit the third ICN packet to the second HTTP client via the ICN.

14. The ICN device of claim 8, wherein the first URL is an address of a file stored on a Motion Picture Experts Group Dynamic Adaptive Streaming over HTTP (MPEG DASH) video server.

15. A method for operation in an information centric network (ICN) device, the method comprising:

receiving a first ICN packet comprising an encapsulated first HTTP request via an ICN, wherein the first HTTP request includes a first universal resource locator (URL);

on a condition that the first URL does not match any URL stored in a database of the ICN device, transmitting the encapsulated first HTTP request to a server identified in the first HTTP request; and

on a condition that the first URL matches a URL stored in the database of the ICN device, suppressing the HTTP request by not transmitting a corresponding HTTP request to the server.

16. The method of claim 15, further comprising:

receiving an HTTP response from the server; and

transmitting the HTTP response to a plurality of quasi-synchronized HTTP clients via the ICN.

17. The method of claim 16, wherein the HTTP response is transmitted using a multicast transmission.

18. The method of claim 15, wherein the first URL is an address of file stored on a Motion Picture Experts Group Dynamic Adaptive Streaming over HTTP (MPEG DASH) video server.

19. The method of claim 15, wherein the ICN device is a server network attachment point (sNAP).

20. The method of claim 15, wherein the encapsulated first HTTP request of the first ICN packet is a request made by an Internet Protocol (IP) capable device which does not implement an ICN compliant protocol.