HK1243569B - Peer-to -peer node, peer-to -peer application server and storage medium - Google Patents

Description

Peer nodes, peer application servers, and storage media

This application was filed on February 21, 2011, with international application number PCT/US2011/025605, and entered the Chinese national phase on August 21, 2013, with national application number 201180068138.X, which is a divisional application of the invention patent application entitled “Managed Peer-to-Peer Sharing in Cellular Networks”.

Technical Field

The present invention generally relates to communication systems and methods for operating the same. In one aspect, the present invention relates to apparatus and methods for performing peer-to-peer (P2P) data sharing operations between peer nodes in a wireless-enabled communication environment.

Background Art

Currently, technologies available for implementation in today's wireless communication environments are capable of supporting bandwidth-intensive content distribution services (CDS) such as video on demand (VoD). As an example, various IEEE 802.11 ("WiFi") variants with limited range currently provide data rates of up to 100 Mbps, while current IEEE 802.16 ("WiMAX") variants provide data rates of up to 40 Mbps. As another example, Long Term Evolution (LTE) technology can generally support 5-10 Mbps downlink and 2-5 Mbps uplink data rates. The widespread adoption of smartphones and other mobile devices, combined with the availability of these data rates, has enabled the mainstream use of resource-intensive multimedia applications in mobile environments.

However, the delivery of bandwidth-intensive content is not without its attendant problems and challenges. As an example, a mobile subscriber typically establishes a wireless connection between a client node (e.g., a smartphone or other mobile device) and an access node (e.g., a cellular base station or a wireless broadband access point). Once the connection is established, the user typically searches for the desired content on a web portal implemented on the Internet or other IP-based network. Once the location is determined, the desired content is retrieved from a content source (e.g., a content data source server also implemented on the Internet). Once the desired content is retrieved, the content is wirelessly transmitted to the requester's client node.

As a result of this process, it is not uncommon to cause delays during the delivery of the content, particularly if the transmission conditions of the wireless link being used are not operating at optimal capacity. One solution to this problem is to implement a cache server at a predetermined network location. For example, a content provider may implement a cache server where a wireless broadband access network connects to the Internet. As another example, a wireless provider may implement multiple cache servers in their wireless environment to reduce local network congestion, data transmission distance, and content delivery delays. However, the cost of deploying such cache servers and keeping the content they contain synchronized can result in significant operational overhead and associated costs.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be understood and its numerous objects, features, and advantages may be attained when the following detailed description is considered in conjunction with the following drawings, in which:

FIG1 illustrates an exemplary system in which the present invention may be implemented;

FIG2 illustrates a wireless communication system including an embodiment of a user equipment (UE) device;

FIG3 is a simplified block diagram of an exemplary client node including a digital signal processor (DSP);

FIG4 is a simplified block diagram of a software environment that may be implemented by a DSP;

5 is a simplified block diagram illustrating a peer-to-peer (P2P) application server (P2P AS) for enabling P2P sharing of content data between client nodes in a wireless-enabled communication environment;

FIG6 illustrates a processing signal flow that is implemented to perform a P2P content data sharing operation between client nodes;

FIG7 illustrates sequential and parallel request processing signal flows that may be implemented to perform P2P content data sharing operations between multiple server peer nodes and client peer nodes;

FIG8 illustrates sequential and parallel request processing signal flows that a content data requester implements to perform P2P content data sharing operations among multiple server peer nodes and client peer nodes;

FIG9 is a simplified block diagram of a server-side implementation of a preference level conversion function (PLCF) module and a P2P AS for improving network operation efficiency;

FIG10 is a simplified block diagram of a client-side implementation of a PLCF module and peer nodes for improving network operation efficiency;

FIG11 shows a signal flow implemented using an application function (AF) for more efficient P2P content data sharing operation; and

FIG12 is a simplified block diagram of a P2P AS for performing P2P content data sharing with traditional peer nodes.

DETAILED DESCRIPTION

A method, system, and apparatus are provided for performing peer-to-peer (P2P) data sharing operations between client nodes in a wireless-enabled communication environment. In various embodiments, a first client node includes content data and operates in a server-to-peer mode to provide the content data. A second client node submits a request for the content data to a P2P application server (P2P AS). In response, the P2P AS provides the address of the first client node to the second client node. The second client node then submits a request to the first client node to provide the content data. The first client node receives the request and then provides the content data to the second client node.

In one embodiment, the third client node includes the same content data as the first client node. In this embodiment, the second client node submits a request for the content data to the P2P AS. In response, the P2P AS provides the second client node with the address of the first client node and the address of the third client node. The second client node then submits a request to the first client node using the address of the first client node, requesting the content data. If the first client node accepts the request, the first client node provides the requested content data to the second client node. However, if the first client node rejects the request, the second client node submits a request for the content data to the third client node using the address of the third client node. If the third client node accepts the request, the third client node provides the requested content data to the second client node.

In another embodiment, the second client node submits a request for the content data to the first client node and the third client node simultaneously. If the first client node rejects the request and the third client node accepts the request, the third client node provides the requested content data to the second client node. In another embodiment, the second client node submits a request for the content data to the first client node and the third client node simultaneously. If both the first client node and the third client node accept the request, the second client node selects the first client node or the third client node to provide the requested content data. The selected client node then provides the requested content data to the second client node.

In another embodiment, the P2P AS includes a content data requester. In this embodiment, the P2P AS receives a request for the content data from the second client node. Furthermore, the P2P AS provides the request to the content data requester. The content data requester then submits the request to the first client node and the third client node, either sequentially or simultaneously, as described in more detail herein. If the first client node or the third client node accepts the request, in response, the first client node or the third client node provides the requested content data to the second client node, as described in more detail herein.

Various illustrative embodiments of the present invention will now be described in detail with reference to the accompanying drawings. Although various details are set forth in the following description, it will be understood that these particular details may not be needed to implement the present invention, and many decisions specifically designed for implementation may be made to the invention described herein to achieve the specific goals of the inventors that are different from one another between the embodiments (e.g., subject to processing technology or design-related restrictions). Although this development work may be complex and time-consuming, it will be a routine for those skilled in the art to undertake that will benefit from this disclosure. For example, in order to avoid limiting the present invention or obscuring the present invention, selected schemes are shown in the form of block diagrams and flow charts rather than in detail. In addition, some parts of the detailed description provided herein are shown, based on algorithms or the operation of data in a computer memory. These descriptions and representations are used by those skilled in the art to describe or convey the essence of their work to other persons skilled in the art.

As used herein, the terms "component," "system," and the like are intended to refer to a computer-related entity, whether hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, or a computer. By way of illustration, both applications running on a computer and the computer itself can be components. One or more components can reside within a process or thread of execution, and a component can be localized on one computer or distributed between two or more computers.

Likewise, the term "node" as used herein refers broadly to a connection point (e.g., a redistribution point or a communication endpoint) of a communication environment such as a network. Thus, such a node refers to an active electronic device capable of sending, receiving, or forwarding information over a communication channel. Examples of such nodes include data circuit-terminating equipment (DCE) (e.g., a modem, hub, bridge, or switch) and digital terminal equipment (DTE) (e.g., a cell phone, printer, or host computer (e.g., a router, workstation, or server)). Examples of local area network (LAN) or wide area network (WAN) nodes include computers, packet switches, broadband modems, data subscriber line (DSL) modems, and wireless LAN (WLAN) access points.

Examples of Internet or intranet nodes include host computers identified by Internet Protocol (IP) addresses, network bridges, and WLAN access points. Similarly, examples of nodes in cellular communications include base stations, base station controllers, home location registers, gateway GPRS support nodes (GGSNs), and serving GPRS support nodes (SGSNs).

