WO2014074719A2

WO2014074719A2 - Channel management for peer-to-peer communications

Info

Publication number: WO2014074719A2
Application number: PCT/US2013/068955
Authority: WO
Inventors: Qing Li; Chonggang Wang; Zongrui DING; Paul L. Russell, Jr.; Hongkun Li
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2012-11-07
Filing date: 2013-11-07
Publication date: 2014-05-15
Also published as: WO2014074719A3

Abstract

Control of inter-peer-to-peer networks (inter-P2PNWs) and intra-P2PNW control may include virtually centralized, and distributed control approaches. A peer may be assigned as a super virtual leader (SuperVL) for communicating control and/or data information between P2PNWs by communicating with at least one peer in each of the P2PNWs, and such communication may be done over a Common Control and Data Channel (CCDCH) that is common to all of the P2PNWs. The CCDCH may be transmitted at the beginning of a superframe. Peers may be assigned as virtual leaders (VLs) or sub-virtual leaders (SubVLs) within the P2PNWs, and a Dedicated Control and Data Channel (DCDCH) may be used for control within each corresponding P2PNW. Fast accessing of CCDCH and DCDCH techniques may be used, as well techniques for inter-P2PNWs and intra-P2PNW channel allocation (CA) and channel accessing (CAc).

Description

CHANNEL MANAGEMENT FOR PEER-TO-PEER COMMUNICATIONS

CROSS REFERENCE TO RELATED APPLICATIONS

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

Application No. 61/723,641, filed on November 7, 2012, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Peer-to-peer (P2P) communications may be based on a peer's proximity for desired services in an infrastructure-base, infrastructure-less wireless communication system, or a hybrid system. According to an infrastructure-based approach, P2P communications may be centralized with a central controller or core network. According to an infrastructure-less approach, P2P communications may function as a distributed system without a central controller or core network.

SUMMARY

[0003] Control of inter-peer-to-peer networks (inter-P2PNWs) and intra-

P2PNW control may include virtually centralized, and distributed control approaches. A peer may be assigned as a super virtual leader (SuperVL) for communicating control and/or data information between P2PNWs by communicating with at least one peer in each of the P2PNWs, and such communication may be done over a Common Control and Data Channel

(CCDCH) that is common to all of the P2PNWs. The CCDCH may be transmitted at the beginning of a superframe. Peers may be assigned as virtual leaders (VLs) or sub-virtual leaders (SubVLs) within the P2PNWs, and a Dedicated Control and Data Channel (DCDCH) may be used for control within each corresponding P2PNW. Fast accessing of CCDCH and DCDCH techniques may be used, as well techniques for inter-P2PNWs and intra-

P2PNW channel allocation (CA) and channel accessing (CAc). BRIEF DESCRIPTION OF THE DRAWINGS

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

[0005] Figure 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

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

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

[0008] Figure 2 is a diagram of an example group of peer-to-peer networks (P2PNWs) in coexistence;

[0009] Figure 3 is a diagram of an example centralized P2PNW for data communication;

[0010] Figure 4 is a diagram of an example distributed P2PNW for data communication;

[0011] Figure 5 is a diagram of an example group of P2PNWs employing virtually centralized inter-P2PNWs control and intra-P2PNW control;

[0012] Figure 6 is a diagram of an example group of P2PNWs employing distributed inter-P2PNWs control and intra-P2PNW control;

[0013] Figure 7 is a diagram of an example group of P2PNWs employing hybrid control, distributed inter-P2PNWs and virtually centralized intra-P2PNW control;

[0014] Figure 8 is a diagram of an example P2PNW superframe including Common Control and Data Channel (CCDCH) and Dedicated Control and Data Channel (DCDCH) in a time division multiple access (TDMA) system; [0015] Figure 9 is a diagram of an example P2PNW superframe 900 including CCDCH and DCDCH in a code division multiple access (CDMA) system;

[0016] Figures 10A and 10B are diagrams of example P2PNW frames including CCDCH and DCDCH in an orthogonal frequency division multiple access (orthogonal FDMA) system;

[0017] Figure 11 is a flow diagram of an example fast channel accessing procedure for inter-P2PNWs communications through a CCDCH;

[0018] Figure 12 is a diagram of an example CCDCH accessing scheme based on priority;

[0019] Figure 13 is a flow diagram of an example fast channel accessing procedure for intra-P2PNW communications through a DCDCH;

[0020] Figure 14 is a flow diagram of an example inter-P2PNW's channel allocation (CA) procedure with P2PNW detection for virtually centralized control;

[0021] Figure 15 is a flow diagram of an example inter-P2PNW's CA procedure with P2PNW detection for distributed control;

[0022] Figure 16 is a flow diagram of an example inter-P2PNWs CA procedure with P2PNW detection for hybrid control;

[0023] Figure 17 is a flow diagram of an example inter-P2PNWs CA procedure with P2PNW cooperation for virtually centralized control;

[0024] Figure 18 is a flow diagram of an example inter-P2PNW's CA procedure with P2PNW cooperation for distributed control;

[0025] Figure 19 is a flow diagram of an example inter-P2PNWs CA procedure with P2PNW cooperation for hybrid control;

[0026] Figure 20 is a flow diagram of an example intra-P2PNW

CA/Channel Accessing (CAc) procedure with peer detection for virtually centralized control;

[0027] Figure 21 is a flow diagram of an example intra-P2PNW CA/CAc procedure with peer detection for distributed control; [0028] Figure 22 is a flow diagram of an example intra-P2PNW CA/CAc procedure with peer cooperation for virtually centralized control; and

[0029] Figure 23 is a flow diagram of an example intra-P2PNW CA/CAc procedure with peer cooperation for distributed control.

DETAILED DESCRIPTION

[0030] Figure 1A is a diagram of an example communications system

100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0031] As shown in Figure 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

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

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

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

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

116 may be established using any suitable radio access technology (RAT).

[0035] More specifically, as noted above, the communications system

100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs

102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High- Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

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

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

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

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

[0038] The base station 114b in Figure 1A may be a wireless router,

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

[0039] The RAN 104 may be in communication with the core network

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

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

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

[0041] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the

WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in Figure 1A may be configured to communicate with the base station 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0042] Figure IB is a system diagram of an example WTRU 102. As shown in Figure IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/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 will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0043] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a

DSP core, a controller, a microcontroller, Application Specific Integrated

Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor

118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122.

While Figure IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver

120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0050] The processor 118 may further be coupled to other peripherals

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

[0051] Figure 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. The RAN 104 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 104, and the core network 106 may be defined as reference points.

[0052] As shown in Figure 1C, the RAN 104 may include base stations

140a, 140b, 140c, and an ASN gateway 142, though it will be appreciated that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 140a, 140b, 140c may each be associated with a particular cell (not shown) in the RAN 104 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 140a, 140b, 140c may implement MIMO technology. Thus, the base station 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 140a, 140b, 140c 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 142 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106, and the like.

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

[0054] The communication link between each of the base stations 140a,

140b, 140c 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 140a, 140b, 140c and the

ASN gateway 215 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, 100c.

[0055] As shown in Figure 1C, the RAN 104 may be connected to the core network 106. The communication link between the RAN 104 and the core network 106 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example.

The core network 106 may include a mobile IP home agent (MIP-HA) 144, an authentication, authorization, accounting (AAA) server 146, and a gateway

148. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0056] The MIP-HA 144 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 144 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. The AAA server 146 may be responsible for user authentication and for supporting user services. The gateway 148 may facilitate interworking with other networks. For example, the gateway 148 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.

In addition, the gateway 148 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0057] Although not shown in Figure 1C, it will be appreciated that the

RAN 104 may be connected to other ASNs and the core network 106 may be connected to other core networks. The communication link between the RAN 104 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 104 and the other ASNs. The communication link between the core network 106 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

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

[0059] Examples of types of P2P communications may include, but are not limited to, connection, advertisement, user centric activities at proximity, smart environments, health, security and safety, smart transportation, and network of networks. For example, connection communication may include a pair or group of connections, status updates, and keep-alive signaling, such as in social networking (SN) and internet of things (IoT). Advertisement communication may include broadcast, group-cast, and unicast for, for example, personalized advertising. User centric activities at proximity communication may include, for example, pair or group based gaming, streaming, content exchanging, and conference meeting. Smart environment communication may include home/office device control, auto configuration, synchronization, and update. Health communication may include peer monitoring and assistance, and medical and hospital services. Security and safety communication may include hazard warning, emergency alarming and police or public safety services. Smart transportation communication may include congestion, accident or event noticing, interactive transportation management such as carpooling, train scheduling, traffic control, and ticket updates for, for example, airplane tickets or other modes of transportation. Network of networks communication may include multi-hop to infrastructure, offloading from infrastructure, and up-loading to hot spot.

[0060] Examples of P2P devices may include, but are not limited to,

Tablets, Smart Phones, Music Player, Game Consoles, Personal Digital Assistances (PDAs), Laptops/PC, Medical Devices, Connected Cars, Smart Meters, Home Gateways, Monitors, Alarms, Switches, Appliances, Set-Top Boxes, and Printers.

[0061] The following terms are used herein, although such terms serve as examples such that other terms may be used. Context may include, but is not limited to, information including service, user, device, and proximity. Channel accessing may include a procedure or action to physically connect to a physical communication channel to transmit or receive signals or data in a wireless communication system. Channel allocation may include a procedure to define or assign the physical communication channel(s) to a WTRU or multiple WTRUs for transmitting or receiving signals or data in a wireless communication system. A WTRU may access a channel allocated to it.

[0062] A peer may be any user or a device. For example, a peer may be, but is not limited to, a mobile station (MS) in 2G, a WTRU in 3GPP, a full- function device (FFD) or a reduced-function device (RFD) in IEEE 802.15/WPAN. A peer may be a group or users or devices sharing a group ID. P2P communications may include, but are not limited to, infrastructure based (centralized) communications, infra structure -less (distributed) communications, or hybrid (centralized and distributed) communications among peers within proximity of each other. Peer discovery (PD), or similarly neighbor discovery (ND), may include a procedure used by a peer to find another peer(s) before peer association or attachment to enable P2P communication in proximity. Peer association (PA) may include a procedure used by a peer to establish a logic connection with another peer(s) before peer data transmission for P2P communications. It may be used interchangeably with Peer Attachment, Pairing, Peering, or Link Establishment, among other terms. Peer association update may include a procedure used for a peer to update an Association Identifier and/or Association Context of an existing association relationship with other peer(s). Peer disassociation may include a procedure used for a peer to cancel an existing association relationship with other peer(s). Peer re-association may include a procedure used by a peer to re-associate a cancelled association relationship with other peer(s).

[0063] A virtual leader (VL) is a peer that may be defined to represent, manage, and/or coordinate the P2P communications among a group of peers sharing the same context-based service(s) or application(s), for example, within a peer-to-peer network (P2PNW). Accordingly, a VL may provide a type of "virtually" centralized intra-P2PNW control. A VL may be dynamically determined and/or may change within the group (e.g. P2PNW). A VL may perform, but is not limited to, any of the following functions for the group of peers (e.g. a P2PNW): context management, context-aware discovery broadcast, context-aware peer association, group membership management, synchronization, link management, channel allocation and accessing control, reliable data transmission, routing management, power control and interference management, and channel measurement coordination. According to an example, a peer may be the VL for one application (e.g. a P2PNW), and one application (e.g. a P2PNW) may have one VL. Examples of other terms that may be used for VL include, but are not limited to, any of the following: group/cluster/zone leader, header, controller, coordinator, master, or manager.

[0064] A sub-virtual leader (SubVL) is a peer that may extend coverage through multi-hop based on the physical or logical topology for centralized intra-P2PNW control. Examples of roles of a SubVL may include, but are not limited to: a VL to manage a subgroup of peers with the same context-based service or application (e.g. a P2PNW); a peer (i.e. a member) under the management of the VL and/or a SubVL of the same group (e.g a P2PNW). The SubVL may perform a subset of functions of the VL.

[0065] A super virtual leader (SuperVL) may be a VL that may coordinate all VLs of P2PNWs in a given proximity for virtually centralized inter-P2PNWs control. This coordination may assist in providing synchronization, power control, interference management, channel allocation and accessing control, among other things. A SuperVL may be dynamically determined and/or changed among the VLs in a given proximity. The SuperVL may be the top leader of the VLs' hierarchical structure for virtually centralized inter-P2PNWs control.

[0066] Proximity-based applications and services represent a recent and enormous socio-technological trend. Many standards have identified the P2P communication use cases inside their standardization scope. For example, the 3rd Generation Partnership Project (3GPP) may support proximity services (ProSe). In contrast to fully distributed P2P as targeted by, for example, IEEE 802.15.8, 3GPP device-to- device (D2D) ProSe may include hybrid P2P as well.

[0067] For example, 3GPP D2D ProSe may operate in any one of three operational modes: operator free, operator assisted, and operator managed. In operator free (OF) mode, a D2D communication may be standalone without any involvement from the operator's network. WTRUs may make the initial determination of proximity, may target peer discovery and may establish direct connections without support from the network.

[0068] In Operator Assisted (OA) mode, the network/operator may assist

WTRUs with proximity detection and provide targeted discovery and authentication and/or security as an added value. The assistance may be provided proactively by the network or upon a WTRU's request. In this case, the network may not monitor the reliability of D2D links and may not support any session continuity if the D2D link is dropped due to user movement or other degradations. If the D2D link is dropped, the application layer may still provide some level of continuity by re-initiating P2P connections via the network using normal procedures.

[0069] In Operator Managed (OM) mode, the network may assist

WTRUs as in the case of Operator Assisted D2D, and may also follow up with radio link monitoring and management to support session continuity during

D2D communication and may anchor the D2D traffic using network access resources. For example, the network anchoring may be used when two WTRUs are within coverage of the same base station or evolved Node B (eNB), but it may also be extended across eNBs to provide session continuity as devices move apart.

[0070] IEEE 802.15.8 aims to specify PHY and MAC protocols for fully distributed peer-aware communications to support emerging services such as social networking, advertising, gaming, streaming, and emergency services. IEEE 802.15.8 may be able to support, for example, discovery of peer information without association, discovery signaling rates of greater than 100 kilobit per second (kbps), more than 100 devices during discovery, scalable data transmission rates of 10 megabit per second (Mbps), group communications with simultaneous membership in multiple groups (e.g. up to 10 groups), relative positioning, multi-hop relay, and security. IEEE 802.15.8 may be operational in selected globally available unlicensed/licensed bands below 11 Gigahertz (GHz) capable of supporting these requirements.

