shanghai breakout: mobile devices and wi-fi

Mobile Devices and Wi-Fi

Peter Thornycroft

December 2014

CONFIDENTIAL

© Copyright 2014. Aruba Networks, Inc.

All rights reserved2 #AirheadsConf

Agenda

The commercial value chain

Consumer device reference models

Battery life

QoS

Location

5GHz and DFS channels

Authentication & Passpoint

Handover behavior

Bluetooth Low Energy

3CONFIDENTIAL


All rights reserved#AirheadsConf

Commercial models

• What we see:

– The chain leads to the

cellular operator and

consumer

• What we want to see:

– Some recognition for the

enterprise user

– … and it’s happening!Consumers (your typical Gen-Y) who

don’t care too much about Wi-Fi

performance at work

Chip vendor incorporates driver, is

really responsible for Wi-Fi

functionality, selling to …

Phone / device vendor who has cost

constraints, won’t waste time on

features not of interest to its biggest

customers who are…

Cellular Operators, for whom Wi-Fi

is a minority interest in the first place

and anyway sell to …

Mobile OS

vendor does

some

influencing

4CONFIDENTIAL



WLANs differ from home APs

Home AP reference model

A single AP, not doing much of interest

WLAN reference model

Many, APs with same SSID and coordinated,

seamless handover (no DHCP, common

authentication etc.)

- No point in looking for other APs because

there (usually) aren’t any

- Established (~correct) behavior is to hang

onto the AP until the signal is very weak,

then switch to cellular data if available

- There is (almost) always a ‘better’ AP

- But the device needs to scan (or use neighbor

report) to be aware of the ‘better’ AP.

Benefits of good WLAN client behavior…

- Devices get higher rates

- Other devices get more airtime, better network

capacity

- Less time on the air - better battery life

- Less mutual (co-channel) interference

Same effects are seen in public places, hot zones – ‘always best connected’ activity in Hotspot 2.0 ph3 groups.

5CONFIDENTIAL



Network reference models

• What we see:

– One dual-band home AP

– “give me battery life, and

keep me connected”


– Option for multiple-AP WLAN

– … and Apple is acting:

The current model is the single-AP home network. In this

framework, the best thing is to hold onto your AP until the

signal is too weak to work, then hope you can switch to cellular

data. Probe requests are a waste of battery life because there’s

only one AP.

We want to see either a dual-model or a more flexible

architecture. Maybe sense that there are other APs in the same

system (spot the neighbor report?) and flip to a multi-AP

algorithm.

Under a multiple-AP network, there is always a really-good

signal (except at the edge). It’s just a question of probing

more often to find the better APs.

But it’s difficult to move device, OS and chip vendors away

from their well-established model. They are wary of breaking

what has taken several years to ‘perfect’.

We’ll also see that consumer APs still don’t offer the advanced

features we incorporated some years ago.

6CONFIDENTIAL



Power Save Modes

sleeping

time

beaconDTIM

Traffic for

you

give sleeping

WMM-PS

beaconDTIM

pkt

Traditional Power-Save

U-APSD (WMM-PS)

pkt

pkt

pkt

pkt

pkt

pkt

pkt

pkt pkt

pkt

buffered

time

DTIM

7CONFIDENTIAL



Battery life

• What we see:

– Minimum possible probing


– More probe requests in

WLAN

– Using 11k reports

– U-APSD within a beacon

interval

Mobile devices are usually unaware of better AP signals

because they don’t probe enough.

They don’t probe enough because of an over-zealous focus on

battery life, and a model that has only one AP.

Sometimes when a device has an ‘acceptable’ signal it stops

probing altogether. Later, when it starts to move, it may not re-

enable probing until too late to maintain the connection.

In fact, Wi-Fi accounts for less battery consumption than the

cellular subsystem, and far less than the display or CPU

processing app tasks and GPU.

So our focus is on showing device vendors they can ‘go

passive’… only using the 802.11 radio in receive mode.

‘WFA Voice-Enterprise light’, or a collection of features that

enable the device to be multi-AP-aware without reducing

battery life.

8CONFIDENTIAL



The mystery of missing smartphone QoS

Android

App Code

(QoS – unaware coder)

Driver & microcode

Multi-level QoS

priority API

(that’s OK)

Parrots the driver

API (that’s not OK)