As used herein, the term "node" refers to a network of devices that can be used to connect to a network or to perform a communication between the network and the server. Other examples of nodes include client nodes, server nodes, peer nodes, and access nodes. Client nodes used herein can refer to wireless devices (e.g., mobile phones, smart phones, personal digital assistants (PDAs), handheld devices, portable computers, tablet computers, and similar devices or other user equipment (UE) with communication capabilities). Such client nodes can also refer to mobile, wireless devices or, on the contrary, refer to devices that cannot be moved generally (e.g., desktop computers, set-top boxes, or sensors) with similar capabilities. Similarly, server nodes used herein refer to information processing devices (e.g., host computers) or a series of information processing devices that perform information processing requests submitted by other nodes. Similarly, peer nodes used herein can sometimes serve as client nodes and serve as server nodes at other times. In peer-to-peer or overlay networks, the node that effectively routes the data for other networked devices and itself can be referred to as a super node.

As used herein, an access node refers to an access node that provides a client node with access to a communication environment. Examples of access nodes include cellular network base stations and wireless broadband (e.g., WiFi, WiMAX, etc.) access nodes that provide corresponding cells and WLAN coverage areas. As used herein, a macrocell is used to generally describe the coverage area of a traditional cellular network cell. Such macrocells are generally found in rural areas, along highways, or in underdeveloped areas. Similarly, as used herein, a macrocell refers to a cellular network cell with a coverage area that is smaller than that of a macrocell. Such macrocells are generally used in densely populated urban areas. Similarly, as used herein, a femtocell refers to a cellular network coverage area that is smaller than that of a microcell. Examples of the coverage area of a femtocell may be a large office, a shopping mall, or a train station. As used herein, a femtocell currently refers to the typically smallest acceptance area of cellular network coverage. As an example, the coverage area of a femtocell is sufficient for a home or a small office.

Generally, a coverage area smaller than two kilometers is generally designated as a microcell, a coverage area of 200 meters or less is generally designated as a nanocell, and a coverage area on the order of 10 meters is generally designated as a femtocell. Similarly, as used herein, a client node communicating with an access node associated with a macrocell is referred to as a "macrocell client." Similarly, a client node communicating with an access node associated with a microcell, nanocell, or femtocell is referred to as a "microcell client," "femtocell client," or "femtocell client," respectively.

As used herein, the term "article of manufacture" (or alternatively, "computer program product") is intended to encompass a computer program accessible from any computer-readable device or medium. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, etc.), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), small cards, and flash memory devices (e.g., cards, sticks, etc.).

The term "example" is used herein to mean serving as an example, instance, or illustration. Any solution or design described herein as an "example" is not necessarily to be construed as better or more advantageous than other solutions or designs. Those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope, spirit, or intent of the claimed subject matter. In addition, the disclosed subject matter may be implemented as a system, method, apparatus, or article of manufacture using standard programming and engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer- or processor-based device to implement the methods described in detail herein.

FIG1 shows an example of a system 100 suitable for implementing one or more embodiments disclosed herein. In various embodiments, system 100 includes a processor 110 (which may be referred to as a central processing unit (CPU) or a digital signal processor (DSP)), a network connection device 120, a random access memory (RAM) 130, a read-only memory (ROM) 140, an auxiliary storage 150, and an input/output (I/O) device 160. In some embodiments, some of these components may not be present, or may be combined with each other or with other components not shown in the figure in various combinations. These components may be located in a single physical entity or in more than one physical entity. Any action described herein performed by processor 110 may be performed by processor 110 alone, or by processor 110 in combination with one or more components shown or not shown in FIG1 .

The processor 110 executes instructions, codes, computer programs, or scripts that may be accessed from the network connection device 120, RAM 130, or ROM 140. Although only one processor 110 is shown, multiple processors may be present. Thus, although instructions are discussed as being executed by the processor 110, the instructions may be executed simultaneously, sequentially, or otherwise by one or more processors 110 implemented as one or more CPU chips.

In various embodiments, the network connection device 120 may be implemented in the form of a modem, a modem bank, an Ethernet device, a Universal Serial Bus (USB) interface device, a serial port, a token ring device, a Fiber Distributed Data Interface (FDDI) device, a Wireless Local Area Network (WLAN) device, a radio transceiver device (e.g., a Code Division Multiple Access (CDMA) device), a Global System for Mobile Communications (GSM) radio transceiver device, a Worldwide Interoperability for Microwave Access (WiMAX) device, and/or other well-known devices for connecting to a network (including a Personal Area Network (PAN) such as Bluetooth). These network connection devices 120 may enable the processor 110 to communicate with the Internet or one or more telecommunication networks or other networks from which the processor 110 may receive information or to which the processor 110 may output information.

The network connection device 120 can also transmit or receive data wirelessly in the form of electromagnetic waves (e.g., radio frequency signals or microwave frequency signals). The information transmitted or received by the network connection device 120 may include data processed by the processor 110 or instructions to be executed by the processor 110. The data may be sorted according to different orders desired for processing or generating the data or transmitting or receiving the data.

In various embodiments, RAM 130 can be used to store volatile data and instructions executed by processor 110. ROM 140, shown in FIG. 1 , can be used to store instructions and possibly data read during instruction execution. Access to RAM 130 and ROM 140 is generally faster than access to secondary storage 150. Secondary storage 150 typically includes one or more disk drives or tape drives and can be used for non-volatile data storage or as an overflow data storage device if RAM 130 is insufficient to hold all working data. Secondary storage 150 can be used to store programs that are loaded into RAM 130 when the program is selected for execution. I/O devices 1360 can include a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a projector, a television, a touch screen display, a keyboard, a keypad, switches, a dial, a mouse, a trackball, a voice recognizer, a card reader, a paper tape reader, a printer, a video monitor, or other well-known input devices.

Fig. 2 shows wireless and enables communication environment, and this communication environment is included in the embodiment of the client node realized in embodiments of the present invention.Although be shown as mobile phone, client node 202 can have various forms (comprising, wireless handset, pager, smart phone or personal digital assistant (PDA)).In various embodiments, client node 202 can also comprise: portable computer, tablet computer, laptop computer or can operate any computing device for performing data communication operation.Some or all functions in these functions of many suitable equipment combinations.In certain embodiments, client 202 is not general computing device, as portable, laptop or tablet computer, but special communication equipment, as the telecommunication equipment installed in vehicle.Client 202 can be the equipment (such as, desktop computer, set-top box or network node) with similar ability but not portable equally, comprises this equipment or is included in this equipment.In these or other embodiments, client 202 can support special activity (such as game, inventory control, job control, task management function etc.).

In various embodiments, the client 202 may include a display 204. In these or other embodiments, the client 202 may also include a touch-sensitive surface, a keyboard, or other input keys 206 generally used for user input. The input keys 206 may also be a full or simplified alphanumeric keyboard (e.g., QWERTY, Dvorak, AZERTY, and continuous keyboard types), or a traditional numeric keypad with letters associated with a telephone keypad. The input keys 206 may also include a scroll wheel, an escape or escape key, a trackball, and other navigational or functional keys that may be inwardly depressible to provide further input functionality. The client node 202 may also present options for the user to select, controls for the user to actuate, and a cursor or other indicator for the user to direct.

The client node 202 may also accept data entries from the user, including digits for dialing or various parameter values for configuring the operation of the client node 202. The client node 202 may also execute one or more software or firmware applications in response to user commands. These applications may configure the client node 202 to perform various personalized functions in response to user interactions. In addition, the client node 202 may be programmed or configured over the air (OTA) (e.g., from wireless network access node 'A' 210, through 'n' 216 (e.g., a base station), a server node 224 (e.g., a host computer), or a peer client node 202).

