11aq Design Framework for P2P Discovery

1. Authors: 11aq Design Framework for P2P Discovery Date: 2013-07-17 Joe Kwak, InterDigital

2. Summary The design options discussed at prior 11aq meetings are adequate for service discovery for BSS use cases. However several use cases are clearly IBSS Peer to Peer (P2P) cases and are not served by options noted in 13/0057r2. This contribution describes an 11aq design framework that will provide P2P Service discovery for STAs in an IBSS. This framework is called Peer Service Discovery (PSDisc). Joe Kwak, InterDigital

3. Outline • Background • Requirements • Peer Service Discovery design framework • Independent mode discovery (few STAs) • Server mode discovery (many STAs) • Framework Summary • Open issues • Conclusions Joe Kwak, InterDigital

4. Background- PAD use cases for Peer Service Disc • 13/0125r4: #21 Max needs a cab: User is in transit on the metropolitan street and has an Taxi application for P2P connection to other STAs with same Taxi application. • 13/0125r4: #23 Gaming: User searching for peer STA with same gaming app. Airline lounge has AP which facilitates discovery of peer for P2P connection. BUT for airline lounge without AP, use case requires P2P discovery of same peer. • 13/0125r4: #8, #11, and #20 are use cases accessing free public information which could also easily be accommodated by P2P model. • No actual BSS association is needed if use case is satisfied by P2P discovery followed by P2p connection. PEER SERVICE DISCOVERY MAY BE USED WHEN NO AP, NETWORK OR DISCOVERY PROXY SERVER IS AVAILABLE. Joe Kwak, InterDigital

5. PAD discovery works differently in BSS and IBSS • For BSS discovery, services are provided by network • User needs service info about access network options • Which APs offer which SP connections? • Which APs have available BW and admission capacity? • Which APs have connection to services user seeks? • ....etc. • PAD access to ANQP info and legacy discovery protocols provide all of these. • For IBSS discovery, services are provided by peers • User needs service info about peers in local area • IBSS formation limited by radio range. All STAs in IBSS communicate with each other. • Peer service information is needed • User’s available sharing applications (service) –SERVICE INFO • User’s handle and membership level, qualifications -USER INFO • User’s MAC ID or other address for possible P2P connection --USER ADDRESS • 11-13-0429r2, presented at the May meeting, discussed the need and rationale to support PAD for IBSS P2P services Joe Kwak, InterDigital

6. Requirements for PSDisc : Keep it simple • LOW POWER: P2P PAD would serve ad-hoc IBSS networks of battery operated mobiles. Power efficiency is a crucial requirement for “always on” discovery. • SCALABLE: P2P PAD needs to be scalable for use in stadiums and large public venues. Several thousands of peers in radio range. • FAIRNESS: All peers are equal, requiring equal discovery access with equal discovery burdens. P2P PAD cannot overburden any single peer. • LOCAL: P2P connections are limited by radio range, so discovery domain must also be limited to peers in range. Joe Kwak, InterDigital

7. P2P PAD Design Framework • Peers in any IBSS adhoc network are currently able to broadcast Beacons, Probe Requests, Probe Responses and GAS Frames. What is needed is specific new IE to advertise service to peers. • Peer Service Advertisement (PSAd) is defined to contain: • Service Description: Describes service /application to be advertised. • User Information: Information about advertising user/STA. • User Address: Network addressing information for P2P connection to advertising user/STA for peer service initiation. • This PSAd may be included in any Beacon, Probe Request, Probe Response or GAS frame. Joe Kwak, InterDigital

8. Terminology for P2P Framework Discussion • PDisc: Peer to Peer Pre-Association Discovery • PSAd: Peer Service Advertisement • PSDir: Peer Service Directory contains a set of PSAds. • PSSum: Peer Service Summary abbreviates the PSDir and lists the union of service descriptions found in the PSDir, without the user info. • PDServ: Peer Discovery Server, STA designated to collect PSAds and to provide peer discovery information to other STAs. • PDWin: Peer Discovery Window, scheduled window used by all to query PDserv or to add new PSAds to the PSDir. Joe Kwak, InterDigital

9. P2P PAD Design Approach—Low Density STAs • LOW POWER requirement satisfied by designation of single channel for Peer Service Discovery. In each band only one channel will be used to host PDisc (PDisc channel). No need to continuously scan other channels and waste power. • When no beacons are present on channel: • STA may broadcast probe request including PSAd on PDisc channel . • Any STA interested in service may reply with probe response including PSAd’ indicating interest in the advertised service and listing user info for responding STA. • Any STA may initiate IBSS on channel if other STAs are detected. • When IBSS beacons are present on channel: • STA joins IBSS and includes his PSAd in any transmitted beacon. (Probe requests may also be broadcast at anytime) • Since IBSS STAs randomly share beacon transmissions, STAs receiving beacons will eventually receive PSAds from all members of IBSS. • LOCAL requirement satisfied by limited IBSS beacon radio range. • This is the INDEPENDENT MODE for PDisc Joe Kwak, InterDigital

10. P2P PAD Design Approach—Hi Density STAs • SCALABLE requirement leads to need to aggregate PSAds to conserve power and radio resource. Individual transmissions each beacon period by all STAs is very inefficient for a large number of STAs. • PDisc includes a Peer Discovery Server which broadcasts directory of advertisements for peers, saving power and channel time for all. Any STA may choose to initiate role as Peer Discovery Server for all IBSS advertising peers. • LOW POWER requirement leads to need for synchronized access to discovery information. • Inefficient for all STAs to wake up and monitor each beacon period. • PDisc includes a scheduled Peer Discovery Window (PDWin) which occurs periodically and limits the awake time for STAs doing PDisc. This is similar to ATIM window used for traffic in IBSS, but with much longer interval, spanning many beacon periods. • FAIRNESS requires that server duties be shared by all advertising peers. • This is the SERVER MODE for PDisc. Joe Kwak, InterDigital