Can’t spell QoS

anyway so it’s

inconsequential

Wi-Fi air interface

• QoS priority (~WMM)is there if

app developers want to use it

• But… it’s not documented And

anyway… app developers are

not QoS-aware– Socket.setTrafficClass(int value) IPTos

• The OS has a hard time figuring out

the QoS Pri required by each app…

• Thus WMM priority is seldom used in

mobile device apps

Same observations apply to WMM-PS (U-APSD) for intra-beacon power save.

9CONFIDENTIAL



QoS

• What we see:

– WMM functionality exists in

mobile device OS

– But APIs are arcane

– No documentation or

promotion


– Better API support

– Developer guidelines

WMM QoS is enabled through the OS to the chip/driver.

But to invoke a high-priority connection, the app developer

must add some parameters to the commands that open sockets .

App developers are unaware of the need to apply Wi-Fi QoS,

and/or are not informed of the required APIs, and/or are not

technically capable of understanding that aspect of app

programming.

This includes developers of voice and video apps including

those in vertically-integrated companies.

10CONFIDENTIAL



Location (distance) enhancements

RTT “Round-Trip-Time”

A standard (actually two standards

and several proprietary variants)

“802.11k”

Location Track Notification,

Modified (to finer timestamps) in

“802.11mc”

Fine Timing Measurements

Distance Calculations

Measure

with me!

Now

here are

my times

t1, t4

OK, here

t1

t3

t4

t2

Challenges:

- Need to combine/average several

frames to get a good reading.

- Averaging many frames affects

battery life, network capacity

Challenges:

- Measuring to nanoseconds

(speed of light: 1 ft per nsec)

- Setting up circuitry to

timestamp the right frame

- Calibration for time frame

leaves (arrives) at the antenna

Once all four timestamps are in one

place, subtraction and /2 gives time-

of-flight and multiply-by-speed-of-

light gives distance

Got

it

Implementation

In mobile device Wi-Fi chips late

2014 (Android 5.0 ‘private API’)

In access points 2015

No Wi-Fi Alliance certification till

2016 >> may cause interoperability

teething troubles

Accuracy should be 1 – 5 metres,

depending on the number of frames

averaged & underlying hardware

Most useful in line-of-sight, but

better accuracy at longer distances

than RSSI

Many variations possible with

WLAN topologies

d = ((t4 – t1) – (t3 – t2)) * c / 2

11CONFIDENTIAL



Location

• What we see:

– RSSI reports


– RTT support

– Raw data for RTT, RSSI

Location and location-based-services have attracted the

attention of many commercial and technical principals across

the industry.

Current development is focused on time-based distance

(mostly Round-Trip-Time) measurements:

- 802.11mc Fine Timing Measurement

- Wi-Fi Alliance Wireless Network Management ++

- In-Location Alliance

Look for RTT announcements and features over the next 12

months.

There is a significant danger that this location technology

reverts to proprietary, closed islands rather than developing

along open, standard APIs.

For example:

- Will raw data be available via OS API calls, or mysteriously

processed within the chip/driver or OS itself?

- Will devices built on different chip families interoperate for

RTT location?

12CONFIDENTIAL



DFS channels – useful at last!

How many radar triggers?

frequency

insallations

0 / year 5 / hour

Usually none, but in some places

> comfortable

Devices supporting DFS

Apple > 2 years

Intel > 2 years

Samsung > 1 year

Others getting there

Most

WLANs

A few

Special concerns

No active client scanning in DFS

bands because they don’t passive-

scan for radar

- slow AP acquisition

- fixed (eventually) by neighbor

report

5GHz Channel count

13 20MHz channels, no DFS

22 20MHz channels including DFS

Channel strategy

Dot them around?

Use the spectrum!

13CONFIDENTIAL



5GHz band

• What we see:

– Beginning to favor 5GHz

over 2.4

– Spreading DFS support


– Overweight 5GHz bias

– 100% DFS support

About 18 months ago Apple supposedly reversed from

unconditionally preferring 2.4GHz to favoring 5GHz.

Unfortunately the battery-saving imperative (see earlier) means

that when a device has an acceptable signal from its AP, it will

stop scanning for a better one. Especially scanning in other

bands.

This can cause difficulties when the WLAN seeks to move a