[0071] IEEE 802.15.8 may satisfy any of the following criteria: fast neighbor discovery without association; fast association with distributed coordination; group communications; and P2P and infrastructure-less communications. For example, a fast neighbor discovery without association may include fast association with distributed coordination, group communications, and P2P and infrastructure-less communications. For fast neighbor discovery without association, the neighbor discovery process in IEEE 802.15.8 may be used for peer-to-peer and group communications and may be a part of functions implemented at the physical (PHY) and medium access control (MAC) layers. Further, the discovery process may be performed without the association process, reducing the latency incurred from neighbor discovery procedures.

[0072] For fast association with distributed coordination, the association process in IEEE 802.15.8 may not rely on a centralized coordinator or a dedicated server. IEEE 802.15.8 devices may be coordinated in a distributed manner for peer to peer and group communications. Accordingly, the centralized association process may suffer from overloading if there exist many mobile devices, while a distributed process that may be adopted by IEEE 802.15.8 may avoid overloading and achieve faster association.

[0073] For group communications, a key functionality may be to support many applications for IEEE 802.15.8 such as social networking and P2P applications. Those applications may be facilitated by implementing parts of the group communication functions at the PHY and MAC layers. Individual Peer Aware Communications (PAC) devices may join multiple groups simultaneously. IEEE 802.15.8 group communications may be managed without any central coordinator.

[0074] For P2P and infrastructure-less communication, IEEE 802.15.8 may support the P2P and infrastructure-less communication at PHY and MAC layers. P2P communication may refer to the direct communication between any two IEEE 802.15.8 devices without any mediating device. This mode of communication may be useful for networks without infrastructure such as base stations. P2P communication may also facilitate multi-hop relay communication, which may support applications for disaster recovery and emergency, for example.

[0075] IEEE 802.15.1 Bluetooth may provide a short range direct radio connection between two devices through a master-slave mechanism for channel accessing. IEEE 802.15.4 Wireless Personal Area Network (WPAN) may provide direct link for device-to-device data exchange within a mesh topology through a central controller, such as a WPAN coordinator in a centralized wireless system. The channel allocation and accessing may be predefined and fully controlled by the central controller. IEEE 802.11 WiFi networks may be based on the presence of a controller device, such as a

Wireless Access Point (WAP), which may provide wireless and wired connections between devices using, for example, a distributed pseudo-random algorithm for channel accessing such as Carrier Sense Multiple Access with

Collision Avoidance (CSMA/CA). IEEE 802.11 WiFi Direct, previously known as Wi-Fi P2P, may provide direct radio connection between two devices without a pre-deployed WiFi WAP, central hub or controller. Instead, WiFi Direct devices may use a Software enabled Access Point (SoftAP) to dynamically activate and set up a WAP when two (or more) devices first connect to each other.

[0076] A P2P communication network may be formed based on the desired context, which may include services or applications, users, and devices, in the proximity. Therefore, P2P networks may be context oriented or context based and may coexist in the proximity. Due to the nature of context driven approaches, P2PNWs may be formed and ceased very dynamically, and may cause predefined channel allocation for P2PNWs in proximity to be limiting or inefficient.

[0077] Infrastructure-based wireless systems may be centralized system, such as the 3GPP wireless cellular system, the IEEE 802.11 WLAN system, or the IEEE 802.15 WPAN system. In such centralized systems, the channel allocation and accessing may be managed or controlled by a central controller. Examples of central controllers may include 3GPP eNB or Mobility Management Entity (MME), IEEE 802.11 WAP, or IEEE 802.15 coordinator. The channel allocation and accessing may be WTRU or device based, not service or application based, and may be unicast. A WTRU or device based approach may not support multiple services or applications simultaneously at lower layers such as PHY and MAC. A unicast approach may not support multicast and group communications at low layers such as PHY and MAC.

[0078] Certain infrastructure-less wireless P2P system's channel allocation and accessing schemes, such as Bluetooth's Master-Slave approach, may not fully support all the features required by P2P communications in an infrastructure-less wireless system at low layers such as PHY and MAC.

[0079] Channel allocation and accessing mechanisms for P2P communications in proximity may be designed to address and solve the following issues, which may not be properly handled by the infrastructure- based or infrastructure-less approaches discussed above: channel allocation and accessing for special emergency services or applications, i.e. high priority and low latency multicast or broadcast services; channel allocation and accessing among coexisting P2P networks in proximity, i.e. inter-P2P-network channel allocation and accessing; channel allocation and accessing for group communications in a dynamic way, i.e. intra-P2P-network channel allocation and accessing; and channel allocation and accessing without central controller for infrastructure-less P2P wireless communications coexisting in proximity, i.e. without the knowledge of the existing channel usage. The embodiments described herein are designed to address these issues.

[0080] In one example, control schemes for P2PNWs may include: virtually centralized control, which may include virtually centralized inter- P2PNWs and intra-P2PNW; distributed control, which may include distributed inter-P2PNWs and intra-P2PNW; and hybrid control, which may include distributed inter-P2PNWs and virtually centralized intra-P2PNW. According to another embodiment, control schemes for P2PNWs may include any of the following: a SuperVL may be used for virtually centralized inter - P2PNWs control; a VL may be used for virtually centralized intra-P2PNW control; and a SubVL may be used for virtually centralized intra-P2PNW control with multiple hops. In another example, control schemes for P2PNWs may include a 1-to-N broadcast channel, for example, a Common Control and Data Channel (CCDCH) or a Dedicated Control and Data Channel (DCDCH). A CCDCH may be shared by SuperVL, VL, SubVL and/or peers among P2PNWs. A DCDCH may be shared by VL, SubVL and peers within a P2PNW.

[0081] In other examples, control schemes for P2PNWs may support fast channel accessing for Inter-P2PNWs communications and/or Intra-P2PNW communications. Inter-P2PNWs Channel Allocation may use P2PNW detection, which may include Inter-P2PNWs Channel Allocation with P2PNW detection for virtually centralized control, for distributed control, or for hybrid control. Inter-P2PNWs Channel Allocation may use P2PNW cooperation, which may include Channel Allocation with P2PNW cooperation for virtually centralized control, for distributed control, or for hybrid control. Intra - P2PNW Channel Allocation/Accessing may use peer detection for centralized control and for distributed control. Intra-P2PNW Channel Allocation and/or Accessing may use peer cooperation for virtually centralized control and for distributed control. These embodiments are described in detail hereinafter.

[0082] P2PNWs may be formed in proximity with the desired contexts, such as services, users and devices, between two peers (pair communication) or among peers (group communication). Figure 2 is a diagram of an example group 200 of P2PNWs in coexistence. Figure 2 shows P2PNWs 201-204 for different example applications that may be found, for example, at a shopping mall, such as P2PNW 201 for broadcasting stores' or personalized advertisements, P2PNW 202 for social connections such as chats, P2PNW 203 for keep alive, and P2PNW 204 for gaming. P2PNWs 201-204 may coexist in a short range or proximity among peers 210-x. A peer 210-x may join one or more P2PNWs 201-204 simultaneously in proximity. For example, peer 210-6 may chat with a friend peer 210-7 on a social network 202 and receive or check advertisements or coupons broadcasted by stores on P2PNW 201. In this example, peer 210-1 may serve as a VL for peers 210-2 to 210-6, peer 210-3 may serve as a SubVL for peers 210-3-1 and 210-3-2, and peer 210-5 may serve as a SubVL for peers 210-5-1, 210-5-2 and 210-5-3.

[0083] Based on the data communications among the peers, the

P2PNWs may be categorized as Centralized or Distributed. Figure 3 is a diagram of an example centralized P2PNW 300 for data communication. In a centralized P2PNW 200, Peer 310-1 may be defined as the VL. Peer 310-3

(one-hop), Peer 310-3-2 (two-hops) and/or Peer 310-5 (one-hop) may be defined as SubVLs. In an example of pair communications 302, peer 310-1 may transmit a pair communication 302 via unicast of one or more messages to a peer 310-2. The pair communication 302 between two peers 310-1 and 310-2 may be the simplest scenario of group communications with only two peers.

In an example of group communications 301, peer 310-1 may transmit one or more multicast messages to a group of peers 310-2, 310-3, 310-3-1, 310-3-2,

310-3-2-1, and/or the group of peers 310-4, 310-5, 310-5-1, 310-5-2, 310-5-3, and 310-6. In another example, peer 310-1 may broadcast 301 one or more messages to all peers (i.e. 310-2, 310-3, 310-3-1, 310-3-2, 310-3-2-1, 310-4, 310- 5, 310-5-1, 310-5-2, 310-5-3, and 310-6) directly or through relays (i.e. SubVL 310-3, SubVL 310-3-2, SubVL 310-5). Each peer may unicast to peer 310-1 directly or through relays (i.e. SubVL 310-3, SubVL 310-3-2, SubVL 310-5). Solutions and schemes for group communications may also be applied to pair communication with some simplifications.

[0084] Figure 4 is a diagram of an example distributed P2PNW 400 for data communication. The P2PNW 400 may include peers 410-1 to 410-5. The solid connection lines illustrate a partially distributed P2PNW, whereas the solid and dotted connection lines together illustrate a fully distributed P2PNW, such that each peer 410-1 to 410-5 may unicast, multicast, and or broadcast to some or all other peers.

[0085] The coexistence of centralized and/or distributed P2PNWs for different services or applications in proximity may require a certain level of management or cooperation among the P2PNWs, such as synchronization, channel allocation and accessing, power control and interference management, to ensure the quality of P2P communications. The control schemes for inter- P2PNWs and intra-P2PNW control illustrated in Figures 5-7 may be used for infrastructure-less P2P communication systems with the virtually centralized control scheme (in Figure 5), which may also be extendable to centralized infrastructure-based P2P communication systems.

[0086] Figure 5 is a diagram of an example group of P2PNWs 500 employing virtually centralized inter-P2PNWs control and intra-P2PNW control. In the example shown in Figure 5, each application P2PNW 501-504 may have a respective VL 510-1, 512-1, 513-1, and 514-1. Data communications between peers are shown by the solid lines, and control communications are shown in dotted lines for inter-P2PNWs communications and dashed lines for intra-P2PNW communications. For centralized inter-

P2PNWs control, a SuperVL may manage all control related communications among the P2PNWs 510-504 in proximity. For example, Peer 510-1 of application P2PNW 501 may be the SuperVL and may handle all control signals and/or messages among each of application P2PNWs 501-504, as shown by the dotted line connections. For centralized intra-P2PNW control, a VL may manage all control related communications (shown in solid lines) directly or through SubVL(s) within a P2PNW. For the example in Figure 5, Peer 514-1 in application P2PNW 504 may handle all control signals and/or messages among the peers within the application P2PNW 504 (i.e. 514-2, 514- 3, 514-4, 514-5). Peer 510-3 may serve as a SubVL in application P2PNW 501.

[0087] Figure 6 is a diagram of an example group of P2PNWs 600 employing distributed inter-P2PNWs control and intra-P2PNW control. Data communications between peers are shown by the dashed lines, and control communications are shown in solid and dotted lines. For distributed inter- P2PNWs control, a peer within a P2PNW may manage its control related communications with the peers within other P2PNWs in proximity, as shown in dotted lines in Figure 6 (i.e. peers 610-3-2 in P2PNW 601 and peers 612-1 and 612-2 in P2PNW 602; and peer 613-1 in P2PNW 603 and peers 614-1 and 614-4 in P2PNW 604). In this example, there may be no SuperVL acting as a virtual central controller among P2PNWs. For distributed intra-P2PNW control, a peer may manage its control related communications (shown in solid lines) when communicating with other peers within a P2PNW. For example, Peer 614-1 of application P2PNW 604 may handle both control and data messages with the peers within application P2PNW 604, as shown in solid and dashed lines in Figure 6, respectively. There may be no VL acting as a virtual central controller, and/or no SubVL.

[0088] Figure 7 shows an example of a group of P2PNWs 700 employing hybrid control, distributed inter-P2PNWs and virtually centralized intra-

P2PNW control. Data communications between peers are shown by the dashed lines, and control communications are shown in dotted and sold lines.

For distributed inter-P2PNWs control, the VL of a P2PNW (e.g. peer 710-1 of

P2PNW 701) may manage its P2PNW's control related communications with the VLs of other P2PNWs in proximity (e.g. peers 712-1, 713-1, and 714-1 via 713-1), as shown in thick dotted lines in Figure 7. There may be no Super VL acting as a virtual central controller among P2PNWs 701-704, and there may be only the VL (e.g. 710-1) as a virtual central controller within a P2PNW (701). For virtually centralized intra-P2PNW control, a VL (e.g. 710-1) may manage all control related communications directly (e.g. with 710-2) or through SubVL(s) (e.g. through 710-3 to 710-3-1 and 710-3-2) within a P2PNW (e.g. 701). For example, Peer 710-1 of P2PNW 701 may handle all control signals and/or data messages among the peers 710-2, 710-3-1, 710-3-2 and SubVL 710-3 within P2PNW 701. Peer 714-1 of P2PNW 704 may handle all control signals and/or data messages among all peers 714-2 to 714-5 within App4 P2PNW (as shown in solid lines for control and dashed lines for data).

[0089] For control communications among SuperVL, VLs, SubVL(s) or

Peers in different P2PNWs in proximity and control communications among the VL, SubVL(s) and Peers within a P2PNW, a Common Control and Data Channel (CCDCH) and a Dedicated Control and Data Channel (DCDCH) may be used.

[0090] CCDCH may be defined for inter-P2PNWs communications and shared by SuperVL, VLs, SubVL(s) and/or Peers of all services or applications in proximity. For example, the CCDCH may be used for, but is not limited to, any of the following: common control messages broadcasted, multicasted or relayed among the P2PNWs in proximity, paging or broadcast messages to the P2PNWs in proximity, and short high priority data broadcasted, multicasted or relayed to the P2PNWs in proximity.

[0091] DCDCH may be defined for intra-P2PNW communications and shared by the VL, Sub VLs and peers within a P2PNW. The DCDCH may be used for, but is not limited to, any of the following: common control messages among VL, Sub VLs, peers within the P2PNW, paging or broadcast messages to VL, SubVLs, or peers within the P2PNW, and short high priority data transmissions broadcasted to VL, SubVLs, or peers within P2PNW. The CCDCH and DCDCH may be defined for different multiplexing schemes, as illustrated in Figures 8-10. [0092] Figure 8 shows an example of a virtually centralized control