Among the various applications executable by client node 202 is a web browser that enables display 204 to display web pages. Web pages can be obtained from server node 224 via a wireless connection to wireless network 220. Similarly, various applications can be obtained from peer client nodes 202 or other systems via a connection to wireless network 220 or any other wireless communication network or system. In various embodiments, wireless network 220 includes multiple wireless subnetworks, from wireless subnetwork 'A' 212 (e.g., cells with corresponding coverage areas) to wireless subnetwork 'n' 218. In these and other embodiments, client node 202 sends and receives communication signals, which are transmitted via wireless network antenna 'A' 208 to wireless network antenna 'n' 214 (e.g., cell towers) to and from wireless network node 'A' 210 to wireless network node 'n' 216, respectively. In turn, wireless network access nodes 'A' 210 to 'n' 216 use the communication signals to establish a wireless communication session with client node 202. Furthermore, wireless network access node 'A' 210 to wireless network access node 'n' 216 are respectively coupled to wireless sub-network 'A' 212 to wireless sub-network 'n' 218 connected to wireless network 220.

In various embodiments, the wireless network 220 is coupled to a physical network 222 (e.g., the Internet). Via the wireless network 220 and the physical network 222, the client node 202 can access information on various hosts (e.g., server nodes 224). In these and other embodiments, the server node 224 can provide content that can be displayed on the display 204. Alternatively, the client node 202 can access the wireless network 220 with a relay-type or hop-type connection through an end client node 202 acting as a relay. Alternatively, the client node 202 is wired and obtains its data from a wired device connected to the wireless network 212. Those skilled in the art will recognize that many such embodiments are possible, and the above is not intended to limit the spirit, scope, or purpose of the present disclosure.

FIG3 shows a block diagram of an exemplary client node implemented using a digital signal processor (DSP) according to an embodiment of the present invention. Although various components of client node 202 are described, various embodiments of client node 202 may include a subset of the listed components or additional components not listed. As shown in FIG3 , client node 202 includes DSP 302 and memory 304. As shown, the client node 202 may also include an antenna and front end unit 306, a radio frequency (RF) transceiver 308, an analog baseband processing unit 310, a microphone 312, a head-mounted speaker 314, a headphone port 316, a bus 318 (e.g., a system bus or an input/output (I/O) interface bus), a removable memory card 320, a universal serial bus (USB) port 322, a short-range wireless communication subsystem 324, an alarm 326, a keyboard 328, a liquid crystal display (LCD) 330 that may include a touch-sensitive surface, an LCD controller 332, a charge-coupled device (CCD) camera 334, a camera controller 336, and a global positioning system (GPS) sensor 338, and a power management module 340 operatively coupled to an energy storage unit (e.g., a battery 342). In various embodiments, the client node 202 may include another type of display that does not provide a touch-sensitive screen. In one embodiment, the DSP 802 may communicate directly with the memory 804 without going through the input/output interface 318.

In various embodiments, the DSP 302 or some other form of controller or central processing unit operates according to embedded software or firmware stored in the memory 304 or stored in memory contained within the DSP 302 itself to control the various components of the client node 202. In addition to the embedded software or firmware, the DSP 302 may execute other applications that are stored in the memory 304 or available via information carrier media (e.g., portable data storage media like the removable memory card 302) or via wired or wireless network communications. The application software may include a compiled set of machine-readable instructions that configure the DSP 302 to provide the desired functionality, or the application software may be high-level software instructions to be processed by an interpreter or compiler to indirectly configure the DSP 302.

The antenna and front end unit 306 is provided to convert between wireless signals and electrical signals, enabling the client node 202 to send and receive information from a cellular network or some other available wireless communication network or from an equivalent client node 202. In an embodiment, the antenna and front end unit 106 may include multiple antennas to support beamforming and/or multiple-input multiple-output (MIMO) operation. As known to those skilled in the art, MIMO operation can provide spatial diversity that can be used to overcome different channel conditions or to increase channel throughput. Similarly, the antenna and front end unit 306 may include antenna tuning and/or impedance matching components, RF power amplifiers, or low-noise amplifiers.

In various embodiments, the RF transceiver 308 provides frequency shifting, converting received RF signals to baseband and converting baseband transmit signals to RF. In some descriptions, a radio transceiver or RF transceiver may be understood to include other signal processing functions (e.g., modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transform (IFFT)/fast Fourier transform (FFT), cyclic prefix addition/removal, and other signal processing functions). For clarity, the description herein separates this signal processing from the description of the RF and/or radio layers and conceptually assigns this signal processing to the analog baseband processing unit 310 and/or the DSP 302 or other central processing unit. In some embodiments, the RF transceiver 108, portions of the antenna and front end unit 306, and the analog baseband processing unit 310 may be combined into one or more processing units and/or application-specific integrated circuits (ASICs).

The analog baseband processing unit 310 can provide various analog processing of inputs and outputs, such as analog processing of inputs from the microphone 312 and the headphone port 316 and outputs to the head-mounted speaker 314 and the headphone port 316. To this end, the analog baseband processing unit 310 can include ports for connecting to the built-in microphone 312 and the head-mounted speaker 314, which enables the client node 202 to function as a mobile phone. The analog baseband processing unit 310 can also include ports for connecting to a headset or other hands-free microphone and speaker configuration. The analog baseband processing unit 310 can provide digital-to-analog conversion in one signal direction and analog-to-digital conversion in the opposite signal direction. In various embodiments, at least some of the functionality of the analog baseband processing unit 310 can be provided by digital processing components (e.g., by the DSP 302 or by other central processing units).

The DSP 302 may perform modulation/demodulation, encoding/decoding, interleaving/deinterleaving, spreading/despreading, inverse fast Fourier transform (IFFT)/fast Fourier transform (FFT), cyclic prefix addition/removal, and other signal processing functions associated with wireless communications. In one embodiment, for example, in a code division multiple access (CDMA) technology application, the DSP 302 may perform modulation, encoding, interleaving, and spreading for transmitter functions, and despreading, deinterleaving, decoding, and demodulation for receiver functions. In another embodiment, for example, in an orthogonal frequency division multiple access (OFDMA) technology application, the DSP 302 may perform modulation, encoding, interleaving, inverse fast Fourier transform, and cyclic prefix addition for transmitter functions, and cyclic prefix removal, fast Fourier transform, deinterleaving, decoding, and demodulation for receiver functions. In other wireless technology applications, the DSP 302 may perform other signal processing functions and combinations of signal processing functions.

DSP 302 can communicate with a wireless network via analog baseband processing unit 310. In some embodiments, this communication can provide an Internet connection, enabling users to access content on the Internet and send and receive emails or text messages. Input/output interface 318 interconnects DSP 302 and various memories and interfaces. Memory 304 and removable memory card 320 can provide software and data for configuring the operation of DSP 302. Among the interfaces may be a USB interface 322 and a short-range wireless communication subsystem 324. USB interface 322 can be used to charge client node 202 and can also enable client node 202 to function as a peripheral device for exchanging information with a personal computer or other computer system. Short-range wireless communication subsystem 324 may include an infrared port, a Bluetooth port, an IEEE 802.11-compliant wireless port, or any other short-range wireless communication subsystem that enables client node 202 to wirelessly communicate with other nearby client nodes and access nodes.

The input/output interface 318 also connects the DSP 302 to the alarm 326, which, when triggered, enables the client node 202 to provide notification to the user, such as by ringing, playing a melody, or vibrating. The alarm 326 can serve as a mechanism for alerting the user of any of a variety of events (e.g., incoming calls, new text messages, and appointment reminders) by silently vibrating or by playing a specific pre-assigned melody for a specific caller.

