WO2014074802A1 - Controlling traffic in information centric networks - Google Patents

Abstract

Congestion management may be performed based on congestion notification, e.g., explicit congestion notification. For example, a congestion level may be determined, and data may be marked based on the level of congestion. Random early marking may be used for congestion notification. A level of congestion may be indicated by receiving, at a device, a request for data. A level of congestion associated with the device may be determined. The data may be marked based on the level of congestion. The marked data may be sent. The marked data may indicate the level of congestion associated with the device.

Description

CONTROLLING TRAFFIC IN INFORMATION CENTRIC NETWORKS

CROSS REFERENCE TO RELATED APPLICATIONS

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

61 /724,833, filed November 9, 2012, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] The Internet and mobile networks may be used for content retrieval and information access. Video and mobile video are growing traffic segments in global Internet and mobile networks.

[0003] Content (e.g., streaming video) may be delivered to a user from a best and/or closes! host. The eonieni delivery mechanism may match operating condiiions of a target user device, and the content may be delivered in a proper format and at a best available quality. Internet Protocol (IP) networks and the TCP/IP architecture may fail to deliver content in a proper format or may fail to deliver content at a best available quality.

[0004] Information- Centric Networking (ICN), also referred to as Content- Oriented

Networking (CON) or Content- Centric Networking (CCN), may address the shortcomings of IP in content distribution, mobility, and/or multi-homing support. ICN may decouple the address and identity at the network level. A content object may be retrieved using its identifier rather than its storage location (e.g., host IP address).

[0005] End-to-end per-flow traffic control mechanisms may treat an ICN flow more like a typical TCP flow. These pre-flow traffic control mechanisms may fail to consider the multi-source and multi-destination traffic nature of ICN s, which may make it difficult to maintain per-flow fair queuing.

[0006] The design and implementation of robust and efficient per-flow control algorithms may be problematic. For example, per-flow request rate control may be performed at a Content Router (CR) that may send or forward the requests. It may be assumed that the request sender knows the downlink rate for the data transmission. In practice, the downlink may be shared with other traffic (e.g., TCP traffic). It may be very difficult for a request sender to predict a link rate for ICN data. Additionally, in wireless networks, the link capacity may vary during a transfer, for example, due to channel conditions.

SUMMARY

[0007] Congestion management may be performed based on congestion notification, e.g., explicit congestion notification. For example, a congestion level may be determined, and data may be marked based on the level of congestion. The marked data may be sent to a downstream device. The downstream device (e.g., a WTRU) may detect the marking in the data. The downstream device may modify its requests based on the marking. For example, the marking may indicate that the sending device is congested, and when requesting additional data, the downstream device may not send such requests (or send less requests) to the device that sent the marked data indicating congestion.

[0008] A device (e.g., a router) may receive a request for data. For example, an end user device such as a WTRU may send a request for multimedia data to an intermediate router (e.g., a content router). A level of congestion associated with the device may be determined (e.g., not congested, a first level of congestion, a second level of congestion, etc. ). For example, a content router may receive requests for data from one or more devices (e.g., end user devices), and in response, send request(s) to source(s) (e.g., content sources) for the data. The device may receive data fro the source(s). The device may have a level of congestion that may depend on the amount of traffic currently being routed through it (e.g., traffic awaiting transmission). The device may mark the data to be delivered to the device that requested the data, and, the marking may be ba sed on the determined level of congestion. The device may send the marked data to the device that requested the data. The marked data may indicate the level of congestion associated with the device.

[0009] Marking the data based on the level of congestion may comprise marking the data with a congestion mark at a first rate on a condition that the data awaiting transmission exceeds a first threshold and is less than a second threshold. Marking the data based on the level of congestion may comprise marking the data with the congestion mark at a second rate, which may be higher than the first rate, on a condition that the data awaiting transmission exceeds the second threshold.

[0010] A marking pattern associated with the level of congestion may be determined.

A packet in the data may be marked on a condition that the packet is indicated by the marking pattern. The marking pattern may comprise a packet marking probability. The indication of the level of congestion may comprise a rate of marked packets in the data.

[001 1 ] When a router, e.g. , an intermediate router or a content router, receives a request, but is congested, it may discard the request packet and may send a Request Response (RR) packet to the requester, for example, to indicate the congestion. Request packets may be discarded with a probability that varies as a function of a level of congestion. For example, if a data transmit queue is greater than a first threshold, request packets may be discarded with a first probability . If the data transmit queue is greater than a second threshold, request packets may be discarded with a second probability.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1A depicts a syste diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0013] FIG. IB depicts a system diagram of an example wireless transmit/receive unit

(WTRU) that may be used within the communications system illustrated in FIG. 1 A.

[0014] FIG. 1 C depicts a system diagram of an example radio access network and an example core network that may be used within the commimications system illustrated in FIG. 1A.

[0015] FIG. ID depicts 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.

[0016] FIG. IE depicts 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.

[0017] FIG. 2 depicts a diagram of an example system.

[0018] FIG. 3 depicts an example Content Object Transport Unit (CTU).

[0019] FIG. 4 depicts a block diagram of an example Content Router (CR).

[0020] FIG. 5 depicts an example protocol stack that corresponds to the example CR depicted in FIG. 4.

[0021 ] FIG. 6 depicts a block diagram of another example content router.

[0022] FIG. 7 depicts another example protocol stack that corresponds to the example

CR depicted in FIG. 6. [0023] FIG. 8 depicts an example content data packet format and an example content header.

[0024] FIG. 9 depicts an example request or interest packet.

[0025] FIG. 10 depicts an example transmitter protocol architecture for hop-by-hop transport,

[0026] FIG. 1 1 depicts an example receiver protocol architecture for liop-by-1 transport.

[0027] FIG. 12 depicts an example packet marking probability.

[0028] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed examples 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 (OFDM A), single-carrier FDMA (SC-FDMA), and the like.

[0029] As shown in FIG. 1A, the communications system 100 may include at least one wireless transmi t/receive unit ( WTRU), such as a plurality of WTRUs, for instance WTRUs 102a, 102b, 102c, and 102d, radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, though it should 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.

[0030] The communications systems 100 may also include a base station 1 14a and a base station 1 14b. Each of the base stations 114a, 1 14b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 02c, 102d to facilitate access to one or more communication networks, such as the core network 106, the internet 1 10, and/or the networks 1 12. By way of example, the base stations 1 14a, 1 14b may be a base transceiver station (BTS), a Node-B, an e ode 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 1 14a, 1 14b are each depicted as a single element it should be appreciated that the base stations 1 14a, 1 14b may include any number of interconnected base stations and/or network elements.

[0031] The base station 1 14a may be part of ihe RAN 104, which ma 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 1 14a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals within a particular 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 1 14a may be divided into three sectors. Thus, in one example, the base station 1 14a may include three transceivers, e.g., one for each sector of the ceil. In another example, the base station 1 14a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0032] The base stations 1 14a, 1 14b may communicate with one or more of the

WTRUs 102a, 102b, 102c, 102d over an air interface 1 16, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 1 16 may be established using any suitable radio access technology (RAT).

[0033] 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 1 14a 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 establish the air interface 1 16 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). [0034] In another example, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- LiTRA), which may establish the air interface 1 16 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0035] In other examples, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., 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 (18-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0036] The base station 1 14b in FIG. IA 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 1 14b 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 1 14b 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 1 14b 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. 1 A, the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the core network 106.

[0037] 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) sendees to one or more of the WTRUs 102a, 102b, 102c, I02d. For example, the core network 106 may provide call control, billing services, mobile location- based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it should 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 FL T 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 ,

[0038] The core network 106 may also serve as a gateway for the WTRUs 102a,

102b, 102c, 102d to access the PSTN 108, the Internet 1 10, and/or other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone sendee (POTS). The Internet 1 10 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 1 12 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 1 12 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.

[0039] Some or all of the WTRUs 102a, 102b, 102c, i02d in the communications system 100 may include multi-mode capabilities, e.g., 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 1 14a, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology.

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