P2PNW superframe 800 including CCDCH and DCDCH in a TDMA system. Figure 8 could also apply to a TDMA/OFDM system. The example of Figure 8 may be for a system with three application P2PNWs in proximity Appl, App2, App3, such that each application P2PNW Appl, App2, App3 has access to a respective application frame 811, 812, 813, within superframe 800 and sends out an application beacon 851, 852, 853 at the beginning of its respective application frame 811, 812, 813. For example, Appl may include a SuperVL that sends out super beacon 851, while VL2 in App2 sends out application beacon 852 and VL3 in App3 sends out application beacon 853. For a TDMA (and/or TDMA/OFDM) system, the CCDCH 820 may be the first i slots (i >= 1) after the first beacon 850 (i.e. super beacon in virtually centralized control) in superframe 800, for all service or application P2PNWs Appl, App2, App3, in proximity. A DCDCH 821 for Appl may be the first j slots (j >= 1) following the CCDCH 821 in application frame 811. A DCDCH 822 for App2 may be the first k slots following beacon 852 in application frame 812. A DCDCH 823 for App3 may be the first 1 slots following beacon 853 in application frame 813. The format of superframe 800 may be repeated in subsequent superframes (not shown) with the same application frames and/or dynamically adjusted different application frames. For distributed control, the SuperVL and VLs may be replaced by peer(s) in superframe 800, and super beacon 851 and application beacons 852, 853 may be replaced by peer beacons. For hybrid control, the SuperVL may be replaced by VL1 (i.e. VL of Appl) in superframe 800, and super beacon 851 may be replaced by an application beacon (i.e. application beacon of Appl).

[0093] Figure 9 shows an example of P2PNW superframe 900 including

CCDCH and DCDCH in a CDMA system. Like for Figure 8, the example of

Figure 9 may be for a system with three application P2PNWs in proximity

Appl, App2, App3, such that each application P2PNW Appl, App2, App3 has access to a respective frame 911, 912, 913, within superframe 900, and sends out a beacon 951, 952, 953, a DCDCH 921, 922, 923, and data 931, 932, 933, within its respective frame 911, 912, 913. Beacons 951, 952, 953, may be scrambled or spread with codes CodeBl, CodeB2, and CodeB3 respectively. Similarly, data 931, 932, and 933 may be spread or scrambled with codes Codel, Code2, and Code3, respectively. For a CDMA system, the CCDCH 920 may be scrambled or spread with a known code CodeC shared by all services or applications P2PNWs Appl, App2, App3 in proximity. A DCDCH 921 for Appl may be scrambled or spread with a known code CodeDl shared by VL, SubVL and peers within P2PNW Appl. A DCDCH 922 for App2 may be scrambled or spread with a known code CodeD2 shared by VL, SubVL(s) and peers within P2PNW App2. A DCDCH 923 for App3 may be scrambled or spread with a known code CodeD3 shared by VL, SubVL(s) and peers within P2PNW App3. The format of superframe 900 may be repeated in subsequent superframes (not shown) with the same application frames, or dynamically adjusted different application frames.

[0094] Figures 10A and 10B are diagrams of example P2PNW superframes 1001, 1002, 1003, and 1004 that may include CCDCH and

DCDCH in an OFDMA system. The examples of Figures 10A and 10B may be for a system with four application P2PNWs in proximity Appl, App2, App3,

App4. In these examples, Appl may be assigned to OFDMA subcarrier group

1011 for all superframes 1001-1004; App2 may be assigned to OFDMA subcarrier group 1012 in superframes 1001 and 1003; App3 may be assigned to OFDMA subcarrier group 1013 for all superframes 1001-1004; and App4 may be assigned to OFDMA subcarrier group 1012 for superframes 1002 and

1004. The CCDCH 1020 subcarrier allocations are shown in diagonal hashed shading. The DCDCH 1021, 1022, 1023, 1024 subcarrier allocations for Appl,

App2, App3, App4, respectively, are shown in vertical hashed shading.

[0095] In the example of Figure 10A, the CCDCH 1020 may be the center k (k > 1) subcarriers and 1 (1 > 1) symbols (in this example, OFDMA subcarrier group 1011) of the first i slot(s) (i >1) in each superframe 1001,

1002 for all services or applications P2PNWs in proximity (i.e. Appl, App2,

App3, App4). The DCDCHx 102x for Appx (x={l,2,3,4}) may be located at the center kx (kx > 1) subcarrier s and lx (lx > 1) symbols (from among OFDMA subcarrier groups 1011, 1012, 1013) of the first available ix slot(s) (ix > 1) in the respective superframes (from among superframes 1001, 1002). For example, the DCDCHl 1021 for Appl may be assigned il slot(s) of OFDMA subcarrier group 1011 following the CCDCH 1020 in each superframe 1001 and 1002. The DCDCH2 1022 for App2 may be assigned the first i2 slot(s) of OFDMA subcarrier group 1012 in superframe 1001, while the DCDCH4 1024 of App4 may be assigned the first i4 slot(s) of OFDMA subcarrier group 012 in superframe 1002. The format of superframes 1001 and 1004 may be repeated in subsequent superframes (not shown) with the same application frames, or dynamically adjusted different application frames.

[0096] In the example of Figure 10B, the CCDCH 1021 may be the center k (k > 1) subcarriers and 1 (1 > 1) symbols (in this example, OFDMA subcarrier group 1011) and every i slot(s) (i > 1) in each superframe 1001, 1002 for all services or applications P2PNWs in proximity (i.e. Appl, App2, App3, App4). The DCDCHx 102x for Appx (x={l,2,3,4}) may be located at the center kx (kx > 1) subcarriers and lx (lx > 1) symbols (from among OFDMA subcarrier groups 1011, 1012, 1013) in every ix slot(s) (ix > 1) in the respective superframes (from among superframes 1001, 1002). For example, the DCDCHl 1021 for Appl may be assigned every il slot(s) of OFDMA subcarrier group 1011 following the CCDCH 1020 in each superframe 1001 and 1002. The DCDCH2 1022 for App2 may be assigned every i2 slot(s) of OFDMA subcarrier group 1012 in superframe 1001, while the DCDCH4 1024 of App4 may be assigned every i4 slot(s) of OFDMA subcarrier group 1012 in superframe 1002.

[0097] Channel Allocation (CA) and Channel Accessing (CAc) schemes for P2P communications may be designed for infrastructure-less wireless systems. The procedures described below provide examples of CA and CAc schemes.

[0098] A fast CCDCH channel accessing scheme may be used in, but is not limited to, the following scenarios: common control messages broadcasted, multicasted, or relayed to the P2PNWs in proximity including, but not limited to, synchronization, discovery, association, disassociation, re-association, channel resource allocation, channel accessing request, power control and interference management; short paging or broadcast messages to the P2PNWs in proximity including, but not limited to, report and status update; and short high priority data broadcasted, multicasted, or relayed transmissions to the P2PNWs in proximity including, but not limited to, security alert, emergency broadcast, and rescue request. Figure 11 is a flow diagram of an example fast channel accessing procedure 1100 for inter-P2PNWs communications through a CCDCH. The fast channel accessing procedure 1100 may be performed by any peer, including a VL, a SuperVL or a SubVL.

[0099] The following parameters may be used in the description of

Figure 11. Parameter tScanCCDCH may be a time window for scanning CCDCH. Parameter tCCDCH may be an initial waiting time before detecting the CCDCH again. Parameter tOutCCDCH may be an initial timeout for CCDCH accessing. Parameter tVLi may be a waiting time before detecting the CCDCH again by VLi of P2PNWi. Parameter tOutVLi may be a timeout for CCDCH accessing by VLi. Parameter tSubVLik may be a waiting time before detecting the CCDCH again by SubVLik of P2PNWi. Parameter tOutSubVLik may be a timeout period for CCDCH accessing by SubVLik. Parameter tPeerip may be a waiting time before detecting the CCDCH again by Peerip of P2PNWi. Parameter tOutPeerip may be a timeout for CCDCH accessing by Peerip of P2PNWi.

[0100] According to the example procedure 1100, the start of fast

CCDCH accessing, 1104, may be triggered by an application or function entity,

1102. For example, such triggers may be from a higher layer, and/or by logical functions including, but not limited to, Peer Discovery (PD), Peer Association

(PA), Synchronization Request (SR), Channel Accessing (CAc), Power Control

(PC), and/or Interference Management (IntM). The CCDCH may be scanned for a predefined time window tScanCCDCH, to determine if the CCDCH is occupied, 1106. The predefined time window tScanCCDCH may be, for example, across the superframe boundary. It may then be determined if the CCDCH channel is occupied, 1108.

[0101] If the CCDCH is occupied, the peer may wait for a time period tCCDCH, 1110, and then check if a predefined timer, tOutCCDCH, has timed out, 1112. If the timer tOutCCDCH has not timed out, the peer may return to scanning the CCDCH, 1106. If the timer has expired, the accessing of the CCDCH may be aborted and the application (i.e. higher layer or logical function) requesting the CCDCH accessing may be notified, 1114.

[0102] If the CCDCH is not occupied, it is determined if a SuperVL requested the fast CCDCH accessing, 1116. If the SuperVL requested the fast CCDCH accessing for a virtually centralized inter-P2PNWs control in proximity, the SuperVL may access the CCDCH immediately (as shown by the dotted line) with its peer (SuperVL) information and CCDCH usage, and control and/or data messages, 1118.

[0103] If the CCDCH is not occupied, and a SuperVL is not requesting, it is determined if a VL (i.e. VLi) is requesting CCDCH accessing, 1120. If the VLi of P2PNWi requested the fast CCDCH accessing for a virtually centralized or hybrid inter-P2PNWs control, VLi may wait for a time period tVLi and then scan if the CCDCH is available for accessing, 1122. The time period tVLi may be greater than 0, and may be defined for VLi based on, for example, a channel accessing priority, or a QoS of application i. It is then verified if the CCDCH channel is occupied, 1124.

[0104] If the CCDCH not occupied (i.e. available), the requesting VLi may access the CCDCH with its peer (i.e. VLi) information, CCDCH usage, and control and/or data messages, 1118. If the CCDCH is occupie (i.e. not available), the VLi may check if the predefined timer tOutVLi for VLi has timed out, 1126. If timer tOutVLi has not expired, the VLi may wait for a time period tVLi and then may scan if the CCDCH is available for accessing, 1122, until either the CCDCH is available or until the expiry of time period tOutVLi. If the timer tOutVLi has expired, the VLi may access its DCDCHi if available (e.g. using the example DCDCH accessing procedure shown in Figure 13) 1128. The accessing of the CCDCH may be aborted and the application (i.e. higher layer or logical function) requesting the CCDCH accessing may be notified, 1114.

[0105] If the CCDCH is not occupied (and a SuperVL or VL are not requesting), it is determined if a SubVLik of P2PNWi is requesting the fast CCDCH accessing, 1130. For example, SubVLik of P2PNWi may be requesting the fast CCDCH accessing for a virtually centralized or hybrid inter-P2PNWs control. If SubVLik of P2PNWi is requesting the fast CCDCH accessing, SubVLik may wait for time period of tSubVLik (for example, tSubVLik > tVLi, and be defined for SubVLik based on channel accessing priority or QoS of application i) and then scan if the CCDCH is available, 1132. It is then determined if the CCDCH is occupied, 1134. If the CCDCH is not occupied, the requesting SubVLik may access the CCDCH with its SubVLik information, CCDCH usage and control and/or data messages, 1118. If the CCDCH is occupied, the SubVLik may check if the predefined timer tOutSubVLik for SubVLik has timed out, 1136. If the timer tOutSubVLik has not expired, SubVLik may wait for time period of tSubVLik and scan if the CCDCH is available, 1132, until either CCDCH is available or timer tOutSubVLik has timed out. If the timer tOutSubVLik has expired, the SubVLik may request to a VLi on the DCDCHi of P2PNWi (for example, following the DCDCH accessing procedure show in Figure 13) to request VLi to access CCDCH with higher priority, 1138. The accessing of the CCDCH may be aborted and the application (i.e. higher layer or logical function) requesting the CCDCH accessing may be notified, 1114.

[0106] If the CCDCH is not occupied and none of a SuperVL, VL or

SubVL are requesting, then a Peerip of P2PNWi may be requesting the fast

CCDCH accessing for, for example, a virtually centralized, hybrid or distributed inter-P2PNWs control. Peerip may wait for a predefined time period tPeerip (for example, tPeerip > tSubVLik > tVLi, and may be defined for Peerip based on channel accessing priority and/or QoS of application i) and then scan if the CCDCH is available, 1142. Peerip may then determine whether the CCDCH channel is occupied, 1144. If the CCDCH not occupied (i.e. available), the requesting Peerip may access the CCDCH with its Peerip information, its CCDCH usage, and control and/or data messages, 1118. If the CCDCH is occupied, the Peerip may check if a predefined timer tOutPeerip for Peerip has timed out, 1146. If the timer tOutPeerip has not expired, the Peerip may continue to wait for a predefined time period tPeerip and scan the CCDCH, 1142, until either the CCDCH is available or timer tOutPeerip has timed out. If the timer tOutPeerip has expired, the Peerip may request to a VLi on the DCDCHi of P2PNWi (for example, following the DCDCH accessing procedure show in Figure 13) to request VLi to access CCDCH with higher priority, 1148. The accessing of the CCDCH may be aborted and the application (i.e. higher layer or logical function) requesting the CCDCH accessing may be notified, 1114.

[0107] Figure 12 is a diagram of an example CCDCH accessing procedure 1200 based on priority. In this example, the SuperVL 1201, VLi 1202, SubVLik 1203 and Peerip 1204 may try to access the CCDCH 1206, which may comprise time slots 1216, 1218, and 1220. The decreasing order of priority of the different types of peers may be as follows: SuperVL 1201 may have highest priority, followed by VLi 1202, SubVLik 1203 and Peerip 1204. Following a beacon 1210, and an inactive period 1212, a peer (SuperVL 1201, VLi 1202, SubVLik 1203 or Peerip 1204) may detect if the CCDCH 1206 is available during a detection period 1214. According to the example of Figure 12, priorities for CCDCH accessing may be defined by delay time parameters, such that SuperVL 1201 may have no delay, VLi 1202 may have a delay of tVLi, SubVLik 1203 may have a delay of tSubVLik, and Peerip 1204 may have a delay of tPeerip, where tPeerip > tSubVLik > tVLi.

[0108] For example, the SuperVL 1201 may access the CCDCH 1206 immediately with a blocking signal following the first detection period 1214.

The SuperVL may transmit SuperVL data 1230 in time slots 1218 and 1220.

The VLi 1202, SubVLik 1203 and Peerip 1204 may wait for a predefined time period (tPeerip, tSubVLik, tVLi, respectively), followed by another detection period 1215, prior to accessing the CCDCH 1206. For example, once the VLi 1202 gains access with a blocking signal it may transmit VLi data 1232 in time slots 1218 and 1220. Similarly, once the SubVLik 1203 gains access with a blocking signal it may transmit SubVLik data 1234 in time slots 1218 and 1220. In another example, Peerip 1204 may reach time out and not gain access to the CCDCH 1206 if Peerip waits too long.