The keyboard 328 is coupled to the DSP 302 via the I/O interface 318 to provide a mechanism for a user to make selections, enter information, and provide input to the client node 202. The keyboard 328 can be a full or simplified alphanumeric keyboard (e.g., QWERTY, Dvorak, AZERTY, and continuous type), or a traditional numeric keypad with letters associated with a telephone keypad. Input keys can also include a scroll wheel, an exit or cancel key, a trackball, and other navigational or functional keys that can be pressed inward to provide other input functions. Another input mechanism can be an LCD 330, which can include touch screen capabilities and can also display text and/or graphics to the user. An LCD controller 332 couples the DSP 302 to the LCD 330.

A CCD camera 334 (if equipped) enables the client node 202 to take digital photos. The DSP 302 communicates with the CCD camera 334 via a camera controller 336. In another embodiment, a camera operating according to a technology other than a charge coupled device camera can be used. A GPS sensor 338 is coupled to the DSP 302 to decode global positioning system signals, thereby enabling the client node 202 to determine its location. Various other peripheral devices may be included to provide additional functionality (e.g., radio and television reception).

FIG4 illustrates a software environment 402 that may be implemented by a digital signal processor (DSP). In this embodiment, the DSP 302 shown in FIG3 runs an operating system 404, which provides a platform for the remaining software operations. The operating system 404 also provides standardized interfaces (e.g., drivers) to the client node 202 hardware that allow access to application software. The operating system 404 also includes an application management service (AMS) 406 that transfers control between applications running on the client node 202. FIG4 also illustrates a web browser application 408, a media player application 410, and a Java application 412. The web browser application 408 configures the client node 202 to operate as a web browser, allowing the user to enter information into forms and select links to retrieve and browse web pages. The media player application 410 configures the client node 202 to retrieve and play audio or audiovisual media. The Java application 412 configures the client node 202 to provide games, tools, and other functionality. Component 414 may provide the functionality described herein. In various embodiments, the client node 202, wireless network node 'A' 210 to wireless network node 'n' 216, and server node 224 shown in Figure 2 may also include processing components capable of executing instructions related to the above-mentioned actions.

FIG5 is a simplified block diagram illustrating a peer-to-peer (P2P) application server (P2P AS) implemented in accordance with an embodiment of the present invention, which facilitates P2P sharing of content data between client nodes in a wireless-enabled communication environment. In this embodiment, an Internet Protocol (IP)-based network 502 (e.g., the Internet) is connected to a mobile wireless network (e.g., a cellular core network 516) and a fixed wireless access network 536. As shown in FIG5 , the network operator's IP service domain 512 includes a P2P AS 514 implemented as a server node of the cellular core network 516 and the IP-based network 502 to facilitate P2P content data sharing between peer nodes, as described in greater detail herein. The IP-based network 502 includes a content data source server 504, a web portal 506, and cache servers 'x' 508 and 'y' 510, which are implemented at the connection points of the IP-based network 502 to the cellular core network 516 and the fixed broadband access network 436, respectively.

5 , cellular core network 516 includes mobile wireless coverage areas '1' 518 and '2' 526, and fixed broadband wireless access network 536 includes wireless coverage area '3' 530. Similarly, mobile wireless coverage areas '1' 518 and '2' 526 overlap, and mobile wireless coverage area '2' 526 overlaps with wireless coverage area '3' 530. In this example, when peer nodes 'A' 520 and 'B' 522 are in mobile wireless coverage area '1' 518, peer nodes 'A' 520 and 'B' 522 achieve connectivity with cellular core network 516, and when peer node 'D' is in mobile wireless coverage area '2' 526, connectivity with cellular core network 516 is achieved by peer node 'D'. However, when peer node ‘C’ 524 is in mobile wireless coverage area ‘1’ 518 or ‘2’ 526, peer node ‘C’ 524 is able to connect with the cellular core network 516. Similarly, when peer nodes ‘D’ 528, ‘E’ 532, and ‘F’ 534 are in fixed wireless coverage area ‘3’ 530, connectivity with the fixed broadband access network 536 is achieved by peer nodes ‘D’ 528, ‘E’ 532, and ‘F’ 534. However, when peer node ‘D’ 528 is in the overlapping coverage area of mobile wireless coverage area ‘2’ 526 and fixed wireless coverage area ‘3’ 530, peer node ‘D’ 528 is able to connect with both the cellular core network 516 and the fixed broadband access network 536.

In various embodiments, individual peer nodes 'A' 520, 'B' 522, 'C' 524, 'D' 528, 'E' 532, and 'F' 534 are implemented to perform peer-to-peer (P2P) content data sharing operations. In these and other embodiments, the P2P content data sharing operations include mutually sharing uplink bandwidth and storage space when downloading data from the content data source server 504. In this manner, the P2P content data sharing operations performed by the peer nodes 'A' 520, 'B' 522, 'C' 524, 'D' 528, 'E' 532, and 'F' 534 can extend traffic across the edge of the cellular core network 516. As a result of performing these P2P content data sharing operations, Internet traffic overhead is reduced, and storage and bandwidth requirements of centralized servers (e.g., the content data source server 504 and the web portal 506) are reduced. Likewise, the local P2P content data sharing operations performed by peer nodes 'A' 520, 'B' 522, 'C' 524, 'D' 528, 'E' 532, and 'F' 534 may also improve user experience due to improved data throughput.

In this embodiment, peer node 'D' 528 can establish a connection with the cellular core network 516 or the fixed wireless coverage area 530 to access the web portal 506. Once accessed, the user performs a search operation on the web portal 506 to locate the desired content data. Once the desired content data is located, the content data source server 504 requests the desired content data. In various embodiments, the content data request can be redirected to cache server 'x' 508 or 'y' 510 (if available), which can be topologically closer to peer node 'D' 528. The desired content data can then be downloaded from the content data source server 504, or alternatively, if cache server 'x' 508 or 'y' 510 is available and topologically closer to peer node 'D' 528, the desired content data can be downloaded from cache server 'x' 508 or 'y' 510.

Utilizing the P2P content data sharing operation described in greater detail herein, peer node 'D' 528 can share its downloaded content with other peer nodes 'A' 520, 'B' 522, 'C' 524, 'E' 532, and 'F' 534. Thus, each of the other peer nodes 'A' 520, 'B' 522, 'C' 524, 'E' 532, and 'F' 534 has the potential to become a source for downloaded content data. Similarly, each of the peer nodes 'A' 520, 'B' 522, 'C' 524, 'D' 528, 'E' 532, and 'F' 534 can operate independently in either a client peer mode or a server peer mode when sharing content data in a P2P mode. When in client peer mode, a single peer node ‘A’ 520, ‘B’ 522, ‘C’ 524, ‘D’ 528, ‘E’ 532, or ‘F’ 534 obtains content data only from the content data source server 504 or other single peer nodes ‘A’ 520, ‘B’ 522, ‘C’ 524, ‘D’ 528, ‘E’ 532, and ‘F’ 534. When in server mode, a single peer node ‘A’ 520, ‘B’ 522, ‘C’ 524, ‘D’ 528, ‘E’ 532, or ‘F’ 534 shares downloaded content data with other peer nodes ‘A’ 520, ‘B’ 522, ‘C’ 524, ‘D’ 528, ‘E’ 532, and ‘F’ 534. Likewise, in various embodiments, multiple P2P application servers (e.g., P2P AS 514) deployed in the P2P AS network 512 manage the sharing of P2P content data among the respective peer nodes 'A' 520, 'B' 522, 'C' 524, 'D' 528, 'E' 532, and 'F' 534. In one embodiment, the P2P application server 514 implemented in the network operator's IP service domain 512 manages the sharing of P2P content data by maintaining a candidate list of individual peer nodes 'A' 520, 'B' 522, 'C' 524, 'D' 528, 'E' 532, and 'F' 534 that can provide the requested content data.