[0041] The processor 1 18 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 1 18 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 1 18 may be coupled to ihe transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. I B depicts the processor 1 18 and the transceiver 120 as separate components, it should be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0042] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface 1 16. For example, in one example, the transmit/receive element 22 may be an antenna configured to transmit and/or receive RF signals. In another example, the transmit/receive element 122 may^¬ be an emitter/detector configured to transmit and/or receive IR, LTV, or visible light signals, for example. In yet another example, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It should be appreciated that the

transmit/receive element 12.2 may be configured to transmit and/or receive any combination of wireless signals,

[0043] 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 1 16.

[0044] 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.1 1, for example.

[0045] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or ihe display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light- emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, ihe keypad 126, and/or the display/touchpad 128. In addition, ihe processor 1 18 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 1 18 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).

[0046] The processor 1 18 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 ceils, fuel cells, and the like.

[0047] The processor 1 18 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 1 16 from a base station (e.g., base stations 1 14a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It should be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an example.

[0048] The processor 1 18 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.

[0049] FIG . 1C is a sy stem diagram of an example of the communications system 100 that includes a RAN 104a and a core network 106a that comprise example implementations of the RAN 104 and the core network 106, respectively. As noted above, the RAN 104, for instance the RAN 104a, may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 1 16. The RAN 104a may also be in communication with the core network 106a. As shown in FIG. 1C, the RAN 104a may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16, The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 104a. The RAN 104a may also include RNCs 142a, 142b. It should be appreciated that the RAN 104a may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0050] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, I40c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0051 ] The core network 106a shown in FIG. 1C may include a media gateway

(MGW) 144, a mobile switching center (MSG) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. Whil e each of the foregoing elements is depicted as part of the core network 106a, it should be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0052] The RNC 142a in the RAN 104a may be connected to the MSG 146 in the core network 106a via an IuCS interface. ^'The MSG 146 may be connected to the MGW 144, The MSG 146 and the MGW" 144 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.

[0053] The RNC 142a in the RAN 104a may also be connected to the SGSN 148 in the core network 106a via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices,

[0054] As noted above, the core network 106a may also be connected to the networks

1 12, which may include other wired or wireless networks that are owned and/or operated by- other service pro viders,

[0055] FIG. I D is a system diagram of an example of the communications system 100 that includes a RAN 104b and a core network 106b that comprise example implementations of the RAN 104 and the core network 106, respectively. As noted above, the RAN 104, for instance, the RAN 104b, may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 1 16. The RAN 104b may also be in communication with the core network 106b.

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

[0057] Each of the eNode-Bs 140d, 140e, and 140f 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. ID, the eNode-Bs 140d, 140e, 140f may communicate with one another over an X2 interface.

[0058] The core network 106b shown in FIG. ID may include a mobility

management gateway (MME) 143, a serving gateway 145, and a packet data network (PDN) gateway 147. While each of the foregoing elements is depicted as part of the core network 106b, it should be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0059] The MME 143 may be connected to each of the eNode-Bs 140d, 140e, and

140f in the RAN 104b via an S I interface and may serve as a control node. For example, the MME 143 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 143 may also provide a control plane function for switching between the RAN 104b and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0060] The serving gateway 145 may be connected to each of the eNode Bs 140d,

140e, 140f in the RAN 104b via the SI interface. The serving gateway 145 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 145 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.

[0061 ] The serving gateway 145 may also be connected to the PDN gateway 147, 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.

[0062] The core network 106b may facilitate communications with other networks.

For example, the core network 106b 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 106b may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that may serve as an interface between the core network 106b and the PSTN 108. In addition, the core network 106b may provide the WTRUs 102a, 102b, 102c with access to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0063] FIG. IE is a system diagram of an example of the communications system 100 that includes a RAN 104c and a core network 106c that comprise example implementations of the RAN 104 and the core network 106, respectively. The RAN 104, for instance, the RAN 104c, may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. As described herein, the communication links between the different func tional entities of the WTRUs 102a, 102b, 102c, the RAN 104c, and the core network 106c may be defined as reference points.

[0064] As shown in FIG. I E, the RAN 104c may include base stations 102a, 102b,

102c, and an ASN gateway 141, though it should be appreciated that the RAN 104c may include any number of base stations and AS gateways while remaining consistent with an example. The base stations 102a, 102b, 102c may each be associated with a particular cell (not shown) in the RAN 104c and may each include one or more transceivers for

communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16, In one embodiment, the base stations 140g, 140h, 140i may implement MIMO technology. Thus, the base station 140g, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 140g, 140h, 140i may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy

enforcement, and the like. The ASN Gateway 141 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106c, and the like.

[0065] The air interface 1 16 between the WTRUs 102a, 102b, 102c and the RAN

104c may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not sho wn) wiih the core network 106c. The logical interface between the WTRUs 102a, 102b, 102c and the core network 106c may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0066] The communication link between each of the base stations 140g, 140b, 1401 may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 140g, 140h, 140i and the ASN gateway 141 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0067] As shown in FIG. I E, the RAN 104c may be connected to the core network

106c. The communication link between the RAN 104c and the core network 106c may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 106c may include a mobile IP home agent (MIP-HA) 144, an authentication, authorization, accounting (AAA) server 156, and a gateway 158. While each of the foregoing elements is depicted as part of the core network 106c, it should he appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator,

[0068] The MIP-HA may be responsible for TP address management, and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and/or different core networks. The MIP-HA 154 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet ί 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 156 may be responsible for user authentication and for supporting user services. The gateway 158 may facilitate interworking with other networks. For example, the gateway 158 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 iandline communications devices. In addition, the gateway 158 may provide the WTRUs 102a, 102b, 102c with access to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0069] Although not shown in FIG. IE, it should be appreciated that the RAN 104c may be connected to other ASNs and the core network 106c may be connected to other core networks. The communication link between the RAN 104c the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 104c and the other ASNs. The communication link between the core network 106c and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0070] The disclosed subject matter may be implemented, for example, in a router, e.g., a content router, a switch, or the like. The router may include a processor, a transceiver, a transmit/receive element, non-removable memory, removable memory, and/or a power source. It should be appreciated that the router may include any sub-combination of the foregoing elements while remaining consistent with the disclosed subject matter,

[0071] The processor 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 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the router to operate in a wired or wireless environment. The processor may be coupled to the transceiver, which may be coupled to the transmit/receive element. The processor and the transceiver may be implemented as separate components or may be integrated together in an electronic package or chip.