[0109] The fast DCDCH channel accessing may be used in, but is not limited to, any of the following scenarios: common control messages within a

P2PNW, including for example synchronization, discovery, association, disassociation, re-association, channel resource allocation and channel accessing request, and power control and interference management; short paging or broadcast messages within a P2PNW, including for example report and status update; and short high priority data transmissions within a

P2PNW, including for example security alert, emergency broadcast, and rescue request. DCDCH may also be used for relaying CCDCH signals or messages. Figure 13 shows a flow diagram of an example fast channel accessing procedure 1300 for intra-P2PNW communications through a

DCDCH (e.g. DCDCHi for P2PNWi). The fast channel accessing procedure

1300 may be performed by any peer, including a VL, a SuperVL or a SubVL.

[0110] The following parameters are used in the description of Figure

13. Parameter tDCDCHi may be a waiting time before detecting DCDCHi again. Parameter tOutDCDCH may be a timeout period for DCDCHi accessing. Parameter tDSubVLik may be a waiting time before detecting

DCDCHi again by SubVLik. Parameter tDOutSubVLik may be a timeout period for DCDCHi accessing by SubVLik. Parameter tDPeerip may be a waiting time before detecting DCDCHi again by Peerip. Parameter tDOutPeerip may be a timeout period for DCDCHi accessing by Peerip.

[0111] According to the example procedure 1300, the start of fast

DCDCHi accessing, 1304, may be triggered by an application or function entity, 1302. For example, such triggers may be from a higher layer, and/or by logical functions including, but not limited to, PD, PA, SR, CAc, PC, and/or IntM. The DCDCHi may be scanned for a predefined time window tScanDCDCHi, to determine if the DCDCHi is occupied within P2PNWi , 1306. The predefined time window tScanDCDCHi may be, for example, across the superframe boundary. It may then be determined if the DCDCHi channel is occupied, 1308.

[0112] If DCDCHi is occupied, the peer may wait for a time period tDCDCHi, 1310, and then check if a predefined timer tOutDCDCHi has timed out, 1312. If the timer tOutDCDCHi has not timed out, the peer may return to scanning step the DCDCHi, 1306. If the timer has expired, the accessing of the DCDCHi may be aborted and the application (i.e. higher layer or logical function) requesting the DCDCHi accessing may be notified, 1314.

[0113] If DCDCHi is not occupied, the peer may determine whether the

VLi requested the fast DCDCHi accessing, 1320. If the VLi requested the fast DCDCHi accessing for a virtually centralized intra-P2PNW control, the VLi may access the DCDCHi immediately (as shown by the dotted line) with its peer (VLi) information and DCDCHi usage, and control and/or data messages, 1318.

[0114] If DCDCHi is not occupied, and a VL is not requesting, it is determined if SubVLik of P2PNWi requested the fast DCDCHi accessing, 1330, for example for a virtually centralized intra-P2PNW control with multi- hops (as shown by the dotted line). If SubVLik is requesting fast DCDCHi accessing, SubVLik may wait for a time period tDSubVLik and then scan the DCDCHi, 1332. For example, the time period tDSubVLik > 0, may be defined for SubVLik based on channel accessing priority and/or QoS of application i. The SubVLik may then determine whether the DCDCHi is occupied, 1334. If DCDCHi is not occupied, the requesting SubVLik may access the DCDCHi with its SubVLik information, its DCDCHi usage and control and/or data messages, 1318. If DCDCHi is occupied, the SubVLik may check if a predefined timer tDOutSubVLik, defined for SubVLik, has timed out, 1336. If the timer tDOutSubVLik has not expired, the SubVLik may continue to wait for a time period tDSubVLik and scan the DCDCHi, 1332, until has timer tDOutSubVLik timed out. If the timer tDOutSubVLik has expired, the SubVLik may abort DCDCHi accessing and notify the application requesting the fast DCDCHi accessing, 1314.

[0115] If DCDCHi is not occupied (and none of a VL or SubVL are requesting accessing) then a Peerip of P2PNWi requested the fast CCDCH accessing for, for example, a virtually scentralized or distributed intra-P2PNW control. Peerip may wait for a predetermined time period tDPeerip (for example, tDPeerip > tDSubVLik, and may be defined for Peerip based on channel accessing priority and/or QoS of application i) and then scan if the DCDCHi is available, 1342. Peerip may determine if the DCDCHi channel is occupied, 1344. If the DCDCHi not occupied (i.e. available), the requesting Peerip may access DCDCHi with its Peerip information, its DCDCHi usage, and control and/or data messages, 1318. If the DCDCHi is occupied, the Peerip may check if the predefined timer tDOutPeerip for Peerip has timed out, 1346. If the timer tDOutPeerip has not expired, the Peerip may continue to wait for a predefined time period tDPeerip and scan DCDCHi, until either DCDCHi is available or timer tDOutPeerip has timed out. If the timer tDOutPeerip has expired, the Peerip may abort DCDCHi accessing and notify the application requesting the fast DCDCHi accessing, 1314.

[0116] P2PNWs may be formed and ceased very dynamically based on the needs for desired services or applications in proximity. Channel Allocation (CA) schemes, including CA with P2PNW Detection and CA with P2PNW Cooperation, may be used to address the dynamic nature of channel allocation for P2P communications.

[0117] Examples of CA with P2PNW detection schemes are shown in

Figure 14, 15, and 16. A SuperVL, VL, or peer may request and receive channel allocation based on the detected resource usage by all the P2PNWs in proximity. Examples of resource usage include, but are not limited to, superframe, frame, slot (e.g. TDMA), code (e.g. CDMA), and/or subcarrier (e.g.

OFDM) information for different multiplexing schemes. CCDCH accessing may use any of the schemes described above. [0118] Figure 14 is a diagram of an example inter-P2PNW's CA procedure 1400 with P2PNW detection for virtually centralized control. The following parameters are referred to in Figure 14. Parameter tOutScanSpVL may be a time out period for scanning SuperVL. Parameter tScanCCDCH may be a time period for scanning CCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0119] The CA with P2PNW detection procedure 1400 for a virtually centralized control scheme may apply, for example, to virtually centralized inter-P2PNWs and intra-P2PNW as shown in Figure 5. With reference to Figure 14, the start of CA with P2PNW detection, 1404, may be triggered by the application, 1402. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. As part of SuperVL detection, 1406, the VL requesting CA (referred to as VLreq) may scan the beacon, paging, and/or broadcast signal for an existing SuperVL, 1408, for centralized P2PNWs control in proximity, which may continue until the SuperVL is detected, 1410, or a predefined timer tOutScanSpVL has timed out, 1412.

[0120] If the SuperVL is detected in proximity, then CA may be managed by the SuperVL, 1414, referred to as virtually centralized inter- P2PNWs control. The VLreq may determine its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 1416.

[0121] The VLreq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH (using, for example, the fast CCDCH accessing scheme of Figure 11) to the SuperVL and wait for the SuperVL's response on the CCDCH, 1418. While waiting, the

VLreq may monitor for the SuperVL's response, 1420, such that the steps

1418 and 1420 continue until a response is received or a predefined timer tOutChReq expires, 1422. If the predefined timer tOutChReq expires, the

VLreq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1424.

[0122] If the VLreq receives a response, it may determine if the response indicates if the request has been "accepted" or "rejected", 1426. If the VLreq receives an "accepted" response from the SuperVL, the VLreq may access the channel allocated by the SuperVL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1428, indicating the newly formed P2PNW in the proximity that is logically led by VLreq as a virtually centralized intra-P2PNW control.

[0123] If the VLreq receives a "rejected" response from the SuperVL, the

VLreq may adjust the requested superframe and/or frame, and slot, code, and/or subcarriers based on SuperVL's rejection response, 1430, then re- broadcast the request to SuperVL on the CCDCH, 1418, and wait for the response from SuperVL if the predefined timer, tOutChReq, has not expired, 1422.

[0124] If no SuperVL is detected in proximity by the time timer tOutScanSpVL has expired, 1412, VLreq may assign itself as the SuperVL (i.e. the first VL in proximity as the default SuperVL) and may commence the CA for SuperVL (i.e. First VL) procedure with Collision Avoidance, 1432. The

VLreq may determine the CCDCH, however, a collision may occur, for example, if there are other VL(s) assuming the SuperVL claim and starting the insertion of the CCDCH at the same time. To avoid a possible collision, the VLreq may conduct a Collision Avoidance procedure, 1434.

[0125] For the collision avoidance procedure, 1434, the VLreq may decide the CCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA request on CCDCH for a time window of tScanCCDCH, 1436. VLreq may determine if the CCDCH is detected, 1438.

If CCDCH is detected, VLreq may update its CCDCH based on the detection,

1440, and then determine if the CCDCH is from a SuperVL, 1442. If it is determined that the CCDCH was transmitted by a SuperVL, (e.g. a SuperVL that was formed while the VLreq was performing CA), VLreq may conduct CA by SuperVL, 1414. If it was not a SuperVL but a VL that transmitted the

CCDCH (e.g. the first VL chose not to be the default SuperVL), the VLreq may respond with "yes" or "accept" to the first VL's request on the CCDCH and may assign itself as the SuperVL, 1444. Alternatively, the VLreq may choose not to be the SuperVL. The VLreq may then update its VL list with the first

VL detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1446. The VLreq may then broadcast the updated CA request on CCDCH and wait for the response on the CCDCH,

1448, until the predefined time tOutChReq has expired, 1450, or until the

VLreq receives a response(s) from other VL(s), 1452, whichever occurs first.

[0126] If no CCDCH is detected, 1438, the VLreq may be the first VL in proximity, and may assign itself as the default SuperVL (it may also choose not to be a SuperVL). Accordingly, the VLreq may insert the CCDCH with the

CA request, indicating itself as the SuperVL (if applicable), and wait for a response, 1445. VLreq may then determine if a response is received, 1464.

[0127] If a response is received, VLreq may determine if the response indicates that the request is "accepted" or "rejected", 1466. If VLreq does not receive a response (e.g. there are no other VL(s) or P2PNW(s) in proximity) or

"accept" response(s) are received from other VL(s) (i.e. not rejected at 1466), the VLreq may be granted with CA as the SuperVL as virtually centralized inter-P2PNWs control. In these cases, the VLreq may update its VL list, 1458, if applicable, and may access the channel allocated by the SuperVL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1428.

[0128] If it is determined that the response is "reject" from other VL(s)

(i.e. rejected at 1466), VLreq may update its VL list with the first VL detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1446. The VLreq may then broadcast the updated CA request on CCDCH and wait for the response on the CCDCH, 1448, until the predefined time tOutChReq has expired, 1450, or until the VLreq receives a response(s) from other VL(s), 1452, indicating "accepted", 1454, for all responses on the VL list, 1456, whichever occurs first. If no response is received, 1452, by the time timer tOutChReq has expired, 1450, the VLreq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1424.

[0129] Figure 15 shows an example inter-P2PNW's CA procedure 1500 with P2PNW detection for distributed control. The following parameters are referred to in Figure 15. Parameter tOutScanP2P may be a time out period for scanning P2PNW. Parameter tScanCCDCH may be a time period for scanning CCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0130] The CA with P2PNW detection for distributed control may apply, for example, to distributed inter-P2PNWs and intra-P2PNW as shown in Figure 6. With reference to Figure 15, the start of CA with P2PNW detection, 1504, may be triggered by the application, 1502. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. The Peer Requesting CA (referred to as PeerReq) may scan the beacon, paging, and/or broadcast signal for peers in a fully distributed P2PNW, 1508, until a peer(s) is detected, 1510, or the predefined timer tOutScanP2P has expired, 1512.

[0131] If no peer is detected in proximity, 1510, and it is determined that the peer list is empty, 1513, PeerReq may assign itself as the first peer and insert may commence the CA for a first peer with collision avoidance, 1532. The PeerReq may decide the CCDCH, however, a collision may occur, for example, if there are other peers(s) starting the insertion of the CCDCH at the same time. To avoid a possible collision, the PeerReq may conduct a Collision Avoidance procedure, 1534.

[0132] For the collision avoidance procedure, 1534, the PeerReq may decide the CCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA request on CCDCH for a time window of tScanCCDCH, 1536. PeerReq may determine if the CCDCH is detected, 1538. If CCDCH is detected, PeerReq may update its CCDCH based on the detection, 1540, and respond to the request with "yes" or "accept" to the first peer's request, 1544. PeerReq may then update its peer list with the first peer detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1546. PeerReq may then broadcast the CA request on CCDCH and wait for the response on the CCDCH, 1548, until the predefined timer tOutChReq has expired, 1550, or PeerReq receives a response(s) from other peer(s), 1552.

[0133] If no CCDCH is detected, 1538, the PeerReq may be the first peer in proximity. PeerReq may insert the CCDCH with its CA request and wait for a response, 1545. It is then determined if a response is received, 1564. If no response is received (e.g. there is no other peer(s) or P2PNW(s) in proximity) or "accept" response(s) from other peer(s) are received, 1566, the PeerReq may be granted with CA. In these cases, the peer list may be updated, 1558, if applicable, and the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1528.

[0134] If the response indicates "rejected" from other peer(s), 1566,

PeerReq may update the peer list and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1546. PeerReq may then broadcast the updated CA request on CCDCH and wait for the response on the CCDCH, 1548, until the predefined time tOutChReq has expired, 1550, or until the PeerReq receives a response(s) from other peer(s), 1552, such that all the received responses indicate "accepted", 1554, for all peers on the peer list, 1556, whichever occurs first.

[0135] If granted the CA, PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1528. If the predefined time tOutChReq expires, 1550, the PeerReq may abort the CA request and report to the higher layer or function(s) that triggered the CA request, 1524.

[0136] If a peer(s) is detected, 1510, and the peer list is not empty, 1513, then the PeerReq may conduct the CA request procedure 1514 as a new peer in the proximity. The PeerReq may decide its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 1516.

[0137] The PeerReq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH (using, for example, the fast CCDCH accessing scheme of Figure 11) and wait for response(s) from other peer(s) on CCDCH, 1518. While waiting, the PeerReq may check for a peer's response, 1520, such that the steps 1518 and 1520 continue until a response is received or a predefined timer tOutChReq expires, 1522. If the predefined timer tOutChReq expires, the PeerReq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1524.