device to a different band: it may refuse to scan the alternate

band.

DFS support is improving, now available on all Apple devices

(since iPhone 4S) and many Android (since early 2013: e.g.

Samsung Note, Galaxy S4).

We believe this is a good time to start deploying DFS channels.

14CONFIDENTIAL



Passpoint

Identify a hotspot with

Internet reachability and

friendly authentication

Pre-association discovery

What

have you

got?

T-Mobile

BT

Comcast

Orange…

- Pre-association

- New GAS/ANQP protocol

- Lists service providers

- Acceptable authentication

Authenticate to home SP

T-Mobile BTOrange

Accuris

Aicent

BSG…

Hub

(settlement)

RADIUS

e.g. DIAMETER

WPA2 Options

- EAP-TLS

- EAP-TTLS

- EAP-SIM

- EAP-AKA(‘)

Make a list of available

options, decide which to use

Prioritise account options

T-Mobile home (have SIM)

BT visiting (have pwd)

Orange visiting (have pwd)

Comcast visiting (have cert)

Home AP (not Passpoint)

Local (not Passpoint) hotspot

SPs, phone designers all want a

say

- Distinction between ‘home’

and ‘visiting’ hotspot

- May have different tariffs

- Policy for time-of-day,

location…

ANDSF is a cellular protocol that can pass policy to the device to help it make offload decisions.

Passpoint phase 2 introduces se mi-automatic online sign-up and policy services.

T-Mobile SIM

15CONFIDENTIAL



Authentication

• What we see:

– Beginning to support HS2.0

(Passpoint)


– Passpoint with EAP-SIM

everywhere

– SPs supporting Passpoint

Passpoint (Hotspot 2.0, from 802.11u) was released as a WFA

certification in June 2012.

For the following 12 months, while SP and enterprise WLAN

equipment supported Passpoint, you could not purchase a

commercial device that was compliant.

That has changed in the last 6 months (iOS7, Samsung Galaxy

S4). Now, we realize that no SP has deployed a network with

standard HS2.0 support.

Why not?

- Actually, NTT has…

- AT&T stayed proprietary

- Cellular operators (see commercial chain above) have no

incentive to allow others (MSOs) to steal their customers

- The enterprise WLAN vendors are waiting for wider

availability

But it’s time!

Public facing vendors should take AOS 6.4, contact a hub

vendor, fire it up and advertise support.

16CONFIDENTIAL



Current handover narrative

A

Good signal, this is dandy!

Time / distance

0 sec

Signal Strength

17CONFIDENTIAL




A


OMG, the signal is getting

really low!

Time / distance

0 sec ~30 sec

Signal Strength

18CONFIDENTIAL




A



really low!

SOS, sending 10 probe

requests on 3 channels

Time / distance

0 sec ~30 sec 35 sec 38 sec

Signal Strength

19CONFIDENTIAL




A

B

C D

E



really low!



Wowza, responses from 20

APs, how to choose?

Time / distance

0 sec ~30 sec 35 sec 38 sec

Signal Strength

20CONFIDENTIAL




A

B

C D

E



really low!



Wowza, responses from 20

APs, how to choose?

Let’s reauthenticate with

this one!

Time / distance

0 sec ~30 sec 35 sec 38 sec 40 sec reauthentication request

40.2 sec reauthenticated

Signal Strength

21CONFIDENTIAL



‘Good’ handovers captured

22CONFIDENTIAL



Sticky smartphone

23CONFIDENTIAL



Typical smartphone

24CONFIDENTIAL



Aruba Utilitieson Nexus 7

25CONFIDENTIAL



802.11 k, v, r

• Many features, most important are:

• Neighbor report from AP to client (802.11k)

• Channel report from AP to client (802.11k)

• Beacon report from client to AP (802.11k)

• BSS Transition Management from AP to client (802.11v)

• Fast Transition by client (802.11r)

• (All rolled up in 802.11-2012, 2014)

26CONFIDENTIAL



802.11r fast BSS transition

C D

R0 key

C

802.1X

authenticator

R0 key

S0 key

S1 key

PTK

Initial Authentication

establishes level 0 keyWLAN distributes

level 1 keys

R1 key

C D

On reassociation,

client presents level

1 key to new AP

R1 key

PTK

S0 key

S1 key

PTK

Mobility domain: A group of