[0072] The transmit/receive element may be configured to transmit signals to, or receive signals from, a WTRU or a base station {e.g., the base station) over the air interface. The transmit receive element may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element may be an emitter/detector configured to transmit and/or receive TR, UV, or visible light signals, for example. In yet another example, the transmit/receive element may be configured to transmit and receive both RF and light signals. It should be appreciated that the transmit/receive element may be configured to transmit and/or receive any combination of wireless signals. The transmit/receive element may be implemented as a single element or as multiple elements. The router may employ MIMO technology and may include two or more transmit/receive elements {e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface.

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

[0074] The processor may access information from, and store data in, any type of suitable memory, such as the non-removable memory and/or the removable memory. The non-removable memory may include random-access memor '' (RAM), read-only memory (ROM), a hard disk, or any other type of memoiy storage device. The removable memoi may include a subscriber identity module (SIM) card, a memor stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor may access information from, and store data in, memory that is not physically located on the router, such as on a server or a home computer (not shown).

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

[0076] Information Centric Networks (ICNs) and/or associated Content Routers

(CRs) may employ per-service class and/or per-interface queue management for bandwidth sharing, for example. Associated edge routers may perform per-user and/or per-class traffic control on one or more network-user interfaces, e.g., such that a network operator may enforce a user policy and/or handle network congestion without depending on users. Two transmission queues per Service Class (SC) may be maintained at each interface, including a first transmission queue for interests (e.g., requests from content consumers or from downstream routers) and a second transmission queue for data. Separate interest and data queues may allow a scheduler to apply different transmission priorities to these packet streams, if congestion is detected, one or more requests may be selectively discarded or returned to respective original requesters, for example, based on preferences of the service classes, A returned request may be passed to an application that issued the request. The application may thus perform content-aware adaptation accordingly (e.g., sending future requests to a different router).

[0077] A link transport protocol may be employed to provide hop-by-hop transport reliability. Error control and traffic control may be separated. Such an approach may provide modularity and/or scalability and may be implemented at one or more end user WTRUs and/or intermediate ICN content routers. Transport protocols may be enhanced to implement these techniques. Interest and/or request forwarding, discarding, and/or returning may be implemented at ICN routers. The resource sharing mechanisms disclosed herein may cause network performance to be independent of how WTRUs send interests. A rate adaptation algorithm may be implemented for an on-demand streaming video class that may exploit video source elasticity, e.g., for optimal resource allocation. An interest packet may retrieve a video chunk (e.g., 2s-3s video) that may be transmitted in multiple packets at the link layer, for example.

[0078] A request control algorithm may be performed by a request receiver (e.g., a data sender or router, such as an intermediate router) and/or a request sender (e.g., a data receiver). For example, the request receiver may be a router that receives a request for data from an end user device. The algorithm may facilitate or enable control and/or prediction of network behavior. Predictability and/or controllability may enable or facilitate management tasks, for example traffic engineering. Per-service queue, as opposed to per-flow queue, management may improve scalability. Explicit hop-by-hop congestion control may be implemented, for example, to avoid inaccurate windo timeout estimation in multi-source and/or multi-path delivery environments. One or more generic components, such as Weighted Round-Robin (WRR) and/or explicit congestion control mechanisms, may be implemented.

[0079] FIG. 2 depicts a diagram of an example system 200. A WTRU 202 may have multiple wired or wireless interfaces (e.g., Ethernet, WiFL Cellular, etc.) and may connect (e.g. , simultaneously) to multiple access networks 204, 206, 208 using its wired and/or wireless interfaces. An access network associated with the WTRU 202 may or may not be an Information Centric Network (ICN). For example, an access network may be an access network that may provide connectivity. If an access network is an ICN network, one or more ICN Content Routers (CRs) 210 may be present in the access network. A Content Router 210 may forward a request for a content object toward one or more content servers, content sources, content hosts, and/or content repositories, e.g., following one or more paths 212, 214. A request forwarding decision may be made based, for example, on a requested content name using name-based routing. A name resolution process may be used, that may resolve the content name into a network location (e.g., an IP address and/or a more general directive for forwarding). The Content Router 210 may forward the request to a next hop based, for example, on the resolved address. When a content source 216, 218 receives a request, it may send a response to a requester that may include the requested data and/or an instruction and/'or metadata to retrieve the content data. The terms Objeci Identifier (OID), identifier, and name may be used interchangeably herein, unless otherwise stated.

[0080] The size of a content object (CO) may range, for example, from a few bytes to hundreds of Gigabytes. A large content object may be segmented into smaller size data units, called chunks, that may be handled by one or more ICN nodes. A chunk may be encapsulated in a Content Object Transport Unit (CTU) for transport, for example. A chunk may be treated as a CO. A CTU or a chunk may be a basic transport and caching unit with one or more of the following properties: it may be uniquely identified by a CO Name and 'or OID and a Chunk ID; it may be requested by an end node; it may be cached by an intermediate node; or it may be signed and/or protected for security purposes, for example, by an original content provider or another entity that creates the CO, such that one or more other nodes may authenticate it. An example Chunk ID may comprise a chunk number, a chunk offset, and/or a size. Other naming methods, such as giving a unique name to a chunk, may be used.

[0081 ] To retrieve a large CO, an end node may obtain a metadata CO of the requested CO, The metadata CO may include information pertaining to chunks, such as chunk naming, sequencing, size, representation, quality (e.g., for audio and/or video media), and'Or others. The end node may retrieve one or more appropriate chunks. An end node may obtain metadata information, for example via an external source, and may retrieve the chunks.

[0082] A CTU may include a header during transport and caching. FIG. 3 depicts an example CTU. The header may include a Service ID sub-header 302 and/or a content (CO) sub-header 304. The Service ID sub-header 302, which may include a Service ID 306, may identify a service and/or application type that generates the traffic (e.g., video streaming, file download, conversional multimedia traffic, etc.) and may represent the traffic class. Each traffic class may be associated with respective Quality of Service (QoS) criteria. The Sendee ID may specify a format of a following header. For example, the CO sub-header 304 may include one or more of a header length and/or a total length 308, a content name and'Or OID 310, a Chunk ID 312 (e.g., a chunk number, a chunk offset, a size, etc.), one or more control bits and'or flags 314, security information 316, and/or a lifetime 318. A payload 320 may follow the lifetime 318.

[0083] In the chunk ID 312, the chunk number of a first chunk may be set to zero.

The chunk offset may specify an offset, or position, in the overall content object where the data in this chunk is located. The chunk offset may be specified in units of 8 bytes (64 bits), for example. A first chunk may have an offset of zero. The chunk size may indicate a size of the chunk (e.g. , in bytes). For example, if the control bits and'or flags are set to zero, the instant chunk may be a last chunk in the content object. If the control bits and'or flags are set to a value of one, there may be more chunks after the instant chunlv in the content object. If the content object has just one chunk, the more chunk flag may be set to zero, and the chunk number may be set to zero. The security information 316 may include one or more of a signature, signed information, a digest algorithm, a publisher ID, and'or a key locator. The lifetime 318 may indicate a time after which the chunk may become obsolete. [0084] The size of a chunk may be up to a few megabytes (MB) or larger. When large chunks are exchanged among ICN nodes, they may be fragmented, for example, to be handled by layer 3 and/or layer 2 technologies that may have a Maximum Transfer Unit (MTU) of a smaller size. With a large chunk size, overhead related to the header may be relatively small. Authentication and/or other security operations may be performed by caching nodes on a chunk- by-chunk basis, for example. A large chunk size may reduce overhead associated with one or more authentication operations. If the chunk size is greater than an MTU, the chunks may be subject to fragmentation, which may introduce overhead and may have a negative effect on performance efficiency . If a single fragment is lost, it may lead to the loss of a whole chunk to which the fragment belongs. A large chunk size may result in less flexibility in congestion control. Selection of an appropriate chunk size may improve the efficiency of the transport mechanism. An optimal chunk size may result in a maximum efficiency of the transport mechanism.

[0085] FIG. 4 depicts a block diagram of an example content router (CR) 400. The

CR 400 may include a routing and name resolution module 402, a storage control module 404, a cache and/or storage 406, one or more interfaces 408, 410, 412, and/or one or more transport modules 414, 416, 418. The routing and name resolution module 402. may determine a next hop and an output interface of a packet and may forward the packet toward the transport module of the output interface, e.g., transport module 414 if the routing and name resolution module 402 determines to use output interface 408. The routing and name resolution module 402 may establish and/or maintain forwarding and/or name resolution tables that may be used for routing decision making (e.g., based on address and/or content name) using one or more control protocols. The routing and name resolution module 402 may maintain one or more pending request tables that may comprise information pertaining to which CO chunks the requests are pending for. The routing and name resolution module 402 may interact with the storage control module 404 to determine whether a chunk should be stored. A chunk may be stored in the cache and/or storage 406 for an interv al of time before being sent to an output interface 408, 410, 412, or may be sent to the output interface 408, 410, 412 without being stored in the cache and/or storage 406, or may be sent to an output interface 408, 410, 412 and stored in the cache and/or storage 406.

[0086] FIG. 5 depicts an example protocol stack 500 that may correspond to the example CR 400 depicted in FIG. 4. An overlay approach may be used, in which hop-by-hop Eransport modules 502, 504, 506 may operate directly on top of link protocol stacks 514, 516, 518 and end-to-end transport control module 508, content name resolution module 510, and/or TP routing module 512 may operate on top of the hop-by-hop transport modules 502, 504, 506 and may provide an end-to-end ICN network. Chunks may be forwarded by one or more link interfaces 514, 516, 518.

[0087] FIG. 6 depicts an example content router (CR) 600. The CR 600 may include a routing and name resolution module 602, a storage control module 604, a cache and/or storage 606, one or more interfaces 608, 610, 612, and/or one or more transport modules 614, 616, 618. Hop-by-hop 1P/UDP/TCP tunnel modules 620, 622, 624 may operate between the interfaces 608, 610, 612. and the hop-by-hop transport modules 614, 616, 618. These Hop-by- hop IP/UDP/TCP modules ensure that communication between ICN devices (routers or receivers) can be enabled over traditional IP networks using either IP/TCP or IP/UDP protocols. The routing and name resolution module 602 may determine a next hop and an output interface of a packet and may forward the packet toward the transport module of the output interface, e.g., transport module 614 if the routing and name resolution module 602 determines to use output interface 608. The routing and name resolution module 602 may establish and/or maintain forwarding and/or name resolution tables that may be used for routing decision making (e.g., based o address and/or content name) using one or more control proiocols. The routing and name resolution module 602 may maintain one or more pending request tables that may contain information pertaining to which CO chunks the requests are pending for. The routing and name resolution module 602 may interact with the storage control module 604 to determine whether a chitnli shoidd be stored. A chunk may be stored in the cache and/or storage 606 for an interval of time before being sent to an output interface 608, 610, 612, or may be sent to the output interface 608, 610, 612 without being stored in the cache and/or storage 606, or may be sent to an output interface 608, 610, 612 and stored in the cache and/or storage 606.

[0088] FIG. 7 depicts an example protocol stack 700 that may correspond to the example CR 600 depicted in FIG. 6. An end-to-end transport control protocol 702 and/or content name resolution 704 may be utilized in addition to the hop-by-hop transport control which may be provided by hop-by-hop transport layer 706, The IP rouiing proiocols 710 may operate below IP/TCP or IP/TJDP underlays (712, 714, 716) as a necessary service of an IP

2.0 network. Chunks may be forwarded by one or more underlying IP and'or UDP and'or TCP tunnels, e.g., interfaces 712, 714, 716.

[0089] A hop-by-hop transport module may fulfill multiple functions, including one or more of the following: fragmentation and'or defragmentation; traffic control and'or scheduling; congestion control; error control; or request and'or interest control. Traffic control and/ or scheduling may include determining whether and/or which packet is to be transmitted on an interface when a link layer (e.g., MAC) allows a transmission. Congestion control may prevent and/or handle congestion. Error control may promote hop-by-hop data transport reliability. Request and'or -interest control may control a request sending rate.

[0090] A CO may be divided into one or more chunks, and a chunk may be fragmented into smaller data units, called fragments, for example, to be handled by layer 3 and/or layer 2 technologies having an MTU. A hop-by-hop transport module may perform fragmentation and/or defragmentat on. IP may be used as an underlying delivery mechanism. The hop-by-hop transport mechanism may operate on one or more other underlying delivery mechanisms (e.g., Ethernet, UDP, TCP, etc.).

[0091] A data fragment may be carried in an IP packet. An IP packet that carries content data may be referred to as a Content Data Packet (CDP). One or more data packets may be sent by a content server, e.g., in response to a content request. A CDP may cany an IP header and'or a content header. Each packet may comprise an address header and a content header. The address header may be an IP header or a lower layer header (e.g., an Ethernet header).

[0092] FIG. 8 depicts an example format of a content data packet 800 and an example content header 802. The content header may include one or more of the following: Packet Type 804; Header Length 806; Service ID 808, Content Name and/or OID 810; Chunk ID 812; Sequence Number 814; Control Bits and/or Flags 816; Checksum 818; or Options 820.

[0093] The Packet Type 804 may identify a packet type (e.g., data packet, request packet, other control packet, etc.). The Chunk ID 812 may include, for example, a chunk number, a chunk offset, and/or a chunk size, as described elsewhere herein. The Sequence Number 814 of a first data byte in the packet may be related to the beginning of the chunk. The Checksum 818 may be used to detect packet error. Options 820 may include one or more of several types of options that may be included after the standard headers. [0094] Control Bits and/or Flags 816 may include one or more of the following: No

Fragmentation; More Fragments; or Explicii Congestion Notification. A No Fragmentation flag, when set to a value of one, may specify that the chunk is not to be fragmented. Since the fragmentation process may be transparent to higher layers, most protocols may not care about this flag and may not set this flag. This flag may be used to test respective MTUs of one or more underlying protocols. A More Fragments flag, when set to a value of zero, may indicate whether the instant fragment is a last fragment in the chunk. When set to a value of one, it may indicate that there are more fragments after the mstant fragment in the chunk. If no fragmentation is used for a chunk (e.g., if there is just one fragment for a chunk) the flag may be set to a value of zero. If fragmentation is used, each fragment but the last fragment may set this flag to one, for example so a recipient may know when each of the fragments of the chunk has been sent. An Explicit Congestion Notification (ECN) flag may indicate

Congestion Experienced (CE). If an ECN flag is used in an associated IP header, an ECN flag in the content header may not be useful. If a lower layer is not IP, for example, an ECN flag in the content header may be useful.

[0095] There may be duplication between information in a packet content header and information a chunk content header. If a content data packet carries a chunk content header (e.g., if the first content data packet for a chunk includes a chunk header), the chunk header may be compressed to reduce overhead.

[0096] A. request or interest packet may be defined. The request packet may be used to request a content object or a chunk, for example. FIG. 9 depicts an example format of a request or interest packet 900. The request or interest packet 900 may include a content header 902 that may include one or more of the following: Packet Type 904; Header Length 906; Sendee ID 908; Content Name and/or Oil⁾ 910; Chunk ID 912; Starting Sequence Number 914; Size 916; Control Bits and/or Flags 918; Checksum 920; or Options 922.

[0097] The Packet Type 904 may identify the packet as an interest packet (e.g., a request packet from a content consumer) and/or a request packet. The Chunk ID 912 may include one or more of a chunk number, a chunk offset, or a size. If a requester does not know the Chunk ID 912, it may set the Chunk ID to a value of zero. A replying node may send the data of the requested CO if the CO is not chunked, the data of a. first chunk of the requested CO if the CO is chunked, or a metadata CO of the requested CO if the CO has a metadata CO. The Starting Sequence Number 914 of the first requested data byte may be related to the beginning of the chunk. The Checksum 920 may be used to detect packet error. Options 922 may include one or more of se veral types of options that may be included after standard headers.

[0098] The Size 916 may indicate a requested data size (e.g., a number of bytes), for example from the Starting Sequence Number 914. Using the Starting Sequence Number 914 and Size 916 may provide flexibility for a requester to request a byte range of chunk data. When a transmission begins, the requester may not have valid information pertaining to chunks. If the requester has no chunk information, it may set the Starting Sequence Number 914 and Size 916 to values of zero. A replying node may send chunk header information (e.g., including chunk size) or may send chunk header information with chunk data. The size of a reply packet may be less than 1500 bytes, for example. After a requester receives the chunk header, it may decide whether to request more data for the chunk. If so, the requester may send a request that may include a requested byte range of the chunk.

[0099] A Request Response (RR) packet that may function as a control packet may be defined. The RR packet may cany a status for a request and/or an instruction to establish one or more further connections. The RR packet may have substantially the same format as a request packet; an RR control bit may include an Explicit Congestion Notification and/or a request Packet Discarded indication.

[0100] When an intermediate roister receives a request, but is congested, it may- discard the request packet and may send a RR packet to the requester, for example, to indicate the congestion.

[0101] A packet may carry an IP header 924 and/or a content header 902. The location information (e.g., IP address) of the content server may be transient, and the Name/OID may serve as a persistent and/or unique identifier for a particular content object. The location information (e.g., IP address) of the consumer (e.g. , the requesting end node) of the content may not be transient if the consumer is not mobile. If the consumer is mobile, an IP address of the consumer ma be transient, but a name of the consumer may be persistent.

[0102] The IP address and the name may be treated separately. The IP addresses in a packet may be changed, for example, by an intermediate CR during forwarding of the packet in a network. For example, if an intermediate CR knows of a better location for the requested content object (e.g., via name resolution) it may change the destination address of the request packet to a different destination and may forward the request packet toward the different destination.

[0103] If a WTRU or a router does not know the location (e.g., the host and/or server

IP address) of the content object, it may use an alternate address (e.g., an anycast IP address, a multicast address, a broadcast IP address, or the like) as the destination address of the packet and may send the packet to one or more next-hop nodes. The WTRU or a router may use one or more next-hop node addresses as respective destination addresses and may send the packet to one or more next-hop nodes. This method may enable automatically discovering and/or retrieving content based on the Content Name and/or ID and may work with one or more IP protocols. Routers that are not enhanced to handle Content Name routing may perform IP routing based on an IP header of the packet, for example.

[0104] An interface may be responsible for receiving and/or transmitting one or more packets under the control of a hop-by-hop transport mechanism. The interface may depend on transmission media and may implement one or more link layer and/or physical layer protocols. A traffic and congestion control method as described herein may be implemented in a transport mechanism. The transport mechanism may be used to control an interface. A single transport mechanism may control multiple interfaces with multiple instances. In addition, a hop-by-hop transport, e.g., as described herein, may be integrated into software and/or hardware of one or more interface line cards, respective main control cards of one or more routers, and/or of one or more WTRUs. The interface may be a wired and/or wireless interface.

[0105] FIG. 10 depicts an example transmitter protocol architecture 1000 for hop-by- hop transport. The example transmitter protocol architecture 1000 may include one or more of: a Fragmentation module 1002; an Error Control module 1004; a Traffic Control module 1006 (which may perform, e.g., scheduling, congestion control, request/interest control, and/or dispatch); a Congestion Control module 1008; and/or a Request and/or Interest Control module 1010.

[0106] FIG. 1 1 depicts an example receiver protocol architecture 1 100 for hop-by- hop transport. The example receiver protocol architecture 1 100 may include one or more of: a Defragmentation module 1 102; an Error Control module 1 104; a Traffic Control module 1 106 (which may perform, e.g., dispatch); a Congestion Control module 1 108; and/ or a Request and/or Interest Control module I I 10. [0107] Hop-by-hop transport may implement per-service class queuing in one or more CRs that may be suitable for use with ICN multi-source and/or multi-path delivery environments. Hop-by-hop transport may improve scalability and/or may simplify network management. For each service or traffic class, a hop-by-hop transport mechanism may maintain one or more queues at a respective CR interface, for example four queues per CR interface that may include a control receiving queue, a data receiving queue, a control transmit queue, and/or a data transmit queue.

[0108] For transmission as depicted in FIG. 10, a data chunk 1012 may be fragmented and may be stored in a. transmit buffer and/or queue, for example based on a Service ID (SID) associated with the data chunk. If one or more lower layers do not provide reliability, an error control module 1014 may be used at a hop-by-hop transport level (e.g., operating at a transmitter and a receiver). The scheduler 1006 may determine which packet and/or fragment from which queue is to be delivered to a lower layer 1014. The scheduler 1006 may use a virtual First In, First Out (FIFO) buffer and/or a WRR algorithm to perform this operation, for example. A congestion control module 1008, e.g., an explicit congestion control mechanism, may be used to handle congestion. A request control module 1010, e.g., a. sender request rate control mechanism, may be used to ensure that a sender of the request consents to and/or is able to accept the requested data.

[0109] For receiving as depicted in FIG. 1 1 , a control and'or data packet received from a lower layer 1 1 12 may be dispatched to a corresponding buffer and/or queue for processing. A request control module 1 1 10, e.g., a receiver request rate control mechanism, may be used, for example, to regulate a request sending rate and/or to prevent congestion. If one or more lower layers do not provide reliability, an error control module 1 104 may operate at a hop-by-hop transport level to provide reliability (e.g., at a transmitter and a receiver). A data chunk 1 1 14 may be re-assembled by the detragmenter module 1 102 and may pass to an upper layer. For cacheable content, the data chunk 1 1 14 may be cached in a storage. To keep the pipeline available for fast forwarding, for example, a received packet (e.g., received in order) may be sent to an output interface without waiting until an entirety of the chunk is received (e.g., sent substantially immediately upon receipt).

[01 10] Network bandwidth may be shared among multiple network flows. Network traffic may be controlled. Network traffic and/or congestion may be controlled so as to ensure efficient and/or robust data deliveiy in a network and/or fair network resource sharing by traffic flows, for example. Network traffic and/or congestion control, as described herein, is not limited to use with an ICN architecture and/or ICN routing and/or name resolution implementations as described herein and may be implemented with other content delivery, content routing, and/or name resolution implementations.

[Oi l 1] Weighted fair sharing scheduling may be implemented for transmission at an interface. One or more queues (e.g. , each queue) may be given a weight wi based on its queue type (e.g., control or data) and/or its service priority, for example. A list ActiveList may be built. Inclusion in the list ActiveList may be limited to transmit queues that have a packet in a buffer. Packet transmission in the list ActiveLisi may be conducted by a WRR request rate control at one or more CRs, for example.

[01 12] Requests and data may travel through the same one or more CRs. The CRs may control a flow of requests in order to trigger rate reduction before a receiver may detect congestion (e.g., via timer expiration), which may prevent congestion and/or improve network utilization. Interest packet shaping may be performed at an output interface of a downstream node (e.g., a request forwarding CR) and may assume that one or more downstream nodes have knowledge of do wnlink rate, which may not be practical, for example, considering link sharing with non-TCN traffic and/or wireless channel dynamics.

[01 13] Request rate mechanisms as described herein may be distributively performed at an input interface of an upstream node (e.g., a request receiver) and/or at an output interface of a downstream node (e.g., a request forwarder). At the input interface of the upstream node, it may be determined whether a request is to be accepted or rejected, for example, based on link congestion status. At the output interface of the downstream node, it may be determined whether to send and/or forward a request, for example, based on a receiving storage status of the node. For example, if the data receiver storage is too full, the node may decide to not forward a request onward (because this action is likely to result in arrival of more data requiring more storage).

[01 14] A CR may forward a request, for example, if the CR determines that it has sufficient buffer space to accept the replied data and to cache the replied data in a content cache. The request message may be used for controlling data to a receiver. Buffer overflow during congestion may be prevented without additional mechanisms. A sending node may send out packets of the requested data as fast as an associated Media Access Control (MAC), for example, allows (e.g., because the receiver may have enough buffer to accept the requested data). This implementation may differ from backpressure-based hop-by-hop flow control, where backpressure between adjacent nodes may be used by a node to adjust a packet forwarding rate of a continuous flow.

[01 15] A request packet with a Service ID and/or a request content ID may be received by an interface. When the request packet is received, a transport module may check its data transmit queue for the same Sei'vice ID. If the data transmit queue is equal to or less than a threshold 7), the request may be sent to a routing and resolution module. If the transmit queue is greater than T;, the request may be discarded, for example at a probability (e.g. , rate) of Pi. If the request is discarded, a response may be sent back, for example to indicate potential network congestion. The response may be transmitted using a control queue for less delay. If the request is not discarded, it may be sent to the routing and name resolution module for processing.

[01 16] If the transmit queue is greater than Τ_η· , the request may be discarded at a (e.g. , rate) probability P . If the request is discarded, a response may be sent back, for example, to indicate potential network congestion. The response may be transmitted using the control queue for less delay . If the request is not discarded, it may be sent to the routing and name resolution module for processing.

[01 17] ^'The discard probability may be expressed as

( 0 B≤ T_i

P_d = \ ^pi T_l < B≤ T_h

{P_h B > T_h

[01 18] Determining whether to service or discard a request may be implemented in accordance with an approach in which a terminal (e.g., a receiver) may specify an amount of content, which it may request using, for example, a number (M) of packets. The receiver may not know where the content is located, but may be multi-homed and may request content from each of a number of networks. The receiver may request data in one or more rounds (e.g., several rounds). In each round, for each network, the receiver may select one or more subsets of packets and may request them. The request may go to a CR in the network that honors the request for a packet or may ignore it, for example. If the CR determines to honor the request for the packet, it may retrieve the appropriate portion of the content from a local cache and/or may request it from one or more appropriate content servers or other CRs, for example. If the CR determmes to ignore the request, it may do nothing (e.g., the CR does not return ihe request to the receiver, it may ignore it).

[01 19] The receiver may have as an interest e.g. , as a primary interest, getting fall content as fast as possible. The receiver may pay no penalty for a total amount of data it receives and may not suffer from receiving duplicates. The CR may be interested in minimizing network load and may be interested in honoring as few requests as possible. The CR may pay a penalty for ignoring requests (e.g., displeased subscribers). The CR may be configured to provide a reasonable level of service to a subscriber, for example, by not overly increasing a number of rounds used to obtain data.

[0120] A strategy for the receiver may be to request each M packet from each network (e.g., all packets from all networks). Such a strategy may be bad for one or more CRs, as it may waste network resources. One or more CRs may act to punish receivers that submit excessive volumes of requests. The receiver may have knowledge of this and may adjust its strategy in light of anticipated CR penalties.

[0121] Requesters and/or CRs may be configured to operate in accordance with the following behavior model, for example. A requestor R may desire to get a sei of M ackets from a server S (e.g., a CR), and may attempt to do so by issuing one or more requests. In each round of requests, the requester may receive one or more packets from one or more other sources (e.g., a side channel). Side channel arrivals may occur according to a random law, which the server may know. The problem may be defined herein, wherein it may be assumed that each packets is equal. Factors may include how many packets are needed, requested, and/or provided, rather than which packets are provided.

[0122] An exchange (e.g., in accordance with game theory) may proceed between the requester and the server, for example over a number of rounds, wherein N may denote a number of rounds required to obtain each of the M packets from the server, and N may be a random variable. M„ may denote a number of packets the requester still requires after round n, with Mo≡ M, then

N = )n ~ y. : .¾/. - 0. M„__/ > 0}

[0123] The requester may, in round n, request μ„ ⁽M„- > , i¾„ -_/) packets from the server, where the strategy \μ„) may be based on various aspects of game history information. Hjir i may be a placeholder for relevant history information known and useful to the requester. The content of ¾_.„- may be explicit.