[0138] If the PeerReq receives a response, it may determine if the response indicates if the request has been "accepted" or "rejected", 1526. If the PeerReq receives response(s) indicating "accepted" (i.e. not rejected at 1526) by all peers on its peer list, 1527, then the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1528. If the PeerReq receives a response indicating "rejected" from peer(s) (i.e. rejected at 1526), then PeerReq may update its peer list and may adjust its superframe and/or frame, and slot, code, and/or subcarriers based on peer's rejection response, 1530.

[0139] Figure 16 is a diagram of an example inter-P2PNWs CA procedure 1600 with P2PNW detection for hybrid control. The following parameters are referred to in Figure 16. Parameter tOutScanP2P may be a time out period for scanning P2PNW. Parameter tScanCCDCH may be a time period for scanning CCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0140] The CA with P2PNW detection for distributed control may apply, for example, to a hybrid control, distributed inter-P2PNWs and virtually centralized intra-P2PNW control as shown in Figure 7. With reference to Figure 16, the start of CA with P2PNW detection, 1604, may be triggered by the application, 1602. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. The VL Requesting CA (referred to as VLreq) may scan the beacon, paging, and/or broadcast signal for VLs in the existing P2PNWs, 1608, until a VL(s) is detected, 1610, or the predefined timer tOutScanP2P has expired, 1612.

[0141] If no VL is detected in proximity, 1610, and VLreq may determine that the VL list is empty, 1613, VLreq may assign itself as the first VL and insert may commence the CA for a first VL with collision avoidance, 1632. The VLreq may decide the CCDCH, however, a collision may occur, for example, if there are other VL(s) starting the insertion of the CCDCH at the same time. To avoid a possible collision, the VLreq may conduct a Collision Avoidance procedure, 1634.

[0142] For the collision avoidance procedure, 1634, the VLreq may determine the CCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA request on CCDCH for a time window of tScanCCDCH, 1636. It is then determined if the CCDCH is detected, 1638. If

CCDCH is detected, VLreq may update its CCDCH based on the detection,

1640, and respond to the request with "yes" or "accept" to the first VL's request, 1644. VLreq may then update its VL list with the first VL detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1646. VLreq may then broadcast the CA request on

CCDCH and wait for the response on the CCDCH, 1648, until the predefined timer tOutChReq has expired, 1650, or VLreq receives a response(s) from other VL(s), 1652.

[0143] If no CCDCH is detected, 1638, the VLreq may be the first VL in proximity. VLreq may insert the CCDCH with its CA request and wait for a response, 1645. VLreq may determine if a response is received, 1664. If no response is received (e.g. there is no other VL(s) or P2PNW(s) in proximity) or "accept" response(s) from other VL(s) are received, 1666, the VLreq may be granted with CA. In these cases, the VL list may be updated, 1658, if applicable, and the VLreq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1628.

[0144] If the response indicates "rejected" from other VL(s), 1666, VLreq may update the VL list and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1646. VLreq may then broadcast the updated CA request on CCDCH and wait for the response on the CCDCH, 1648, until the predefined time tOutChReq has expired, 1650, or until the VLreq receives a response(s) from other VL(s), 1652, such that all the received responses indicate "accepted", 1654, for all VLs on the VL list, 1656, whichever occurs first.

[0145] If granted the CA, VLeq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1628. If the predefined time tOutChReq expires, 1650, the VLreq may abort the CA request and report to the higher layer or function(s) that triggered the CA request, 1624.

[0146] If a VL(s) is detected, 1610, and the VL list is not empty, 1613, then the VLreq may conduct the CA request procedure 1614 as a new VL in the proximity. The VLreq may determine its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 1616. [0147] The VLreq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH (using, for example, the fast CCDCH accessing scheme of Figure 11) and wait for response(s) from other VL(s) on CCDCH, 1618. While waiting, the VLreq may check for the VL's response, 1620, such that the steps 1618 and 1620 may continue until a response is received or a predefined timer tOutChReq expires, 1622. If the predefined timer tOutChReq expires, the VLreq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1624.

[0148] If the VLreq receives a response, it may determine if the response indicates if the request has been "accepted" or "rejected", 1626. If the VLreq receives response(s) indicating "accepted" (i.e. not rejected at 1626) by all VLs on its VL list, 1627, then the VLreq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1628. If the VLreq receives a response indicating "rejected" from VL(s) (i.e. rejected at 1626), then VLreq may update its VL list and may adjust its superframe and/or frame, and slot, code, and/or subcarriers based on VL's rejection response, 1630.

[0149] Examples of CA with P2PNW cooperation schemes are shown in

Figure 17, 18, and 19. A SuperVL, VL or peer may request channel allocation based on the detected resource usage and may receive the channel allocation through the P2PNWs' cooperation. Examples of resource usage include, but are not limited to, superframe, frame, slot (e.g. TDMA), code (e.g. CDMA), and/or subcarrier (e.g. OFDM) information for different multiplexing schemes. CCDCH accessing may use any of the schemes described above.

[0150] Figure 17 is a diagram of an example inter-P2PNWs CA procedure 1700 with P2PNW cooperation for virtually centralized control. The following parameters are referred to in Figure 17. Parameter tOutScanSpVL may be a time out period for scanning SuperVL. Parameter tScanCCDCH may be a time period for scanning CCDCH. Parameter tOutChReq may be a time out period for a channel request. [0151] CA with P2PNW cooperation for a virtually centralized control scheme may apply, for example, to virtually centralized inter-P2PNWs and intra-P2PNW as shown in Figure 5. With reference to Figure 17, the start of CA with P2PNW cooperation, 1704, may be triggered by the application, 1702. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. As part of SuperVL detection, 1706, the VL requesting CA (referred to as VLreq) may scan the beacon, paging, and/or broadcast signal for an existing SuperVL, 1708, for virtually centralized P2PNWs control in proximity, which may continue until the SuperVL is detected, 1710, or a predefined timer tOutScanSpVL has timed out, 1712.

[0152] If the SuperVL is detected in proximity, then CA may be managed by the SuperVL, 1714, referred to as centralized inter-P2PNWs control. The VLreq may decide its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 1716.

[0153] The VLreq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH (using, for example, the fast CCDCH accessing scheme of Figure 11) to the SuperVL and wait for the SuperVL's response on the CCDCH, 1718. While waiting, the VLreq may check for the SuperVL's response, 1720, such that the steps 1718 and 1720 ma continue until a response is received or a predefined timer tOutChReq expires, 1722. If the predefined timer tOutChReq expires, the VLreq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1724.

[0154] If the VLreq receives a response, it must determine if the response indicates if the request has been "accepted" or "rejected", 1726. If the

VLreq receives an "accepted" response from the SuperVL, the VLreq may access the channel allocated by the SuperVL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1728, indicating the newly formed P2PNW in the proximity that is logically led by VLreq as a SuperVL or VL. The other VLs in proximity may also make adjustments for the new superframe and/or frame, and slot, code, and/or subcarriers accordingly.

[0155] If the VLreq receives a "rejected" response from the SuperVL, then the cooperation procedure, 1729, may commence where the SuperVL may request VL(s) to adjust their superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH and VLreq may wait for the response from VL(s), 1730, until a response is received, 1770, or timer tOutChReq has timed out, 1722.

[0156] If a response is received, VLreq may determine if the response indicates that the request was "accepted" or "rejected", 1776. If VLreq is rejected, 1776, and VLreq has not timed out, 1722, the SuperVL may request

VL(s) to adjust their superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH and VLreq may wait for the response from VL(s),

1730, until a response is received, 1770, or timer tOutChReq has timed out,

1722. If not rejected, 1776, VLreq may check if it has received all responses from the VL(s), 1774, requested by the SuperVL to adjust their superframe and/or frame, and slot, code, and/or subcarriers. If VLreq has received all the

VL(s)' responses for accepting the adjustments, the VLreq may access the channel allocated by the SuperVL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1728. If VLreq has not received all the

VL(s)' responses and not timed out, the SuperVL may request VL(s) to adjust their superframe and/or frame, and slot, code, and/or subcarriers on the

CCDCH and VLreq may wait for the response from VL(s), 1730, until a response is received, 1770, or timer tOutChReq has timed out, 1722.

[0157] If no SuperVL is detected in proximity by the time timer tOutScanSpVL has expired, 1712, VLreq may assign itself as the SuperVL (i.e. the first VL in proximity as the default SuperVL) and may commence the CA for SuperVL (i.e. First VL) procedure with Collision Avoidance, 1732. The VLreq may decide the CCDCH, however, a collision may occur, for example, if there are other VL(s) assuming the SuperVL claim and starting the insertion of the CCDCH at the same time. To avoid a possible collision, the VLreq may conduct a Collision Avoidance procedure, 1734.

[0158] For the collision avoidance procedure, 1734, the VLreq may determine the CCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA request on CCDCH for a time window of tScanCCDCH, 1736. It is then determined if the CCDCH is detected, 1738. If CCDCH is detected, VLreq may update its CCDCH based on the detection, 1740, and then determine if the CCDCH is from a SuperVL, 1742. If it is determined that the CCDCH was transmitted by a SuperVL, (e.g. a SuperVL that was formed while the VLreq was performing CA), VLreq may conduct CA by SuperVL, 1714. If it was not a SuperVL but a VL that transmitted the CCDCH (e.g. the first VL chose not to be the default SuperVL), the VLreq may respond with "yes" or "accept" to the first VL's request on the CCDCH and may assign itself as the SuperVL, 1744. Alternatively, the VLreq may choose not to be the SuperVL. The VLreq may then enter the cooperation procedure 1769 and may then update its VL list with the first VL detected, and the superframe and/or frame, and slot, code, and/or subcarriers for all VL(s) on its VL list based on the detection, 1746. The VLreq may then broadcast the updated CA request on CCDCH to VL(s) and wait for the response on the CCDCH, 1748, until the predefined time tOutChReq has expired, 1750, or until the VLreq receives a response from other VL(s), 1752, whichever occurs first.

[0159] If no CCDCH is detected, 1738, the VLreq mayfrom be the first

VL in proximity, and may assign itself as the default SuperVL (it may also choose not to be a SuperVL). Accordingly, the VLreq may insert the CCDCH with the CA request, indicating itself as the SuperVL (if applicable), and wait for a response, 1745. VLreq may then determine if a response is received, 1764.

[0160] If a response is received, VLreq may determine if the response indicates that the request is "accepted" or "rejected", 1766. If VLreq does not receive a response (e.g. there are no other VL(s) or P2PNW(s) in proximity) or "accept" response(s) are received from other VL(s) (i.e. not rejected at 1766), the VLreq may be granted with CA as the SuperVL as virtually centralized inter-P2PNWs control. In these cases, the VLreq may update its VL list, 1758, if applicable, and may access the channel allocated by the SuperVL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1728.

[0161] If it is determined that the response is "reject" from other VL(s)

(i.e. rejected at 1766), VLreq may enter the cooperation procedure 1769, and may update its VL list with the first VL detected, and adjust the superframe and/or frame, and slot, code, and/or subcarriers for all VL(s) on its VL list based on the detection, 1746. The VLreq may then broadcast the updated CA request on CCDCH and wait for the response on the CCDCH, 1748, until the predefined time tOutChReq has expired, 1750, or until the VLreq receives a response(s) from other VL(s), 1752, indicating "accepted", 1754, for all responses on the VL list, 1756, whichever occurs first.

[0162] If no response is received, 1752, by the time timer tOutChReq has expired, 1750, the VLreq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1724.

[0163] Figure 18 is a diagram of an example inter-P2PNW's CA procedure 1800 with P2PNW cooperation for distributed control. The following parameters are referred to in Figure 18. Parameter tOutScanPeer may be a time out period for scanning peers. Parameter tScanCCDCH may be a time period for scanning CCDCH. Parameter tOutChReq may be a time out period for a channel request. [0164] The CA procedure 1800 with P2PNW cooperation for distributed control may apply, for example, to distributed inter-P2PNWs and intra- P2PNW as shown in Figure 6. With reference to Figure 18, the start of CA with P2PNW detection, 1804, may be triggered by the application, 1802. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. The Peer Requesting CA (referred to as PeerReq) may scan the beacon, paging, and/or broadcast signal for peers in a fully distributed P2PNW, 1808, until a peer(s) is detected, 1810, or the predefined timer tOutScanPeer has expired, 1812.

[0165] If no peer is detected in proximity, 1810, and it is determined that the peer list is empty, 1813, PeerReq may assign itself as the first peer and may commence the CA for a first peer with collision avoidance, 1832. The PeerReq may decide the CCDCH, however, a collision may occur, for example, if there are other peers(s) starting the insertion of the CCDCH at the same time. To avoid a possible collision, the PeerReq may conduct a Collision Avoidance procedure, 1834.

[0166] For the collision avoidance procedure, 1834, the PeerReq may determine the CCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA request on CCDCH for a time window of tScanCCDCH, 1836. It is then determined if the CCDCH is detected, 1838. If CCDCH is detected, PeerReq may update its CCDCH based on the detection, 1840, and respond to the request with "yes" or "accept" to the first peer's request, 1844. Then the cooperation procedure, 1829, may commence where the PeerReq may then update its peer list with the first peer detected, and PeerReq may adjust the superframe and/or frame, and slot, code, and/or subcarriers for all the peers on its peers list based on the detection, 1846. PeerReq may then broadcast the CA request on CCDCH to peers for adjustments and wait for the peers' responses on the CCDCH, 1848, until the predefined timer tOutChReq has expired, 1850, or PeerReq receives a response(s) from other peer(s), 1852. [0167] If no CCDCH is detected, 1838, the PeerReq may be the first peer in proximity. PeerReq may insert the CCDCH with its CA request and wait for a response, 1845. It is then determined if a response is received, 1864. If no response is received (e.g. there is no other peer(s) or P2PNW(s) in proximity) or "accept" response(s) from other peer(s) are received, 1866, the PeerReq may be granted with CA. In these cases, the peer list may be updated, 1858, if applicable, and the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1828.

[0168] If the response indicates "rejected" from other peer(s), 1866, the cooperation procedure, 1829, may be initiated and PeerReq may update the peer list and adjust the superframe and/or frame, and slot, code, and/or subcarriers for all the peers on its peer list based on the detection, 1846. PeerReq may then broadcast the updated CA request on CCDCH to peers for adjustment and wait for the peers' responses on the CCDCH, 1848, until the predefined time tOutChReq has expired, 1850, or until the PeerReq receives a response(s) from other peer(s), 1852, such that all the received responses indicate "accepted", 1854, for all peers on the peer list, 1856, whichever occurs first.

[0169] If granted the CA, PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1828. If the predefined time tOutChReq expires, 1850, the PeerReq may abort the CA request and report to the higher layer or function(s) that triggered the CA request, 1824.