Figure 6 illustrates a signal flow for performing a peer-to-peer (P2P) content data sharing operation between user equipment (UE) devices, implemented according to an embodiment of the present invention. In this embodiment, content data is exchanged between a client peer node '1' 602 and a server peer node '2' 604 connected to a wireless network 516, thereby providing access to a P2P application server (P2P AS) 514.

In various embodiments, client peer node ‘1’ 602 and server peer node ‘2’ register with P2P AS 514, indicating their ability to participate in P2P content data sharing operations. In these and other embodiments, the registration of client peer node ‘1’ 602 and server peer node ‘2’ 604 also indicates the preferred peer operation mode to client peer node ‘1’ 602 and server peer node ‘2’ 604 via application layer signaling. In these various embodiments, the application layer signaling can be an IP Multimedia Subsystem (IMS) (e.g., Session Initiation Protocol (SIP) signaling), or non-IMS signaling (e.g., (BB) signaling). Therefore, in these various embodiments, P2P AS 514 will consider the peer mode preference indication of the peer node to determine which candidate peer node can operate as a content data source when participating in P2P content data sharing.

In various embodiments, a P2P content data sharing protocol including a client mode is implemented as the default peer mode for various peer nodes (e.g., client peer node '1' 602). However, in these various embodiments, a peer node does not need to indicate its peer mode preference unless the peer node requests to be configured as a server peer node (e.g., in the case of server peer node '2' 604). When this is the case, the peer node (e.g., server peer node '2' 604) indicates its server mode preference to the P2P AS 514. In turn, the P2P AS 514 lists the peer node on a server peer node list. Similarly, the P2P AS 514 does not place peer nodes that are configured as client peer nodes (e.g., client peer node '1' 602) on a server peer node list. Those skilled in the art will recognize that the present solution provides the advantage of providing reverse compatibility, i.e., older peer nodes that are not able to provide server peer node capabilities will still be compatible with the P2P content data sharing operations described in more detail herein.

In one embodiment, P2P AS 514 maintains a server peer list containing all peer nodes that have indicated server mode as their preferred peer mode. In this embodiment, the server peer list is sorted based on the preference priority that P2P AS 514 has assigned to each server peer. When a client peer receives the server peer list, it selects a target server peer based on its associated preference priority, which is sorted from highest to lowest in the server peer list. Alternatively, a client peer may not select a target server peer based on its associated preference priority.

In another embodiment, the server peer node list includes some of the peer nodes that have indicated server mode as their preferred peer mode. In this embodiment, the P2P AS 514 has filtered out some peer nodes based on a predetermined P2P content data sharing operation policy. The server peer node list can be sorted based on the preference priority that the P2P AS 514 has assigned to each server peer node. If the list is sorted, the client peer node can select a target server peer node based on its preference priority, sorted from high to low. Alternatively, the client peer node may not select a target server peer node based on its associated preference priority. Those skilled in the art will appreciate that this solution provides the P2P AS 514 with more control over how P2P content data sharing operations are performed among the peer nodes.

In one embodiment, the P2P AS 514 can optionally notify a peer node whether it is set to server mode in the server peer node list. In this embodiment, when the P2P AS 514 receives a peer node preference indication, the notification is embedded in a positive acknowledgement (ACK) message sent to the associated peer node. However, once a peer node has sent its server mode preference indication, even if the peer node has not received a mode setting notification from the P2P AS 514, the peer node remains ready to serve other peer nodes. In another embodiment, a peer node can change its peer mode preference by sending a new indication to the P2P AS 514. As an example, when a peer node's battery level falls below a certain threshold, the peer node may prefer to operate as a client rather than a server.

In another embodiment, a timer is associated with each peer mode preference indication. In this embodiment, if P2P AS 514 does not receive information from the associated peer node after the timer expires, P2P AS 514 resets the peer node's peer mode preference to client mode. Those skilled in the art will appreciate that once a peer node ceases operating in server peer mode, the timer can eliminate the need for additional signaling between the peer node and P2P AS 514. However, the peer node can resume operating in server peer mode after the timer expires by resending its server mode preference indication to P2P AS 514.

Referring now to FIG6 , in step 620, server peer node ‘2’ 604 connects to a wireless network to perform a P2P content data sharing operation between server peer node ‘2’ 604 and client peer node ‘1’ 602. Server peer node ‘2’ 604 then sends a registration request 622 to P2P AS 514. As described in more detail herein, registration request 622 indicates to P2P AS 514 the peer mode preference of server peer node ‘2’ 604 and its associated timer value. Similarly, registration request 622 announces the available content data segments that server peer node ‘2’ 604 is willing to share. Alternatively, if server peer node ‘2’ only wishes to act as a client, server peer node ‘2’ does not need to register until it requests its desired content data from P2P AS 514. Thereafter, P2P AS 514 responds with an ACK response 624, which confirms the peer mode setting for server peer node ‘2’ 604. In some embodiments, as described in more detail herein, the ACK response 624 is optional. In some embodiments, the ACK response message 624 may also include a predetermined content data sharing operation policy.

In a first embodiment, as shown in option '1' 630 in FIG6 , client peer node '1' sends a request 626 to P2P AS 514 to inquire about the feasibility of retrieving content data. In response, P2P AS 514 responds with a response 628 containing a list of server peer nodes (e.g., server peer node '2' 604) and associated information (e.g., their respective addresses). After receiving the address information for server peer node '2' 604, client peer node '1' 602 then sends a request 632 for the desired content data directly to server peer node '2' 604, without going through P2P AS 514. In response, server peer node '2' 604 responds directly to client peer node '1' 602 with an ACK response 634, without going through P2P AS 514. The requested content data is then transmitted 636 from server peer node '2' 604 to client peer node '1' 602.

In a second embodiment, as shown in option '2' 640 in Figure 6 , client peer node '1' 620 then sends a request 642 for the desired content data to P2P AS 514, which is then sent to server peer node '2' 604. In response, server peer node '2' 604 responds to P2P AS 514 with an ACK response 644, which is then sent to client peer node '1' 602. The requested content data is then transmitted 646 from server peer node '2' 604 to client peer node '1' 602.

Those skilled in the art will appreciate that the first embodiment, shown as option '1' 630 in FIG6 , reduces the signal processing load at the P2P AS 514, as well as the signaling delay between the server peer node '2' 604 and the client peer node '1' 602. It will also be appreciated that if either the server peer node '2' 604 or the client peer node '1' 602, or both, are located in a private network behind a firewall with Network Address Translation (NAT), option '2' 640 also facilitates NAT. In contrast, the second embodiment (shown as option '2' in FIG6 ) provides more control to the P2P AS 514 by allowing the P2P AS 514 to perform authorization and authentication operations on content data requests between the client peer node '1' 602 and the server peer node '2' 604.

In some embodiments, the content data requests 632, 642 and the ACK responses 634, 644 may not be defined by the P2P content data sharing protocol described in more detail herein. Instead, they may be carried by a standard application layer protocol (e.g., HTTP or SIP). In other embodiments, when the P2P AS 514 receives the registration request 622, the server peer node '2' 604 may only operate as a server peer node during the P2P content data sharing operation. In these and other embodiments, if the registration request from the server peer node '2' 604 is lost before being received by the P2P AS 514, the server peer node '2' 604 cannot operate as a server peer node.