11. P2P PAD Design Approach—Server Mode -Synchronized Peer Discovery Window (PDWin) • Peer Discovery Server is defined to be the STA which transmits beacons and discovery info (PSDir) for a service interval spanning an integer number of PDWin intervals. • Peer Discovery Server is a collects and aggregates service ads (PSAds) from all Peer Discovery STAs in group. • Once its PSAd is collected by PDServ, STA may leave IBSS and sleep for longer intervals. • FAIRNESS requirement leads to need to transition Server role and duties among all Peer Discovery STAs. • Any STA may start Server mode and be Peer Discovery Server Joe Kwak, InterDigital

12. P2P PAD Design Approach—Server Mode - Peer Discovery Server (PDServ) duties • Peer Discovery Server (PDServ) creates a Peer Service Directory (PSDir) by aggregating all PSAds received. • The PDServ creates a Peer Service Summary (PSSum) which is a superset list of all service descriptions in the PSDir. • The PSSum is transmitted in each beacon to advertise available services. Peer Service Summary includes: • Service Information from all PSAds • Beacon count to next PDWin • PDWin count to next PDServ transition (see slide #14) • PDWin may be used by any STA to list a new PSAd or to query the PDServ for details about a particular service advertised in PSSum. Joe Kwak, InterDigital

13. P2P PAD Design Approach—Server Mode -Peer Discovery Window (PDWin) Transactions • PDWin used for • Any STA to list new PSAd in the PSDir maintained by the PDServ: • Unicast Probe request to PDServ during PDWin includes new PSAd • PDServ adds new PSAd to PSDir and acknowledges with Probe Response including new PSSum • Any STA can query PDServ to get complete PSAd for service of interest: • Unicast Probe request to PDServ during PDWin includes Service Info for service of interest. • PDServ responds with Probe Response which includes all PSAds whose Service Info matches the one in Probe Request. • PDServ stays awake for all beacons, ATIMs and PDWins, and can sleep at other times. • PDServ “steals” beacon transmission from other IBSS members by transmitting beacon without random back off. • Other advertising STAs stay awake for beacon and ATIM coincident with PDWin, and can sleep at other times. –Very power efficient Joe Kwak, InterDigital

14. P2P PAD Design Approach—Server Mode -PDServ Role Transition to next STA in list • During Group Server Transition, current server (STAx) transmits PSDir to next target STA (STAy) in directory list. If STAy does not respond, STAy’s PSAd is deleted from directory and STAx attempts transition to STAz, the next STA in PSDir listing of ads. • This process ages out advertising STAs which are no longer in range. • RTS/CTS is used for transmission of transition request which includes PSDir Joe Kwak, InterDigital

15. P2P PAD Design Approach—Peer Service Access • When a STA finds a peer offering a service of interest, the STA may establish a connection with that peer by: • In Individual Mode of PDisc without IBSS beacons: • STA transmits unicast Probe Request to peer STA. Probe request includes PSAd from STA with a Service Info field matching the advertised service from peer. • Probe response from peer may provide additional connection information. • Connection established per needs of service application. • In Individual Mode of PDisc with IBSS beacons: • STA transmits ATIM to peer during next ATIM window following beacon. • Then follows with probe request and steps defined above. • In Server Mode of PDisc: • STA waits until next PDWin and transmits ATIM to peer during the ATIM window following beacon. • Then follows with probe request and steps defined above. • P2P authentication and connection security is application specific and out of scope for 11aq draft. Joe Kwak, InterDigital

16. Summary of Proposed P2P Discovery Framework • Designate single channel per band for P2P discovery • Define Peer Service Advertisement IE (PSAd) describing service and service provider. • INDIVIDUAL MODE: • Use Probe Request/Response to broadcast PSAds and solicit response • Use IBSS beacons to broadcast PSAds, response in Probe Request • SERVER MODE: • Designate STA as server to aggregate PSAds and broadcast Service Summary in IBSS beacons. • Periodic Peer Discovery Window is used to access Server for PSAd information using request/response , and to access peers for service. • Server collects new PSAds from STAs and deletes PSAds from STAs no longer in range. • Server role transitions to next STA in list of PSAds at end of service period. Joe Kwak, InterDigital

17. Open Issues • Decision on design and content of Peer Service Ad is very important. Service description format should be flexible and extensible to describe current and future services. • Will need to survey existing discovery standards for service descriptions and possibly reuse already standardized description. • Message/IE format for server queries should likewise be flexible and extensible. • All discovery timing should use variable parameters for various scaling points, e.g. beacons/PDWin, PDWins/server-transition. Default parameters need to be selected. Joe Kwak, InterDigital

18. Conclusions • P2P Discovery for peer services complements BSS discovery for network selection. • Simple P2P Discovery framework designed to be low power IBSS service which can scale to serve large crowds of mobile users. • IBSS probe request/response used with or without IBSS beacons to broadcast Peer Service Ads. • IBSS concept of sharing beacon transmission is extended to provide server access to aggregated Peer Service Ads. • Simple framework will be used to draft straightforward specification text for 11aq amendment. • InterDigital welcomes collaboration with others on this task. Joe Kwak, InterDigital

19. Discussion and Questions Thank you. Joe Kwak, InterDigital