[0170] If a peer(s) is detected, 1810, and the peer list is not empty, 1813, then the PeerReq may conduct the CA request procedure 1814 as a new peer in the proximity. The PeerReq may determine its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 1816. [0171] The PeerReq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH (using, for example, the fast CCDCH accessing scheme of Figure 11) and wait for response(s) from other peer(s) on CCDCH, 1818. While waiting, the PeerReq may check for a peer's response, 1820, as part of the cooperation procedure, 1825, such that the steps 1818 and 1820 continue until a response is received or a predefined timer tOutChReq expires, 1822. If the predefined timer tOutChReq expires, the PeerReq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1824.

[0172] If the PeerReq receives a response, it must determine if the response indicates if the request has been "accepted" or "rejected", 1826. If the PeerReq receives response(s) indicating "accepted" (i.e. not rejected at 1826) by all peers on its peer list, 1827, then the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1828. If the PeerReq receives a response indicating "rejected" from peer(s) (i.e. rejected at 1826), then PeerReq may update its peer list and may adjust the superframe and/or frame, and slot, code, and/or subcarriers for peers on its peer list based on peer's rejection response, 1830.

[0173] Figure 19 is a diagram of an example inter-P2PNWs CA procedure 1900 with P2PNW cooperation for hybrid control. The following parameters are referred to in Figure 19. Parameter tOutScanVL may be a time out period for scanning VL. Parameter tScanCCDCH may be a time period for scanning CCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0174] The CA with P2PNW detection for distributed control may apply, for example, to a hybrid control, distributed inter-P2PNWs and virtually centralized intra-P2PNW control as shown in Figure 7. With reference to

Figure 19, the start of CA with P2PNW detection, 1904, may be triggered by the application, 1902. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. The VL Requesting CA (referred to as VLreq) may scan the beacon, paging, and/or broadcast signal for VLs in the existing P2PNWs, 1908, until a VL(s) is detected, 1910, or the predefined timer tOutScanVL has expired, 1912.

[0175] If no VL is detected in proximity, 1910, and it is determined that the VL list is empty, 1913, VLreq may assign itself as the first VL and insert may commence the CA for a first VL with collision avoidance, 1932. The VLreq may decide the CCDCH, however, a collision may occur, for example, if there are other VL(s) starting the insertion of the CCDCH at the same time. To avoid a possible collision, the VLreq may conduct a Collision Avoidance procedure, 1934.

[0176] For the collision avoidance procedure, 1934, the VLreq may determine the CCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA request on CCDCH for a time window of tScanCCDCH, 1936. It is then determined if the CCDCH is detected, 1938. If

CCDCH is detected, VLreq may update its CCDCH based on the detection,

1940, and respond to the request with "yes" or "accept" to the first VL's request, 1944. The cooperation procedure, 1929, may commence and VLreq may update its VL list with the first VL detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 1946.

VLreq may then broadcast the CA request on CCDCH and wait for the peers' responses on the CCDCH, 1948, until the predefined timer tOutChReq has expired, 1950, or VLreq receives a response(s) from other VL(s), 1952.

[0177] If no CCDCH is detected, 1938, the VLreq may be the first VL in proximity. VLreq may insert the CCDCH with its CA request and wait for a response, 1945. It is then determined if a response is received, 1964. If no response is received (e.g. there is no other VL(s) or P2PNW(s) in proximity) or

"accept" response(s) from other VL(s) are received, 1966, the VLreq may be granted with CA. In these cases, the VL list may be updated, 1958, if applicable, and the VLreq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1928.

[0178] If the response indicates "rejected" from other VL(s), 1966, then the cooperation procedure, 1929, may commence and VLreq may update the VL list and adjust the superframe and/or frame, and slot, code, and/or subcarriers for all VLs in its VL list based on the detection, 1946. VLreq may then broadcast the updated CA request on CCDCH and wait for the peers' responses on the CCDCH, 1948, until the predefined time tOutChReq has expired, 1950, or until the VLreq receives a response(s) from other VL(s), 1952, such that all the received responses indicate "accepted", 1954, for all VLs on the VL list, 1956, whichever occurs first.

[0179] If granted the CA, VLreq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1928. If the predefined time tOutChReq expires, 1950, the VLreq may abort the CA request and report to the higher layer or function(s) that triggered the CA request, 1924.

[0180] If a VL(s) is detected, 1910, and the VL list is not empty, 1913, then the VLreq may conduct the CA request procedure 1914 as a new VL in the proximity. The VLreq may determine its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 1916.

[0181] The VLreq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the CCDCH (using, for example, the fast CCDCH accessing scheme of Figure 11) and wait for response(s) from other VL(s) on CCDCH, 1918. While waiting, the VLreq may check for the VL's response, 1920, as part of the cooperation procedure 1925, such that the steps 1918 and 1920 may continue until a response is received or a predefined timer tOutChReq expires, 1922. If the predefined timer tOutChReq expires, the VLreq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 1924.

[0182] If the VLreq receives a response, it must determine if the response indicates if the request has been "accepted" or "rejected", 1926. If the VLreq receives response(s) indicating "accepted" (i.e. not rejected at 1926) by all VLs on its VL list, 1927, then the VLreq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 1928. If the VLreq receives a response indicating "rejected" from VL(s) (i.e. rejected at 1926), then VLreq may update its VL list and may adjust the superframe and/or frame, and slot, code, and/or subcarriers for the VLs on its VL list based on VL's rejection response, 1930.

[0183] As the inter-P2PNWs CA may be very active, the intra-P2PNW

CA may be very dynamic as well. For example, a peer may join or leave the P2PNW for gaming; a peer may become a subVL for hopping or vice visa; or personalized commercial advertisement in a store may be frequently changing. In addition, the intra-P2PNW CA may need to be adjusted accordingly whenever the inter-P2PNW CA is conducted with P2PNW cooperation.

[0184] For a fully distributed group based P2PNW, the channel resources may be too limited to provide a dedicated channel for each peer participating in the group communications. This may be very limiting for users in a large fully distributed grouped based P2PNW at a very crowded area with many P2PNWs in proximity, because a peer may have to share the limited channels with other peers in the group for transmitting or receiving data from any other peer in the group. Clear Channel Assessment (CCA) may be used for accessing shared channels to avoid collision. Fast DCDCH accessing may be used as an efficient approach for CCA, and more efficient than Carrier Sense Multiple Access (CSMA) schemes. An intra-P2PNW CA may also be used for intra-P2PNW Channel Accessing (CAc). For example, the requesting peer, PeerReq, in the following schemes described below may be replaced by a SubVL requesting CA/CAc, SubVLreq, for multi-hops in a P2P with virtually centralized intra- P2PNW control.

[0185] Similar to inter-P2PNW CA with P2PNW detection, exemplary dynamic intra-P2PNW CA/CAc with peer detection schemes are shown in Figure 20 for virtually centralized control and Figure 21 for distributed control.

[0186] Figure 20 shows an example of a intra-P2PNW CA/CAc procedure 2000 with peer detection for virtually centralized control. The following parameters are referred to in Figure 20. Parameter tOutScanVL may be a time out period for scanning VL. Parameter tScanDCDCH may be a time period for scanning DCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0187] The CA/CAc with peer detection procedure 2000 for a virtually centralized control scheme may apply, for example, to virtually centralized inter-P2PNWs and intra-P2PNW as shown in Figure 5 or hybrid control as shown in Figure 7. With reference to Figure 20, the start of CA/CAc with peer detection, 2004, may be triggered by the application, 2002. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests.

[0188] As part of VL detection, 2006, the peer requesting CA/CAc

(referred to as PeerReq) may scan the beacon, paging, and/or broadcast signal for an existing VL, 2008, for a centralized P2PNW control in proximity, which may continue until the VL is detected, 2010, or a predefined timer tOutScanVL has timed out, 2012.

[0189] If a VL is detected in proximity, then CA/CAc may be managed by the VL, 2014, referred to as centralized inter-P2PNWs control. The PeerReq may decide its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 2016. [0190] The PeerReq may broadcast the CA/CAc request indicating superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH (using, for example, the fast DCDCH accessing scheme of Figure 13) to the VL and wait for the VL's response on the DCDCH, 2018. While waiting, the PeerReq may check for the VL's response, 2020, such that the steps 2018 and 2020 continue until a response is received or a predefined timer tOutChReq expires, 2022. If the predefined timer tOutChReq expires, the PeerReq may abort the CA/CAc request and report to the higher layer or function(s) requesting the CA/CAc (i.e. the application that triggered the CA request), 2024.

[0191] If the PeerReq receives a response, 2020, it must determine if the response indicates if the request has been "accepted" or "rejected", 2026. If the PeerReq receives an "accepted" response from the VL, the PeerReq may access the channel allocated by the VL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal for a CA request or PeerReq may access the channel allocated by the VL for a CAc request, 2028.

[0192] If the PeerReq receives a "rejected" response from the VL, the

PeerReq may adjust the requested superframe and/or frame, and slot, code, and/or subcarriers based on VL's rejection response, 2030, then re-broadcast the request to the VL on the DCDCH, 2018, and wait for the response from the VL if the predefined timer, tOutChReq, has not expired, 2022.

[0193] If no SVL is detected in the P2PNW by the time timer tOutScanSpVL has expired, 2012, PeerReq may assign itself as the VL (i.e. the first peer in a P2PNW as the default VL) and may commence the CA/CAc for VL (i.e. First peer) procedure with Collision Avoidance, 2032. The PeerReq may decide the DCDCH, however, a collision may occur, for example, if there are other peer(s) assuming the VL claim and starting the insertion of the DCDCH at the same time. To avoid a possible collision, the PeerReq may conduct a Collision Avoidance procedure, 2034. [0194] For the collision avoidance procedure, 2034, the PeerRq may decide the DCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA/Cac request on DCDCH for a time window of tScanDCDCH, 2036. It is then determined if the DCDCH is detected, 2038. If DCDCH is detected, PeerReq may update its DCDCH based on the detection, 2040, and then determine if the DCDCH is from a VL, 2042. If it is determined that the DCDCH was transmitted by a VL, (e.g. a VL that was formed while the PeerReq was performing CA/Cac), PeerReq may conduct CA/Cac by VL, 2014. If it was not a VL but a peer that transmitted the DCDCH (e.g. the first peer chose not to be the default VL), the PeerReq may respond with "yes" or "accept" to the first peer's request on the DCDCH and may assign itself as the VL, 2044. Alternatively, the PeerReq may choose not to be the VL. The PeerReq may then update its peer list with the first peer detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 2046. The PeerReq may then broadcast the updated CA/Cac request on DCDCH and wait for the response on the DCDCH, 2048, until the predefined time tOutChReq has expired, 2050, or until the PeerReq receives a response(s) from other peer(s), 2052, whichever occurs first.

[0195] If no DCDCH is detected, 2038, the PeerReq may be the first peer in proximity, and may assign itself as the default VL (it may also choose not to be a VL). Accordingly, the PeerReq may insert the DCDCH with the CA/CAc request, indicating itself as the VL (if applicable), and wait for a response,

2045. PeerReq may then determine if a response is received, 2064.

[0196] If a response is received, PeerReq may determine if the response indicates that the request is "accepted" or "rejected", 2066. If PeerReq does not receive a response (e.g. there are no other peer(s) or P2PNW(s) in proximity) or "accept" response(s) are received from other peer(s) (i.e. not rejected at 2066), the PeerReq may be granted with CA/CAc as the VL as virtually centralized intra-P2PNWs control. In these cases, the PeerReq may update its peer list, 2058, if applicable, and may access the channel allocated by the VL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, for a CA request or PeerReq may access the channel allocated by the VL for a CAc request, 2028.

[0197] If it is determined that the response is "reject" from other peer(s)

(i.e. rejected at 2066), PeerReq may update its peer list with the first peer detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 2046. The PeerReq may then broadcast the updated CA request on DCDCH and wait for the response on the DCDCH, 2048, until the predefined time tOutChReq has expired, 2050, or until the PeerReq receives a response(s) from other peer(s), 2052, indicating "accepted", 2054, for all responses on the peer list, 2056, whichever occurs first. If no response is received, 2052, by the time timer tOutChReq has expired, 2050, the PeerReq may abort the CA request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA request), 2024.

[0198] Figure 21 shows an example of an intra-P2PNW CA/CAc procedure 2100 with peer detection for distributed control. The following parameters are referred to in Figure 21. Parameter tOutScanPeer may be a time out period for scanning peers. Parameter tScanDCDCH may be a time period for scanning DCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0199] The CA/CAc with peer detection for distributed control may apply, for example, to distributed inter-P2PNWs and intra-P2PNW as shown in Figure 6. With reference to Figure 21, the start of CA with P2PNW detection, 2104, may be triggered by the application, 2102. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. The Peer Requesting CA (referred to as PeerReq) may scan the beacon, paging, and/or broadcast signal for peers, 2108, until a peer(s) is detected, 2110, or the predefined timer tOutScanPeer has expired, 2112.

[0200] If no peer is detected in proximity, 2110, and it is determined that the peer list is empty, 2113, PeerReq may assign itself as the first peer and insert may commence the CA/CAc for a first peer with collision avoidance, 2132. The PeerReq may decide the DCDCH, however, a collision may occur, for example, if there are other peers(s) starting the insertion of the DCDCH at the same time. To avoid a possible collision, the PeerReq may conduct a Collision Avoidance procedure, 2136.

[0201] For the collision avoidance procedure, 2136, the PeerReq may decide the DCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA/CAc request on DCDCH for a time window of tScanDCDCH, 2134. It is then determined if the DCDCH is detected, 2138. If DCDCH is detected, PeerReq may update its DCDCH based on the detection, 2140, and respond to the request with "yes" or "accept" to the first peer's request, 2144. PeerReq may then update its peer list with the first peer detected, and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 2146. PeerReq may then broadcast the CA/CAc request on DCDCH and wait for the response on the DCDCH, 2148, until the predefined timer tOutChReq has expired, 12150, or PeerReq receives a response(s) from other peer(s), 2152.

[0202] If no DCDCH is detected, 2138, the PeerReq may be the first peer in proximity. PeerReq may insert the DCDCH with its CA/CAc request and wait for a response, 2145. It is then determined if a response is received,

2164. If no response is received (e.g. there is no other peer(s) or P2PNW(s) in proximity) or "accept" response(s) from other peer(s) are received, 2166, the

PeerReq may be granted with CA/CAc. In these cases, the peer list may be updated, 2158, if applicable, and the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 2128. [0203] If the response indicates "rejected" from other peer(s), 2166,