[0124] The requester may, in round n, receive a subset Q(M_n-i) of requested packets from another source at no cost. Q(n) may be distributed according to some q(n) and \q(n) is a family of discrete distributions on { 1 , . . . , n ) for B £ Z¹,

[0125] The requester may seek to minimize UR(N) where UR(X) is some monotonically non-decreasing function Z+→ ¾.

[0126] The server may, in round n, receive a request for μ„ packets from the requester.

[0127] The server may, in round n, select ν„(μ„ , ¾„../) packets to honor and may ignore the rest. ¾„-/ is a placeholder for relevant history information known and useful to the requester. The content of ¾_»-i may be explicit.

The server may seek to minimize u_s (N, {t¾}) = f(.N + g(2__i Vn ) where /( ) and g( ) are some monotonically non-decreasing functions Z+→ ¾.

[0129] Based on the relations disclosed herein, M_n may satisfy a recursion

M_n = max

, ¾.„-,) , ¾_r/) - , 0] ( 1)

[0130] Analysis may begin by considering a simple repeated game, where μ.„ and v„ are fixed prior to the game siart to be dependent on M_n- r only and are thus functions μ : Z^÷→ N and μ : N ^"→ Ν. The recursion on M„ may be expressed as

M_n = max [M_n-! - v (ji{M_n-i)) - Q(M_n-i) , 0] (2)