7 illustrates a sequential and parallel request processing signal flow for performing a peer-to-peer (P2P) content data sharing operation between multiple server peer nodes and client peer nodes, implemented according to embodiments of the present invention. In these embodiments, content data is exchanged in various ways between client peer node '1' 702 and server peer nodes '2' 704, '3' 706, and '4' 708, along with a P2P application server (P2P AS) 512. To initiate a P2P content data sharing operation, client peer node '1' 702 first sends a content data request 732 to P2P AS 514. P2P AS 514 then responds to client peer node '1' 702 with a response 734 containing a list of server peer nodes (e.g., server peer nodes '2' 704, '3' 706, and '4' 708) and associated information (e.g., their respective addresses).

In one embodiment, client peer node ‘1’ uses a list of server peer nodes and their associated address information to sequentially request 736 content data from server peer nodes ‘4’ 708, ‘3’ 706, and ‘2’ 704. As shown in Figure 7, client peer node ‘1’ 702 first sends a content data request 738 to server peer node ‘4’ 708, but receives a rejection response 740 in return. As a result, client peer node ‘1’ 702 then sends a content data request 742 to server peer node ‘3’ 706 and receives an ACK response 744 in return. Therefore, data transfer 746 is then performed between server peer node ‘3’ 706 and client peer node ‘1’ 702. As a result, client peer node ‘1’ 702 does not need to send a content data request to server peer node ‘2’ 704.

In another embodiment, client peer node ‘1’ uses the server peer node list and their associated address information to request content data from server peer nodes ‘4’ 708, ‘3’ 706 and ‘2’ 704 in parallel. As shown in Figure 7, client peer node ‘1’ 702 simultaneously sends content data requests 752, 754 and 756 to server-side UE ‘4’ 708, ‘3’ 706 and ‘2’ 704 respectively. In response, client peer node ‘1’ 702 receives a rejection request 758 from server peer node ‘4’ 708 and ACK responses 760 and 762 from server peer nodes ‘3’ 706 and ‘2’ 702 respectively. Then, client peer node ‘1’ 702 selects server peer node ‘3’ 706 to perform data transmission 764. Therefore, server peer node ‘2’ 704 does not need to transmit the requested data content data to client peer node ‘1’ 702.

8 illustrates a sequential and parallel request processing signal flow implemented by a content data requester for performing a peer-to-peer (P2P) content data sharing operation between multiple server peer nodes and client peer nodes according to an embodiment of the present invention. In these embodiments, content data is exchanged in different ways between client peer node '1' 802 and server peer nodes '2' 804 and '3' 806 along with a P2P application server (P2P AS) 512.

In these and other embodiments, the P2P AS 514 includes a content data requester entity 808 that is responsible for issuing content data requests according to a predetermined algorithm (e.g., sequentially, in parallel, etc.). In various embodiments, the content data requester entity 808 can be located in the P2P AS 514 or in the client peer node '1' 802. Those skilled in the art will appreciate that the implementation of the content data requester entity 808 in the P2P AS 514 provides the benefit of offloading signaling responsibilities from the client peer node '1' 802, which may have limited processing power and battery power. In this way, despite needing to contact multiple client peer nodes (e.g., server peer nodes '2' 804 and '3' 806), the client peer node '1' 802 only needs to send a single content data request. To initiate a P2P content data sharing operation, the client peer node '1' 802 first sends a content request 832 to the P2P AS 514. The P2P AS 514 then forwards the content request 832 along with a list of server peer nodes '2' 804 and '3' 806 and their associated information (e.g., their respective addresses).

In one embodiment, the content data requester entity 808 uses the server peer node list and its associated address information to sequentially request 736 content data from server peer nodes '2' 804 and '3' 806. As shown in Figure 8, the content data requester entity 808 first sends a content data request 738 to server peer node '2' 804, but receives a rejection response 840 in return. As a result, the content data requester entity 808 then sends a content data request 842 to server peer node '3' 806 and receives an ACK response 844 in return. In turn, the content data requester entity 808 forwards the ACK response 846 to the P2P AS 514, which then forwards the ACK response 848 to the client peer node '1' 802. Therefore, data transfer 850 is then performed between the server peer node '3' 806 and the client peer node '1' 802.

In another embodiment, the content data requester entity 808 uses the server peer node list and its associated address information to concurrently request 750 content data from server peer nodes '2' 804 and '3' 706. As shown in FIG8 , the content data requester entity 808 simultaneously sends content data requests 862 and 864 to server-side UEs '2' 804 and '3' 806, respectively. In response, the content data requester entity 808 receives a rejection request 866 from server peer node '2' 804 and an ACK response 868 from server peer nodes '2' 804 and '3' 806, respectively. In turn, the content data requester entity 808 forwards the ACK response 870 to the P2P AS 514, which then forwards the ACK response 872 to the client peer node '1' 802. Consequently, data transfer 874 is then performed between the server peer node '3' 806 and the client peer node '1' 802.

FIG9 is a simplified block diagram of a server-side implementation of a preference level conversion function (PLCF) module and a peer-to-peer (P2P) application server (P2P AS) according to an embodiment of the present invention for improving network operational efficiency. In various embodiments, when the P2P AS configures a peer node to operate as a server peer node, the peer node can upload content data received from other peer nodes. In these and other embodiments, the P2P AS configures the peer node's peer mode based on various cellular network conditions. This improves network operational efficiency by reducing content data delivery overhead and minimizing the impact on the quality of service (QoS) of other data services. For example, a peer node in a heavily loaded cell is not preferred to operate as a server peer node because doing so would exacerbate the cell's load. As another example, conflicts in a WiFi access network are less problematic than conflicts in a cellular network. Therefore, a peer node implemented using resources for WiFi access may be preferred to operate as a server peer node over a peer node implemented using resources solely for cellular access.

In these various embodiments, the cellular state may include the cellular network state (e.g., cell load), as well as the cellular state of an individual peer node (e.g., radio access type and subscription type). In one embodiment, the cellular state is static and includes the peer node's subscription type (e.g., fixed-rate data plan or data usage-based charging). In another embodiment, the cellular state is slowly changing (e.g., changing every tens of minutes) and includes the peer node's radio access type (e.g., cellular or WiFi), battery level, and user input. In another embodiment, the cellular state is rapidly changing (e.g., changing every tens of milliseconds) and includes the peer node's radio link quality and cell load.

In various embodiments, static and slowly changing cellular states are used to determine whether a peer node is suitable for operation as a server peer node. In these and other embodiments, state information associated with these cellular states is communicated to the P2PAS via application-layer signaling. In some embodiments, making the P2P AS access-agnostic is beneficial because the P2P AS may not need to know precise state information (e.g., radio access type). In these various embodiments, a PLCF module is implemented to translate received cellular state information into a binary indication (e.g., preferred or non-preferred). Furthermore, the P2PAS uses the binary indication to determine the peer mode of the peer node. Those skilled in the art will appreciate that this solution decouples the P2PAS from various potential cellular state information. Therefore, network operators can pre-configure or dynamically provision associated policies for preference level transitions at the PLCF. In various embodiments, the binary indication is extended with additional bits (e.g., two indication bits for four preference levels) to use more bits to indicate the additional preference levels.

9 , the PCLF module 906 is implemented in the server 902 along with the P2P AS 514. In this embodiment, the PCLF module 906 receives policy information 908 from the P2P AS 514 and cellular status information 922 from the peer node 902 acting as the client 902. The PCLF module 906 then processes the policy information 908 and the cellular status information 922 to generate a preference level 910, and then provides the preference level 910 to the P2P AS 514. In turn, the P2P AS 514 uses the preference level to determine whether the peer node 902 should operate in server-to-peer mode.