APs covered by a level 0

keyholder

Over-the-air reassociation

widely adopted, over-the-DS

reassociation (via the current

AP) not used

Key suite includes:

Level 0 key (derived at initial authentication,

never exposed OTA)

Level 1 key (per-AP keys) used to derive…

Pairwise temporal keys (to encrypt

communication)

PTK

R1 key

Differences between FT and OKC? … Not much

keyscope keyscope

27CONFIDENTIAL



802.11k, v, r features

B

C D

E

Neighbor report

AP chan secy key beacon

scope offset

B 6 WPA2 0 45

D 52 WPA2 0 12

E 161 WPA2 0 74

Information about other APs to help

with handover candidate discovery

C

Beacon report

Client reports how it hears (RSSI)

the beacons of other APs

BSSID RSSI

AP B -65

AP D -72

AP E -65

C

BSS Transition Management

AP instructs client to move to

another AP

Move to AP D…

E

DB

D

C

Channel report

AP informs client of channels used

by the WLAN

Channel

6

52

161

Overlaps with neighbor report

28CONFIDENTIAL



802.11k Neighbor report

• Advertised by AP in the beacon (for all clients, non-

associated) and sent solicited per-client

• List of ‘neighbor’ APs with same SSID includes:

– BSSID

– Channel

– Beacon time offset

– PHY type

– QoS capability

– ‘Key scope’ for common authenticator

• 802.11 does not require neighbor list to be cropped or

ordered or modified per-client (but infrastructure may do so)

• Eliminates the need for active probe request-response

scanning

29CONFIDENTIAL



The evils of active scanning

• Takes time

– Need to probe on each selected channel in turn, wait ‘reasonable’ interval for responses

– Need to return to current channel for beacon (DTIM)

• Inaccurate results

– RSSI of a single probe response varies ~ +/- 6dB from ‘average’

– Some APs will miss probe requests, or responses are lost

– If the device returns to current channel after ~15msec, sometimes misses responses

• Consumes power

– Typical pattern is to send 2 probe requests per channel, stay awake ~15–20msec

– Each probe request generates ~6 probe responses in a ‘typical’ WLAN

– Each probe response needs an ack

• Consumes airtime, affecting others’ performance

– Frames are sent at low rates, probe responses are retried

30CONFIDENTIAL



Better handover performance with ‘11k’

Current handover sequence:

1. Figure out it’s time to scan

2. Figure out channels to scan

3. Send probe requests, get responses

4. Identify best AP

5. Reauthenticate to new AP

802.11k handover sequence:

1. Periodically request neighbor report

2. Passive scan for neighbor beacons

3. Note if a neighbor AP is ‘better’

4. Reauthenticate to new AP

Probe requests & responses

Signal strength

Time, distance

Signal strength

Time, distance

Behavior c 1999 Behavior c 2013

Signal strength

Time, distanceNeighbor reports & passive scanning

Behavior c 2014 ?

31CONFIDENTIAL



Signal Strength

Proper ‘11k’ handover narrative

A


Time / distance

0 sec

32CONFIDENTIAL



B

C

D

Signal Strength


A

B

C D

E


Check neighbor report

every ~10sec

Identify ‘best’ AP and check

for beacon (passive scan)

Time / distance

0 sec ~10 sec 20 sec 30 secB

C

C

D

33CONFIDENTIAL



Signal Strength


A

B

C D

E



every ~10sec



Signal is low, but I have

already identified the best AP

Time / distance

0 sec ~10 sec 20 sec 30 secB

CB

C

D

C

D

34CONFIDENTIAL



B

CB

C

D

C

D

D

C

Signal Strength


A

B

C D

E



every ~10sec



Signal is low, but I have

already identified the best AP

Reauthenticate

Time / distance

0 sec ~10 sec 20 sec 30 sec 30 sec reauthentication request

30.2 sec reauthenticated

35CONFIDENTIAL



Client Match

Client Match forms a virtual Beacon Report:

1. APs measure RSSI from client

2. APs receive beacon reports from the

client

3. Estimate the ‘best’ AP

4. If client is _far_ from ‘best’ AP…

5. Redirect (force handover) to ‘best’

AP

B

C D

E

A

track

-50

-60

-70

-80

AB E

Signal strength

distance

36CONFIDENTIAL