[0131 ] A first goal may be to determine the stopping time N and to do so, (2) may be relaxed by dropping the maximum, letting M„ take on real values, and setting v and μ to be constants with 0 < μ, v < 1. Equation (2) then becomes n] .x^'\ .'! 1 ] - νμχ[η ^~ 1 ] - {/ {x{n ^~ 1 j ) (3) where Q fx) is a random variable taking values in [0, x] according to some family of distribution q '(x) parameterized by x £ ¾ ^' . Equation (3) may be expressed as Ι - (i -

- φ (4) where x[0] > 0 is a deterministic value.

[0132] By definition, x[N] is the smallest value of n such that x[n] < 0. Thus, equation

(4) may result in the following condition on the stopping time:

N = min { n : (1 - νμ)^ηχ [0]≤ ∑',' _; ( 3 - νμ -^'{χ [η - 1] )} (5) or, assuming that .N <∞ a.e..

1 (l-νμγ . which provides a simple condition on the statistics of the stopping time. Because the distribution family Q' is independent of N, the summation on the right hand side of equation (6) may increase as with N, with a rate of increase controlled by the selection of v and μ. For e v ery sample path of the underlying probability field, N decreases as the product v μ increases and vice versa, such th at increasing the proportion of packets requested and honored reduces the number of rounds required.

[0133] Since a cost to the server (us) may depend on v, setting μ = 1 may be optimal in this case. In a situation where a strategy of the server is fixed, there may be no reason for the requester to request less than a full set of data in every round. The setting of v in the server may depend on the simplified form of the server's cost function as given below us (N, v) =/ ^f((.N) + givN) 00

[0134] An appropriate strategy for server may be determined for a specific selection on functions /and g and solving the resulting probabilistic optimization problem.

[0135] Considering time and history dependent strategies μ [η] and v[n], the continuous relation in equation (3) may become

[0136] The non-recursive version may then be expressed η-ί

x[n] = x[0] Π(1 - (9)

1=1

[0137] N may be given by the following

[0138] The game may then be formulated by an appropriate selection

and v[n] as well as the requester's and server's utility. One possible choice for selection of μ[η] and v[n] may be as follows. The requester's action may be that μ[η] may depend on the number of remaining packets, such that μ[η \≡ μ(χ[η])^'

[0139] The server may consider an overall history of requests and responses, such that vim≡ vfiviiw , ^ΙίυΓ {⁾ where two situations relative to to the server's knowledge may be considered: the server knows μ; and the server estimates μ based on observations of x[n].

[0140] in a case where the server may know μ, v\vi≡ v(nAv\iW {} [0141 ] in a case where the server may estimate μ, v\n\≡ vi\x\( y , ,{v\l\y; [0142] A proper strategy may depend on solving the minimax problem derived from simultaneous minimization of the receiver's and sender's objective functions given the complex relationship between Q' , μ and {v[»]} as they are connected through N (see equation 10), One possible way to deal with this problem may involve further simplification. At every n, the sender may assume that a number of remaining steps may be determined (e.g., exactly) by replacing Q' (x[n - I]) with its expected value. At any given time, the sender may then test several potential strategies «]}, to: use (10) to find N; and use the found value of Nand strategy {v[«]} to find one that may minimize its cost as given by u_s (N, {v_n» - /^'(A^f) + g (y ^A v_n)

[0143] The problem may no be solved numerically given appropriate selection of parameters and functions g, etc,

[0144] A. router in hop-by-hop transport may act as both a requester (e.g., of data from one or more other routers and/or sources that may be upstream with respect to the router) and a sender (e.g., of requests from a content consumer to one or more routers that may be downstream from the router). The exchange disclosed herein may apply to routers as well as to sources and/or consumers of content.

[0145] Random Early Marking (REM) may be implemented. REM (e.g., a REM process) may be implemented on an output queue with the same or different priorities at respective output interfaces of one or more CRs and/or content sources where congestion may occur. Implementing REM may avoid congestion and/or long delays and may improve bandwidth sharing. If a buffer is almost empty, one or more input packets (e.g., all input packets) may be transmitted without marking. As the queue grows, a probability for marking a packet, e.g. , inserting a congestion mark that identifies or indicates a level of congestion, may increase. When the buffer is full or substantially full, the probability may reach or approach one, and a high rate of packets (e.g., all packets) may be marked.

[0146] REM may differ from Random Early Detection (RED). For example, there may be no data loss, even in congestion, for example, due to a hop-by-hop request rate control at one or more CRs and/or cache management. REM may determine whether a packet is to be moved to a transmit queue from a cache and/or content storage and/or whether the packet is to be marked. The transmit queue may be a virtual queue, for example, depending on the implementation. In contrast to TCP and RED, where a packet source may reduce its transmission rate, with REM, one or more marked data packets may be sent to the requester of the content and the requester may reduce its requesting rate (e.g., to the device that sent the data with marking indicating congestion).

[0147] During congestion, data packets may be delayed, whether or not they are dropped by one or more intermediate CRs. Multiple requesters may incur a timeout and may send respective requests at a lower rate. This may cause congestion to clear, A

synchronization (e.g., global synchronization) of requesters may occur, for example, if multiple requesters reduce their request raies substantially coincidentally. If the congestion clears, one or more of the requesters may increase their request rates, which may result in one or more waves of congestion, followed by one or more periods where a transmission link may not be fully used.

[0148] Random Early Marking may mark one or more packets, for example, with a congestion mark that indicates a level of congestion, before congestion occurs, in order to avoid long delays and or repeated requests and to minimize the likelihood of synchronization. REM may allo a transmission line to be used substantially fully. REM may statistically drop more packets from large users than small users, such that users that request the most data may be more likely to be slowed down than users that request smaller amounts of data.

[0149] REM may provide one or more separate thresholds and/or weights, e.g., for different queues or the same queue, with the same or different packet precedence, which may enable respective different Qualities of Sendee for one or more different sendee traffic types or priority levels. Standard traffic may be marked more frequently than premium traffic, for example, during periods of congestion,

[0150] REM may monitor an average data transmit queue size and may mark one or more packets using ECN, for example based on statistical probabilities (e.g., where marking in accordance with the calculated rate may result in a marking rate). When deciding whether to move a packet from its cache and/or storage to the transmit queue, REM may calculate an average queue size. The average queue size may be based on a previous average and/or a size of the queue, for example, using

Ave₀ = old_ave x (1 - ) + current„ x where a may be a configurable value 0<α≤1. For small values of a, a previous average may smooth out one or more peaks and/or lows in a queue length. Average queue size may be unlikely to change quickly, such that drastic swings in queue size are unlikely. REM may be slow to begin marking packets, but may continue marking packets for an interval of time after the queue size has fallen below a first (e.g., minimum) threshold. A slow -moving average queue size may accommodate one or more temporary bursts in traffic. If the value of a becomes too small, REM may not react to congestion. For example, may be set as follows

10

=^■—

link packet rate

[0151 ] A packet size may be set in accordance with an MTU (e.g. , 1500 bytes). For high values of a, the average queue size may track a size of the queue at a select time (e.g., a current queue size). The average queue size may fluctuate, for example, along with changes in traffic levels. REM may respond quickly to long queues, for example, that may result from a sudden increase in traffic levels. Once the queue falls below a first (e.g. , minimum) threshold, REM may stop dropping packets. If the value of a becomes too low, REM may- react to temporary traffic bursts, for example, by marking traffic unnecessarily.

[0152] If the average queue size falls below a first (e.g. , minimum) queue threshold, one or more packets may be moved to a transmit queue, for example, without marking the one or more packets. If the average queue size falls between the first (e.g., minimum) queue threshold and a maximum queue threshold, one or more packets may be marked, for example, depending on a packet marking probability. If the average queue size rises above the maximum queue threshold, one or more packets may be kept in the cache and/or storage. A lifetime may be associated with one or more cached chunks (e.g., each cached chunk). One or more data packets that belong to the chunk may be removed from the cache, for example, upon expiration of their respective lifetimes.

[0153] A packet marking probability may be based, for example, on a first (e.g. , minimum) threshold Ti, a second (e.g., maximum) threshold 7_¾, and a mark probability denominator ^. When an average queue depth rises above the first (e.g. , minimum) threshold, REM may begin marking packets. A rate of packet marking may increase (e.g. , linearly), for example, as the average queue size increases, until the average queue size reaches the second (e.g. , maximum) threshold. The mark probability denominator may be indicative of a fraction of packets marked when the average queue depth is at the second (e.g., maximum) threshold. For example, if the denominator A^" is 512, one out of every 512 packets may be marked when the average queue size is at the second (e.g., maximum) threshold. When the average queue size rises above the second (e.g., maximum) threshold, a higher rate of packets (e.g., all packets) may be marked. FIG. 12 depicts an example packet marking probability 1200. The following equation summarizes a packet marking probability

[0154] The first (e.g., minimum) threshold value may be set high, for example, to increase or maximize utilization of an associated transmission link. If the first (e.g., minimum) threshold value is set too low, one or more packets may be marked unnecessarily, and the transmission link may not be fully used. The difference between the second (e.g. , maximum) threshold value and the first (e.g., minimum) threshold value may be large enough to avoid global synchronization. If the difference between the second (e.g., maximum) threshold value and the first (e.g., minimum) threshold value is too small, multiple packets may be marked at once, which may result in global synchronization. An example set of parameters may include 7} = 0.03B, 7_& ^;;; 0.1B and K == 512, where B is a link rate.

[0155] Data may be pulled by one or more receivers and/or requesters. A rate of requested data may be controlled and/or adapted by one or more receivers. One or more resource sharing and/or request rate control mechanisms, for example, in one or more CRs may cause network performance to be at leas t partially independent of how one or more users send respective requests.

[0156] A user (e.g. , end user device) may be able to send one or more requests, e.g., such that one or more application requirements may be met and/or such that requests are not likely to be rejected and/or discarded by the network. A user, requester, and/or data receiver may adapt its request rate, for example, based on one or more application criteria and/or network status.

[0157] A request rate adaptation may emulate TCP, for example, by implementing

Additive Increase, Multiplicative Decrease (AIMD) congestion control. This request rate adaptation may be applicable for content retrieval with a relative large delay, for example. A requester may maintain a window W of pending requests (e.g., W requests sent for which corresponding data packets have not been received). A size of the window may be adjusted, for exampl e, by adding alW to Wfor each portion of requested data that is received. This may correspond to an increment of a each time a complete W f requests is acknowledged by data reception. If a congestion event is detected, If⁷ may be decreased, for example, by a factor β<\ (e.g. , no more than once in an interval of time). The values of a and/or β may determine how aggressively a user may track available bandw dth.

[0158] Congestion may be detected in one or more of the following ways: receiving one or more data packets having ECN control flags set; receiving one or more control packets that indicate an occurrence of congestion and/ or that indicate the discard of one or more request packets; and/or expiration of a request retransmission timer.

[0159] When a request is sent, a timer may be set, for example, at the receiver, to detect losses. Expiration of the timer may be interpreted as a congest ion e v ent, A protocol may account for request retransmission timeout and'Or ECN in one or more different ways, for example, using different values οϊβ<\ .

[0160] A request may be retransmitted after its timeout. One or more previous requests and/or portions of data may not be lost, but rather may be delayed, for example, at a bottleneck, such that properly setting the request retransmission timer value may provide management. In general, the timer may be set to a value that is larger than a network delay value, such that at least a majority of sent requests (e.g. , all sent requests) may not trigger a timer expiration. A small value of a retransmission timer may cause unnecessary

retransmissions of reques ts, while a large value of the retransmission timer may slow down loss recovery. Shorter timeout values may lead to shorter intervals of time during which transmissions may be stopped. If the timeout values are too short, then one or more requests that have not been dropped but are instead taking too long to arrive may be retransmitted. This may cause inefficient use of bandwidth and'Or may increase congestion in the network. Timeout values may be adjusted to improve performance of corresponding protocols. In accordance with ECN, the retransmission timer may be set to a relatively large value.

[0161] One or more retransmitted requests, for example, that may be sent shortly after a timeout, may be filtered if a. Pending Request Timer (PRT) at an intermediate node is larger than the request retransmission timer value set at a corresponding receiver. The PRT timer may be used to optimize traffic, for example, by limiting a number of pending requests, A number of requests that are not forwarded upstream toward one or more content repositories may increase as the value of the PRT timer increases. This may reduce duplication, but may slow loss recovery. A small PRT timer value may cause a large number of unnecessary retransmissions, for example, because one or more delayed data packets arriving after one or more PRT timeouts may be discarded. A PRT timer may not be used, such that one or more requested packets may be forwarded toward one or more content repositories until a cached copy is hit.

[0162] A receiver transport module may maintain a retransmission timer, for example, for each flow. The receiver transport module may estimate a Round-Trip Time (RTT) and/or a RTT variance. RTT may be a length of time between the time a request is sent and the time that the first response packet is received, A protocol may perform RTT and/or RTT variance estimates, for example, at reception of a first response packet of an initial request. The protocol may not perform RTT or RTT variance estimates for one or more retransmitted requests since the protocol may not know whether the response is for a first request or a retransmitted request. For example,

SRTT(k+l) - (T-a) x SRTT(k) + a x RTT(k+l )

SERRi K + 1) = RTT(K + 1) - SRTT(K)

SDEVfK · ! } · ! b s \ SDEV(K) + b x|SERR(K + l)j

[0163] A Retransmission Timeout (RTO) value may be, for example

RTO(K + 1 ) = SRTT(K + 1 ) + c x SDEV(K + 1)

[0164] Example values of a, b and c may be a = 0.125, b = 0.25, and c = 4 or c=8. An initial value of RTO may be set to a relatively large value compared to a potential network round-trip delay.

[0165] A requester and/or a data receiver may send a first request and may start performing RTT measurements and/or maintaining a congestion window. The congestion window, may be defined as a maximum number of outstanding requests that a receiver is allowed to send. An initial value of the congestion window ma be one. A congestion window size, for example, at a requester, may be adjusted as disclosed herein. [0166] For example, W ay be incremented by alW (e.g., W+-oJW) for one or more portions of requested data received. W may be incremented by a (e.g., a=l ), for example, each time a complete window W of a request is acknowledged (e.g., by data reception), W may be set to the maximum of 1 and β) W (e.g. , ^'^m i 1 ,β ι Wj) for receiving one or more data packets with respective ECN control flags set (e.g., β =1/2). When one or more control packets indicative of congestion are received and/or one or more request packets are discarded, one or more discarded requests may be retransmitted, the discarded requests and W may be set to ? ^:;;inax(l ,/ii W). If a request retransmission timer expires, Wmay be set to

.

[0167] The protocol may not react to congestion indications more than once per window of requests (e.g. , more than once per round-trip time). A congestion window of a receiver may be reduced once in response to one or more ECN packets and'Or control packets (e.g., a series of ECN packets and'Or control packets) from a single windo of requests. Dropping one or more retransmitted request packets may be interpreted as an instance of congestion. The value of the congestion window may be bounded by a value of one request. For example, if a receiver were to continue to send requests, using a congestion window of one request, this may result in the transmission of one or more requests and/ or corresponding data per round-trip time. If the congestion window includes one request and the receiver receives ECN and/or control packets to indicate congestion, the receiver may reduce its congestion window. The retransmit timer may be used to reduce the rate further in this circumstance. The receiver may reset the request retransmit timer, for example on receiving the ECN and'Or control packets when the congestion window is one. The receiver may then send a request packet, for example when the retransmit tinier expires.

[0168] A routing and name resolution engine module may resolve a name and may determine an output interface, for example when it receives a request packet from a hop-by- hop transport module. The routing and name resolution engine module may determine whether the requested content has been cached in the local catch and/or storage, for example by communicating with the storage control module. If the requested content has been cached, the requested content data may be sent to a requester, for example from the local cache. If the requested content has not been cached, the routing and name resolution engine module may- use a name-based routing table, for example, to obtain the requested content name and a next- hop and/or output interface mapping. The routing and name resolution engine module may use name resolution to obtain an address of the content and may, based on the address, obtain a next-hop and/or output interface, if there is more than one content pro vider to choose from, the routing and name resolution engine module may select a content provider having a best cost and/or that is closest, for example, in accordance with a routing policy.

[0169] The routing and name resolution engine module may make contact with a storage control module if the requested content is cacheable based on the service and/or traffic class ID, for example. The routing and name resolution engine module may determine whether there is enough available storage space. If there is enough storage space in a local storage for a cacheable content object, ihe request may be sent to an output transport module. Otherwise, the request may be discarded and/or a response control message may be sent to an original requester, for example to indicate potential network congestion. The request message may be also used for controlling data to a receiving CR, without additional mechanisms for flow and/or congestion control, which may simplify network management. This

implementation may differ from backpressure-based hop-by-hop flow control, where backpressure between adjacent nodes may be used by a node to adjust a packet forwarding rate of a continuous flow. A transmitting node may send out one or more packets of a requested content object as fast as an associated MAC, for example, allows (e.g., because the receiver has enough buffer to accept the requested data). For a non-cacheable object (e.g., traffic for interactive conversation applications) one or more requests may be sent to a transport module of an output interface, for example directly.

[0170] When the transport module receives an output request and/or a response packet from the routing and name resolution module, it may place the packet into a control message transmitting queue for a corresponding Service ID,

[0171 ] If reliability is specified for a requested content object based on a Service ID, the transport module may ensure the reliability in a hop-by-hop transport. The transport module may use an ACK protocol, for example, to ensure that the packet is received by an intended receiver.

[0172] When the transport module receives a content object, it may pass the content object to the routing and name resolution module. If the content object is a cacheable content object, the routing and name resolution module may interact with a storage control module to cache the content object in the local cache. Based on a routing table, for example, the transport module may forward the object to an output interface, toward a requester. [0173] When the transport module of the output interface receives a content object from the routing and name resolution module, it may place ihe content object in a data transmit queue for a corresponding Service ID. For a cacheable content object, the data transmit queue may not overflow, for example because it may retrieve the cached content object from the storage at a time when it has sufficient buffer space for ihe content object.

[0174] A lthough features and elements are described above in particular

combinations, one of ordinary skill in the art will appreciate that each feature or element may^¬ be used alone or in any combination with the other features and elements. In addition, the meihods 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, WTRU, terminal, base station, RNC, or any host computer. Features and/or elements described herein in accordance with one or more example embodiments may be used in combination with features and/or elements described herein in accordance with one or more other example embodiments.

Claims

C AIM :;s What is claimed:

1. A method for indicating a level of congestion, the method comprising:

receiving, at a device, a request for data:

determining a level of congestion associated with the device;

marking the data based on the level of congestion; and

sending the marked data, wherem the marked data indicates the level of congestion associated with the device,

2. The method of claim 1 , wherein determining the level of congestion associated with the device comprises determining that data awaiting transmission exceeds at least one of a first threshold or a second threshold.

3. The method of claim 2, wherem the data awaiting transmission is associated with a certain queue or a packet precedence,

4. ^'The method of claim 2, wherein marking the data based on the level of congestion comprises:

marking the data with a congestion mark at a first rate on a condition that the data awaiting transmission exceeds the first threshold and is less than the second threshold; and marking the data with the congestion mark at a second rate higher than the first rate on a condition thai the data awaiting transmission exceeds the second threshold.

5. ^'The method of claim 1 , wherein marking the data comprises:

determining a marking pattern associated with the level of congestion; and marking a packet in the data on a condition that the packet is indicated by the marking pattern.

6. The method of claim 5, wherein the marking pattern comprises a packet marking probability.

7. The method of claim 5, wherein the indication of the level of congestion comprises a frequency of marked packets in the data.

8. The method of claim 1 , further comprising:

determining that the level of congestion is crossing from a higher threshold to a lower threshold; and

continuing to mark the data based on the higher level of congestion for a period of time.

9. The method of claim 1 , wherein the data comprises multimedia data.

10. The method of claim I, further comprising:

sending a request for the data to a content source; and

receiving the data from the content source,

1 1. A device for indicating a level of data congestion, the device comprising a processor configured to:

receive, at the device, a request for data;

determine a level of congestion associated with the device:

mark the data based on the level of congestion; and

send the marked data, wherein the marked data indicates the level of congestion associated with the device.

12. The device of claim 1 1 , wherein determining the level of congestion associated with the device comprises determining that data awaiting transmission exceeds at least one of a first threshold or a second threshoid.

13. The device of claim 12, wherein the data awaiting transmission is associated with a certain queue or a packet precedence.

14. The device of claim 12, wherem marking the data based on the level of congestion comprises: marking the data with a congestion mark at a first rate on a condition that the data awaiting transmission exceeds the first threshold and is less than the second threshold; and marking the data with the congestion mark at a second rate higher than the first rate on a condition that the data awaiting transmission exceeds the second threshold.

15. The device of claim 1 1, wherein marking the data comprises:

determining a marking pattern associated with the level of congestion; and marking a packet in the data on a condition that the packet is indicated by the marking pattern.

16. The device of claim 15, wherein the marking pattern comprises a packet marking probability.

17. The device of claim 15, wherein the indication of the level of congestion comprises a frequency of marked packets in the data.

18. The device of claim 1 1 , wherein the processor is further configured to:

determine that the level of congestion is crossing from a higher threshold to a lower threshold: and

continue to mark the data based on the higher level of congestion for a period of time.

19. The device of claim 1 1, wherein the data comprises multimedia data.

20. The device of claim 1 1 , wherein the processor is further configured to:

send a request for the data to a content source; and

receive the data from the content source.