PeerReq may update the peer list and adjust its superframe and/or frame, and slot, code, and/or subcarriers based on the detection, 2146. PeerReq may then broadcast the updated CA/CAc request on DCDCH and wait for the response on the DCDCH, 2148, until the predefined time tOutChReq has expired, 2150, or until the PeerReq receives a response(s) from other peer(s), 2152, such that all the received responses indicate "accepted", 2154, for all peers on the peer list, 2156, whichever occurs first.

[0204] If granted the CA/CAc, PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal (for CA) or may access the channel granted (for CAc), 2128. If the predefined time tOutChReq expires, 2150, the PeerReq may abort the CA/CAc request and report to the higher layer or function(s) that triggered the CA/CAc request, 2124.

[0205] If a peer(s) is detected, 2110, and the peer list is not empty, 2113, then the PeerReq may conduct the CA/CAc request procedure 2114 as a new peer in the proximity. The PeerReq may decide its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 2116.

[0206] The PeerReq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH (using, for example, the fast DCDCH accessing scheme of Figure 13) and wait for response(s) from other peer(s) on DCDCH, 2118. While waiting, the PeerReq may check for a peer's response, 2120, such that the steps 2118 and 2120 continue until a response is received or a predefined timer tOutChReq expires,

2122. If the predefined timer tOutChReq expires, the PeerReq may abort the

CA/CAc request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA/CAc request), 2124.

[0207] If the PeerReq receives a response, it must determine if the response indicates if the request has been "accepted" or "rejected", 2126. If the PeerReq receives response(s) indicating "accepted" (i.e. not rejected at 2126) by all peers on its peer list, 2127, then the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 2128. If the PeerReq receives a response indicating "rejected" from peer(s) (i.e. rejected at 2126), then PeerReq may update its peer list and may adjust its superframe and/or frame, and slot, code, and/or subcarriers based on peer's rejection response, 2130.

[0208] Figure 22 shows an example of an intra-P2PNW CA/CAc procedure 2200 with peer cooperation for virtually centralized control. The following parameters are referred to in Figure 22. Parameter tOutScanVL may be a time out period for scanning VL. Parameter tScanDCDCH may be a time period for scanning DCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0209] CA/CAc with peer cooperation for virtually centralized control scheme may apply, for example, to virtually centralized inter-P2PNWs and intra-P2PNW as shown in Figure 5 or hybrid control as shown in Figure 7. With reference to Figure 22, the start of CA/CAc with peer cooperation, 2204, may be triggered by the application, 2202. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. As part of VL detection, 2206, the peer requesting CA/CAc (referred to as PeerReq) may scan the beacon, paging, and/or broadcast signal for an existing VL, 2208, for virtually centralized P2PNWs control in proximity, which may continue until a VL is detected, 2210, or a predefined timer tOutScanVL has timed out, 2212.

[0210] If the VL is detected in proximity, then CA/CAc may be managed by the VL, 2214, referred to as virtually centralized intra-P2PNW control. The PeerReq may decide its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 2216. [0211] The PeerReq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH (using, for example, the fast DCDCH accessing scheme of Figure 13) to the VL and wait for the VL's response on the DCDCH, 2218. While waiting, the PeerReq may check for the VL's response, 2220, such that the steps 2218 and 2220 may continue until a response is received or a predefined timer tOutChReq expires, 2222. If the predefined timer tOutChReq expires, the PeerReq may abort the CA/CAc request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA/CAc request), 2224.

[0212] If the PeerReq receives a response, it must determine if the response indicates if the request has been "accepted" or "rejected", 2226. If the PeerReq receives an "accepted" response from the VL, the PeeReq may access the channel allocated by the VL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 2228, indicating the newly formed P2PNW in the proximity that is logically led by PeerReq as VL. The other peers in proximity may also make adjustments for the new superframe and/or frame, and slot, code, and/or subcarriers accordingly.

[0213] If the PeerReq receives a "rejected" response from the VL, then the cooperation procedure, 2229, may commence where the VL may request peer(s) to adjust their superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH and PeerReq may wait for the response from peer(s), 2230, until a response is received, 2270, or timer tOutChReq has timed out, 2222.

[0214] If a response is received, 2270, PeerReq must determine if the response indicates that the request was "accepted" or "rejected", 2276. If

PeerReq is rejected, 2276, and PeerReq has not timed out, 2222, the VL may request the peers(s) to adjust their superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH and PeerReq may wait for the response,

2230, from all the peer(s), 2274, until a response is received, 2270, or timer tOutChReq has timed out, 2222. If PeerReq was not rejected, 2276, PeerReq may check if it has received all responses from the peer(s), 2274, requested by the VL to adjust their superframe and/or frame, and slot, code, and/or subcarriers. If PeerReq has received all the peer(s)' responses for accepting the adjustments, the PeeReq may access the channel allocated by the VL, with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal for CA or access the channel (if CAc), 2228. If PeerReq has not received all the peer(s)' responses and not timed out, the VL may request peer(s) to adjust their superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH and PeerReq may wait for the response from peer(s), 2230, until a response is received, 2270, or timer tOutChReq has timed out, 2222.

[0215] If no VL is detected in proximity by the time timer tOutScanVL has expired, 2212, PeerReq may assign itself as the VL (i.e. the first peer in proximity as the default VL) and may commence the CA/CAc for VL (i.e. First VL) procedure with Collision Avoidance, 2232. The PeerReq may select the DCDCH, however, a collision may occur, for example, if there are other peer(s) assuming the VL claim and starting the insertion of the DCDCH at the same time. To avoid a possible collision, the PeerReq may conduct a Collision Avoidance procedure, 2234.

[0216] For the collision avoidance procedure, 2234, the PeerReq may decide the DCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA/CAc request on DCDCH for a time window of tScanDCDCH, 2236. It is then determined if the DCDCH is detected, 2238.

If DCDCH is detected, PeerReq may update its DCDCH based on the detection, 2240, and then determine if the CCDCH is from a SuperVL, 2242.

If it is determined that the DCDCH was transmitted by a VL, (e.g. a VL that was formed while the PeerReq was performing CA/CAc), PeerReq may conduct

CA/CAc by VL, 2214. If it was not a VL but a peer that transmitted the

DCDCH (e.g. the first peer chose not to be the default VL), the PeerReq may respond with "yes" or "accept" to the first peer's request on the DCDCH and may assign itself as the VL, 2244. Alternatively, the PeerReq may choose not to be the VL. The PeerReq may then enter the cooperation procedure, 2269, and may then update its peer list with the first peer detected, and the superframe and/or frame, and slot, code, and/or subcarriers for all peer(s) on its peer list based on the detection, 2246. The PeerReq may then broadcast the updated CA/CAc request on DCDCH to peer(s) and wait for the response on the DCDCH, 2248, until the predefined time tOutChReq has expired, 2250, or until the PeerReq receives a response(s) from other peer(s), 2252, whichever occurs first.

[0217] If no DCDCH is detected, 2238, the PeerReq may be the first peer in proximity, and may assign itself as the default VL (it may also choose not to be a VL). Accordingly, the PeerReq may insert the DCDCH with the CA/CAc request, indicating itself as the VL (if applicable), and wait for a response,

2245. PeerReq may then determine if a response is received, 2264.

[0218] If a response is received, PeerReq may determine if the response indicates that the request is "accepted" or "rejected", 2266. If PeerReq does not receive a response (e.g. there are no other peer(s) in proximity) or "accept" response(s) are received from other peer(s) (i.e. not rejected at 2266), the

PeerReq may be granted with CA/CAc as the VL as centralized intra-P2PNW control. In these cases, the PeerReq may update its peer list, 2258, if applicable, and may access the channel allocated by the VL with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 2228.

[0219] If it is determined that the response is "reject" from other peer(s)

(i.e. rejected at 2266), PeerReq may enter the cooperation procedure 2269, and may update its peer list with the first peer detected, and adjust the superframe and/or frame, and slot, code, and/or subcarriers for all peer(s) on its peer list based on the detection, 2246. The PeerReq may then broadcast the updated CA/CAc request on DCDCH and wait for the response on the

DCDCH, 2248, until the predefined time tOutChReq has expired, 2250, or until the PeerReq receives a response(s) from other peer(s), 2252, indicating "accepted", 2254, for all responses on the peer list, 2256, whichever occurs first.

[0220] If no response is received, 2252, by the time timer tOutChReq has expired, 2250, the PeerReq may abort the CA/CAc request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA/CAc request), 2224.

[0221] Figure 23 shows an example of an intra-P2PNW CA/CAc procedure 2300 with peer cooperation for distributed control. The following parameters are referred to in Figure 23. Parameter tOutScanPeer may be a time out period for scanning peers. Parameter tScanDCDCH may be a time period for scanning DCDCH. Parameter tOutChReq may be a time out period for a channel request.

[0222] The CA/CAc procedure 2300 with peer cooperation for distributed control may apply, for example, to distributed inter-P2PNWs and intra- P2PNW as shown in Figure 6. With reference to Figure 23, the start of CA/CAc with peer detection, 2304, may be triggered by the application, 2302. For example, the trigger may be from a higher layer or by other logical functions including, but not limited to PD, PA, and CAc requests. The Peer Requesting CA/CAc (referred to as PeerReq) may scan the beacon, paging, and/or broadcast signal for peers, 2308, until a peer(s) is detected, 2310, or the predefined timer tOutScanPeer has expired, 2312.

[0223] If no peer is detected in proximity, 2310, and it is determined that the peer list is empty, 2313, PeerReq may assign itself as the first peer and may commence the CA/CAc for a first peer with collision avoidance procedure, 2332. The PeerReq may decide the DCDCH, however, a collision may occur, for example, if there are other peers(s) starting the insertion of the DCDCH at the same time. To avoid a possible collision, the PeerReq may conduct a Collision Avoidance procedure, 2334.

[0224] For the collision avoidance procedure, 2334, the PeerReq may decide the DCDCH and its superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. application's QoS) and other parameters, and then scan the CA/CAc request on DCDCH for a time window of tScanDCDCH, 2336. It is then determined if the DCDCH is detected, 2338. If DCDCH is detected, PeerReq may update its DCDCH based on the detection, 2340, and respond to the request with "yes" or "accept" to the first peer's request, 2344. Then the cooperation procedure, 2329, may commence where the PeerReq may then update its peer list with the first peer detected, and PeerReq may adjust the superframe and/or frame, and slot, code, and/or subcarriers for all the peers on its peers list based on the detection, 2346. PeerReq may then broadcast the CA/CAc request on DCDCH to peers for adjustments and wait for the peers' responses on the DCDCH, 2348, until the predefined timer tOutChReq has expired, 2350, or PeerReq receives a response(s) from other peer(s), 2352.

[0225] If no DCDCH is detected, 2338, the PeerReq may be the first peer in proximity. PeerReq may insert the DCDCH with its CA/CAc request and wait for a response, 2345. It is then determined if a response is received, 2364. If no response is received (e.g. there is no other peer(s) in proximity) or "accept" response(s) from other peer(s) are received, 2366, the PeerReq may be granted with CA/CAc. In these cases, the peer list may be updated, 2358, if applicable, and the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 2328.

[0226] If the response indicates "rejected" from other peer(s), 2366, the cooperation procedure, 2329, may be initiated and PeerReq may update the peer list and adjust the superframe and/or frame, and slot, code, and/or subcarriers for all the peers on its peer list based on the detection, 2346. PeerReq may then broadcast the updated CA/CAc request on DCDCH to peers for adjustment and wait for the peers' responses on the DCDCH, 2348, until the predefined time tOutChReq has expired, 2350, or until the PeerReq receives a response(s) from other peer(s), 2352, such that all the received responses indicate "accepted", 2354, for all peers on the peer list, 2356, whichever occurs first. [0227] If granted the CA/CAc, PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal (for CA) or access the granted channel (for CAc), 2328. If the predefined time tOutChReq expires, 2350, the PeerReq may abort the CA/CAc request and report to the higher layer or function(s) that triggered the CA/CAc request, 2324.

[0228] If a peer(s) is detected, 2310, and the peer list is not empty, 2313, then the PeerReq may conduct the CA/CAc request procedure 2314 as a new peer in the proximity. The PeerReq may decide its proposed superframe and/or frame, and slot, code, and/or subcarriers based on its application (e.g. applications QoS) and current superframe and/or frame, and slot, code, and/or subcarriers usage, if detected, 2316.

[0229] The PeerReq may broadcast the request indicating superframe and/or frame, and slot, code, and/or subcarriers on the DCDCH (using, for example, the fast DCDCH accessing scheme of Figure 13) and wait for response(s) from other peer(s) on DCDCH, 2318. While waiting, the PeerReq may check for a peer's response, 2320, as part of the cooperation procedure, 2325, such that the steps 2318 and 2320 continue until a response is received or a predefined timer tOutChReq expires, 2322. If the predefined timer tOutChReq expires, the PeerReq may abort the CA/CAc request and report to the higher layer or function(s) requesting the channel (i.e. the application that triggered the CA/CAc request), 2324.

[0230] If the PeerReq receives a response, it must determine if the response indicates if the request has been "accepted" or "rejected", 2326. If the PeerReq receives response(s) indicating "accepted" (i.e. not rejected at 2326) by all peers on its peer list, 2327, then the PeerReq may access the channel with the proposed superframe and/or frame, and slot, code, and/or subcarriers that may be broadcasted on the beacon, paging, or broadcasting signal, 2328. If the PeerReq receives a response indicating "rejected" from peer(s) (i.e. rejected at 2326), then PeerReq may update its peer list and may adjust the superframe and/or frame, and slot, code, and/or subcarriers for peers on its peer list based on peer's rejection response, 2330.

[0231] Embodiments

[0232] 1. A method for virtually centralized control of a plurality of peer-to-peer networks (P2PNWs).

[0233] 2. The method of embodiment 1 wherein each P2PNW has at least one associated peer and a corresponding application.

[0234] 3. The method as in any of the previous embodiments further comprising assigning a peer, associated with a first P2PNW from the plurality of P2PNWs, as a super virtual leader (SuperVL).

[0235] 4. The method as in embodiment 3 wherein the SuperVL is configured for communicating control and data information between P2PNWs from the plurality of P2PNWs.

[0236] 5. The method of embodiments 3-4 wherein the SuperVL communicates with at least one peer in each of the plurality of P2PNWs.

[0237] 6. The method as in any of embodiments 3-5, wherein the

SuperVL communicates control and data information with the at least one peer in each of the plurality of P2PNWs over a Common Control and Data Channel (CCDCH).

[0238] 7. The method of embodiment 6, wherein the CCDCH is common to the plurality of P2PNWs.