Galaxy Nexus with AU app

37CONFIDENTIAL



Nexus7 with AU app

38CONFIDENTIAL



Samsung GS4 with AU app

39CONFIDENTIAL



All together

Galaxy Nexus

Nexus 7

Galaxy S4

40CONFIDENTIAL



Again…

Galaxy Nexus

Galaxy S4

Nexus 7

41CONFIDENTIAL



If 11k, why Client Match ?

• ‘11k’ makes information available to the client

– Neighboring APs, channels, beacon offsets…

• ‘11k’ cannot confirm that the client receives information or how it prioritises

the information

– Neighbor report information may not be used

• Transmitting (or receiving) ‘11k’ does not guarantee that the client will act on

the information

– Handover decisions may not be improved

• Client Match uses information from the infrastructure and the client (if

supports beacon reports)

– The infra knows more about the client’s situation than the client does

• Client Match completes the task by forcing a handover

42CONFIDENTIAL



Handover

• What we see:

– Not much


– More probe requests when

in WLAN

– Or… use passive 11k

reports

– Reauthenticate with

802.11r or OKC

Most people think inter-AP handovers take ~1second.

In fact, inter-AP handovers take 30msec, or 250msec, or 7sec

depending on the syndrome.

7sec outages occur when a device (not probing) does not

realize until too late that the signal from its serving AP is

dropping fast. By the time it starts to probe, it has lost the AP

and has to go into cold-start mode. More frequent probes (or

using passive measures as above) would eliminate 7 sec

outages.

Full WPA2 MSCHAPv2 re-authentication takes 200-250msec

to exchange ~50 frames (including acks). This is a stable

figure in the absence of very weak signals due to poor choice

of target AP (mobile devices usually make good AP choices

when aware of their environment through probing). This

outage will be barely noticeable to the user.

But faster re-authentication is possible, through old-school

OKC (from 802.11i) or 802.11r (now available on iPad).

… The ‘bad’ handover syndrome can be solved if the mobile

device is more aware of its surroundings (neighbor report) or

responds to BSS transition management frames (directed

handover from the AP).

43CONFIDENTIAL



Aruba Utilities shows behaviour

• What we see:

– Frequent long outages

around handover events


– More awareness of

environment

– Faster reaction to losing

signal

Aruba Utilities shows very graphically what goes on

when a mobile device moves around an enterprise

WLAN.

CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

iBeacon deployment model for navigation

UUID: Aruba

Major: 1000

Minor: 501

UUID: Aruba

Major: 1000

Minor: 502

UUID: Aruba

Major: 1000

Minor: 509

UUID: Aruba

Major: 1000

Minor: 503

-66

-68

-76

-82


Bluetooth Low Energy overview

• BLE is also known as Bluetooth Smart, Bluetooth 4.0

• Evolution of the existing Bluetooth standard (2010)

• Focus on ultra-low power consumption (battery powered devices)

• Differences

– Efficient discovery / connection mechanism

– Very short packets

– Asymmetric design for peripherals

– Client server architecture

– Fixed advertising channels designed around WiFi channels

– Not compatible with older Bluetooth

• Most new devices support both ‘classic’ Bluetooth and BLE (“Bluetooth Smart Ready”)

– iPhone 4S+, current (2013) iPad, Samsung Galaxy S4+, Nexus 7+


Bluetooth Low Energy & iBeacon

• Bluetooth– Very low-power consumption: years of life from a button cell

– Advertises… ‘beacons’

– Allows scanning for ‘peripherals’

– Allows ‘central’ devices to discover ‘peripherals’

– Two-way communication channel to read/write values

• iBeacon– A subset of BLE, just the ‘advertising’ function with special fields

– Allows a background app to be alerted on proximity

– No explicit location information in an iBeacon, just a reference ID


Spectrum for iBeacons & BLE

6 11

2412 2437 246224222402 2427 2447 2452 2472

1

2400 2483.5

Ch 37

(2402 MHz)

Ch 38

(2426MHz)Ch 39

(2480MHz)

Wi-Fi

Bluetooth Low Energy Advertisement (iBeacon)

2 MHz channels

Gaussian Frequency Shift Keying

0.5 modulation index

1 Msymbol/second rate

1 Mbps data rate

~250 kbps application throughput

(in connection mode)

