Network Discovery Considerations

1. Network DiscoveryConsiderations • Date: 2012-01-17 Authors: HTC

2. Abstract • This document proposes an idea about Network Discovery which can help achieve the goal of FILS • The proposal is more suitable for Smartphones/Tablets which have other communication interfaces in addition to Wi-Fi • The resulted Wi-Fi connection can help cellular traffic offloading and reduce user intervention HTC

3. Conformance w/ TGai PAR & 5C HTC

4. Jan 2012 User wishing to retrieve contents via Wi-Fi … • Successfully connect to Internet • Safely connect to Internet • Easily connect to Internet • Better UI to direct user • Clear directions and fewer steps • Quicklyconnect to Internet • Automatically (eliminate human intervention) • Lengthy network association • Waste of time, battery power, radio resource, expense • Could be error-prone and confusing to general users • Lead to user experience frustrationand loss of chance for Business/Service matching Slide 4 HTC

5. Background • FILS can be hindered by the following (11/1523) • Excessive air link traffic generated by active scan • A probe request generating several probe responses from different APs • Passive scan requires waiting for the next beacon • Scanning multiple channels before converging on the channel ofthe required AP HTC

6. Jan 2012 Background • Why so much overhead?Total stranger assumed • Only if SSID is recorded and no captive portal is required can avoid user intervention for initial link setup • Conventional idea: AP discovery → Network discovery • AP discovery using Wildcard SSID • Anybody here? • (Long) Beacon • Various capabilities in AP part • Flexibility on channel selection • Operating channel is unknown and may be subject to change • Have to determine a BSS to join after reviewing multiple BSSs with intersecting coverage and have to speak one after another • Network discovery if 11u is supported • Focus on merging these processesand reducing redundancy Slide 6 HTC

7. Jan 2012 Discovery requirements (11/1548r0) • Pre-association messages should provide just enough information to ensure that a particular service/application will work • No need to provide all capabilities or any negotiation • Action frame based discovery should have clear back-off rules to prevent flooding • Define format for a list of APs: • Identifying information for AP • Location, Band, etc • Discovery should be focused on: • Authentication domain or similar construct • Required services Slide 7 HTC

8. Jan 2012 Characteristics of Smartphone/Tablet • Mobility • Battery powered • Limited band supporting • Multiple communications options • Often GPS included or can obtain approximate location info via alternative methods like cellular network [1] • The quality of uplink is weaker than downlink • Multiple Internet applications in addition to web browser • Certain services are subscribed • Usually “smarter” than Layer-2/Layer-3 device such as AP Slide 8 HTC

9. Jan 2012 Introduction • Key principles followed in this contribution: • Idea: I am here, so what network/serviceis availablefor me? • Conventional: What AP can I found now? (no matter where I am) • Network discovery prior to AP discovery • The existence of BSS does not necessarily imply the availability of going online • Use of location information • Help determine if there is available network in this neighborhood • Subscribed/free network database required HTC

10. Jan 2012 Proposal • User has subscribed some network services cooperating with WiFi services or free WiFi is available • Should have a mechanism and format tospecify a set of subscribed/available networks of the user • An exchange mechanism of the above info • Location-based Network (Entrance) Discovery • Look for the database for locations of BSSs • Online or offline (pre-acquired) • Obtain local special offers or temporary network unavailability announcement • Many popular applications also utilize location info so it is useful for the MID to know its location with reasonable update period Slide 10 HTC

11. Jan 2012 Proposal • Required info to join a network • SSID (BSSIDs, SSIDs, HESSIDs, Venues) • Roaming consortium ID/ Free public WiFi • Operating Channel • Security parameters (credentials) • Capabilities • Optional/Optimization • BSS Loading info • BSS Coverage info • Service range should take uplink limitations into consideration Slide 11 HTC

12. Jan 2012 Proposal • Trigger network joining process when Applications (Email, Social network, Weather, …) are launched • Determine device location • Determine suitable BSSs based on subscribed/free service provided in current location • Preloaded/loaded-upon-request list of usable SSIDs • Perform authentication and association • Bring up captive portal if necessary • Reduce human intervention as much as possible Slide 12 HTC

13. Jan 2012 Things to do and concerns • Requirement for the connection manager • List/format of available SSIDs/BSSIDs in current venue • The association/authentication/IP configuration • Forms of preassociation: based on location/subscription/application • Network unavailability notifications/reports • Positioning • Level of Accurateness • Privacy • Security • Necessity of multi-layer encryption (necessary in open/free hotspot) • The credentials should be protected since the actions are intended to be automated without human intervention • Access notification/confirmation/approval (double-check) • Backward compatibility • Unified log-in info and process are preferable but seems not feasible now Slide 13 HTC

14. Reference • OMA SUPL (Secure User Plane Location) V2.0 • 11/1523, Access Delay Reduction for FILS: Network Discovery & Access congestion Improvements • 11/1548, TGai Discovery Proposal Slide 14 HTC

15. Jan 2012 Questions and Comments? Slide 15 HTC