[0239] 8. The method of embodiments 6-7, wherein communications of control and data information over the CCDCH include any of the following: common control messaging, paging, broadcasting, or short high priority data broadcasting among the plurality of P2PNWs.

[0240] 9. The method of embodiments 6-8, wherein the CCDCH is transmitted at the beginning of a superframe.

[0241] 10. The method of any of the previous embodiments, further comprising: for a second P2PNW from the plurality of P2PNWs, assigning a peer associated with the second P2PNW, as a virtual leader (VL). [0242] 11. The method of embodiment 10, wherein the VL is configured for communicating control and data information with peers within the second P2PNW.

[0243] 12. The method of embodiments 10-11, wherein the VL is configured for communicating control and data information for applications in other P2PNWs from the plurality of P2PNWs.

[0244] 13. The method of embodiment 12, wherein the VL is configured for communicating control and data information for applications in other P2PNWs from the plurality of P2PNWs with the SuperVL in the first P2PNW.

[0245] 14. The method of embodiments 10-13, wherein a plurality of peers is associated with the second P2PNW.

[0246] 15. The method of embodiment 14, further comprising: assigning a peer from the plurality of peers as a sub-virtual leader (SubVL) for communicating control and data information with the VL.

[0247] 16. The method of embodiment 15, wherein the SubVL is configured for communicating control and data information with other peers in the plurality of peers.

[0248] 17. The method of embodiment 16, wherein the other peers in the plurality of peers communicate control and data information with the VL via a SubVL.

[0249] 18. The method of embodiments 10-17, wherein the VL,

SubVLs and plurality of peers communicate control and data information within the second P2PNW over at least one Dedicated Control and Data Channel (DCDCH).

[0250] 19. The method of embodiment 18, wherein communication of control and data information over the DCDCH include any of the following: common control messaging, paging, broadcasting, or short high priority data broadcasting among the peers within the second P2PNW. [0251] 20. The method of any of the previous embodiments, wherein a corresponding DCDCH is used for each application in a plurality of applications.

[0252] 21. The method of embodiment 20, wherein each corresponding DCDCH appears in a different application frame.

[0253] 22. The method of any of embodiments 16-21, further comprising on a condition that a Common Control and Data Channel (CCDCH) is transmitted at the beginning of a first application frame of a superframe, transmitting the DCDCH immediately after the CCDCH in the first application frame of the superframe; and transmitting a second DCDCH at the beginning of a second application frame of the superframe, wherein the second application frame comes after the first application frame in the superframe.

[0254] 23. The method of embodiments 16-22, further comprising on a condition that the CCDCH is not occupied.

[0255] 24. The method of embodiments 16-23, further comprising on a condition that the peer is a super virtual leader (SuperVL), accessing the CCDCH.

[0256] 25. The method of embodiments 16-24, further comprising on a condition that the CCDCH is not occupied.

[0257] 26. The method of embodiments 16-25, further comprising on a condition that the peer is a virtual leader (VL), a sub-virtual leader (SubVL) or a peer, waiting a time period tVLi, tSubVLik, or tPeerip, respectively, and scanning if the CCDCH is available.

[0258] 27. The method of embodiment 26 wherein tVLi < tSubVLik < tPeerip.

[0259] 28. The method of embodiments 16-27, further comprising on a condition that the CCDCH is available, accessing the CCDCH with VL, SubVL, or peer information, respectively, CCDCH usage, control messages, and data messages. [0260] 29. The method of embodiments 16-28, further comprising on a condition that the CCDCH is not available, scanning if the CCDCH is available for a time period tOutVLi, tOutSubVLik, or tOutPeerip, respectively.

[0261] 30. The method of embodiments 16-29, further comprising on a condition that the CCDCH is available before the time period tOutVLi, tOutSubVLik, or tOutPeerip, respectively, expires, accessing the CCDCH.

[0262] 31. The method of embodiments 16-30, further comprising on a condition that the CCDCH is not available before the time period tOutVLi, tOutSubVLik, or tOutPeerip, respectively, expires, aborting CCDCH accessing and notifying the application.

[0263] 32. The method of embodiments 16-31, wherein accessing the

CCDCH includes accessing the CCDCH with any of the following: VL, SubVL, or peer information, respectively, CCDCH usage, control messages, and data messages.

[0264] 33. The method of any of the previous embodiments performed for fast accessing of a Dedicated Control and Data Channel (DCDCH) for intra-P2PNW communications.

[0265] 34. The method of any of the previous embodiments, further comprising A method for inter-peer-to-peer network (Inter-P2PNW) channel allocation (CA), performed by a first peer.

[0266] 35. The method of embodiment 34, further comprising receiving a trigger for a CA from an application.

[0267] 36. The method of embodiments 34-35, further comprising scanning a beacon for a second peer for a time period tOutScanP2P;

[0268] 37. The method of embodiments 34-36, further comprising on a condition that the second peer is detected before the time period tOutScanP2P expires.

[0269] 38. The method of embodiments 34-37, further comprising transmitting a request to the second peer indicating a requested allocation.

[0270] 39. The method of embodiments 34-38, further comprising waiting for a response from the second peer for a time period tOutChReq. [0271] 40. The method of embodiments 34-39, further comprising on a condition that the response is not received before time period tOutChReq expires, aborting the CA and notifying the application.

[0272] 41. The method of embodiments 34-40, further comprising on a condition that the response is received before time period tOutChReq expires and indicates that the request is accepted, accessing the requested allocation.

[0273] 42. The method of embodiments 34-41, further comprising on a condition that the response is received before time period tOutChReq expires and indicates that the request is rejected, adjusting the requested allocation based on the response, resending the request with the adjusted requested allocation, and waiting for the response from the second peer for a time period tOutChReq.

[0274] 43. The method of embodiments 34-42, further comprising on a condition that the second peer is not detected before the time period tOutScanP2P expires, deciding a common control/data channel (CCDCH) and an allocation.

[0275] 44. The method of embodiments 34-43, wherein the deciding the CCDCH and allocation further comprises scanning for an existing CCDCH for a time period tScanCCDCH.

[0276] 45. The method of embodiments 34-44, further comprising on a condition that an existing CCDCH is detected: updating the CCDCH based on the existing CCDCH.

[0277] 46. The method of embodiment 45, further comprising responding to a third peer on the CCDCH.

[0278] 47. The method of embodiments 45-46, further comprising updating a peer list with the third peer.

[0279] 48. The method of embodiments 45-47, further comprising adjusting the requested allocation based on the existing CCDCH.

[0280] 49. The method of embodiments 45-48, further comprising transmitting the request to the third peer indicating a requested allocation. [0281] 50. The method of embodiments 34-49, further comprising waiting for a response from the third peer on the existing CCDCH for a time period tOutChReq.

[0282] 51. The method of embodiments 34-50, further comprising on a condition that the response from the third peer is received before time period tOutChReq expires and indicates that the request is rejected, adjusting the requested allocation based on the response from the third peer, resending the request with the adjusted requested allocation, and waiting for the response from the third peer for a time period tOutChReq.

[0283] 52. The method of embodiments 34-51, further comprising on a condition that the response is received before time period tOutChReq expires and indicates that the request is accepted, accessing the requested allocation and updating the peer list.

[0284] 53. The method of embodiments 34-52, wherein the updating the peer list includes updating the peer list for other peers.

[0285] 54. The method of embodiments 34-53, wherein the second peer is one of: a super virtual leader (SuperVL), or a virtual leader (VL).

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

Claims

CLAIMS What is claimed:

1. A method for virtually centralized control of a plurality of peer- to-peer networks (P2PNWs), wherein each P2PNW has at least one associated peer and a corresponding application, the method comprising:

assigning a peer, associated with a first P2PNW from the plurality of P2PNWs, as a super virtual leader (SuperVL) for communicating control and data information between P2PNWs from the plurality of P2PNWs, wherein the SuperVL communicates with at least one peer in each of the plurality of P2PNWs.

2. The method of claim 1, wherein the SuperVL communicates control and data information with the at least one peer in each of the plurality of P2PNWs over a Common Control and Data Channel (CCDCH) that is common to the plurality of P2PNWs.

3. The method of claim 2, wherein communications of control and data information over the CCDCH include any of the following: common control messaging, paging, broadcasting, or short high priority data broadcasting among the plurality of P2PNWs.

4. The method of claim 2, wherein the CCDCH is transmitted at the beginning of a superframe.

5. The method of claim 1, further comprising:

for a second P2PNW from the plurality of P2PNWs, assigning a peer associated with the second P2PNW, as a virtual leader (VL) for communicating control and data information with peers within the second P2PNW, and for communicating control and data information for applications in other P2PNWs from the plurality of P2PNWs with the SuperVL in the first P2PNW.

6. The method of claim 5, wherein a plurality of peers is associated with the second P2PNW, further comprising:

assigning a peer from the plurality of peers as a sub-virtual leader (SubVL) for communicating control and data information with the VL and other peers in the plurality of peers, wherein the other peers in the plurality of peers communicate control and data information with the VL via a SubVL.

7. The method of claim 6, wherein the VL, SubVLs and plurality of peers communicate control and data information within the second P2PNW over at least one Dedicated Control and Data Channel (DCDCH).

8. The method of claim 7, wherein communication of control and data information over the DCDCH include any of the following: common control messaging, paging, broadcasting, or short high priority data broadcasting among the peers within the second P2PNW.

9. The method of claim 7, wherein a corresponding DCDCH is used for each application in a plurality of applications, and wherein each corresponding DCDCH appears in a different application frame.

10. The method of claim 7, wherein:

on a condition that a Common Control and Data Channel (CCDCH) is transmitted at the beginning of a first application frame of a superframe, transmitting the DCDCH immediately after the CCDCH in the first application frame of the superframe; and

transmitting a second DCDCH at the beginning of a second application frame of the superframe, wherein the second application frame comes after the first application frame in the superframe.

11. A method for distributed control of a plurality of peer-to-peer networks (P2PNWs), wherein each P2PNW has at least one associated peer and a corresponding application, the method comprising:

for a P2PNW in the plurality of P2PNWs, assigning a peer associated with the P2PNW, as a virtual leader (VL) for communicating control and data information for applications in other P2PNWs in the plurality of P2PNWs with VLs associated with the other P2PNWs in the plurality of P2PNWs.

12. The method of claim 11, wherein the VL communicates control and data information with VLs associated with the other P2PNWs over a common control/data channel (CCDCH) that is common to the plurality of P2PNWs.

13. The method of claim 11, further comprising assigning the VL for communicating control and data information with peers within the P2PNW.

14. The method of claim 13, wherein a plurality of peers is associated with the P2PNW, further comprising:

15. The method of claim 14, wherein the VL, Sub VLs and plurality of peers communicate control and data information within the P2PNW over at least one Dedicated Control and Data Channel (DCDCH).

16. A method for fast Common Control and Data channel (CCDCH) accessing for inter-peer-to-peer network (inter-P2PNW) communications, performed by a peer, the method comprising:

receiving a trigger for fast CCDCH accessing from an application; scanning if a CCDCH is occupied for a time period tscanCCDCH;

on a condition that the CCDCH is occupied, waiting for a time period tccDCH, and

on a condition that a time period t_outccDCH has not expired, scanning if the CCDCH is occupied for the time period tscanCCDCH;

on a condition that the time period t_outccDCH has expired, aborting CCDCH accessing and notifying the application;

on a condition that the CCDCH is not occupied:

on a condition that the peer is a super virtual leader (SuperVL), accessing the CCDCH.

17. The method of claim 16, further comprising:

on a condition that the CCDCH is not occupied:

on a condition that the peer is a virtual leader (VL), a sub-virtual leader (SubVL) or a peer, waiting a time period tvii, tsu Lik, or tp_eerip, respectively, and scanning if the CCDCH is available, wherein tvii < tSubVLik < tpeeripj and

on a condition that the CCDCH is available, accessing the CCDCH with VL, SubVL, or peer information, respectively, CCDCH usage, control messages, and data messages;

on a condition that the CCDCH is not available, scanning if the CCDCH is available for a time period toutVLi, toutSubVLik, or tOutPeerip_? respectively;

on a condition that the CCDCH is available before the time period toutvii, toutSubVLik, or toutPeerip, respectively, expires, accessing the CCDCH;

on a condition that the CCDCH is not available before the time period toutvii, toutSubVLik, or toutPeerip, respectively, expires, aborting CCDCH accessing and notifying the application.

18. The method of claim 17, wherein accessing the CCDCH includes accessing the CCDCH with any of the following: VL, SubVL, or peer information, respectively, CCDCH usage, control messages, and data messages.

19. The method of claim 17 performed for fast accessing of a Dedicated Control and Data Channel (DCDCH) for intra-P2PNW communications.

20. A method for inter-peer-to-peer network (Inter-P2PNW) channel allocation (CA), performed by a first peer, comprising:

receiving a trigger for a CA from an application;

scanning a beacon for a second peer for a time period touts_canP2p;

on a condition that the second peer is detected before the time period toutScanP2P expires;

transmitting a request to the second peer indicating a requested allocation;

waiting for a response from the second peer for a time period toutChReq; and

on a condition that the response is not received before time period toutChReq expires, aborting the CA and notifying the application;

on a condition that the response is received before time period toutChReq expires and indicates that the request is accepted, accessing the requested allocation;

on a condition that the response is received before time period toutChReq expires and indicates that the request is rejected, adjusting the requested allocation based on the response, resending the request with the adjusted requested allocation, and waiting for the response from the second peer for a time period toutChReq; and on a condition that the second peer is not detected before the time period touts_canP2P expires, deciding a common control/data channel (CCDCH) and an allocation.

21. The method of claim 20, wherein the deciding the CCDCH and allocation further comprises:

scanning for an existing CCDCH for a time period tscanCCDCH;

on a condition that an existing CCDCH is detected:

updating the CCDCH based on the existing CCDCH;

responding to a third peer on the CCDCH;

updating a peer list with the third peer;

adjusting the requested allocation based on the existing CCDCH;

transmitting the request to the third peer indicating a requested allocation;

waiting for a response from the third peer on the existing CCDCH for a time period toutChR_eq;

on a condition that the response from the third peer is received before time period toutChReq expires and indicates that the request is rejected, adjusting the requested allocation based on the response from the third peer, resending the request with the adjusted requested allocation, and waiting for the response from the third peer for a time period toutChReq; and

on a condition that the response is received before time period toutChReq expires and indicates that the request is accepted, accessing the requested allocation and updating the peer list.

22. The method of claim 21, wherein the updating the peer list includes updating the peer list for other peers.

23. The method of claim 20, wherein the second peer is one of: a super virtual leader (SuperVL), or a virtual leader (VL).