Advertisements are one-way transmissions

An advertisement can be sent on any/all of the

3 designated channels

Advertisements are repeated every 20 – 10000

msec (500msec typ)

Tx power ~ 0 dBm ( ~ 2 year battery life typ)

Apple specifications for iBeacons are more

constrained (but not widely followed)


BLE Advertisement and iBeacon

Preamble

1

Advertiser

4

PDU

2 - 39

CRC

3

MAC address

6

Header

2

Data

1 - 31

iBeacon Prefix

9

Proximity UUID

16

Major

2

8E89BED6

0201061AFF4C000215

Minor

2

size, type.. e.g. 112233445566

e.g. 4152554e-f99b-86d0-947070693a78 e.g. 4159 e.g. 27341

BLE Advertisement Frame

BLE Advertisement Payload

iBeacon Data

Measured Tx Pwr

2

e.g. -59

iBeacon information

RSSI Measured by receiver

MAC From BLE header

Proximity UUID (can be) company reference

Major, Minor Integer values identifying the

tag and/or zone

Measured Tx Pwr Calibrated power at 1m from

the iBeacon (dBm)


RSSI vs distance (iBeacon)

-100

-95

-90

-85

-80

-75

-70

-65

-60

-55

-50

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

iBeacon RSSI (dBm) vs distance (m), line of sight

GS4 with iBeacon 100 GS4 with iBeacon 101 Nexus 7 with iBeacon 100 Nexus 7 with iBeacon 101

iBeacon Tx power 0dBm

‘measured power’ -61dBm @ 1 m


RSSI vs distance (iBeacon)

-90

-85

-80

-75

-70

-65

-60

-55

-50

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

iBeacon RSSI (dBm) vs distance (m), line of sight (RSSI averaged over 5 readings)

GS4 with iBeacon 100 GS4 with iBeacon 101 Nexus 7 with iBeacon 100 Nexus 7 with iBeacon 101 grand average


Why iBeacons matter on iDevices

• The iOS app lifecycle puts an app on ice when

not in foreground. How to wake up on

proximity to a particular location?

– iOS maintains BLE in always-listening mode

– If the app registers for a UUID, iOS will awaken it

when that UUID is seen

– Event is a ‘region entry/exit’

– iBeacon background detection can take minutes

• Even in foreground, iOS will only return data

on known, specified UUIDs

– ‘Ranging mode’ in foreground gives RSSI every ~

1 second

• Android makes for a much more flexible

iBeacon hunter

iOS

Mobile App

BLE radio

BLE air interface

Register for < 20

UUIDs

Continuously

scanning for

iBeacons

Woken from

background

when UUID

heard

Database of UUID-

Major-Minor to

locations (part of

the app server)


Use cases

Indoor location

– Beacons are placed throughout the building in such a way that each location is covered by at least 3 beacons

– The mobile apps will look for nearby beacons, get beacon locations from the cloud and calculate location locally

– Examples – any public venue with navigation apps: airports, casinos, stadiums

Proximity

– Beacons are placed nearby exhibits or points of interest

– Mobile apps discover beacon context from the cloud and impart interesting information

– Examples – museums, self-guided tours, door opening, forgot keys


iBeacon hunting with Android


Wi-Fi Calling Architecture

New in iOS8, but an old model – UMA at T-Mobile, Rogers, Orange since 2007, FMC at Agito-ShoreTel

Not compatible with UMA, SIP-voice rather than GSM

Carrier core network

SIP

termination

SIP

LTEWi-Fi

Internet

Wi-Fi LTE


iOS incorporates 802.11k and 802.11r features

New support note “iOS8 wireless roaming reference” http://support.apple.com/en-us/HT203068

New support note “Wi-Fi network roaming with 802.11k and 802.11r” http://support.apple.com/en-us/HT202628

– 11k neighbor report

– 11r fast BSS transition

– (11v BSS transition management)

– Key figures:

• Roaming trigger threshold -70 dBm (measured by the device)

• Reads the first 6 entries in the neighbor report to restrict scanning

• If active traffic, a new AP must be >8 dB better for the device to move

• If no active traffic, a new AP must be >12 dB better

http://support.apple.com/en-us/HT203068

http://support.apple.com/en-us/HT202628

shanghai breakout: mobile devices and wi-fi

Technology