In one embodiment, the PLCF module is implemented as a network node separate from the server 902. In various embodiments, the peer node 902 may not provide the cellular state information 922 to the PLCF module 906. As an example, if the peer node 902 changes its radio access type from WiFi to cellular, there is no need to send a cellular state information update to the PLCF module 906. Therefore, even if the peer mode of the peer node 902 should be set to client peer mode when the current radio access type of the peer node 902 changes, its server peer mode may not be changed by P2PAS.

Thus, peer node 902 can receive content data requests from other peer nodes. Consequently, peer node 902 can reject the first content data request it receives, and PLCF module 906 will intercept the rejection message. The rejection message can include a rejection reason (e.g., radio access type change), which will also serve as a status update to PLCF module 906. Therefore, it will be apparent to those skilled in the art that P2P AS 514 will ultimately change the peer mode configuration of peer node 902 to client peer based on the preference level input 910 from PLCF module 906. Likewise, it will be apparent that the described implicit cellular state update scheme has the advantage of reducing the signaling overhead of peer node 902.

FIG10 is a simplified block diagram of a preference level conversion function (PLCF) module and a client-side implementation of peer-to-peer mode, according to an embodiment of the present invention, which is used to improve network operation efficiency. In this embodiment, the P2P AS 514 is implemented in a server 1002, and the PCLF module 1006 is implemented in a client 1020 along with the peer node 1002. The PCLF module 1006 receives policy information 1008 from the P2P AS 514 and cellular state information 1022 from the peer node 1002. The PLCF module 1006 then processes the policy information 1008 and cellular state information 1022 to generate a preference level 9100, which is then provided to the P2P AS 514. The P2P AS 514 then uses the preference level to determine whether the peer node 1002 should operate in server-to-peer mode.

FIG11 illustrates a signal flow implemented using an application function (AF) according to an embodiment of the present invention for more efficiently performing peer-to-peer (P2P) content data sharing operations. The rapidly changing cell states, described in greater detail herein, have no impact on the peer modes assigned by the P2P application server (P2P AS) to peer nodes. Instead, they are used to determine whether establishing content data sharing connections between various peer nodes is efficient. However, those skilled in the art will appreciate that using application layer signaling to provide rapidly changing cell state information is inefficient.

In one embodiment, a server peer node determines whether to accept or reject a content data request based on the current, rapidly changing cellular state (e.g., the quality of its current radio link). For example, if the radio link quality is poor, the server peer node simply rejects the content data sharing request. In this and other embodiments, the corresponding response message may include the reason for the rejection (e.g., poor radio link quality). If the content data request is rejected, the Preference Level Conversion Function (PLCF) module, described in more detail herein, intercepts its corresponding response message. Because the rejection is based on the rapidly changing cellular state, the server peer node's preference level is unaffected. To expand on this example, if the server peer node does not want to share content data at a particular moment due to poor current radio conditions, the server peer node may not respond to the content data request. It is even possible that the server peer node may be outside of its radio coverage area when the content data request is received. Similarly, the server peer node may not recognize the content data request at all, in which case the server peer node will not respond. If there is no response from the server peer node, its preference level and thus its peer mode are unaffected, as in the case of a content data request rejection.

In another embodiment, a subset of the fast-changing cellular state information may not be applicable to the previously described embodiments. For example, a peer node may not have state information associated with the overall load condition of the current cell. Instead, in this embodiment, a network-based solution is implemented, in which the fast-changing cellular state (e.g., cellular load condition) at the system level is evaluated to determine whether it is efficient to initiate a content data sharing connection with the server peer node. Similarly, if the cell in which the server peer node is located is overloaded, incoming content data requests may be delayed or blocked. In this embodiment, this situation is addressed by implementing a conditional bearer establishment request message so that the corresponding cellular network can determine whether to establish a bearer based on the current network condition (e.g., cell load). As shown in Figure 11, the application layer content data request is converted into a low-layer conditional bearer establishment request.

11 , an application function (AF) 1114 implemented in the cellular network operator's service domain intercepts application signaling information 1132 originating from the P2P AS and destined for the target server peer node 1102. Simultaneously, the P2P AS intercepts corresponding incoming content data requests 1132 originating from client peer nodes and also destined for the server peer node 1102.

AF 1114 then provides 1134 the relevant service information to Policy and Charging Rules Function (PCRF) 1112. In turn, PCRF 1110 generates a Policy Control and Charging (PCC) provision message 1134 to Packet Data Network Gateway (PDN GW) 1110, which converts the received application signaling information and content data request into a conditional bearer establishment request 1136. The conditional bearer establishment request 1136 is then provided to Serving Gateway (GW) 1108, which in turn generates its own conditional bearer establishment request 1138 and provides the conditional bearer establishment request 1138 to Mobility Management Entity (MME) 1106. In turn, MME 1106 then generates a bearer establishment request/session management request 1140 and provides the bearer establishment request/session management request 1140 to access point (e.g., eNodeB) 1104. Access point 1104 generates a radio resource control (RRC) connection reconfiguration message 1142, which is received by server peer node 1102. In this embodiment, after access node 1104 (e.g., eNodeB) receives the conditional bearer establishment request 1140, access node 1104 determines whether to establish a conditional bearer based on cell load conditions. This solution requires changes to the current Evolved Packet System (EPS) specifications.

In response, server peer node 1102 generates a response 1444 indicating that the RRC connection reconfiguration is complete. Once generated, the response is provided to access point 1104, which in turn provides a bearer establishment response 1146 to MME 1106. Server peer node 1102 also sends a direct transfer 1148 message to access point 1104, which in turn sends a session management response 1150 to MME 1106. MME 1106 then sends a create bearer response 1152 message to serving GW 1108, which then forwards the create bearer response 1154 message to PDD GW 1110. PDDGW 1110 then provides an ACK response 1156 to PCRF 1112, which in turn provides an event notification 1158 to AF 1114.

In another embodiment, PCRF 1112 converts the received service information into a Quality of Service (QoS) policy. In this embodiment, the QoS policy is defined such that the Allocation and Retention Priority (ARP) associated with the requested bearer is set at the lowest layer. Therefore, if the cell is overloaded, the access point (e.g., eNodeB) can reject the bearer request. This approach may require some clarification of the current EPS specifications regarding how ARP settings are interpreted for conditional bearer establishment. Those skilled in the art will appreciate that new ARP definitions could also be proposed to explicitly indicate whether the bearer establishment is conditional.

It is obvious from the above that there may be multiple copies of the same content data, and some of the copies may be located on hosts where there are rapid fluctuations in the cost of acquiring the content data. The fluctuations in mobile devices and their radio resources are the main example, but not necessarily the only case. It is also obvious that it is beneficial to acquire the desired content data from the host with the lowest acquisition cost. However, by the time the acquisition request reaches the host that is believed to represent the lowest cost, its cost may have changed and this host is no longer the best choice. It will also be obvious that the implementation of conditional acquisition requests (e.g., "acquire only when the cost is acceptable" or "below a certain level", etc.) allows content data to be acquired optimally when there is no prior information about the acquisition cost associated with it.

FIG12 is a simplified block diagram illustrating a peer-to-peer (P2P) application server (P2PAS) implemented in accordance with an embodiment of the present invention for performing P2P content data sharing with legacy user equipment (UE) devices. In various embodiments, a peer node may need to implement a P2P content data sharing protocol stack (as described in greater detail herein) to perform P2P content data sharing operations, particularly when the peer node acts as a serving peer node. However, in other embodiments, many UE devices currently in operation may not be able to utilize the P2P content data sharing protocol.

Nevertheless, conventional peer nodes that are currently capable of receiving content data from a network can also receive content data from a server peer node without implementing a P2P content data sharing protocol stack. In these other embodiments, conventional peer nodes send content requests to the P2P content data overlay network using a standard protocol (e.g., HTTP) just as they would normally send requests to a content server. However, the P2P content data overlay network determines an appropriate server peer node to service the content data request from the conventional peer node. Thus, the server peer node can then share the requested content data directly with the conventional peer node using a standard protocol (e.g., HTTP), or alternatively, a P2P content data serving proxy can relay the requested content data.

In this embodiment, the P2P content data overlay network 1208 includes: a P2P AS 1210, a plurality of server peer nodes (e.g., server peer nodes '1' 1214 and '2' 1216), and a P2P content data service agent 1212. The P2P content data overlay network 1208 is connected to the Internet 502 or the network operator's IP-based network, which includes a web portal 1206 and a content/cache server 1204 operable to provide content data. As shown in FIG12 , a P2P content data service (CDS) agent 1212 is also connected to the Internet 502 or the network operator's IP-based network for accessing the web portal 1206 and the content/cache server 1204.

Referring now to FIG. 12 , a conventional peer node '3' 1218 is implemented without using a P2P content data sharing protocol stack. Therefore, conventional peer node '3' 1218 sends a content data request 1220 carried by a standard protocol (e.g., HTTP) to query a web portal 1206 for the desired content data. In this and other embodiments, the web portal 1206 provides content data indexing, browsing, and search functionality. Furthermore, the web portal 1206 responds 1222 with the requested content data source information (including the address information of the P2P CDS agent 1210). In this and other embodiments, the P2P CDS agent 1212 acts as a gateway for the P2P content data overlay network.

Legacy peer node '3' 1218 then sends an HTTP request 1224 to P2P CDS proxy 1210 requesting the desired content data. P2P CDS proxy 1212 converts the HTTP content request into a P2P content request 1226, which is then sent to P2P AS 1210. Furthermore, P2P AS 1210 sends P2P content data requests 1228 and 1230 to server peer nodes '1' 1214 and '2' 1216, respectively. In response, server peer node '1' 1214 accepts 1232 the content data requests, while server peer node '2' 1216 rejects 1234 the content data requests. P2P AS 1210 then responds 1236 to P2P CDS proxy 1210, confirming that server peer node '1' 1214 can provide the requested content data. In turn, the P2P CDS proxy 1212 translates the P2P ACK response 1236 into an HTTP ACK response 1240. The requested content data is then transmitted 1242 from the server peer node '3' 1214 to the P2P CDS proxy 1212, which then transmits the requested content data to the legacy peer node '3' 1218.

Although the exemplary embodiments disclosed herein are described with reference to peer-to-peer (P2P) data sharing operations performed between peer nodes in a wireless-enabled communication environment, the present invention is not necessarily limited to the exemplary embodiments, which illustrate the inventive aspects of the present invention applicable to various authentication algorithms. Therefore, the specific embodiments disclosed above are merely illustrative and should not be taken as limitations on the present invention, as it will be apparent to those skilled in the art having the benefit of the teachings herein that the present invention may be modified and implemented in different but equivalent manners. Therefore, the foregoing description is not intended to limit the invention to the specific form set forth, but on the contrary, the foregoing description is intended to cover changes, modifications and equivalents included within the spirit and scope of the invention as defined by the appended claims, so that those skilled in the art will understand that they can make various changes, substitutions and alterations in its broadest form without departing from the spirit and scope of the invention.

Claims (14)

1. A peer node, comprising: Memory, the memory storing computer-executable instructions; and A processor configured to execute computer-executable instructions to perform peer-to-peer (P2P) content data sharing operations in a wireless-enabled communication environment using processing logic, to provide status information to one of a P2P application server (P2P AS) and a preference level conversion function (PLCF), and to operate in server-peer mode to provide the content data to a second peer node operating in client-peer mode, wherein the status information includes at least one of current radio access type, battery level, and user input. 2. The peer node of claim 1, wherein the processor is further configured to execute the computer-executable instructions to: Receive a request from the second peer node to provide the content data using the address of the peer node; and Provide the content data to the second peer node. The address of the peer node is received by the second peer node in response to a request for the content data submitted by the second peer node to the P2P AS. 3. A storage medium containing computer-executable instructions, which, when executed by a computer, cause the computer to: Processing logic is used to perform peer-to-peer (P2P) content data sharing operations in a wireless-enabled communication environment to provide status information to one of the P2P application server (P2P AS) and the preference level conversion function (PLCF), and to provide the content data to a second peer node operating in a client-peer mode, wherein the status information includes at least one of the following: current radio access type, battery level, and user input. 4. The storage medium according to claim 3, wherein, when executed by a computer, the computer is executable instructions that cause the computer to: Receive a request from the second peer node to provide the content data using the address of the peer node; and Provide the content data to the second peer node. The address of the peer node is received by the second peer node in response to a request for the content data submitted by the second peer node to the P2P AS. 5. A peer-to-peer (P2P) application server (PAS), comprising: Memory, the memory storing computer-executable instructions, and A processor configured to execute computer-executable instructions to perform P2P content data sharing operations in a wireless-enabled communication environment using processing logic, to receive status information from a first peer node operating in a server-peer mode, and to receive a request for content data from a second peer node operating in a client-peer mode, and subsequently provide address data corresponding to the first peer node, wherein the first peer node includes the content data, and the status information includes at least one of current radio access type, battery level, and user input. 6. The P2P AS of claim 5, wherein the processor is further configured to execute the computer-executable instructions to allocate the server peering mode to the first peer node and the client peering mode to the second peer node using the peering mode data. 7. The P2P AS of claim 6, wherein the processor is further configured to execute the computer-executable instructions to allocate the server peering mode to a third peer node using the peering mode data, the third peer node including the same content data as the first peer node. 8. The P2P AS of claim 7, wherein the processor is further configured to execute the computer-executable instructions to assign a first preference priority to the first peer node and a second preference priority to the third peer node using the peer-to-peer mode data. 9. The P2P AS according to claim 8, wherein: The first peer node includes a first set of cellular status data, and the second peer node includes a second set of cellular status data; and The processor is also configured to execute the computer-executable instructions to assign a first preference priority to the first peer node and a second preference priority to the third peer node, using the first set of the cellular state data and the second set of the cellular state data, respectively. 10. A storage medium containing computer-executable instructions, which, when executed by a computer, cause the computer to: Processing logic is used to perform P2P content data sharing operations in a wireless-enabled communication environment to receive status information from a first peer node operating in a server-peer mode and to receive a request for content data from a second peer node operating in a client-peer mode, and subsequently provide address data corresponding to the first peer node, wherein the first peer node includes the content data, and the status information includes at least one of the current radio access type, battery level, and user input. 11. The storage medium of claim 10, wherein, when executed by a computer, the computer-executable instructions cause the computer to allocate the server peering mode to the first peer node and the client peering mode to the second peer node using peering mode data. 12. The storage medium of claim 11, wherein, when executed by a computer, the computer-executable instructions cause the computer to allocate the server peer mode to a third peer node using the peer mode data, the third peer node including the same content data as the first peer node. 13. The storage medium of claim 12, wherein, when executed by a computer, the computer-executable instructions cause the computer to use the peer-to-peer mode data to assign a first preference priority to the first peer node and a second preference priority to the third peer node. 14. The storage medium of claim 13, wherein the first peer node comprises a first set of cellular state data, and the second peer node comprises a second set of cellular state data; and When executed by a computer, the computer-executable instructions cause the computer to use the first set of cellular state data and the second set of cellular state data to assign a first preference priority to the first peer node and a second preference priority to the third peer node, respectively.