SlideShare a Scribd company logo
1 of 166
Download to read offline
Android WiFi Direct
& Performance Measurement
Ph.D. HayoungYoon
hyyoon@zvolti.com
R&D Lead
zVolti LLC.
July., 2015
Present to Hyundai NGV
About Me
Experience
2
HayoungYoon (윤하영)
zVolti
Co-Founder & R&D Lead (2013~)
WiFi Test Automation
ITEC-Tokyo (Tokyo, Japan)
Manager (2012~2013)
WiFi P2P Data Sharing Solution
I2R (Institute for Infocomm Research)
(Singapore)
Intern (2010)
Peer-based Multimedia Distribution System
National ICT Australia (Sydney,Australia)
Intern (2009)

Mobility Emulation for Wireless P2P App.
Experiments
Deutsche Telekom T-Labs (Berlin, Germany)
Intern (2006)

P2P Service Framework over WiFi network
Education
Gwangju Institute of
Science and Technology (GIST)
Ph. D., Information & Communications (2011)

Master, Information & Communications (2006)
Korean Aerospace University
Bachelor, Telecom. & Info. Engineering (2004)
COMPANY
zVolti
Seoul, Korea
Saratoga, CA
Founded
Feb, 2013
Product & Service
ZESTER

Wi-Fi/BT Test Automation Solution
Wi-Fi/BT Product QA Consulting
Partners
Samsung Mobile Comm.
Broadcom Wireless Connectivity
Samsung System LSI
WiFi Direct Overview: Discovery
• It’s not totally NEW connection methodology
• 802.11-based access, security and association management
• WiFi Direct sits on top of WiFi (MAC/PHY)
S
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
DS
DLS
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
ith miDLS
• Switching only if local outgoing queues
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migr
to other channel for short time and
comeback
• No additional H/W support by both t
network interface card (NIC) and the
• Average switching duration in MadWiF
based implementation < 20ms
CHA
HB
DS
with miDLS
Original
• Switching only if
both are empty
• Not to loose
• We propose and
support two mo
to other channe
comeback
• No additional H/
network interfac
• Average switchin
based implement
CHA CHA
CHB
DS
with iDLS
Original
• Localized commun
• Consumes double
infrastructure mod
• Possible solutions
• IEEE 802.11e DLS
• H/W change nee
• Can’t initiate DL
• We propose iDLS
• S/W change at end
• Can initiate DL acr
DS
with miDLS
Original
• S
b
•
• W
s
t
c
• N
n
• A
b
CHA CHA
CHB
scanscan scanscan
p2p scan
Legacy
WiFi
WiFi
Direct
3
Discover Non-AP P2P STA
• In scan phase, a Probe. Req is transmitted all supported channels
• In search phase, a Probe. Req is transmitted only to social channels
(CH#1, CH#6, CH#11)
• Q: How to find GO established in 5GHz band?
DS • Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
DS
with miDLS
• No
• We pr
suppo
to oth
comeb
• No ad
netwo
• Averag
based
CHA CHA
CHB
Listen Search or Scan
P2PWildcard SSID
P2P IE
Wildcasrd BSSID
Probe Req.
Probe Resp.
WPS/RSN/SR IE
P2PWildcard SSID
P2P IE
Wildcasrd BSSID
WPS/RSN/SR IE
Broadcast or Unicast
Unicast
4
WiFi Direct Overview: ConnectionS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
DS
DLS
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
ith miDLS
• Switching only if local outgoing queues
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migr
to other channel for short time and
comeback
• No additional H/W support by both t
network interface card (NIC) and the
• Average switching duration in MadWiF
based implementation < 20ms
CHA
HB
DS
with miDLS
Original
• Switching only if
both are empty
• Not to loose
• We propose and
support two mo
to other channe
comeback
• No additional H/
network interfac
• Average switchin
based implement
CHA CHA
CHB
DS
with iDLS
Original
• Localized commun
• Consumes double
infrastructure mod
• Possible solutions
• IEEE 802.11e DLS
• H/W change nee
• Can’t initiate DL
• We propose iDLS
• S/W change at end
• Can initiate DL acr
DS
with miDLS
Original
• S
b
•
• W
s
t
c
• N
n
• A
b
CHA CHA
CHB
connectconnect connectconnect
p2p connect
Legacy
WiFi
WiFi
Direct
GO GC
WiFi WiFi Direct
Security WEP/WPA1.0/WPA2.0/”NULL” WPA2.0
Connection OPEN/WPS/WPS2.0 WPS1.0/WPS2.0
PHY 802.11abgn/ac 802.11agn/ac
5
WiFi/WiFi Direct Concurrency(1)
6
S
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
OVi: Direct-Link Communications
DS
iDLS
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
with miDLS
• IEEE 802.11 is designed assuming tha
single CH per BSS
• Switching only if local outgoing queue
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices mig
to other channel for short time and
comeback
• No additional H/W support by both
network interface card (NIC) and th
• Average switching duration in MadW
based implementation < 20ms
CHA
CHB
Single Channel
Concurrent Mode
p2p connect
CH#1
CH#1
~2012/1Q
DS
with miDLS
Original
• IEEE 802.11 i
single CH per
• Switching onl
both are emp
• Not to lo
• We propose
support two
to other chan
comeback
• No additiona
network inte
• Average switc
based implem
CHA CHA
CHB
MOVi: Direct-Link Commu
DS
with iDLS
Original
• Localized comm
• Consumes do
infrastructure
• Possible solutio
• IEEE 802.11e D
• H/W change
• Can’t initiate
• We propose iD
• S/W change at
• Can initiate D
DS
with miDLS
Original
•
•
•
•
•
CHA CHA
CHB
p2p connect
Same-Band Multi-Channel
Concurrent Mode
CH#1
CH#11
~2012/3Q
Time sharing exploiting
802.11 power-saving
WiFi/WiFi Direct Concurrency(2)
7
S
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
OVi: Direct-Link Communications
DS
iDLS
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
with miDLS
• IEEE 802.11 is designed assuming tha
single CH per BSS
• Switching only if local outgoing queue
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices mig
to other channel for short time and
comeback
• No additional H/W support by both
network interface card (NIC) and the
• Average switching duration in MadW
based implementation < 20ms
CHA
CHB
Diff-Band Multi-Channel
Concurrent Mode
p2p connect
CH#36
CH#11
~2013/1Q
MOVi: Direct-Link C
DS
with iDLS
Original
• Loc
• C
in
• Pos
• IE
•
•
• We
• S
• C
DS
with miDLS
Original
• IEEE 802.11 is
single CH per
• Switching only
both are empty
• Not to loo
• We propose an
support two m
to other chann
comeback
• No additional H
network interf
• Average switch
based impleme
CHA CHA
CHB
MOVi: Direct-Link Commu
DS
with iDLS
Original
• Localized commu
• Consumes doub
infrastructure m
• Possible solution
• IEEE 802.11e DL
• H/W change n
• Can’t initiate D
• We propose iDL
• S/W change at e
• Can initiate DL
DS
with miDLS
Original
•
•
•
•
•
CHA CHA
CHB
p2p connect
CH#1
CH#1
1
Diff-Band Multi-Channel
Concurrent Mode - the island
CH#36
2013/1Q~
BT-COEX
WiFi/WiFi Direct Concurrency(3)
8
MOVi: Direct-Link Communications
DS
with iDLS
iginal
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
Vi: Direct-Link Communications
DS
DLS
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
th miDLS
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
HB
p2p connect
CH#1
CH#11
Diff-Band Multi-Channel
Concurrent Mode - the island
CH#36
~2014/1Q
BT-COEX
MOVi: Direct-Link Com
DS
with iDLS
Original
• Localized
• Consum
infrastru
• Possible s
• IEEE 80
• H/W
• Can’
• We prop
• S/W ch
• Can init
Multi-channel iDLS (mi
DS
with miDLS
Original
• IEEE 802.11 is desig
single CH per BSS
• Switching only if loc
both are empty
• Not to loose pa
• We propose and im
support two mobile
to other channel fo
comeback
• No additional H/W
network interface c
• Average switching d
based implementati
CHA CHA
CHB
MOVi: Direct-Link Communic
DS
with iDLS
Original
• Localized communicat
• Consumes double cha
infrastructure mode W
• Possible solutions
• IEEE 802.11e DLS (Dir
• H/W change needed
• Can’t initiate DL acro
• We propose iDLS (int
• S/W change at end-dev
• Can initiate DL across
Multi-channel iDL
DS
with miDLS
Original
• IEEE
sing
• Swit
both
• N
• We
supp
to o
com
• No
netw
• Ave
base
CHA CHA
CHB
p2p connect
CH#
CH#1
CH#3
2014/1Q~
BT/BLE-COEX
Diff-Band Multi-Channel
Concurrent Mode
BT/BLE Coexist
Limited toTime-Division Sharing
WiFi/WiFi Direct Concurrency(4)
9
MOVi: Direct-Link Communications
DS
with iDLS
Original
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
h miDLS
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
HB
MOVi: Direct-Link Communications
DS
with iDLS
Original
• Localized communication with a neighbor
• Consumes double channel resource ion
infrastructure mode WiFi
• Possible solutions
• IEEE 802.11e DLS (Direct-Link Setup)
• H/W change needed at AP
• Can’t initiate DL across BSSs (Basic Service Set)
• We propose iDLS (inter-BSS DLS)
• S/W change at end-devices
• Can initiate DL across BSSs
DS
with miDLS
Original
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA CHA
CHB
p2p connect
CH#
CH#1
CH#3
*2015/1Q~
BT/BLE-COEX
Diff-Band Multi-Channel
Concurrent Mode
BT/BLE Coexist
* 2015 MWC, BRCM - RSDB : http://www.broadcom.com/blog/wireless-technology/rsdb-gets-a-boost-from-broadcom-at-mwc/
Single
BT/WiFi Chip
CH#36
CH#1
1
**As if two 1x1 wifi chip for each band
** None of commercial wifi device implemented this feature so far
Who’s the Driver
GB ICS JB KK
Android Release
Integration to JB
Integrated to
JB/KK
10
Integration to ICS
WiFi Direct Concurrent Mode
WiFi Display
GoogleManufacturer
Manufacturers adopt first Google makes it popular
WiFi TDLS
Integrated to KK
Brief: S/W Dev. on Android
11
Linux Kernel
Native
Android
Framework
Android APP
Android APIs
• Whatever you do with APIs can run most
of Android Devices* and you might be able
to distribute your work via “App Market”
*Target Android DeviceVersion must be greater than APP
Calling APIs
Custom C/C++ Code
JNI
Calling
Custom C/C++ Code
• You may use to build own C/C++ Library if
you
➡ want to optimise the performance with your own
➡ want to access own H/W infrastructure
• If your work requires changes in either the
**standard “Android Framework” or “Linux
Kernel”, your work may only work on your
device
**We are referring AOSP as a standard
WiFi Direct on Android (1)
12
WiFi Device Driver
Native
Android Framework
Android APP
WiFi Chipset
dependent
3rd party
developers
Manufacturer
dependent
Android
OpenSource
WiFi Direct capable device driver
WiFi Direct Daemon
WiFi Direct UI
Ginger Bread
Interface
WiFi
Direct APPsWiFi
Direct APPs
WiFi Direct capable device driver
WiFi Direct Daemon
WiFi
Direct APPs
WiFi Direct APIs
Since IC Sandwich
+ɑ
+ɑ
Android Framework
WiFi
Direct
APP
Hard to Dev.APPs &
Poor inter-operability across
manufacturers
WiFi Direct on Android (2)
13
WiFi Device Driver
Native
Android Framework
Android APP
WifiMonitor
WifiP2pManager
wpa_supplicant
WifiNative
JNI:WifiNative Wifi (wifi.c)
WiFi Driver
WiFi Direct APP
WiFi FW
(P2P/STA)
WifiP2pService
WiFi Direct APPWiFi Direct APP
WiFi FW
(Softap)
Used Selectively
Case Study
14
Case Study: How to Discover WiFi Direct Devices (1)
15
WifiMonitor
WifiP2pManager
WiFi Direct APP
wpa_supplicant
::discoverPeers
via Async Message :
WifiP2pManager.DISCOVER_PEERS
WifiP2pService
JNI:WifiNative
WifiNative ::p2pFind
::doBooleanCommand(P2PFIND)
Wifi (wifi.c)
::doCommand(P2PFIND)
via UNIX_SOCKET by
wpa_cli: P2PFIND
WiFi DR/FW
via ioctl by chipset dependent
kernel/user interface
::startMonitoring
::waitForEvent
WiFi Direct APP
WiFi Direct APP
Case Study: How to Discover WiFi Direct Devices (2)
16
WifiMonitor
WifiP2pManager
WiFi Direct APP
wpa_supplicant
::discoverPeers
via Async Message :
WifiP2pManager.DISCOVER_PEERS
WifiP2pService
JNI:WifiNative
WifiNative ::p2pFind
::doBooleanCommand(P2PFIND)
Wifi (wifi.c)
::doCommand(P2PFIND)
via UNIX_SOCKET by
wpa_cli: P2PFIND
WiFi DR/FW
via ioctl by chipset dependent
kernel/user interface
::startMonitoring
::waitForEvent
WiFi Direct APP
WiFi Direct APP
ANY APP register broadcast listener gets notified the changes of WiFi Direct
PEER-DISCOVERED
::requestPeers
::onPeersAvailable
Case Study: How to Create WiFi Direct Group (1)
17
WifiMonitor
WifiP2pManager
WiFi Direct APP
wpa_supplicant ::connect
(Peer MAC Address)
via Async Message :
WifiP2pManager.CONNECT
WifiP2pService
JNI:WifiNative
WifiNative ::p2pConnect
::doStringCommand(P2PCONNECT)
Wifi (wifi.c)
::doCommand(P2PCONNECT)
via UNIX_SOCKET by
wpa_cli: P2PCONNECT
PEER MAC
WiFi DR/FW
via ioctl by chipset dependent
kernel/user interface
::startMonitoring
::waitForEvent
WiFi Direct APP
WiFi Direct APP
1-to-1 Connection
Case Study: How to Create WiFi Direct Group (2)
18
with miDLS
to other cha
comeback
• No addition
network int
• Average swi
based imple
CHB
th miDLS
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
HB To know whatWPS method available
PROV-DISC-REQ
PROV-DISC-RESP
P2P-GROUP-FROM-REQ
P2P-GROUP-FROM-RESP
wpa_sup.
wpa_sup. Framework
Framework
p2pConnect
Popup to user
INVITATION
RECEIVED
stopP2pFind
p2pConnectUser OK
Standard WiFi Protected
Setup Procedure
Q: Can APP know that
someone has invited me?
P2P-GROUP-NEGO-REQ
P2P-GROUP-NEGO-RESP
Become GO
Start GO
Become GC
P2P-GROUP-NEGO-CONFM
Case Study: How to Create WiFi Direct Group (3)
19
with miDLS
• We propose a
support two m
to other chan
comeback
• No additional
network inter
• Average switc
based implem
CHA CHA
CHB
miDLS
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
wpa_sup.
wpa_sup. Framework
Framework
GROUP-STARTED as GC
L2 Connected
GROUP-STARTED as GO
DHCP
Server
DHCP
Client
Dynamic IP Allocation
L3 Connected
GROUP-STARTED as GC
APP
GROUP-STARTED as GO
APP
Application can talk each other
Case Study: How to Remove WiFi Direct Group
20
with miDLS
to other chan
comeback
• No additional
network inter
• Average switc
based implem
CHB
miDLS
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
wpa_sup.
wpa_sup. Framework
Framework
GROUP-STARTED as GC
L2 Connected
GROUP-STARTED as GC
APP
GROUP-STARTED as GO
GROUP-STARTED as GO
APPDHCP
Server
DHCP
Client
Dynamic IP Allocation
L3 Connected
p2pGroupRemove
Standard 802.11 Disconnect Process
p2pGroupRemove
GROUP-REMOVEDGROUP-REMOVED
GROUP-REMOVED GROUP-REMOVED
DHCP
1. Detect STA disconnect
2. Check if no one connected
p2pFind
p2pFind
starts automatically
starts automatically
Case Study: Persistent P2P Group (1)
21
DS
miDLS
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
P2P Connection Request
Q: Do we really need to bother the driver whenever she want to pair?
A: Use Persistent P2P Group
Case Study: Persistent P2P Group (2)
22
DS
DLS
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
P2P Connection Request (with Persistent Group Indication=true)
L2 Connected Succeed
GOGC
{ - Group SSID
- Key
- Credential
- Type=GO
- Peer-Mac Addr
{- Group SSID
- Credential
- Type=GC
- GO-Mac Addr
Save to local storage
Save to local storage
It’s similar to you don’t need to enter PIN code
to connect you HOMEWiFi Router everyday!
Case Study: Persistent P2P Group (3)
23
DS • Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
P2P Connection Request
(with Persistent Group
Indication=true)
- Group SSID
- Credential
- Type=GC
- GO-Mac Addr
checkup
{
wpa_sup.APP
P2P-INVITATION-REQUEST
{ - Group SSID
- Key
- Credential
- Type=GO
- Peer-Mac Addr
checkup
L2 Connected Succeed
GROUP-STARTED as GC
No Popup Requests
Case Study: Persistent P2P Group (4)
24
DS • Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
P2P Connection Request
(with Persistent Group
Indication=true)
L2 Connected Succeed
wpa_sup.APP
- Group SSID
- Credential
- Type=GC
- GO-Mac Addr
checkup
{
P2P-INVITATION-REQUEST
checkup => false
P2P-INVITATION-REJECT
{
- Group SSID
- Key
- Credential
- Type=GO
- Peer-Mac Addr
Delete
Normal P2P Connection Procedure
L2 Connected Succeed
Connected as GC
Case Study: Who Should Become GO (1)
25
DS
with miDLS
• Not to loose
• We propose and
support two mob
to other channel
comeback
• No additional H/W
network interface
• Average switching
based implementa
CHA CHA
CHB
Intended to equally distribute the chance to become GO
P2P-GROUP-NEGO-REQ/RESP/CONFM
• GO transmits Beacon Packet
• GO sleeps less than GC for
• GO need to forward packet between two GCs
• Car infotainment system is almost wall-powered
• Mobiles are battery-powered
How to make your BlueLink always become GO?
Case Study: Who Should Become GO (2)
26
WifiP2pManager
WiFi Direct APP
::connect
(Peer MAC Address,
WifiP2pConfig)
WifiP2pConfig
/**
* This is an integer value between 0 and 15 where 0 indicates the least
* inclination to be a group owner and 15 indicates the highest inclination
* to be a group owner.
*
* A value of -1 indicates the system can choose an appropriate value.
*/
public int groupOwnerIntent = -1;
@{Code}
Multi-channel iDLS (miDLS)
DS
with miDLS
Original
• IEEE 802.11 is designed assuming th
single CH per BSS
• Switching only if local outgoing que
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices m
to other channel for short time an
comeback
• No additional H/W support by bot
network interface card (NIC) and
• Average switching duration in Mad
based implementation < 20ms
CHA CHA
CHB
Multi-channel
DS
with miDLS
Original
•
•
•
•
•
CHA CHA
CHB
Multi-channel iDLS (m
DS
Original
• IEEE 802.11 is d
single CH per B
• Switching only i
both are empty
• Not to loos
• We propose an
support two m
to other channe
comeback
• No additional H
network interfa
• Average switch
based implemen
CHA CHA
CHB
GO
GC
GC
GC
It is also beneficial for one-to-many P2P Group Setup!
Android support “configurable GO Intent value”
Case Study: One-to-Many Connection
27
*Invitation and Join
DS
with miDLS
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
A CHA
CHB
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
GO P2P-STAInvite
DS
with miDLS
•
• We
sup
to o
com
• No
net
• Ave
bas
CHA CHA
CHB
DS
with miDLS
• Not to loose packets
• We propose and implem
support two mobile WiF
to other channel for sho
comeback
• No additional H/W supp
network interface card (
• Average switching durati
based implementation <
CHA CHA
CHB
GO P2P-STAJoin
*Android Application Develop does not have to care
whether “Connect”,“Invite”, and “Join”.
One is dynamically selected under the Framework
S
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
GO
DS
with miDLS
riginal
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA CHA
CHB
Invite
Multi-channel iDLS (miDLS)
DS
with miDLS
riginal
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA CHA
CHB
Invite
Multi-channel iDLS (miDLS)
DS
riginal
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA CHA
CHB
Invite
**Sequential Invitation
** Sequential invitation may use “Autonomous GO creation”
WiFi / WiFi Direct
Performance
28
WiFi Throughput Performance on Mobiles
1Q/2011 4Q/2012 1Q/2014
*4Q/
2014
1Q/
2016
WiFi PHY 802.11g
802.11n
 802.11ac
(wave1)
802.11ac
(pre-
wave2)
802.11ac
(wave2)
Archivable
Throughput
10~15 Mbps 40~45Mbps
(dual-Band, CB)
>400Mbps
(Quad-CB, MIMO,
Beam-forming)

<500Mbps
(4x4 MIMO,
Beam-forming)

>700Mbps
(Hexa-CB,
MIMO, MU-
MIMO, Beam-
forming)

Host computing power were
even slower thanWiFi Speed!
29
Enough computing power on
mobile for P2P,WFD
*Product has released but features are blocked by FW : ASUSTM AC87U
Reminder: MIMO vs SISO
30
Independent Spatial Path between RX andTX
- Need “X 2TX power” to increase one bit/sec/Hz
- Need N bit/sec/Hz increased with use of N antennas
RX
TX
RX
TX
The Shannon Capacity
Multiple Antenna Installation Does NOT Mean MIMO
31
802.11g (2.4GHz)Wireless Router
Though the multiple antenna exist, the system is SISO
if only a pair of TX/RX active at a time
20072006
RX
TX
Use one of two antennas
selectively for better SINR
And such MIMO comes since 802.11n
MIMO: Spatial Diversity vs Spatial Multiplexing
32
Wider coverage and higher
throughput because it is not likely
to fail all on every available paths
at the sometime
RX
TX
Spatial Diversity: Sending/Receiving Redundant Stream Spatial Multiplex: Sending/Receiving Independent Stream
ABCD…ABCD…
RX
TX
BD…AC…
ABCD… ABCD…
Complex but it is like to have
multiple TX/RX system at the
same time so the gain is high
IEEE 802.11ac Overview: Bitrate Evolutionary
33
up to 6.9Gbps
- Channel Bonding
- Multi-user MIMO
- Beamforming
- 256QAM
- Better back/forward compatibility
IEEE 802.11ac Overview: Channel Bonding
34
80211ac: 160MHz
or (80MHz + 80MHz)
80MHz 80MHz 80MHz 80MHz
11a
11n
11ac
11ac
*another 80MHz band from 149~161@ U-NII3 is omitted
IEEE 802.11ac Overview: Beam-forming Basic
35
*Note that the signal starts at 0-degrees and is rising31/45
λ-
0- 0-
amforming,#also#called#Beamsteering,#allows#electronic#aiming#of#the#strongest#
nal#from#(and#the#best#recepXon#angle#to)#an#antenna#array#
Two#antennas,#transmieng#the#
same#signal,#with#both#antennas#
transmieng#inIphase.#
The#½#wavelength#separaXon#
between#the#antennas#makes#the#
signal#cancel#to#the#leh#and#right.#
Note-that-the-signal-starts-at-0]degrees-and-is-rising-
LEFT-to-RIGHT Signal Cancelation
by sending in-phase signal
λ/2
Chipset Beamforming – The Phased Array
λ-
No
180
b
se
si
DOWN-to-UP Signal Cancelation
by sending 180-degrees out-of-phase signal
IEEE 802.11ac Overview: Beamforming
36
35/45
environment
•  Attenuation and phase shift experienced by each spatial stream
•  Transmit Beamforming and MU-MIMO require knowledge of the
channel state to compute a steering matrix to optimize reception at
one or more receivers
–  Individual space-time streams are
sounded separately
–  Training symbols are transmitted
(“Sounding Poll”) and measured by the
recipient station (or stations)
–  A channel state estimate is sent back
to the beamformer from each station
included in the Sounding Poll for the
derivation of a steering matrix
The environment is “sounded”
to create a digital representation
of the state
of the transmission channel
S
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
Multi-channel iDLS (miDLS)
DS
• IEEE 802.11 is designed assuming tha
single CH per BSS
• Switching only if local outgoing queue
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices mig
to other channel for short time and
comeback
• No additional H/W support by both
network interface card (NIC) and the
• Average switching duration in MadW
based implementation < 20ms
CHA
CHB
VHT Null Data Packet
Announcement frame
VHT Compressed Beamforming
frame (measured RF status)
IEEE 802.11ac Overview: Multi-user MIMO
37
No uplink multi-user MIMO
Much better Air-time fairness, where a
number of poor quality links exists
MCS9 MCS5
X bits X bits
WiFi Throughput Performance
38
Hi, I’m 802.11ac GigabitWireless Router and
can transfer more than 1Gbit/sec
WiFi Throughput Performance:
Range vs Rate
39
Only if you come closer
• Measured received throughput performance
• Latest Android Mobile Phone (11ac 2x2 MIMO)
• NetgearTM R7000
• No interfering devices (shield env)
• Injecting attenuation to the communication signal
between mobile and AP
WiFi Throughput Performance:
WiFi/WiFi Direct Concurrent Mode
40
• Measured received throughput performance
• Latest 2 Android Mobile Phone (11ac 2x2 MIMO)
• NetgearTM R7000
• No interfering devices (shield env)
If you talk only to me
P2P
AP-STA
WiFi Throughput Performance:
WiFi/BT Coexistence
41
• Measured received throughput performance
• Latest Android Mobile Phone (11ac 2x2 MIMO)
• NetgearTM R7000
• No interfering devices (shield env)
BT/BLE-SCAN
CH #6
Note: 11ac does not work
at 2.4GHz.
WiFi Throughput Performance:
Interference vs Rate
42
• Measured received throughput performance
• Latest Android Mobile Phone (11ac 2x2 MIMO)
• NetgearTM R7000
• Typical Office Env where more than 30 APs are around
Office-Midnight
Note: 11ac does not work
at 2.4GHz.
Office-Daytime
Android Wi-Fi Direct
Application Development
43
Android App Dev Workflow
44
Setup • Download SDK and Setup IDE
✓*EclipseTM or Android StudioTM
* No official support by Google for Eclipse in the near future
Development
Publishing
Debugging and
Testing
• Create UI and code
• Build your code and testing
• Release to application Markets
Android SDK
45
Android APP
Calling APIs
• S/W Packages written in Java
• To provide APIs to application developer
android.hardware
android.hardware.
camera2
android.net android.media
android.net.wifi
android.bluetooth
android.media.tv android.bluetooth.le
android.net.wifi.p2p
FYI: Google vs Oracle case
46
• API is a library with
• each Package is a bookshelf in the
library
• each Class is a book on the shelf
• each Method is a chapter out of
how-to book
1심 판사의 판결문중… Library as a Metaphor
android.net.wifi.p2p
android.net.wifi.p2p.WifiP2pManager
android.net.wifi.p2p.WifiP2pManager.connect()
Brief: S/W Dev. on Android
47
Linux Kernel
Native
Android
Framework
Android APP
Android APIs
What we do focus on
Calling APIs
Custom C/C++ Code
JNI
Calling
Custom C/C++ Code
• Whatever you do with APIs can run
most of Android Devices* and you
might be able to distribute your
work via “App Market”
* Application’sTarget Android DeviceVersion must be greater than APP
Android Wi-Fi Direct API
48
WifiMonitor
WifiP2pManager
WifiNative
WifiP2pService
Summary
• WiFi Direct is a “SOFT” extension of existing WiFi to allow
WiFi P2P communication without infrastructure
• AndroidTM provides complete WiFi Direct SDK since the
version of Ice Cream Sandwich
• We review end-to-end interaction of AndroidTM WiFi Direct
Stack implementation
• New 802.11ac provide very high throughput more than
1Gbit/sec
• But the practical performance of WiFi/WiFi Direct is affected
by environmental condition and concurrent radio activity at
WiFi devices.
49
WiFi Display
Control Plane & Implementation Case Study
Ph.D. HayoungYoon
hyyoon@zvolti.com
R&D Lead
zVolti LLC.
July., 2015
Present to Hyundai NGV
Table Of Contents
51
•WiFi Performance Issue (Review & Extended)
•WiFi WMM (QoS)
•WiFi Display Control Plane
•WiFi Display Case Study (Android)
•WiFi Display Case Study (Linux)
•Quality Assurance (Extended)
Revisit:WiFi Performance
52
Range vs. Rate Test (1)
53
DS
with miDLS
• Not to loose
• We propose and
support two mo
to other channe
comeback
• No additional H
network interfac
• Average switchin
based implemen
CHA CHA
CHB
Shield Env.
RF Conducted
Signal Attenuator
short distance
Change the AttenuationValue InTime
Ethernet
Traffic Generator
DUT
• Field test costs a lot but includes
errors
• “Range” is replicated by signal
attenuation
Time
Range vs. Rate Test (2)
54
- Link quality i.e., RSSI (dBm) between AP-
STA decreases (getting worse) in time as
the level of attenuation increases
- What if not changing it?
Signal Attenuator
DS
with miDLS
iginal
• IEEE 802.11 is designed assum
single CH per BSS
• Switching only if local outgoing
both are empty
• Not to loose packets from
• We propose and implement m
support two mobile WiFi devi
to other channel for short tim
comeback
• No additional H/W support b
network interface card (NIC)
• Average switching duration in
based implementation < 20ms
CHA CHA
CHB
- Link Speed (Mbps) is also getting lower
as theWiFi adaptively changes its rate
w.r.t. link quality
with miDLS
CHA C
CHB
Range vs. Rate Test (3)
55
- Link Speed (Mbps) does not tell the actual performance.Why?
- May be due to bad selection
- Packet Errors
- We need to inject traffic and count # of bits received correctly
Range vs. Rate Test (4)
56
- Convert RSSI vs Rate to Distance vs Rate
- For those who does not familiar with RSSI (dBm)
Range vs. Rate Test (5)
57
- Convert RSSI vs Rate to Distance vs Rate
- For those who does not familiar with RSSI (dBm)
- Getting RSSI from DUT might be erroneous for benchmarking
- Use Attenuation vs Rate plot for benchmark if the
configuration is same for DUTs
- Q:Which one looks better?
DUT2
DUT1
RvR under BT-Coex (1)
58
DS
with miDLS
• Not to loose
• We propose and
support two mo
to other channe
comeback
• No additional H
network interfac
• Average switchin
based implemen
CHA CHA
CHB
Shield Env.
RF Conducted
Signal Attenuator
short distance
Ethernet
Traffic Generator
DUT
Change the AttenuationValue InTime
• Same Setup but…
• Pair DUT with BT-Device
• InjectTraffic between DUT and BT-
Device
• No attenuation on the link between
DUT and BT-Device
BT-Paired
RvR under BT-Coex (2)
59
WiFiTput (BT-COEX)
BTTput
WiFiTput (Standalone)
- Q:Which one looks better?
2.4GHz BT-Coex Results
RvR under BT-Coex (3)
60
WiFi RSSI per Antenna (BT-COEX) WiFi RSSI per Antenna (Standalone)
- Q:Which one looks better?
2.4GHz BT-Coex Results
RvR under BT-Coex (4)
61
WiFiTput (BT-COEX)
BTTput
WiFiTput (Standalone)
- Q:Which one looks better?
5GHz BT-Coex Results
RvR under BT-Coex (5)
62
WiFi RSSI per Antenna (BT-COEX) WiFi RSSI per Antenna (Standalone)
- Q:Which one looks better?
5GHz BT-Coex Results
RvR under BT-Coex (6)
63
WiFiTput (BT-COEX)
BTTput
WiFiTput (Standalone)
- Q:Which one looks better?
2.4GHz BT-Coex Results
RvR under BT-Coex (7)
64
WiFiTput (BT-COEX)
BTTput
WiFiTput (Standalone)
- Q:Which one looks better?
5GHz BT-Coex Results
RvR under BT-Coex (8)
65
WiFiTput (BT-COEX) BTTput (BT-COEX)
Note: this is ideal environment where no external interference injected
Busy Air (1)
66
P2P
comm.
T
CH1
CH1
CH1
P2P
comm.
T
- Separating P2P comm. over orthogonal freq. -
CH1
CH6
CH11
- IEEE 802.11 support 11 orthogonal channels
Busy Air (2)
67
P2P
comm.
T
CH1
CH2
CH3
P2P
comm.
T
- Separating P2P comm. over orthogonal freq. -
CH1
CH6
CH11
- IEEE 802.11 support 9 orthogonal channels
- takes longer to finish the transfer
WiFi QoS Effort
68
Brief:WMM/WME
69
• The principle of 802.11 resource allocation
• Designed for the fairness
• Give equal chance to all devices willing to
access
• Contention-based Medium Access
DS
with miDLS
Original
• IEEE 802.11 is design
single CH per BSS
• Switching only if loca
both are empty
• Not to loose pack
• We propose and imp
support two mobile W
to other channel for
comeback
• No additional H/W s
network interface ca
• Average switching du
based implementatio
CHA CHA
CHB
DS
with miDLS
Original
•
single C
• Switchi
both ar
• No
• We pro
suppor
to othe
comeb
• No add
networ
• Averag
based i
CHA CHA
CHB
CH1
data to transfer
DS
with miDLS
Original
CHA CHA
CHB
CH1
Note: separate BSSs sharing carrier-sense range are
considered as single “scheduling domain”
Brief:WMM/WME
70
• Problem
• HOL (Head of line problem)
TX-Queue STA1’ sTX-Queue STA2’ sTX-Queue
VoIP
WWW
WWW
WWW
MAC MAC MAC
delaying access
for others
VoIP
VoIP
VoIP
WWW
WWW
WWW
Fairness is not always good
Brief:WMM/WME
71
• How?
• Give more chance to use wireless communication
resource to QoS-demanding traffic
• Virtualise MAC to content within single device
• WMM provides 4 Access Categories
• Each vMac has different chance to access to the
physical medium
MAC
vMAC vMAC vMAC vMAC
BE BK VI VO
VoIP
VoIP
VoIP
www
www
www
Video
Video
www
www
www
WMM: QoS Differentiation
72
STA1
DS
ith miDLS
single CH per BSS
• Switching only if local outgoing queues
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migr
to other channel for short time and
comeback
• No additional H/W support by both t
network interface card (NIC) and the
• Average switching duration in MadWiF
based implementation < 20ms
CHA
HB
STA2
BE: 20Mbps
ith miDLS
• We propose and implement miDLS
support two mobile WiFi devices migr
to other channel for short time and
comeback
• No additional H/W support by both t
network interface card (NIC) and the
• Average switching duration in MadWiF
based implementation < 20ms
CHA
HB
VO: 24Mbps
• Measured received throughput performance
• Shielded Environment (5GHz)
• Use 802.11a
• Atheros Chipset
WMM: QoS Differentiation
73
DS
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
BE: 10MbpsVO: 40Mbps
• Measured received throughput performance
• Shielded Environment (5GHz)
• Use 802.11a
• Atheros Chipset
WMM: QoS Differentiation
74
DS
• IEEE 802.11 is designed assuming that
single CH per BSS
• Switching only if local outgoing queues at
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
BK: 10MbpsVO: 40Mbps
• Measured received throughput performance
• Shielded Environment (5GHz)
• Use 802.11a
• Atheros Chipset
WMM: QoS Differentiation
75
Is WMM Good for…
• V2X?
• AC_VI for Emergent MSG?
• Head unit?
• Design Issue!
• Multiplexed TS packets may be mixed up for
WFD case
76
Learn from Mobile Industry: Metal…
77
- One RF engineer says: adopting the metal body is the most challenging
task ever since the first WiFi integration into the mobile phone
Same Distance btw. TX/RX but …
Metal vs. Non-Metal: Performance w.r.t DUT Position (1)
78
Fixed AP Location
Various DUT position
RF Shielded Env.
Traffic Generator
• Manipulate DUT positions against AP’s antenna over two polar coordinates
• Measure TX/RX Throughput for each position
• Video Demo
Metal vs. Non-Metal: Performance w.r.t DUT Position (2)
79
Non-Metal Metal
• 6 different position across TILT (Vertical)
• 18 different position across PAN (Horizontal)
• Measure for 100 sec for each position
• Sleep 100 sec between measurement (WHY?)
- Q:Which one looks better?
Mbps
Iteration
Mbps
Iteration
A:301/m:272/M:335/D:14 A:485/m:390/M:572/D:38
Metal vs. Non-Metal: Performance w.r.t DUT Position (3)
80
Non-Metal Metal
• Map position info (PAN-Angle,TILT-Angle) to rectangular coordinates
• Normalise sample value for each position
• Map the value to a Bubble
- Q:Which one looks better?
- Put a little bit of make up
TILT
PAN
TILT
PAN
Metal vs. Non-Metal: Performance w.r.t DUT Position (4)
81
Non-Metal Metal- Q:Which one looks better?
- Vertical Map (Top)
Metal vs. Non-Metal: Performance w.r.t DUT Position (5)
82
Non-Metal Metal- Q:Which one looks better?
- Horizontal Map (Side))
WiFi Display Control Plane
83
Overview:WFD Components
84
SRC
Primary SINK
Secondary SINK
(Optional)
LPCM
LPCM
Time Synch:
gPTP in 802.1AS
UIBC
Overview:WFD is a Multi-player Game
• AP (or GPU)Vendors
• Better performing AV processor
• WiFi ChipsetVendors
• Fast/Reliable/Energy-efficient WiFi
• Manufacturers
• Optimal deployment of
communication and AV processing
units
• Smooth UX designs
• WFD Solution Provider
• Cross-platform/Cross-chipset vendor
WFD Architecture and Requirements
3-1 illustrates the functional blocks in the Wi-Fi Display data and control planes. The data plane
s of video codec (section 3.4.2 and 3.4.4), audio codec (section 3.4.1), PES packetization (Annex-B),
CP system 2.0/2.1 (section 4.7), and MPEG2-TS over RTP/UDP/IP (section 4.10.2 and Annex-B).
ntrol plane consists of RTSP over TCP/IP (section 6), remote I2C Read/Write (section 7), UIBC
IDC and generic user input (section 4.11), and the HDCP session key establishment (section 4.7).
-Fi P2P/TDLS block forms the layer-2 connectivity using either Wi-Fi P2P or TDLS as described in
4.5.
TCP
Control
(RTSP)
CapabilityNegotiation,SessionEstablishment,
MaintenannceandManagement
L2SetupandDiscoveryAssist
RTP
UDP
IP
Wi-Fi P2P / TDLS and Wi-Fi Protected Setup
UIBC
Capsulation
UserInputData
Generic
HIDC
HDCP2.0ControlMessage
MPEG2-TS
PES
packetization
Audio
codec
Video
codec
HDCP 2.0 / 2.1
Remote
I2C
R/W
I2CData
Figure 3-1 : Logical Data and Control Plane Connections
WFD Source, Primary Sink, Secondary Sink and WFD85
WFD Session Establishment
• Use RTSP to exchange WFD Capability and setup streaming session
86
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
WiFi Direct Connected
GC
SRC SINK
TCP connect to {IP:Port from WFD IE}
GO
M1-REQ
M1-RESP
1. SRC gets SINK’s AV playout and
rendering capability (M3)
3. SRC choses the best configuration
5. SRC set SINK’s AV Processing
Configuration (M4)
7. Trigger AV Streaming (M6,M7)
.
.
.
M7-PLAY-REQ
M7-PLAY-RESP
Start AV Streaming
.
.
.
Q:Why SRC becomes GC?
WFD Session Management
87
• Use RTSP to Control Playback
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
GC
SRC SINK
GOStart AV Streaming
M7-PLAY-REQ
M7-PLAY-RESP
AV Streaming
.
.
.
M9-PAUSE-REQ
M9-PAUSE-RESP
.
.
.
M5-TRIGGER-REQ {PLAY}
M5-TRIGGER-RESP-{PLAY}
• No RTSP specification to
control playback by SERVER
• WFD uses Trigger method with
playback control as a parameter
WFD Session Termination
88
• Teardown process is same to generic RTSP streaming
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
GC
SRC SINK
GOStart AV Streaming
M8-TEARDOWN-REQ
M8-TEARDOWN-RESP
• It is “out-of-scope” that actions
after teardown process
• One may keep WiFi Direct
connection to save connection time
for next session establishment
or
M5-TRIGGER-REQ {TEARDOWN}
M5-TRIGGER-RESP-{TEARDOWN}
M8-TEARDOWN-REQ
M8-TEARDOWN-RESP
Q: Keeping P2P connection is Good?
WFD Session Keep Alive
89
• WFD Source should check the sanity of WFD Session
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
GO
SRC SINK
GCAV Streaming in Progress
M16-GET_PARAM-REQ
M16-GET_PARAM-RESP• TIMEOUT in M6-SETUP
• Should be larger than 10 sec
• Default 60 sec
• Android sets 30 sec
• Certification process requires 120
sec to be tested
.
.
.
At least one within
TIMEOUT - 5 sec
TIMEOUT
Detect Session Broken!
• SRC should teardown RTP/
RTSP sessions
Something
wrong!
Q:What happen if a device
goes wrong before RTSP?
M16-GET_PARAM-REQ
User Input Back Channel (1)
90
• UIBC delivers user actions on WFD Sink to the WFD Source
• A separate (independent) UIBC Session (different Port) runs on-demand
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
SRC SINK
M14-SET_PARAM-REQ
M14-SET_PARAM-RESP
• WFD Source can selectively
enable/disable UIBC session
via RTSP M15
AV Streaming in Progress
Exchange
UIBC Capability
M4-SET_PARAM-REQ
M4-SET_PARAM-RESP
UIBC Session / TCP
UIBC Data
Note: AV Streaming and
UIBC Session runs parallel!
Update UI
.
.
.
When UIBC session is disabled?
User Input Back Channel (2)
91
• What actions to deliver?
• Generic
• Mouse
• Single/Multi Touch
• V/H Scrolling
• Rotate
• Key Up / Down (WHAT-KEY-ASCII)
• …
• HDIC (Human Interface Device Class)
• Mouse / BT
• Remote Control / Infrared
• Vendor Specific /Vendor Specific
• …
Type / InputPath
Both WFD Sink / WFD Src should
agree with same capability to receive
and respond to the “input”Q:When the capability should be updated?
Remote I2C (1)
• WFD only defines the data path for delivering I2C transactions
• Manufacturer specific data structure
92
It’s Like TV Remote Control
Remote I2C (2)
9393
• A separate (independent) I2C Session (different Port) runs on-demand
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
SRC SINK
AV Streaming in Progress
I2C port
M3-GET_PARAM-REQ
M3-GET_PARAM-RESP
I2C Session / TCP
I2C Read/Write Request
Note: AV Streaming and
I2C Session runs parallel!
listen on I2C
port
.
.
.
I2C Read/Write Reply
Remote I2C (3)
9494
• Read Request Data Structure (TLV)
0x00 WB-Cnt=N WB-Data[1]
.
.
.
WB-Data[N] Read From Read L
Write Block
variable
Write To W-Cnt=X B[1]
.
.
.
B[X] NOSTOP Delay
• Write Request Data Structure (TLV)
0x01
.
.
.Write Data
Write To W-Cnt=X B[1] B[X]
1Byte
Write Data
Transferred from SRC to SINK
Remote I2C (4)
9595
• Read Reply ACK
• Read Reply NACK
• Write Reply ACK
• Write Reply NACK
0x00
.
.
.
Write Data
R-Cnt=X B[1] B[X]
Transferred from SINK to SRC
0x80
0x01
0x81
• For Implementation side, parsing bit stream
in to MSG is required.
• Thanks to TCP, bits are never mixed nor
errored.
• Security?
• No, authentication for I2C session
AV Processing & Transport
96
AV Streaming Format
97
• NAL / MPEG PES / MPEG2 TS / RTP /UDP
• Not the best but mostly accepted for the compatibility
Reference
RTP header PT field ‘33’ from [4], [6] for MPEG2-TS
Marker bit (M) ‘1’ whenever timestamp is discontinuous from [4]
RTP Timestamp 32-bit timestamp derived from a 90 kHz clock,
representing the target transmission time for the
first byte of the packet. This clock is
synchronized to the system stream PCR (TS) or
the SCR (PS), and represents the target
transmission time of the first byte of the packet
payload.
from [4]
Table B- 5- RTP encapsulation of MPEG-TS3488
3489
Figure B- 1 Example of Recommended Encapsulation of MPEG2-TS Packets3490
Reference
RTP header PT field ‘33’ from [4], [6] for MPEG2-TS
Marker bit (M) ‘1’ whenever timestamp is discontinuous from [4]
RTP Timestamp 32-bit timestamp derived from a 90 kHz clock,
representing the target transmission time for the
first byte of the packet. This clock is
synchronized to the system stream PCR (TS) or
the SCR (PS), and represents the target
transmission time of the first byte of the packet
payload.
from [4]
Table B- 5- RTP encapsulation of MPEG-TS3488
3489
Figure B- 1 Example of Recommended Encapsulation of MPEG2-TS Packets3490
Reference
RTP header PT field ‘33’ from [4], [6] for MPEG2-TS
Marker bit (M) ‘1’ whenever timestamp is discontinuous from [4]
RTP Timestamp 32-bit timestamp derived from a 90 kHz clock,
representing the target transmission time for the
first byte of the packet. This clock is
synchronized to the system stream PCR (TS) or
the SCR (PS), and represents the target
transmission time of the first byte of the packet
payload.
from [4]
Table B- 5- RTP encapsulation of MPEG-TS3488
3489
Figure B- 1 Example of Recommended Encapsulation of MPEG2-TS Packets3490
MPEG2 TS Encapsulation
98
Start code Start code Start code
header headerpayload payload
elementary stream elementary stream
header header header …payload payload payload
PES Packets
stream
PES Packets
stream
PES Packets
stream
PES Packets
188 Bytes 188 Bytes 188 Bytes
Elementary Stream
(Compressed audio, video, or PSI data)
TS Packets
AV Streaming Format
99
• Considering MTP size of Ethernet, 7 MPEG2 TS packets (188B) fits into single RTP payload
Key WFD Performance: Packet Loss
100
• Can’t avoid
• MAC retransmission is not enough
• UDP/RTP has no ACK/NAK feedback
• ARQ may not be employed for latency
Key WFD Performance: Packet Loss
101
Wi-Fi Display Technical Specification D1.44
491
• Splitting single AV unit across packet chain for the error resilience
• Assuming that AV decoder performs sort of error mitigations
Key WFD Performance: Packet Loss
102
Which One Looks Better?
Priority in CompressedVideo
103
P5B2P3B2 B4I1
Initial
Object Descriptor
ES_Descriptor
ES_Descriptor
Scene Description Stream
Object Description Stream
Visual Stream
Visual Stream
Audio Stream
…
Scene Graph
<GOP Structure>
Reference to decode
Video consists of media units with different priority
Video frames with different priority
MPEG: I > P > B
Video Objects with different priority
MPEG-4: Meta > Audio stream > Video stream
Note: WFD does not allow B
frames in use.WHY?
Packet Loss Propagation inVideo Decoding
104
I P P P P P I
.
.
.
P P P P P
.
.
.
GOP (Group of Pictures)
• GOP Size tends to be variable
• Packet loss could damage to the
subsequent frame decoding
decoding dependency time
.
.
.
IDR Request By WFD Sink
105
• Video decoder at WFD Sink may require “Refresh” to receive IDR (Instantaneous Decoder Refresh)
th miDLS
• We propose and implement miDLS
support two mobile WiFi devices migra
to other channel for short time and
comeback
• No additional H/W support by both th
network interface card (NIC) and the A
• Average switching duration in MadWiFi
based implementation < 20ms
CHA
HB
with miDLS
•
•
•
CHA CHA
CHB
GO
SRC SINK
GCAV Streaming in Progress
M13-SET_PARAM-REQ
M13-SET_PARAM-RESP
• No changes in RTP/RTCP
session
• Transparent to the AV/Codec
Layer
• Modern video DSPs can
reproduce IDR within
acceptable latency
Network
Stack or
Decoder
detects erros
AV Streaming Restarts with IDR
Q: Is every frame at the
beginning of streaming IDR
frame?
“Refresh”Video Encoder to get IDR
Flush all buffered frames
@ decoder upon IDR reception
Key WFD Performance: Latency
• Require <50 msec glass-to-glass latency for fluent 3D Action gaming
106
FB
Capture
Scaling
a frame
H.264
Video
Encoding
Packetization
Audio
Sampling
Audio
Encoding
Packetization
glass-to-glass latency
UDP/RTP
Encapsulation
AV Mux
AV Packet
Transmit
SRC-side Video
Decoding
Audio
Decoding
Render
Video
Play
Audio
SINK-side
AV Packet
Reception
AV Demux
Kernel-to-Kernel Propagation
Latency Analysis (1)
107
Encoding latency
Experiments Results
• CDF of 2000 samples
of latency measure
• 99% of samples are
within 5msec
• Avg. :4.5 msec
• Dev.: 0.137msec
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
3.8 4 4.2 4.4 4.6 4.8 5
P(X>x)
channel switching latency (msec)
Monday, December 20, 2010
Experiments Results
• CDF of 2000 samples
of latency measure
• 99% of samples are
within 5msec
• Avg. :4.5 msec
• Dev.: 0.137msec
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
3.8 4 4.2 4.4 4.6 4.8 5
P(X>x)
channel switching latency (msec)
Monday, December 20, 2010
H.264 720p Per-frame Encoding Latency
Measured on 2012/Late Android Mobile (ICS)
- QCA QuadCore S4 Pro
Latency Analysis (2)
108
Sampling = 30fps
I P
4.5msec 33.3msec
TS
TS
TS
RTP
RTP
RTP
TS
TS
TS
RTP
RTP
RTP
OverWiFi
Playout
F
[bits] / Mbps
4.5msec
Decoder Buffering
Note: Decoding time
much less than
encoding time!
.
.
.
F
Decoding Latency
Packetization DePacketization
Latency Analysis (3)
109
Sampling = 60fps
I P
4.5msec 16.7msec
TS
TS
TS
RTP
RTP
RTP
TS
TS
TS
RTP
RTP
RTP
OverWiFi
Playout
F
[bits] / Mbps
4.5msec
Decoder Buffering
Note: Decoding time
much less than
encoding time!
F
Decoding Latency
.
.
.
Packetization DePacketization
Latency Analysis (4)
110
Jitter mitigation
Throughput
Time
Good
RTP
RTP
RTP
RTP
RTP
RTP
OverWiFi
[bits] / Mbps
Jitter Buffer is needed
for both Intra-media
and Inter-media Sync
Case Study:Android
111
WFD on Android
112
Native
Android Framework
Android APP
AV Chipset
dependent
Manufacturer
dependent
Android
OpenSource*
Framebuffer / Audio out
Handling
WFD Daemon
(WiFi Direct / RTSP/RTP)
WFD UI
Early Jellybean (~4.1)
JNI
libstageFright/wifi-display
libstageFright/foundation
OMX
WFD APPs
SurfaceFlinger/DisplayManager/
Remote Display Device
Since Late Jellybean (4.2~)
+ɑ
+ɑWFD
APP
Hard to Dev.APPs &
Poor inter-operability across
manufacturers
AV DSP / WiFi Chipset
Kernel/Driver
Media Player
H/W Codec H/W Codec
{pre-standard}
*As of Android 4.4.4WFD APIs a part of AOSP but not a part Android Framework
, the operation ofWFD APIs is highly depend upon device capability
*WFD on Android: Key Components
DisplayManagerServi
ce
WifiDisplayAdapter
WifiDisplayControll
er
WifiDisplay
WifiDisplayDevice
RemoteDisplay
RemoteDisplay
WifiDisplaySourceANetworkSession
MediaSender
RTPSender
RepeaterSource
NuMediaExtractor
MediaPuller
Converter
MediaRouter
WifiP2pManager
NuPlayer
SurfaceComposerClient
OMX
WFD Setting APP
wpa_supplicant / wpa_cli
C++ LibraryJava LibraryUI/APP Executable
Presentation
**Only for
*Since Android 4.3 Google has removed otherWFD Sink core logics from AOSP
**The component list is gathered from AOSP 4.4113
*WFD on Android: Key Components
-Code Location in AOSP-
$(BASESVC)/display/
DisplayManagerService.j
$(BASESVC)/display/
WifiDisplayAdapter.java
$(BASESVC)/display/
WifiDisplayController.ja
$(BASEHW)/display/
WifiDisplay.java
$(BASESVC)/display/
WifiDisplayAdapter.java
$(MEDIASVC) /
RemoteDisplay.cpp
$(BASEMDL)/
remotedisplay/
$(WFD)/source/
WifiDisplaySource.cpp
$(FOUNDATION)/
ANetworkSession.cpp
$(WFD)/
MediaSender.cpp
$(BASEHW)/hw/
RTPSender.java
$(WFD)/source/
RepeaterResource.cpp
$(AVLIB)/nuplayer/
NuMediaExtractor.cpp
$(WFD)/source/
MediaPuller.cpp
$(WFD)/source/
Converter.cpp
$(SUPP)/v7/media/
MediaRouter.java
$(NET)/wifi/p2p/
WifiP2pManager.java
$(AVLIB)/nuplayer/
NuPlayer.cpp
$(GUI)/
SurfaceComposerClient.cpp
$(OMX)/OMX.cpp
$(PKG)/wfd/WifiDisplaySettings.java
$(ETERNAL)/wpa_supplicant_8/wpa_supplicant/src/
C++ LibraryJava LibraryUI/APP Executable
$(CORE)/Presentation.java
**Only for
*Since Android 4.3 Google has removed otherWFD Sink core logics from AOSP
**The component list is gathered from AOSP 4.4114
Case Study: How to Discover WFD Devices (1)
115
DisplayManagerServi
ce
WifiDisplayAdapter
WifiDisplayControll
er
WifiMonitor
MediaRouter
WifiP2pManager
WFD Setting APP
wpa_supplicant
Getting Lock /
Register Callback
::startWifiDisplayScan
::requestStartScanLocked
::requestStartScan
::discoverPeers
via Async Message :
WifiP2pManager.DISCOVER_PEERS
WifiP2pService
JNI:WifiNative
WifiNative ::p2pFind
::doBooleanCommand(P2PFIND)
Wifi (wifi.c)
::doCommand(P2PFIND)
via UNIX_SOCKET by
wpa_cli: P2PFIND
WiFi DR/FW
via ioctl by chipset dependent
kernel/user interface
::setWfdInfo
::startMonitoring
::waitForEvent
Q: WHY Only
Single APP?
Case Study: How to Discover WFD Devices (2)
116
DisplayManagerServi
ce
WifiDisplayAdapter
WifiDisplayControll
er
WifiMonitor
MediaRouter
WifiP2pManager
WFD Setting APP
wpa_supplicant
Getting Lock /
Register Callback
::startWifiDisplayScan
::requestStartScanLocked
::requestStartScan
::discoverPeers
via Async Message :
WifiP2pManager.DISCOVER_PEERS
WifiP2pService
JNI:WifiNative
WifiNative
::p2pFind
::doBooleanCommand(P2PFIND)
Wifi (wifi.c)
::doCommand(P2PFIND)
via UNIX_SOCKET by
wpa_cli: P2PFIND
WiFi DR/FW
via ioctl by chipset dependent
kernel/user interface
::setWfdInfo
::startMonitoring
::waitForEvent
via MSG_Broadcast
(MSG_SEND_STATUS
_CHANGE_BROADCAST)
WifiDisplay[]
Case Study: How to Discover WFD Devices (3)
117
DisplayManagerServi
ce
WifiDisplayAdapter
WifiDisplayControll
er
WifiMonitor
MediaRouter
WifiP2pManager
WFD Setting APP
wpa_supplicant
Getting Lock /
Register Callback
::startWifiDisplayScan
::requestStartScanLocked
::requestStartScan
::discoverPeers
via Async Message :
WifiP2pManager.DISCOVER_PEERS
WifiP2pService
JNI:WifiNative
WifiNative ::p2pFind
::doBooleanCommand(P2PFIND)
Wifi (wifi.c)
::doCommand(P2PFIND)
via UNIX_SOCKET by
wpa_cli: P2PFIND
WiFi DR/FW
via ioctl by chipset dependent
kernel/user interface
::setWfdInfo
::startMonitoring
::waitForEvent
via MSG_Broadcast
(MSG_SEND_STATUS
_CHANGE_BROADCAST)
WifiDisplay[]
WiFi Direct Native SubLayer
Case Study: How to Connect WFD Sink (1)
118
WifiDisplayAdapter
WifiDisplayControll
er
WifiP2pManager
WFD Setting APP
::connectWifiDisplay
::requestConnectLocked
::connect
::connect
::setMiracastMode
SRC) onGroupInfo
Available
RemoteDisplay
WiFi Direct Native
SubLayer
::connect
::listen (INTF: PORT)
JNI:RemoteDisplay
RemoteDisplay
::startListen
::nativeListen
WifiDisplaySource
::start
Sync MSG kWhatStart
ANetworkSession
::createRtspSession
Session
ASync MSG
kWhatStart, …
M1…MX
onM6RxNoError
PlaybackSession
::init
::play, ::pause,… upon MX
MediaSender
videoTrackaudioTrack
RTPSender
WFD Source
AV/Codec SubLayer
tsPkt
cfg
tsPkt
Socket
RTSPServer
DisplayManagerSer
vice
Case Study: How to Connect WFD Sink (2)
119
WifiDisplayAdapter
WifiDisplayControll
er
DisplayManagerSer
vice
WifiP2pManager
WFD Setting APP
::connectWifiDisplay
::requestConnectLocked
::connect
::connect
::setMiracastMode
SRC) onGroupInfo
Available
RemoteDisplay
WiFi Direct Native
SubLayer
::connect
::listen (INTF: PORT)
JNI:RemoteDisplay
RemoteDisplay
::startListen
::nativeListen
WifiDisplaySource
::start
Sync MSG kWhatStart
ANetworkSession
::createRtspSession
Session
ASync MSG
kWhatStart, …
M1…MX
onM6RxNoError
PlaybackSession
::init
::play, ::pause,… upon MX
MediaSender
videoTrackaudioTrack
RTPSender
WFD Source
AV/Codec SubLayer
tsPkt
cfg
tsPkt
Socket
RTSPServer
Only for WFD Source Capability
Case Study: Extension for WFD Sink
120
WifiDisplayAdapter
WifiDisplayControll
er
WifiP2pManager
WFD Setting APP
::connectWifiDisplay
::requestConnectLocked
::connect
::connect::setMiracastMode
(SINK)
onGroupInfo
Available
WifiDisplaySink
WiFi Direct
::connect
::connect (INTF: PORT)
JNI:WifiDisplaySink
::connect
WifiDisplaySink
::start
Sync MSG kWhatStart
ANetworkSession
::createRtspSession
Session
ASync MSG
kWhatStart, …
M1…MX
onM6RxNoError
BnMediaPlayerClient
::init
::connect
::play, ::pause,… upon MX
TunnelRenderer
videoTrack
audioTrack
RTPSink
tsPkt
Socket
RTSPServer
Reuse Android
4.2 AOSP Code
Small
Modification
Create
Your Own
DisplayManagerSer
vice
Case Study: User Input Back Channel (1)
121
Video Player
Transparent Layer
Touch Screen
WFD Sink App
H/W Abstract
Transparent Activity
- Programmatically detect User Action (TOUCH)
Case Study: User Input Back Channel (2)
122
Transparent Activity
UIBC Translater
Video Player
(minX, minY)
(maxX, maxY)
WFD AV Session Config
(minX, minY)
Action, x, y
(|Src-X|, |Src-Y|) Dismiss for
invalide action
Action, NewX, NewY
@ WFD Src
- Check the validity of User Action
UIBC Data over
TCP/IP
Dismissed
Dismissed
UIBC Session RX
UIBC Session TX
@ WFD Sink
Case Study: User Input Back Channel (3)
123
UIBC Session TX
UIBC Session RX
@ WFD Src
- Apply UIBC Data at WFD SRC
UIBC Data over
TCP/IP
InputEvent
*InputManager
*./frameworks/base/core/java/android/
hardware/input/InputManager.java
Virtual Touch Event
Application Running on WFD SRC
has no idea whether the action
comes from itself (by user) or from
WFD Sink via UIBC.
Transparency!
@ WFD Sink
Case Study: Use of TCP Transport (1)
124
If the source frame rate is not 60 fps, the End-to-End latency is anyway not
enough for realtime gaming experience,
The Tradeoff
- If we recover packet loss, we have to be tolerant with Quality degradation
-You have to explain why this is happening to you QA manager and to the customer
- TCP slower than UDP, but guarantee the PER=0.
- Why not to use TCP?
Case Study: Use of TCP Transport (2)
125
There is code for using TCP in the Android Source.
If your WFD sink can handle
“RTP/AVP/TCP”, you can put it
into M3 Response
The certification?
Certification is okay as long as
you can handle “RTP/AVP/UDP”
Case Study: Noticeable Lollipop’s new API
- android.media.projection
- android.bluetooth.le
- Allow you to capture screen at API-level
- No audio capturing supported
- Allow your device works as BLE Peripheral
- Your head unit can advertise the location over BLE like a beacon
- You may be able to build your own Android App to screencast
Case Study: Linux
127
Case Study:WFD Source & Sink on Linux (1)
• Streaming one’s display output to another is not “NEW” for Linux
- VNCTM supports for WFD’s UIBC like functionalities for keyboard and mouse
• Open source tools for capture, compress, and streaming of Desktop’s frame buffer
- FFmpegTM is the best IMO
• Open source RTP/RTSP Streaming clients are readily available
- VLCTM (Video Lan Client) is commercial-quality streaming client (and server)
• Most Linux distribution uses wpa_supplicant for WiFi controls & managements as
AndroidTM does
BUT why there is no “WORKING” Linux WFD Source &
Sink ?
• No WiFi Direct support by default in the most Linux distribution
• Not all WiFi chipsets for Desktop/Laptop support WiFi Direct feature (at F/W level)
- List of IntelTM WiFi Chipset for WiFi Direct Support (link)
That is…
• Recall HOW WFD Devices distinguish WFD Devices from other WiFi Direct
Devices in discovery process
• Can the vendor-specific WiFi F/W allow to insert “WFD IE (Information Element)”
into IEEE 802.11 control packets?
You may be able to active WiFi Direct … but
Case Study:WFD Source & Sink on Linux (2)
Inside of WFD IE (1)
• TLV as other IEs
• 11 types of WFD Subelements are defined (D 1.44)
• WFD Device Information (Type=0) is the most useful for discovering
WFD Devices
WFD IE Header WFD Subelements
WFD IE
ID=0 Length=6
WFD Device
Information
Session Management
Control Port
WFD Device
Maximum Throughput
2 2 221Octets
Inside of WFD IE (2)
131
ID=0 Length=6
WFD Device
Information
Session Management
Control Port
WFD Device
Maximum Throughput
2 2 221Octets
...
Audio Only
supported bit @
SRC
Audio unsupported
bit @ SINK ... WFD Session
Availability ... Device Type
Bits 1 1 2 2
2Byte TCP Server Port @ SRC
WFD Device’s maximum
tolerable throughput
0b00 SRC
0b01 P-SINK
0b10 S-SINK
0b11 Dual
0b00 Not Avail.
0b01 Available
0b10 Reserved
0b11 Reserved
SRC can only
send Audio SINK can only
render video
Discover Non-AP P2P STA
• In scan phase, a Probe. Req is transmitted all supported channels
• In search phase, a Probe. Req is transmitted only to social channels
(CH#1, CH#6, CH#11)
• Q: How to find GO established in 5GHz band?
DS • Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
DS
with miDLS
• No
• We pr
suppo
to oth
comeb
• No ad
netwo
• Averag
based
CHA CHA
CHB
Listen Search or Scan
P2PWildcard SSID
P2P IE
Wildcasrd BSSID
Probe Req.
Probe Resp.
WPS/RSN/SR IE
P2PWildcard SSID
P2P IE
Wildcasrd BSSID
WPS/RSN/SR IE
Broadcast or Unicast
Unicast
132
Discover WFD Device
• WFD uses Wi-Fi Direct
• WFD IE carries
• device-type: SRC? or SINK?
• device-status: Busy? or Ready?
DS • Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrate
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the AP
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
DS
with miDLS
• No
• We pr
suppo
to oth
comeb
• No ad
netwo
• Averag
based
CHA CHA
CHB
Listen Search or Scan
P2PWildcard SSID
P2P IE + WFD IE
Wildcasrd BSSID
Probe Req.
Probe Resp.
WPS/RSN/SR IE
P2PWildcard SSID
P2P IE + WFD IE
Wildcasrd BSSID
WPS/RSN/SR IE
Broadcast or Unicast
Unicast
133
• L3 Connectivity in WiFi Direct Group may not be working correctly
• Need to change the DHCP Server operations when WiFi Direct is running
And…
Case Study:WFD Source & Sink on Linux (3)
“DHCP Storm Scenario”
Ethernet
DHCP Server
DHCP Server
P2P-GO
P2P-GC
192.168.0.1
192.168.0.2
192.168.10.1
192.168.10.2
192.168.10.3 ????
WiFi
• MiracleCast (link)
• Started from OpenWFD project
• Portable P2P Link management via “adhoc” version of DHCP Server
• As of now (OCT 2014),
• Only WiFi Direct Link Control and Management works
• Local Sink and Source Control is under development
Latest Opensource Activity Updates
Case Study:WFD Source & Sink on Linux (4)
V2X with Multiple Wireless
Connectivity
136
Wi-Fi/LTE Multipath Aggregation (1)
*LTE/WiFi Multipath Aggregation 기술 동향 2014,TTA
Wi-Fi LTE
137
• Better throughput
• Seamless connection
• Lower price for communication
BD…
AC…
ABCD…
+
Wi-Fi/LTE Multipath Aggregation (2)
*LTE/WiFi Multipath Aggregation 기술 동향 2014,TTA 138
• Application Driven
• MPTCP (Multipath TCP)
• RAN (RADIO Access Network)
Aggregation
Normal WebserverMultipath-aware HTTP
MPTCP-patched WebserverNormal App using TCP
Normal App
Normal Webserver
No H/W Infra change
No H/W Infra change
HUGE H/W Infra change
S/W patch for web server
iOS Siri!
Samsung download booster
Wi-Fi/LTE Multipath Aggregation (3)
*LTE/WiFi Multipath Aggregation 기술 동향 2014,TTA 139
$$$$$
Normal WebserverMultipath-aware HTTP
MPTCP-patched WebserverNormal App using TCP
Normal App
Normal Webserver
No H/W Infra change
No H/W Infra change
HUGE H/W Infra change
S/W patch for web server
높은 범용성!
$
특정 App 에 제한
적!
$($$ with Proxy)
모든 TCP 사용 응용!
Wi-Fi/LTE Aggregation forV2I
140
USE Intermittent Wi-Fi Hotspot at much as possible!
Stay Connected with LTE with wider coverage!
Prioritise theV-to-I traffic and choose effective one!
Wi-Fi/LTE Aggregation forV2V
141
Be prepared: Link disconnection
Get Diversity for emergent information
MPTCP Performance Field Test Result (1)
142
- DUT: Quadcore / LTE Cat6 / 802.11ac (2x2) - 2014/12
- Measure Throughput for 200 sec and compute contribution ratio for Wi-Fi and LTE
M: 도곡역 플렛폼
M: 도곡역/zVolti Office
S: zVolti Office
S: 도심 아파트 상가
MPTCP Performance Field Test Result (2)
143
M: 도곡역 플렛폼
Wi-Fi Disconnected
Tput Aggr. Tput for LTE and Wi-Fi
RSSI for LTE and Wi-Fi
Wi-Fi Linkspeed
MPTCP Performance Field Test Result (3)
144
M: 도곡역/zVolti Office
Tput Aggr. Tput for LTE and Wi-Fi
RSSI for LTE and Wi-Fi
Wi-Fi Linkspeed
MPTCP Performance Field Test Result (4)
145
S: zVolti Office
Tput Aggr. Tput for LTE and Wi-Fi
RSSI for LTE and Wi-Fi
Wi-Fi Linkspeed
WiFi Device
Quality Assurance
146
WiFi Tech Evolutionary
• Floods of new tech. standards from IEEE fuels to industrial
standards driven by WiFi Alliance
802.11
802.11b
802.11a
802.11g
802.11e
802.11i
802.11n
802.11r
802.11s
802.11k
802.11u
802.11ac
WiFi
Direct
WiFi Display
WiFi
WiFi
WPS
WiFi
TDLS
Time
PHY MACWFA
Complexity
Performance
Hotspot
2.0
802.11ad
147
Complexity
to other chan
comeback
• No additional
network inter
• Average switc
based implem
802.11b 802.11a
802.11g
802.11e
802.11n
WiFi DirectWiFi
3Q/2012
148miDLS
802.11b 802.11a
802.11g
802.11e
802.11n
WiFi
Direct
WiFi
WiFi Display
WiFi
TDLS
802.11k
802.11u
4Q/2014 Concurrency
802.11ac
Multi-User MIMO
Beam-forming
WFA Filesharing
Situation
149
**
*
BT/BLE
GPS
ManyVendors & Models
Connected Car!
with multiple wireless connectivity
[Bloomberg] Hyundai Connects With Verizon to Bring Wireless to Its
U.S. Cars 2014. 01.21
Many Services
User Scenario depends on “Smartness”
150
- WiFi Only
- Custom *“Screencasting” APP
** The feature is yet feasible in mobiles
* For each vendor and model
- P2P Only
- Standard Miracast
- No value for “Connected Car”
- No value for “Connected Car”
- S/W Updates
- Hotspot Only
- Custom *“Screencasting” APP
- **Hotspot & P2P Concurrent
- Standard Miracast
Most Latest Android Mobile supports WiFi/P2P Concurrent Mode
Expected Radio Components
151
WiFi (SoftAP)
WiFi (P2P)
WiFi (Legacy)
2.4GHz/5GHz RF for
WiFi
700MHz ~ 3.6GHz RF
for Cellular
2.4GHz/2.3GHz for
Satellite Radio
13.56MHz for NFC
1.5GHz for GPS
V2V/V2I (802.11p)3G/4G Cellular
Digital Radio (Satellite)
BT/BLE
GPS
NFC
Chipset
RF
V2V Radar
Single chip solution?
Quality?
152
• Durability
• Stability
• Performance
• Interoperability
*
BT/BLE
GPS
[Bloomberg] Hyundai Connects With Verizon to Bring Wireless to Its
U.S. Cars 2014. 01.21
*
Learn from Mobile Industry: Durability
153
BT/WiFi Combo chip
SDIO
BUS
Application Processor
(Core)WiFi Chip SDIO Module
RF
Power
I/O (bits)
I/O (signal)
On/Off
- The module damaged by 10,000 times of radio on/off
The life time of Mobile vs. Auto?
Learn from Mobile Industry: Stability
154
BT/WiFi Combo chip
SDIO
BUS
Application Processor
(Core)
WiFi Chip SDIO Module
RF
I/O (bits)
I/O (signal)
- Performance degradation by non-WiFi issue
LinkQ
Time
Good
Core Temperature
Time
High
Core Clock
Time
Good
Throughput
Time
Good
Learn from Mobile Industry: Interoperability
155
- So many counterpart devices
- Simple Lab-test is not enough
- So much user complains from the market after the product releases
100+ Different configuration for each AP
- 80211 mode
- Security
- Channel
Interference
from others
Link-state
btw TX/RX
Learn from Mobile Industry: Metal…
156
- One RF engineer says: adopting the metal body is the most challenging
task ever since the first WiFi integration into the mobile phone
Same Distance btw. TX/RX but …
Learn from Mobile Industry:Too Strong Signal
157
- Muti-path MIMO, performance degradation happens when the signal btw. TX/
RX is too high
Not desirable!
• Measured received throughput performance
• Latest Android Mobile Phone (No interfering devices (shield
env)
• Injecting attenuation to the communication signal between
mobile and AP
Distance to Attenuation?
Learn from Mobile Industry: UDP Packet Reordering
158
The problem hard to produce in old age!
2
DS
h miDLS
both are empty
• Not to loose packets from AP
• We propose and implement miDLS
support two mobile WiFi devices migrat
to other channel for short time and
comeback
• No additional H/W support by both the
network interface card (NIC) and the A
• Average switching duration in MadWiFi-
based implementation < 20ms
CHA
HB
DS
with miDLS
both a
• No
• We pr
suppo
to oth
comeb
• No ad
netwo
• Avera
based
CHA CHA
CHB
13
.
.
.
4
For maximum performance, modern WiFi Driver/
Firmware buffering incoming packets from upper
layer and scheduling them
4 13
.
.
.
2
TX-Order
RX-Order
Without RX-side pre-buffering, P2 and P3 are lost and
discarded upon receiving P1 and P4.
Learn from Mobile Industry: RX/TX Stalls
159
Lazy Link Adaptation ; Connected but can’t TX/RX
Learn from Mobile Industry: RX/TX Stalls
160
Lazy Link Adaptation ; Connected but can’t TX/RX
Typical mid-quality link
Learn from Mobile Industry:Try and Errors (1)
161
2. P2P Group Operating Channel selection
3. Softap Operating Channel selection for Tethering Service
4.WiFi Direct / WFD User Scenario
1) Softap / P2P Group Timeout if no activity sensed
2) Maximum size of P2P Group
3) Vendor specific behaviour
1.WiFi chipset selection?
Learn from Mobile Industry:Try and Errors (2)
162
5. Leveraging with NFC and BLE
1) Auto WiFi Direct pairing with BLE
2) Auto WFD Session kicking with NFC tagging
3) Authentication
7. System parameter tuning
1) TCP Windows size
2) Read/Write buffer length
3) Kernel-side socket operation tuning
6.WiFi MAC/PHY Parameter tuning
1) Retransmission control
2) Link-adaptation policy
3) BT/BLE Coex parameters
Learn from Mobile Industry: TCP ParameterVs Tput
163
TCP Windows Size (Mbyte) Parallel Stream Count
In order to find the best system default In order to know the ground performance
Challenges & Possible Approaches
• Resource intensive
• Certification doesn’t promise
the performance
• Large volume of test cases
• Field-test vs. Lab-test
• To much test results
164
• Test automation
• Field-to-Lab tests
• Quantitative analysis
• Ageing and interoperability test
Test Automation
165
R&D Phase
Field Test with Prototype Installation
Bench Mark the Performance w.r.t.,
- Different positions of antenna installation
- Different counter part device (i.e., mobile)
- User scenario (BT/BLE-Coex, Hotspot, Miracast)
- Environments (Channel, Interference)
Measurement under real environment
- Link-quality variation
- Level of congestion
- User scenario
Feedback
Field-to-Lab Test
- Recreation of recorded link-quality
- Injection of congestion and Interference
- System parameter tunes (TX/RX gain,
Core Clock Speed, UX guides)
Bench Mark and Ageing Test with
Summary
• WiFi Display runs across AV Processing,AV Streaming,and
WiFi Direct wireless connectivity
• AndroidTM provides WFD Source functionality since the
version of JellyBean
• We review end-to-end interaction of AndroidTM WiFi Display
Stack implementation
• Troubles to bring up WiFi Direct make it hard to implement
WiFi Display on Linux platform
• Test automation is a key for Quality Assurance
166

More Related Content

What's hot

5G Network Architecture, Planning and Design
5G Network Architecture, Planning and Design5G Network Architecture, Planning and Design
5G Network Architecture, Planning and DesignTonex
 
Presentation on Vowifi
Presentation on VowifiPresentation on Vowifi
Presentation on Vowifisrishti jain
 
Session initiation-protocol
Session initiation-protocolSession initiation-protocol
Session initiation-protocolSanthosh Somu
 
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating SystemTech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating Systemnvirters
 
Application Layer and Protocols
Application Layer and ProtocolsApplication Layer and Protocols
Application Layer and ProtocolsRubal Sagwal
 
IPv4 to IPv6
IPv4 to IPv6IPv4 to IPv6
IPv4 to IPv6mithilak
 
CCNA SUMMER TRAINNING PPT
CCNA SUMMER TRAINNING PPTCCNA SUMMER TRAINNING PPT
CCNA SUMMER TRAINNING PPTNishant Goel
 
SIP: Call Id, Cseq, Via-branch, From & To-tag role play
SIP: Call Id, Cseq, Via-branch, From & To-tag role playSIP: Call Id, Cseq, Via-branch, From & To-tag role play
SIP: Call Id, Cseq, Via-branch, From & To-tag role playSridhar Kumar N
 
F5 Solutions for Service Providers
F5 Solutions for Service ProvidersF5 Solutions for Service Providers
F5 Solutions for Service ProvidersBAKOTECH
 
Introduction into SIP protocol
Introduction into SIP protocolIntroduction into SIP protocol
Introduction into SIP protocolMichal Hrncirik
 

What's hot (20)

Sip
SipSip
Sip
 
5G Network Architecture, Planning and Design
5G Network Architecture, Planning and Design5G Network Architecture, Planning and Design
5G Network Architecture, Planning and Design
 
SIP vs PRI
SIP vs PRISIP vs PRI
SIP vs PRI
 
WebRTC presentation
WebRTC presentationWebRTC presentation
WebRTC presentation
 
Presentation on Vowifi
Presentation on VowifiPresentation on Vowifi
Presentation on Vowifi
 
Session initiation-protocol
Session initiation-protocolSession initiation-protocol
Session initiation-protocol
 
VOIP
VOIPVOIP
VOIP
 
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating SystemTech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
 
Virtual LAN
Virtual LANVirtual LAN
Virtual LAN
 
OSPF Configuration
OSPF ConfigurationOSPF Configuration
OSPF Configuration
 
Application Layer and Protocols
Application Layer and ProtocolsApplication Layer and Protocols
Application Layer and Protocols
 
IPv4 to IPv6
IPv4 to IPv6IPv4 to IPv6
IPv4 to IPv6
 
CCNA SUMMER TRAINNING PPT
CCNA SUMMER TRAINNING PPTCCNA SUMMER TRAINNING PPT
CCNA SUMMER TRAINNING PPT
 
SIP: Call Id, Cseq, Via-branch, From & To-tag role play
SIP: Call Id, Cseq, Via-branch, From & To-tag role playSIP: Call Id, Cseq, Via-branch, From & To-tag role play
SIP: Call Id, Cseq, Via-branch, From & To-tag role play
 
F5 Solutions for Service Providers
F5 Solutions for Service ProvidersF5 Solutions for Service Providers
F5 Solutions for Service Providers
 
Wi-Fi Direct
Wi-Fi DirectWi-Fi Direct
Wi-Fi Direct
 
Getting ready for wi-fi 6 and IOT
Getting ready for wi-fi 6 and IOTGetting ready for wi-fi 6 and IOT
Getting ready for wi-fi 6 and IOT
 
Introduction into SIP protocol
Introduction into SIP protocolIntroduction into SIP protocol
Introduction into SIP protocol
 
Network switch
Network switchNetwork switch
Network switch
 
Ipv4 vs Ipv6 comparison
Ipv4 vs Ipv6 comparisonIpv4 vs Ipv6 comparison
Ipv4 vs Ipv6 comparison
 

Similar to [July/2015] Android Wi-Fi Direct/Display Overview and Performance Measurement (Extended)

[Oct./2012] WiFi : More Than Internet Connectivity
[Oct./2012] WiFi : More Than Internet Connectivity[Oct./2012] WiFi : More Than Internet Connectivity
[Oct./2012] WiFi : More Than Internet ConnectivityHayoung Yoon
 
[Mar./2014] WiFi : Filling the Big Pipe
[Mar./2014] WiFi : Filling the Big Pipe[Mar./2014] WiFi : Filling the Big Pipe
[Mar./2014] WiFi : Filling the Big PipeHayoung Yoon
 
Internet of Things: Comparison of Protocols & Standards
Internet of Things: Comparison of Protocols & StandardsInternet of Things: Comparison of Protocols & Standards
Internet of Things: Comparison of Protocols & StandardsAshu Joshi
 
Wireless Technologies and Standards
Wireless Technologies and StandardsWireless Technologies and Standards
Wireless Technologies and StandardsRubal Sagwal
 
IPv6 translation methods
IPv6 translation methodsIPv6 translation methods
IPv6 translation methodsAhmad Hijazi
 
Computer networks basic network_hardware_1
Computer networks basic network_hardware_1Computer networks basic network_hardware_1
Computer networks basic network_hardware_1Aneesh Nelavelly
 
WIRELESS INTERNET BY SAIKIRAN PANJALA
WIRELESS INTERNET BY SAIKIRAN PANJALAWIRELESS INTERNET BY SAIKIRAN PANJALA
WIRELESS INTERNET BY SAIKIRAN PANJALASaikiran Panjala
 
WiFi Networks.pdf
WiFi Networks.pdfWiFi Networks.pdf
WiFi Networks.pdfwaqas232871
 
Lifi data transmission
Lifi data transmission Lifi data transmission
Lifi data transmission shyam sunder
 
Videoconferencing Technology Workshop
Videoconferencing Technology WorkshopVideoconferencing Technology Workshop
Videoconferencing Technology WorkshopVideoguy
 
PLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aq
PLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aqPLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aq
PLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aqPROIDEA
 
Campus WiFi: Case Study of IITB Wireless
Campus WiFi: Case Study of IITB WirelessCampus WiFi: Case Study of IITB Wireless
Campus WiFi: Case Study of IITB WirelessAniruddh Rao Kabbinale
 
Voice and Data Delivery Networks
Voice and Data Delivery NetworksVoice and Data Delivery Networks
Voice and Data Delivery NetworksKen V
 

Similar to [July/2015] Android Wi-Fi Direct/Display Overview and Performance Measurement (Extended) (20)

[Oct./2012] WiFi : More Than Internet Connectivity
[Oct./2012] WiFi : More Than Internet Connectivity[Oct./2012] WiFi : More Than Internet Connectivity
[Oct./2012] WiFi : More Than Internet Connectivity
 
[Mar./2014] WiFi : Filling the Big Pipe
[Mar./2014] WiFi : Filling the Big Pipe[Mar./2014] WiFi : Filling the Big Pipe
[Mar./2014] WiFi : Filling the Big Pipe
 
Media Access Layer
Media Access LayerMedia Access Layer
Media Access Layer
 
Internet of Things: Comparison of Protocols & Standards
Internet of Things: Comparison of Protocols & StandardsInternet of Things: Comparison of Protocols & Standards
Internet of Things: Comparison of Protocols & Standards
 
Wireless Technologies and Standards
Wireless Technologies and StandardsWireless Technologies and Standards
Wireless Technologies and Standards
 
IoT Control Units and Communication Models
IoT Control Units and Communication ModelsIoT Control Units and Communication Models
IoT Control Units and Communication Models
 
IPv6 translation methods
IPv6 translation methodsIPv6 translation methods
IPv6 translation methods
 
Computer networks basic network_hardware_1
Computer networks basic network_hardware_1Computer networks basic network_hardware_1
Computer networks basic network_hardware_1
 
WIRELESS INTERNET BY SAIKIRAN PANJALA
WIRELESS INTERNET BY SAIKIRAN PANJALAWIRELESS INTERNET BY SAIKIRAN PANJALA
WIRELESS INTERNET BY SAIKIRAN PANJALA
 
WiFi Networks.pdf
WiFi Networks.pdfWiFi Networks.pdf
WiFi Networks.pdf
 
5 IEEE standards
5  IEEE standards5  IEEE standards
5 IEEE standards
 
Lifi data transmission
Lifi data transmission Lifi data transmission
Lifi data transmission
 
Networking
NetworkingNetworking
Networking
 
Videoconferencing Technology Workshop
Videoconferencing Technology WorkshopVideoconferencing Technology Workshop
Videoconferencing Technology Workshop
 
Networking
NetworkingNetworking
Networking
 
PLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aq
PLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aqPLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aq
PLNOG 8: Peter Ashwood-Smith - Shortest Path Bridging IEEE 802.1aq
 
Campus WiFi: Case Study of IITB Wireless
Campus WiFi: Case Study of IITB WirelessCampus WiFi: Case Study of IITB Wireless
Campus WiFi: Case Study of IITB Wireless
 
Rpl2018
Rpl2018Rpl2018
Rpl2018
 
Voice and Data Delivery Networks
Voice and Data Delivery NetworksVoice and Data Delivery Networks
Voice and Data Delivery Networks
 
L6 6 lowpan
L6 6 lowpanL6 6 lowpan
L6 6 lowpan
 

Recently uploaded

DEVICE DRIVERS AND INTERRUPTS SERVICE MECHANISM.pdf
DEVICE DRIVERS AND INTERRUPTS  SERVICE MECHANISM.pdfDEVICE DRIVERS AND INTERRUPTS  SERVICE MECHANISM.pdf
DEVICE DRIVERS AND INTERRUPTS SERVICE MECHANISM.pdfAkritiPradhan2
 
Engineering Drawing section of solid
Engineering Drawing     section of solidEngineering Drawing     section of solid
Engineering Drawing section of solidnamansinghjarodiya
 
Research Methodology for Engineering pdf
Research Methodology for Engineering pdfResearch Methodology for Engineering pdf
Research Methodology for Engineering pdfCaalaaAbdulkerim
 
Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...
Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...
Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...Erbil Polytechnic University
 
System Simulation and Modelling with types and Event Scheduling
System Simulation and Modelling with types and Event SchedulingSystem Simulation and Modelling with types and Event Scheduling
System Simulation and Modelling with types and Event SchedulingBootNeck1
 
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMSHigh Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMSsandhya757531
 
Earthing details of Electrical Substation
Earthing details of Electrical SubstationEarthing details of Electrical Substation
Earthing details of Electrical Substationstephanwindworld
 
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...Sumanth A
 
Prach: A Feature-Rich Platform Empowering the Autism Community
Prach: A Feature-Rich Platform Empowering the Autism CommunityPrach: A Feature-Rich Platform Empowering the Autism Community
Prach: A Feature-Rich Platform Empowering the Autism Communityprachaibot
 
Cost estimation approach: FP to COCOMO scenario based question
Cost estimation approach: FP to COCOMO scenario based questionCost estimation approach: FP to COCOMO scenario based question
Cost estimation approach: FP to COCOMO scenario based questionSneha Padhiar
 
US Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of ActionUS Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of ActionMebane Rash
 
Paper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdf
Paper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdfPaper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdf
Paper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdfNainaShrivastava14
 
Ch10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdfCh10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdfChristianCDAM
 
SOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATIONSOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATIONSneha Padhiar
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfManish Kumar
 
KCD Costa Rica 2024 - Nephio para parvulitos
KCD Costa Rica 2024 - Nephio para parvulitosKCD Costa Rica 2024 - Nephio para parvulitos
KCD Costa Rica 2024 - Nephio para parvulitosVictor Morales
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...Erbil Polytechnic University
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating SystemRashmi Bhat
 
Energy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptxEnergy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptxsiddharthjain2303
 
Computer Graphics Introduction, Open GL, Line and Circle drawing algorithm
Computer Graphics Introduction, Open GL, Line and Circle drawing algorithmComputer Graphics Introduction, Open GL, Line and Circle drawing algorithm
Computer Graphics Introduction, Open GL, Line and Circle drawing algorithmDeepika Walanjkar
 

Recently uploaded (20)

DEVICE DRIVERS AND INTERRUPTS SERVICE MECHANISM.pdf
DEVICE DRIVERS AND INTERRUPTS  SERVICE MECHANISM.pdfDEVICE DRIVERS AND INTERRUPTS  SERVICE MECHANISM.pdf
DEVICE DRIVERS AND INTERRUPTS SERVICE MECHANISM.pdf
 
Engineering Drawing section of solid
Engineering Drawing     section of solidEngineering Drawing     section of solid
Engineering Drawing section of solid
 
Research Methodology for Engineering pdf
Research Methodology for Engineering pdfResearch Methodology for Engineering pdf
Research Methodology for Engineering pdf
 
Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...
Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...
Comparative study of High-rise Building Using ETABS,SAP200 and SAFE., SAFE an...
 
System Simulation and Modelling with types and Event Scheduling
System Simulation and Modelling with types and Event SchedulingSystem Simulation and Modelling with types and Event Scheduling
System Simulation and Modelling with types and Event Scheduling
 
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMSHigh Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
High Voltage Engineering- OVER VOLTAGES IN ELECTRICAL POWER SYSTEMS
 
Earthing details of Electrical Substation
Earthing details of Electrical SubstationEarthing details of Electrical Substation
Earthing details of Electrical Substation
 
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
Robotics-Asimov's Laws, Mechanical Subsystems, Robot Kinematics, Robot Dynami...
 
Prach: A Feature-Rich Platform Empowering the Autism Community
Prach: A Feature-Rich Platform Empowering the Autism CommunityPrach: A Feature-Rich Platform Empowering the Autism Community
Prach: A Feature-Rich Platform Empowering the Autism Community
 
Cost estimation approach: FP to COCOMO scenario based question
Cost estimation approach: FP to COCOMO scenario based questionCost estimation approach: FP to COCOMO scenario based question
Cost estimation approach: FP to COCOMO scenario based question
 
US Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of ActionUS Department of Education FAFSA Week of Action
US Department of Education FAFSA Week of Action
 
Paper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdf
Paper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdfPaper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdf
Paper Tube : Shigeru Ban projects and Case Study of Cardboard Cathedral .pdf
 
Ch10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdfCh10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdf
 
SOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATIONSOFTWARE ESTIMATION COCOMO AND FP CALCULATION
SOFTWARE ESTIMATION COCOMO AND FP CALCULATION
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
 
KCD Costa Rica 2024 - Nephio para parvulitos
KCD Costa Rica 2024 - Nephio para parvulitosKCD Costa Rica 2024 - Nephio para parvulitos
KCD Costa Rica 2024 - Nephio para parvulitos
 
"Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ..."Exploring the Essential Functions and Design Considerations of Spillways in ...
"Exploring the Essential Functions and Design Considerations of Spillways in ...
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating System
 
Energy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptxEnergy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptx
 
Computer Graphics Introduction, Open GL, Line and Circle drawing algorithm
Computer Graphics Introduction, Open GL, Line and Circle drawing algorithmComputer Graphics Introduction, Open GL, Line and Circle drawing algorithm
Computer Graphics Introduction, Open GL, Line and Circle drawing algorithm
 

[July/2015] Android Wi-Fi Direct/Display Overview and Performance Measurement (Extended)

  • 1. Android WiFi Direct & Performance Measurement Ph.D. HayoungYoon hyyoon@zvolti.com R&D Lead zVolti LLC. July., 2015 Present to Hyundai NGV
  • 2. About Me Experience 2 HayoungYoon (윤하영) zVolti Co-Founder & R&D Lead (2013~) WiFi Test Automation ITEC-Tokyo (Tokyo, Japan) Manager (2012~2013) WiFi P2P Data Sharing Solution I2R (Institute for Infocomm Research) (Singapore) Intern (2010) Peer-based Multimedia Distribution System National ICT Australia (Sydney,Australia) Intern (2009)
 Mobility Emulation for Wireless P2P App. Experiments Deutsche Telekom T-Labs (Berlin, Germany) Intern (2006)
 P2P Service Framework over WiFi network Education Gwangju Institute of Science and Technology (GIST) Ph. D., Information & Communications (2011)
 Master, Information & Communications (2006) Korean Aerospace University Bachelor, Telecom. & Info. Engineering (2004) COMPANY zVolti Seoul, Korea Saratoga, CA Founded Feb, 2013 Product & Service ZESTER
 Wi-Fi/BT Test Automation Solution Wi-Fi/BT Product QA Consulting Partners Samsung Mobile Comm. Broadcom Wireless Connectivity Samsung System LSI
  • 3. WiFi Direct Overview: Discovery • It’s not totally NEW connection methodology • 802.11-based access, security and association management • WiFi Direct sits on top of WiFi (MAC/PHY) S • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA DS DLS • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS ith miDLS • Switching only if local outgoing queues both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migr to other channel for short time and comeback • No additional H/W support by both t network interface card (NIC) and the • Average switching duration in MadWiF based implementation < 20ms CHA HB DS with miDLS Original • Switching only if both are empty • Not to loose • We propose and support two mo to other channe comeback • No additional H/ network interfac • Average switchin based implement CHA CHA CHB DS with iDLS Original • Localized commun • Consumes double infrastructure mod • Possible solutions • IEEE 802.11e DLS • H/W change nee • Can’t initiate DL • We propose iDLS • S/W change at end • Can initiate DL acr DS with miDLS Original • S b • • W s t c • N n • A b CHA CHA CHB scanscan scanscan p2p scan Legacy WiFi WiFi Direct 3
  • 4. Discover Non-AP P2P STA • In scan phase, a Probe. Req is transmitted all supported channels • In search phase, a Probe. Req is transmitted only to social channels (CH#1, CH#6, CH#11) • Q: How to find GO established in 5GHz band? DS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA DS with miDLS • No • We pr suppo to oth comeb • No ad netwo • Averag based CHA CHA CHB Listen Search or Scan P2PWildcard SSID P2P IE Wildcasrd BSSID Probe Req. Probe Resp. WPS/RSN/SR IE P2PWildcard SSID P2P IE Wildcasrd BSSID WPS/RSN/SR IE Broadcast or Unicast Unicast 4
  • 5. WiFi Direct Overview: ConnectionS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA DS DLS • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS ith miDLS • Switching only if local outgoing queues both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migr to other channel for short time and comeback • No additional H/W support by both t network interface card (NIC) and the • Average switching duration in MadWiF based implementation < 20ms CHA HB DS with miDLS Original • Switching only if both are empty • Not to loose • We propose and support two mo to other channe comeback • No additional H/ network interfac • Average switchin based implement CHA CHA CHB DS with iDLS Original • Localized commun • Consumes double infrastructure mod • Possible solutions • IEEE 802.11e DLS • H/W change nee • Can’t initiate DL • We propose iDLS • S/W change at end • Can initiate DL acr DS with miDLS Original • S b • • W s t c • N n • A b CHA CHA CHB connectconnect connectconnect p2p connect Legacy WiFi WiFi Direct GO GC WiFi WiFi Direct Security WEP/WPA1.0/WPA2.0/”NULL” WPA2.0 Connection OPEN/WPS/WPS2.0 WPS1.0/WPS2.0 PHY 802.11abgn/ac 802.11agn/ac 5
  • 6. WiFi/WiFi Direct Concurrency(1) 6 S • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA OVi: Direct-Link Communications DS iDLS • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS with miDLS • IEEE 802.11 is designed assuming tha single CH per BSS • Switching only if local outgoing queue both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices mig to other channel for short time and comeback • No additional H/W support by both network interface card (NIC) and th • Average switching duration in MadW based implementation < 20ms CHA CHB Single Channel Concurrent Mode p2p connect CH#1 CH#1 ~2012/1Q DS with miDLS Original • IEEE 802.11 i single CH per • Switching onl both are emp • Not to lo • We propose support two to other chan comeback • No additiona network inte • Average switc based implem CHA CHA CHB MOVi: Direct-Link Commu DS with iDLS Original • Localized comm • Consumes do infrastructure • Possible solutio • IEEE 802.11e D • H/W change • Can’t initiate • We propose iD • S/W change at • Can initiate D DS with miDLS Original • • • • • CHA CHA CHB p2p connect Same-Band Multi-Channel Concurrent Mode CH#1 CH#11 ~2012/3Q Time sharing exploiting 802.11 power-saving
  • 7. WiFi/WiFi Direct Concurrency(2) 7 S • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA OVi: Direct-Link Communications DS iDLS • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS with miDLS • IEEE 802.11 is designed assuming tha single CH per BSS • Switching only if local outgoing queue both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices mig to other channel for short time and comeback • No additional H/W support by both network interface card (NIC) and the • Average switching duration in MadW based implementation < 20ms CHA CHB Diff-Band Multi-Channel Concurrent Mode p2p connect CH#36 CH#11 ~2013/1Q MOVi: Direct-Link C DS with iDLS Original • Loc • C in • Pos • IE • • • We • S • C DS with miDLS Original • IEEE 802.11 is single CH per • Switching only both are empty • Not to loo • We propose an support two m to other chann comeback • No additional H network interf • Average switch based impleme CHA CHA CHB MOVi: Direct-Link Commu DS with iDLS Original • Localized commu • Consumes doub infrastructure m • Possible solution • IEEE 802.11e DL • H/W change n • Can’t initiate D • We propose iDL • S/W change at e • Can initiate DL DS with miDLS Original • • • • • CHA CHA CHB p2p connect CH#1 CH#1 1 Diff-Band Multi-Channel Concurrent Mode - the island CH#36 2013/1Q~ BT-COEX
  • 8. WiFi/WiFi Direct Concurrency(3) 8 MOVi: Direct-Link Communications DS with iDLS iginal • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA Vi: Direct-Link Communications DS DLS • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS th miDLS • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA HB p2p connect CH#1 CH#11 Diff-Band Multi-Channel Concurrent Mode - the island CH#36 ~2014/1Q BT-COEX MOVi: Direct-Link Com DS with iDLS Original • Localized • Consum infrastru • Possible s • IEEE 80 • H/W • Can’ • We prop • S/W ch • Can init Multi-channel iDLS (mi DS with miDLS Original • IEEE 802.11 is desig single CH per BSS • Switching only if loc both are empty • Not to loose pa • We propose and im support two mobile to other channel fo comeback • No additional H/W network interface c • Average switching d based implementati CHA CHA CHB MOVi: Direct-Link Communic DS with iDLS Original • Localized communicat • Consumes double cha infrastructure mode W • Possible solutions • IEEE 802.11e DLS (Dir • H/W change needed • Can’t initiate DL acro • We propose iDLS (int • S/W change at end-dev • Can initiate DL across Multi-channel iDL DS with miDLS Original • IEEE sing • Swit both • N • We supp to o com • No netw • Ave base CHA CHA CHB p2p connect CH# CH#1 CH#3 2014/1Q~ BT/BLE-COEX Diff-Band Multi-Channel Concurrent Mode BT/BLE Coexist Limited toTime-Division Sharing
  • 9. WiFi/WiFi Direct Concurrency(4) 9 MOVi: Direct-Link Communications DS with iDLS Original • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS h miDLS • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA HB MOVi: Direct-Link Communications DS with iDLS Original • Localized communication with a neighbor • Consumes double channel resource ion infrastructure mode WiFi • Possible solutions • IEEE 802.11e DLS (Direct-Link Setup) • H/W change needed at AP • Can’t initiate DL across BSSs (Basic Service Set) • We propose iDLS (inter-BSS DLS) • S/W change at end-devices • Can initiate DL across BSSs DS with miDLS Original • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA CHA CHB p2p connect CH# CH#1 CH#3 *2015/1Q~ BT/BLE-COEX Diff-Band Multi-Channel Concurrent Mode BT/BLE Coexist * 2015 MWC, BRCM - RSDB : http://www.broadcom.com/blog/wireless-technology/rsdb-gets-a-boost-from-broadcom-at-mwc/ Single BT/WiFi Chip CH#36 CH#1 1 **As if two 1x1 wifi chip for each band ** None of commercial wifi device implemented this feature so far
  • 10. Who’s the Driver GB ICS JB KK Android Release Integration to JB Integrated to JB/KK 10 Integration to ICS WiFi Direct Concurrent Mode WiFi Display GoogleManufacturer Manufacturers adopt first Google makes it popular WiFi TDLS Integrated to KK
  • 11. Brief: S/W Dev. on Android 11 Linux Kernel Native Android Framework Android APP Android APIs • Whatever you do with APIs can run most of Android Devices* and you might be able to distribute your work via “App Market” *Target Android DeviceVersion must be greater than APP Calling APIs Custom C/C++ Code JNI Calling Custom C/C++ Code • You may use to build own C/C++ Library if you ➡ want to optimise the performance with your own ➡ want to access own H/W infrastructure • If your work requires changes in either the **standard “Android Framework” or “Linux Kernel”, your work may only work on your device **We are referring AOSP as a standard
  • 12. WiFi Direct on Android (1) 12 WiFi Device Driver Native Android Framework Android APP WiFi Chipset dependent 3rd party developers Manufacturer dependent Android OpenSource WiFi Direct capable device driver WiFi Direct Daemon WiFi Direct UI Ginger Bread Interface WiFi Direct APPsWiFi Direct APPs WiFi Direct capable device driver WiFi Direct Daemon WiFi Direct APPs WiFi Direct APIs Since IC Sandwich +ɑ +ɑ Android Framework WiFi Direct APP Hard to Dev.APPs & Poor inter-operability across manufacturers
  • 13. WiFi Direct on Android (2) 13 WiFi Device Driver Native Android Framework Android APP WifiMonitor WifiP2pManager wpa_supplicant WifiNative JNI:WifiNative Wifi (wifi.c) WiFi Driver WiFi Direct APP WiFi FW (P2P/STA) WifiP2pService WiFi Direct APPWiFi Direct APP WiFi FW (Softap) Used Selectively
  • 15. Case Study: How to Discover WiFi Direct Devices (1) 15 WifiMonitor WifiP2pManager WiFi Direct APP wpa_supplicant ::discoverPeers via Async Message : WifiP2pManager.DISCOVER_PEERS WifiP2pService JNI:WifiNative WifiNative ::p2pFind ::doBooleanCommand(P2PFIND) Wifi (wifi.c) ::doCommand(P2PFIND) via UNIX_SOCKET by wpa_cli: P2PFIND WiFi DR/FW via ioctl by chipset dependent kernel/user interface ::startMonitoring ::waitForEvent WiFi Direct APP WiFi Direct APP
  • 16. Case Study: How to Discover WiFi Direct Devices (2) 16 WifiMonitor WifiP2pManager WiFi Direct APP wpa_supplicant ::discoverPeers via Async Message : WifiP2pManager.DISCOVER_PEERS WifiP2pService JNI:WifiNative WifiNative ::p2pFind ::doBooleanCommand(P2PFIND) Wifi (wifi.c) ::doCommand(P2PFIND) via UNIX_SOCKET by wpa_cli: P2PFIND WiFi DR/FW via ioctl by chipset dependent kernel/user interface ::startMonitoring ::waitForEvent WiFi Direct APP WiFi Direct APP ANY APP register broadcast listener gets notified the changes of WiFi Direct PEER-DISCOVERED ::requestPeers ::onPeersAvailable
  • 17. Case Study: How to Create WiFi Direct Group (1) 17 WifiMonitor WifiP2pManager WiFi Direct APP wpa_supplicant ::connect (Peer MAC Address) via Async Message : WifiP2pManager.CONNECT WifiP2pService JNI:WifiNative WifiNative ::p2pConnect ::doStringCommand(P2PCONNECT) Wifi (wifi.c) ::doCommand(P2PCONNECT) via UNIX_SOCKET by wpa_cli: P2PCONNECT PEER MAC WiFi DR/FW via ioctl by chipset dependent kernel/user interface ::startMonitoring ::waitForEvent WiFi Direct APP WiFi Direct APP 1-to-1 Connection
  • 18. Case Study: How to Create WiFi Direct Group (2) 18 with miDLS to other cha comeback • No addition network int • Average swi based imple CHB th miDLS to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms HB To know whatWPS method available PROV-DISC-REQ PROV-DISC-RESP P2P-GROUP-FROM-REQ P2P-GROUP-FROM-RESP wpa_sup. wpa_sup. Framework Framework p2pConnect Popup to user INVITATION RECEIVED stopP2pFind p2pConnectUser OK Standard WiFi Protected Setup Procedure Q: Can APP know that someone has invited me? P2P-GROUP-NEGO-REQ P2P-GROUP-NEGO-RESP Become GO Start GO Become GC P2P-GROUP-NEGO-CONFM
  • 19. Case Study: How to Create WiFi Direct Group (3) 19 with miDLS • We propose a support two m to other chan comeback • No additional network inter • Average switc based implem CHA CHA CHB miDLS • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA wpa_sup. wpa_sup. Framework Framework GROUP-STARTED as GC L2 Connected GROUP-STARTED as GO DHCP Server DHCP Client Dynamic IP Allocation L3 Connected GROUP-STARTED as GC APP GROUP-STARTED as GO APP Application can talk each other
  • 20. Case Study: How to Remove WiFi Direct Group 20 with miDLS to other chan comeback • No additional network inter • Average switc based implem CHB miDLS to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA wpa_sup. wpa_sup. Framework Framework GROUP-STARTED as GC L2 Connected GROUP-STARTED as GC APP GROUP-STARTED as GO GROUP-STARTED as GO APPDHCP Server DHCP Client Dynamic IP Allocation L3 Connected p2pGroupRemove Standard 802.11 Disconnect Process p2pGroupRemove GROUP-REMOVEDGROUP-REMOVED GROUP-REMOVED GROUP-REMOVED DHCP 1. Detect STA disconnect 2. Check if no one connected p2pFind p2pFind starts automatically starts automatically
  • 21. Case Study: Persistent P2P Group (1) 21 DS miDLS • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA P2P Connection Request Q: Do we really need to bother the driver whenever she want to pair? A: Use Persistent P2P Group
  • 22. Case Study: Persistent P2P Group (2) 22 DS DLS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA P2P Connection Request (with Persistent Group Indication=true) L2 Connected Succeed GOGC { - Group SSID - Key - Credential - Type=GO - Peer-Mac Addr {- Group SSID - Credential - Type=GC - GO-Mac Addr Save to local storage Save to local storage It’s similar to you don’t need to enter PIN code to connect you HOMEWiFi Router everyday!
  • 23. Case Study: Persistent P2P Group (3) 23 DS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA P2P Connection Request (with Persistent Group Indication=true) - Group SSID - Credential - Type=GC - GO-Mac Addr checkup { wpa_sup.APP P2P-INVITATION-REQUEST { - Group SSID - Key - Credential - Type=GO - Peer-Mac Addr checkup L2 Connected Succeed GROUP-STARTED as GC No Popup Requests
  • 24. Case Study: Persistent P2P Group (4) 24 DS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA P2P Connection Request (with Persistent Group Indication=true) L2 Connected Succeed wpa_sup.APP - Group SSID - Credential - Type=GC - GO-Mac Addr checkup { P2P-INVITATION-REQUEST checkup => false P2P-INVITATION-REJECT { - Group SSID - Key - Credential - Type=GO - Peer-Mac Addr Delete Normal P2P Connection Procedure L2 Connected Succeed Connected as GC
  • 25. Case Study: Who Should Become GO (1) 25 DS with miDLS • Not to loose • We propose and support two mob to other channel comeback • No additional H/W network interface • Average switching based implementa CHA CHA CHB Intended to equally distribute the chance to become GO P2P-GROUP-NEGO-REQ/RESP/CONFM • GO transmits Beacon Packet • GO sleeps less than GC for • GO need to forward packet between two GCs • Car infotainment system is almost wall-powered • Mobiles are battery-powered How to make your BlueLink always become GO?
  • 26. Case Study: Who Should Become GO (2) 26 WifiP2pManager WiFi Direct APP ::connect (Peer MAC Address, WifiP2pConfig) WifiP2pConfig /** * This is an integer value between 0 and 15 where 0 indicates the least * inclination to be a group owner and 15 indicates the highest inclination * to be a group owner. * * A value of -1 indicates the system can choose an appropriate value. */ public int groupOwnerIntent = -1; @{Code} Multi-channel iDLS (miDLS) DS with miDLS Original • IEEE 802.11 is designed assuming th single CH per BSS • Switching only if local outgoing que both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices m to other channel for short time an comeback • No additional H/W support by bot network interface card (NIC) and • Average switching duration in Mad based implementation < 20ms CHA CHA CHB Multi-channel DS with miDLS Original • • • • • CHA CHA CHB Multi-channel iDLS (m DS Original • IEEE 802.11 is d single CH per B • Switching only i both are empty • Not to loos • We propose an support two m to other channe comeback • No additional H network interfa • Average switch based implemen CHA CHA CHB GO GC GC GC It is also beneficial for one-to-many P2P Group Setup! Android support “configurable GO Intent value”
  • 27. Case Study: One-to-Many Connection 27 *Invitation and Join DS with miDLS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms A CHA CHB • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA GO P2P-STAInvite DS with miDLS • • We sup to o com • No net • Ave bas CHA CHA CHB DS with miDLS • Not to loose packets • We propose and implem support two mobile WiF to other channel for sho comeback • No additional H/W supp network interface card ( • Average switching durati based implementation < CHA CHA CHB GO P2P-STAJoin *Android Application Develop does not have to care whether “Connect”,“Invite”, and “Join”. One is dynamically selected under the Framework S • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA GO DS with miDLS riginal • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA CHA CHB Invite Multi-channel iDLS (miDLS) DS with miDLS riginal • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA CHA CHB Invite Multi-channel iDLS (miDLS) DS riginal • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA CHA CHB Invite **Sequential Invitation ** Sequential invitation may use “Autonomous GO creation”
  • 28. WiFi / WiFi Direct Performance 28
  • 29. WiFi Throughput Performance on Mobiles 1Q/2011 4Q/2012 1Q/2014 *4Q/ 2014 1Q/ 2016 WiFi PHY 802.11g 802.11n
 802.11ac (wave1) 802.11ac (pre- wave2) 802.11ac (wave2) Archivable Throughput 10~15 Mbps 40~45Mbps (dual-Band, CB) >400Mbps (Quad-CB, MIMO, Beam-forming)
 <500Mbps (4x4 MIMO, Beam-forming)
 >700Mbps (Hexa-CB, MIMO, MU- MIMO, Beam- forming)
 Host computing power were even slower thanWiFi Speed! 29 Enough computing power on mobile for P2P,WFD *Product has released but features are blocked by FW : ASUSTM AC87U
  • 30. Reminder: MIMO vs SISO 30 Independent Spatial Path between RX andTX - Need “X 2TX power” to increase one bit/sec/Hz - Need N bit/sec/Hz increased with use of N antennas RX TX RX TX The Shannon Capacity
  • 31. Multiple Antenna Installation Does NOT Mean MIMO 31 802.11g (2.4GHz)Wireless Router Though the multiple antenna exist, the system is SISO if only a pair of TX/RX active at a time 20072006 RX TX Use one of two antennas selectively for better SINR And such MIMO comes since 802.11n
  • 32. MIMO: Spatial Diversity vs Spatial Multiplexing 32 Wider coverage and higher throughput because it is not likely to fail all on every available paths at the sometime RX TX Spatial Diversity: Sending/Receiving Redundant Stream Spatial Multiplex: Sending/Receiving Independent Stream ABCD…ABCD… RX TX BD…AC… ABCD… ABCD… Complex but it is like to have multiple TX/RX system at the same time so the gain is high
  • 33. IEEE 802.11ac Overview: Bitrate Evolutionary 33 up to 6.9Gbps - Channel Bonding - Multi-user MIMO - Beamforming - 256QAM - Better back/forward compatibility
  • 34. IEEE 802.11ac Overview: Channel Bonding 34 80211ac: 160MHz or (80MHz + 80MHz) 80MHz 80MHz 80MHz 80MHz 11a 11n 11ac 11ac *another 80MHz band from 149~161@ U-NII3 is omitted
  • 35. IEEE 802.11ac Overview: Beam-forming Basic 35 *Note that the signal starts at 0-degrees and is rising31/45 λ- 0- 0- amforming,#also#called#Beamsteering,#allows#electronic#aiming#of#the#strongest# nal#from#(and#the#best#recepXon#angle#to)#an#antenna#array# Two#antennas,#transmieng#the# same#signal,#with#both#antennas# transmieng#inIphase.# The#½#wavelength#separaXon# between#the#antennas#makes#the# signal#cancel#to#the#leh#and#right.# Note-that-the-signal-starts-at-0]degrees-and-is-rising- LEFT-to-RIGHT Signal Cancelation by sending in-phase signal λ/2 Chipset Beamforming – The Phased Array λ- No 180 b se si DOWN-to-UP Signal Cancelation by sending 180-degrees out-of-phase signal
  • 36. IEEE 802.11ac Overview: Beamforming 36 35/45 environment •  Attenuation and phase shift experienced by each spatial stream •  Transmit Beamforming and MU-MIMO require knowledge of the channel state to compute a steering matrix to optimize reception at one or more receivers –  Individual space-time streams are sounded separately –  Training symbols are transmitted (“Sounding Poll”) and measured by the recipient station (or stations) –  A channel state estimate is sent back to the beamformer from each station included in the Sounding Poll for the derivation of a steering matrix The environment is “sounded” to create a digital representation of the state of the transmission channel S • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA Multi-channel iDLS (miDLS) DS • IEEE 802.11 is designed assuming tha single CH per BSS • Switching only if local outgoing queue both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices mig to other channel for short time and comeback • No additional H/W support by both network interface card (NIC) and the • Average switching duration in MadW based implementation < 20ms CHA CHB VHT Null Data Packet Announcement frame VHT Compressed Beamforming frame (measured RF status)
  • 37. IEEE 802.11ac Overview: Multi-user MIMO 37 No uplink multi-user MIMO Much better Air-time fairness, where a number of poor quality links exists MCS9 MCS5 X bits X bits
  • 38. WiFi Throughput Performance 38 Hi, I’m 802.11ac GigabitWireless Router and can transfer more than 1Gbit/sec
  • 39. WiFi Throughput Performance: Range vs Rate 39 Only if you come closer • Measured received throughput performance • Latest Android Mobile Phone (11ac 2x2 MIMO) • NetgearTM R7000 • No interfering devices (shield env) • Injecting attenuation to the communication signal between mobile and AP
  • 40. WiFi Throughput Performance: WiFi/WiFi Direct Concurrent Mode 40 • Measured received throughput performance • Latest 2 Android Mobile Phone (11ac 2x2 MIMO) • NetgearTM R7000 • No interfering devices (shield env) If you talk only to me P2P AP-STA
  • 41. WiFi Throughput Performance: WiFi/BT Coexistence 41 • Measured received throughput performance • Latest Android Mobile Phone (11ac 2x2 MIMO) • NetgearTM R7000 • No interfering devices (shield env) BT/BLE-SCAN CH #6 Note: 11ac does not work at 2.4GHz.
  • 42. WiFi Throughput Performance: Interference vs Rate 42 • Measured received throughput performance • Latest Android Mobile Phone (11ac 2x2 MIMO) • NetgearTM R7000 • Typical Office Env where more than 30 APs are around Office-Midnight Note: 11ac does not work at 2.4GHz. Office-Daytime
  • 44. Android App Dev Workflow 44 Setup • Download SDK and Setup IDE ✓*EclipseTM or Android StudioTM * No official support by Google for Eclipse in the near future Development Publishing Debugging and Testing • Create UI and code • Build your code and testing • Release to application Markets
  • 45. Android SDK 45 Android APP Calling APIs • S/W Packages written in Java • To provide APIs to application developer android.hardware android.hardware. camera2 android.net android.media android.net.wifi android.bluetooth android.media.tv android.bluetooth.le android.net.wifi.p2p
  • 46. FYI: Google vs Oracle case 46 • API is a library with • each Package is a bookshelf in the library • each Class is a book on the shelf • each Method is a chapter out of how-to book 1심 판사의 판결문중… Library as a Metaphor android.net.wifi.p2p android.net.wifi.p2p.WifiP2pManager android.net.wifi.p2p.WifiP2pManager.connect()
  • 47. Brief: S/W Dev. on Android 47 Linux Kernel Native Android Framework Android APP Android APIs What we do focus on Calling APIs Custom C/C++ Code JNI Calling Custom C/C++ Code • Whatever you do with APIs can run most of Android Devices* and you might be able to distribute your work via “App Market” * Application’sTarget Android DeviceVersion must be greater than APP
  • 48. Android Wi-Fi Direct API 48 WifiMonitor WifiP2pManager WifiNative WifiP2pService
  • 49. Summary • WiFi Direct is a “SOFT” extension of existing WiFi to allow WiFi P2P communication without infrastructure • AndroidTM provides complete WiFi Direct SDK since the version of Ice Cream Sandwich • We review end-to-end interaction of AndroidTM WiFi Direct Stack implementation • New 802.11ac provide very high throughput more than 1Gbit/sec • But the practical performance of WiFi/WiFi Direct is affected by environmental condition and concurrent radio activity at WiFi devices. 49
  • 50. WiFi Display Control Plane & Implementation Case Study Ph.D. HayoungYoon hyyoon@zvolti.com R&D Lead zVolti LLC. July., 2015 Present to Hyundai NGV
  • 51. Table Of Contents 51 •WiFi Performance Issue (Review & Extended) •WiFi WMM (QoS) •WiFi Display Control Plane •WiFi Display Case Study (Android) •WiFi Display Case Study (Linux) •Quality Assurance (Extended)
  • 53. Range vs. Rate Test (1) 53 DS with miDLS • Not to loose • We propose and support two mo to other channe comeback • No additional H network interfac • Average switchin based implemen CHA CHA CHB Shield Env. RF Conducted Signal Attenuator short distance Change the AttenuationValue InTime Ethernet Traffic Generator DUT • Field test costs a lot but includes errors • “Range” is replicated by signal attenuation Time
  • 54. Range vs. Rate Test (2) 54 - Link quality i.e., RSSI (dBm) between AP- STA decreases (getting worse) in time as the level of attenuation increases - What if not changing it? Signal Attenuator DS with miDLS iginal • IEEE 802.11 is designed assum single CH per BSS • Switching only if local outgoing both are empty • Not to loose packets from • We propose and implement m support two mobile WiFi devi to other channel for short tim comeback • No additional H/W support b network interface card (NIC) • Average switching duration in based implementation < 20ms CHA CHA CHB - Link Speed (Mbps) is also getting lower as theWiFi adaptively changes its rate w.r.t. link quality with miDLS CHA C CHB
  • 55. Range vs. Rate Test (3) 55 - Link Speed (Mbps) does not tell the actual performance.Why? - May be due to bad selection - Packet Errors - We need to inject traffic and count # of bits received correctly
  • 56. Range vs. Rate Test (4) 56 - Convert RSSI vs Rate to Distance vs Rate - For those who does not familiar with RSSI (dBm)
  • 57. Range vs. Rate Test (5) 57 - Convert RSSI vs Rate to Distance vs Rate - For those who does not familiar with RSSI (dBm) - Getting RSSI from DUT might be erroneous for benchmarking - Use Attenuation vs Rate plot for benchmark if the configuration is same for DUTs - Q:Which one looks better? DUT2 DUT1
  • 58. RvR under BT-Coex (1) 58 DS with miDLS • Not to loose • We propose and support two mo to other channe comeback • No additional H network interfac • Average switchin based implemen CHA CHA CHB Shield Env. RF Conducted Signal Attenuator short distance Ethernet Traffic Generator DUT Change the AttenuationValue InTime • Same Setup but… • Pair DUT with BT-Device • InjectTraffic between DUT and BT- Device • No attenuation on the link between DUT and BT-Device BT-Paired
  • 59. RvR under BT-Coex (2) 59 WiFiTput (BT-COEX) BTTput WiFiTput (Standalone) - Q:Which one looks better? 2.4GHz BT-Coex Results
  • 60. RvR under BT-Coex (3) 60 WiFi RSSI per Antenna (BT-COEX) WiFi RSSI per Antenna (Standalone) - Q:Which one looks better? 2.4GHz BT-Coex Results
  • 61. RvR under BT-Coex (4) 61 WiFiTput (BT-COEX) BTTput WiFiTput (Standalone) - Q:Which one looks better? 5GHz BT-Coex Results
  • 62. RvR under BT-Coex (5) 62 WiFi RSSI per Antenna (BT-COEX) WiFi RSSI per Antenna (Standalone) - Q:Which one looks better? 5GHz BT-Coex Results
  • 63. RvR under BT-Coex (6) 63 WiFiTput (BT-COEX) BTTput WiFiTput (Standalone) - Q:Which one looks better? 2.4GHz BT-Coex Results
  • 64. RvR under BT-Coex (7) 64 WiFiTput (BT-COEX) BTTput WiFiTput (Standalone) - Q:Which one looks better? 5GHz BT-Coex Results
  • 65. RvR under BT-Coex (8) 65 WiFiTput (BT-COEX) BTTput (BT-COEX) Note: this is ideal environment where no external interference injected
  • 66. Busy Air (1) 66 P2P comm. T CH1 CH1 CH1 P2P comm. T - Separating P2P comm. over orthogonal freq. - CH1 CH6 CH11 - IEEE 802.11 support 11 orthogonal channels
  • 67. Busy Air (2) 67 P2P comm. T CH1 CH2 CH3 P2P comm. T - Separating P2P comm. over orthogonal freq. - CH1 CH6 CH11 - IEEE 802.11 support 9 orthogonal channels - takes longer to finish the transfer
  • 69. Brief:WMM/WME 69 • The principle of 802.11 resource allocation • Designed for the fairness • Give equal chance to all devices willing to access • Contention-based Medium Access DS with miDLS Original • IEEE 802.11 is design single CH per BSS • Switching only if loca both are empty • Not to loose pack • We propose and imp support two mobile W to other channel for comeback • No additional H/W s network interface ca • Average switching du based implementatio CHA CHA CHB DS with miDLS Original • single C • Switchi both ar • No • We pro suppor to othe comeb • No add networ • Averag based i CHA CHA CHB CH1 data to transfer DS with miDLS Original CHA CHA CHB CH1 Note: separate BSSs sharing carrier-sense range are considered as single “scheduling domain”
  • 70. Brief:WMM/WME 70 • Problem • HOL (Head of line problem) TX-Queue STA1’ sTX-Queue STA2’ sTX-Queue VoIP WWW WWW WWW MAC MAC MAC delaying access for others VoIP VoIP VoIP WWW WWW WWW Fairness is not always good
  • 71. Brief:WMM/WME 71 • How? • Give more chance to use wireless communication resource to QoS-demanding traffic • Virtualise MAC to content within single device • WMM provides 4 Access Categories • Each vMac has different chance to access to the physical medium MAC vMAC vMAC vMAC vMAC BE BK VI VO VoIP VoIP VoIP www www www Video Video www www www
  • 72. WMM: QoS Differentiation 72 STA1 DS ith miDLS single CH per BSS • Switching only if local outgoing queues both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migr to other channel for short time and comeback • No additional H/W support by both t network interface card (NIC) and the • Average switching duration in MadWiF based implementation < 20ms CHA HB STA2 BE: 20Mbps ith miDLS • We propose and implement miDLS support two mobile WiFi devices migr to other channel for short time and comeback • No additional H/W support by both t network interface card (NIC) and the • Average switching duration in MadWiF based implementation < 20ms CHA HB VO: 24Mbps • Measured received throughput performance • Shielded Environment (5GHz) • Use 802.11a • Atheros Chipset
  • 73. WMM: QoS Differentiation 73 DS • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA BE: 10MbpsVO: 40Mbps • Measured received throughput performance • Shielded Environment (5GHz) • Use 802.11a • Atheros Chipset
  • 74. WMM: QoS Differentiation 74 DS • IEEE 802.11 is designed assuming that single CH per BSS • Switching only if local outgoing queues at both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA BK: 10MbpsVO: 40Mbps • Measured received throughput performance • Shielded Environment (5GHz) • Use 802.11a • Atheros Chipset
  • 76. Is WMM Good for… • V2X? • AC_VI for Emergent MSG? • Head unit? • Design Issue! • Multiplexed TS packets may be mixed up for WFD case 76
  • 77. Learn from Mobile Industry: Metal… 77 - One RF engineer says: adopting the metal body is the most challenging task ever since the first WiFi integration into the mobile phone Same Distance btw. TX/RX but …
  • 78. Metal vs. Non-Metal: Performance w.r.t DUT Position (1) 78 Fixed AP Location Various DUT position RF Shielded Env. Traffic Generator • Manipulate DUT positions against AP’s antenna over two polar coordinates • Measure TX/RX Throughput for each position • Video Demo
  • 79. Metal vs. Non-Metal: Performance w.r.t DUT Position (2) 79 Non-Metal Metal • 6 different position across TILT (Vertical) • 18 different position across PAN (Horizontal) • Measure for 100 sec for each position • Sleep 100 sec between measurement (WHY?) - Q:Which one looks better? Mbps Iteration Mbps Iteration A:301/m:272/M:335/D:14 A:485/m:390/M:572/D:38
  • 80. Metal vs. Non-Metal: Performance w.r.t DUT Position (3) 80 Non-Metal Metal • Map position info (PAN-Angle,TILT-Angle) to rectangular coordinates • Normalise sample value for each position • Map the value to a Bubble - Q:Which one looks better? - Put a little bit of make up TILT PAN TILT PAN
  • 81. Metal vs. Non-Metal: Performance w.r.t DUT Position (4) 81 Non-Metal Metal- Q:Which one looks better? - Vertical Map (Top)
  • 82. Metal vs. Non-Metal: Performance w.r.t DUT Position (5) 82 Non-Metal Metal- Q:Which one looks better? - Horizontal Map (Side))
  • 84. Overview:WFD Components 84 SRC Primary SINK Secondary SINK (Optional) LPCM LPCM Time Synch: gPTP in 802.1AS UIBC
  • 85. Overview:WFD is a Multi-player Game • AP (or GPU)Vendors • Better performing AV processor • WiFi ChipsetVendors • Fast/Reliable/Energy-efficient WiFi • Manufacturers • Optimal deployment of communication and AV processing units • Smooth UX designs • WFD Solution Provider • Cross-platform/Cross-chipset vendor WFD Architecture and Requirements 3-1 illustrates the functional blocks in the Wi-Fi Display data and control planes. The data plane s of video codec (section 3.4.2 and 3.4.4), audio codec (section 3.4.1), PES packetization (Annex-B), CP system 2.0/2.1 (section 4.7), and MPEG2-TS over RTP/UDP/IP (section 4.10.2 and Annex-B). ntrol plane consists of RTSP over TCP/IP (section 6), remote I2C Read/Write (section 7), UIBC IDC and generic user input (section 4.11), and the HDCP session key establishment (section 4.7). -Fi P2P/TDLS block forms the layer-2 connectivity using either Wi-Fi P2P or TDLS as described in 4.5. TCP Control (RTSP) CapabilityNegotiation,SessionEstablishment, MaintenannceandManagement L2SetupandDiscoveryAssist RTP UDP IP Wi-Fi P2P / TDLS and Wi-Fi Protected Setup UIBC Capsulation UserInputData Generic HIDC HDCP2.0ControlMessage MPEG2-TS PES packetization Audio codec Video codec HDCP 2.0 / 2.1 Remote I2C R/W I2CData Figure 3-1 : Logical Data and Control Plane Connections WFD Source, Primary Sink, Secondary Sink and WFD85
  • 86. WFD Session Establishment • Use RTSP to exchange WFD Capability and setup streaming session 86 th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB WiFi Direct Connected GC SRC SINK TCP connect to {IP:Port from WFD IE} GO M1-REQ M1-RESP 1. SRC gets SINK’s AV playout and rendering capability (M3) 3. SRC choses the best configuration 5. SRC set SINK’s AV Processing Configuration (M4) 7. Trigger AV Streaming (M6,M7) . . . M7-PLAY-REQ M7-PLAY-RESP Start AV Streaming . . . Q:Why SRC becomes GC?
  • 87. WFD Session Management 87 • Use RTSP to Control Playback th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB GC SRC SINK GOStart AV Streaming M7-PLAY-REQ M7-PLAY-RESP AV Streaming . . . M9-PAUSE-REQ M9-PAUSE-RESP . . . M5-TRIGGER-REQ {PLAY} M5-TRIGGER-RESP-{PLAY} • No RTSP specification to control playback by SERVER • WFD uses Trigger method with playback control as a parameter
  • 88. WFD Session Termination 88 • Teardown process is same to generic RTSP streaming th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB GC SRC SINK GOStart AV Streaming M8-TEARDOWN-REQ M8-TEARDOWN-RESP • It is “out-of-scope” that actions after teardown process • One may keep WiFi Direct connection to save connection time for next session establishment or M5-TRIGGER-REQ {TEARDOWN} M5-TRIGGER-RESP-{TEARDOWN} M8-TEARDOWN-REQ M8-TEARDOWN-RESP Q: Keeping P2P connection is Good?
  • 89. WFD Session Keep Alive 89 • WFD Source should check the sanity of WFD Session th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB GO SRC SINK GCAV Streaming in Progress M16-GET_PARAM-REQ M16-GET_PARAM-RESP• TIMEOUT in M6-SETUP • Should be larger than 10 sec • Default 60 sec • Android sets 30 sec • Certification process requires 120 sec to be tested . . . At least one within TIMEOUT - 5 sec TIMEOUT Detect Session Broken! • SRC should teardown RTP/ RTSP sessions Something wrong! Q:What happen if a device goes wrong before RTSP? M16-GET_PARAM-REQ
  • 90. User Input Back Channel (1) 90 • UIBC delivers user actions on WFD Sink to the WFD Source • A separate (independent) UIBC Session (different Port) runs on-demand th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB SRC SINK M14-SET_PARAM-REQ M14-SET_PARAM-RESP • WFD Source can selectively enable/disable UIBC session via RTSP M15 AV Streaming in Progress Exchange UIBC Capability M4-SET_PARAM-REQ M4-SET_PARAM-RESP UIBC Session / TCP UIBC Data Note: AV Streaming and UIBC Session runs parallel! Update UI . . . When UIBC session is disabled?
  • 91. User Input Back Channel (2) 91 • What actions to deliver? • Generic • Mouse • Single/Multi Touch • V/H Scrolling • Rotate • Key Up / Down (WHAT-KEY-ASCII) • … • HDIC (Human Interface Device Class) • Mouse / BT • Remote Control / Infrared • Vendor Specific /Vendor Specific • … Type / InputPath Both WFD Sink / WFD Src should agree with same capability to receive and respond to the “input”Q:When the capability should be updated?
  • 92. Remote I2C (1) • WFD only defines the data path for delivering I2C transactions • Manufacturer specific data structure 92 It’s Like TV Remote Control
  • 93. Remote I2C (2) 9393 • A separate (independent) I2C Session (different Port) runs on-demand th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB SRC SINK AV Streaming in Progress I2C port M3-GET_PARAM-REQ M3-GET_PARAM-RESP I2C Session / TCP I2C Read/Write Request Note: AV Streaming and I2C Session runs parallel! listen on I2C port . . . I2C Read/Write Reply
  • 94. Remote I2C (3) 9494 • Read Request Data Structure (TLV) 0x00 WB-Cnt=N WB-Data[1] . . . WB-Data[N] Read From Read L Write Block variable Write To W-Cnt=X B[1] . . . B[X] NOSTOP Delay • Write Request Data Structure (TLV) 0x01 . . .Write Data Write To W-Cnt=X B[1] B[X] 1Byte Write Data Transferred from SRC to SINK
  • 95. Remote I2C (4) 9595 • Read Reply ACK • Read Reply NACK • Write Reply ACK • Write Reply NACK 0x00 . . . Write Data R-Cnt=X B[1] B[X] Transferred from SINK to SRC 0x80 0x01 0x81 • For Implementation side, parsing bit stream in to MSG is required. • Thanks to TCP, bits are never mixed nor errored. • Security? • No, authentication for I2C session
  • 96. AV Processing & Transport 96
  • 97. AV Streaming Format 97 • NAL / MPEG PES / MPEG2 TS / RTP /UDP • Not the best but mostly accepted for the compatibility Reference RTP header PT field ‘33’ from [4], [6] for MPEG2-TS Marker bit (M) ‘1’ whenever timestamp is discontinuous from [4] RTP Timestamp 32-bit timestamp derived from a 90 kHz clock, representing the target transmission time for the first byte of the packet. This clock is synchronized to the system stream PCR (TS) or the SCR (PS), and represents the target transmission time of the first byte of the packet payload. from [4] Table B- 5- RTP encapsulation of MPEG-TS3488 3489 Figure B- 1 Example of Recommended Encapsulation of MPEG2-TS Packets3490 Reference RTP header PT field ‘33’ from [4], [6] for MPEG2-TS Marker bit (M) ‘1’ whenever timestamp is discontinuous from [4] RTP Timestamp 32-bit timestamp derived from a 90 kHz clock, representing the target transmission time for the first byte of the packet. This clock is synchronized to the system stream PCR (TS) or the SCR (PS), and represents the target transmission time of the first byte of the packet payload. from [4] Table B- 5- RTP encapsulation of MPEG-TS3488 3489 Figure B- 1 Example of Recommended Encapsulation of MPEG2-TS Packets3490 Reference RTP header PT field ‘33’ from [4], [6] for MPEG2-TS Marker bit (M) ‘1’ whenever timestamp is discontinuous from [4] RTP Timestamp 32-bit timestamp derived from a 90 kHz clock, representing the target transmission time for the first byte of the packet. This clock is synchronized to the system stream PCR (TS) or the SCR (PS), and represents the target transmission time of the first byte of the packet payload. from [4] Table B- 5- RTP encapsulation of MPEG-TS3488 3489 Figure B- 1 Example of Recommended Encapsulation of MPEG2-TS Packets3490
  • 98. MPEG2 TS Encapsulation 98 Start code Start code Start code header headerpayload payload elementary stream elementary stream header header header …payload payload payload PES Packets stream PES Packets stream PES Packets stream PES Packets 188 Bytes 188 Bytes 188 Bytes Elementary Stream (Compressed audio, video, or PSI data) TS Packets
  • 99. AV Streaming Format 99 • Considering MTP size of Ethernet, 7 MPEG2 TS packets (188B) fits into single RTP payload
  • 100. Key WFD Performance: Packet Loss 100 • Can’t avoid • MAC retransmission is not enough • UDP/RTP has no ACK/NAK feedback • ARQ may not be employed for latency
  • 101. Key WFD Performance: Packet Loss 101 Wi-Fi Display Technical Specification D1.44 491 • Splitting single AV unit across packet chain for the error resilience • Assuming that AV decoder performs sort of error mitigations
  • 102. Key WFD Performance: Packet Loss 102 Which One Looks Better?
  • 103. Priority in CompressedVideo 103 P5B2P3B2 B4I1 Initial Object Descriptor ES_Descriptor ES_Descriptor Scene Description Stream Object Description Stream Visual Stream Visual Stream Audio Stream … Scene Graph <GOP Structure> Reference to decode Video consists of media units with different priority Video frames with different priority MPEG: I > P > B Video Objects with different priority MPEG-4: Meta > Audio stream > Video stream Note: WFD does not allow B frames in use.WHY?
  • 104. Packet Loss Propagation inVideo Decoding 104 I P P P P P I . . . P P P P P . . . GOP (Group of Pictures) • GOP Size tends to be variable • Packet loss could damage to the subsequent frame decoding decoding dependency time . . .
  • 105. IDR Request By WFD Sink 105 • Video decoder at WFD Sink may require “Refresh” to receive IDR (Instantaneous Decoder Refresh) th miDLS • We propose and implement miDLS support two mobile WiFi devices migra to other channel for short time and comeback • No additional H/W support by both th network interface card (NIC) and the A • Average switching duration in MadWiFi based implementation < 20ms CHA HB with miDLS • • • CHA CHA CHB GO SRC SINK GCAV Streaming in Progress M13-SET_PARAM-REQ M13-SET_PARAM-RESP • No changes in RTP/RTCP session • Transparent to the AV/Codec Layer • Modern video DSPs can reproduce IDR within acceptable latency Network Stack or Decoder detects erros AV Streaming Restarts with IDR Q: Is every frame at the beginning of streaming IDR frame? “Refresh”Video Encoder to get IDR Flush all buffered frames @ decoder upon IDR reception
  • 106. Key WFD Performance: Latency • Require <50 msec glass-to-glass latency for fluent 3D Action gaming 106 FB Capture Scaling a frame H.264 Video Encoding Packetization Audio Sampling Audio Encoding Packetization glass-to-glass latency UDP/RTP Encapsulation AV Mux AV Packet Transmit SRC-side Video Decoding Audio Decoding Render Video Play Audio SINK-side AV Packet Reception AV Demux Kernel-to-Kernel Propagation
  • 107. Latency Analysis (1) 107 Encoding latency Experiments Results • CDF of 2000 samples of latency measure • 99% of samples are within 5msec • Avg. :4.5 msec • Dev.: 0.137msec 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 3.8 4 4.2 4.4 4.6 4.8 5 P(X>x) channel switching latency (msec) Monday, December 20, 2010 Experiments Results • CDF of 2000 samples of latency measure • 99% of samples are within 5msec • Avg. :4.5 msec • Dev.: 0.137msec 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 3.8 4 4.2 4.4 4.6 4.8 5 P(X>x) channel switching latency (msec) Monday, December 20, 2010 H.264 720p Per-frame Encoding Latency Measured on 2012/Late Android Mobile (ICS) - QCA QuadCore S4 Pro
  • 108. Latency Analysis (2) 108 Sampling = 30fps I P 4.5msec 33.3msec TS TS TS RTP RTP RTP TS TS TS RTP RTP RTP OverWiFi Playout F [bits] / Mbps 4.5msec Decoder Buffering Note: Decoding time much less than encoding time! . . . F Decoding Latency Packetization DePacketization
  • 109. Latency Analysis (3) 109 Sampling = 60fps I P 4.5msec 16.7msec TS TS TS RTP RTP RTP TS TS TS RTP RTP RTP OverWiFi Playout F [bits] / Mbps 4.5msec Decoder Buffering Note: Decoding time much less than encoding time! F Decoding Latency . . . Packetization DePacketization
  • 110. Latency Analysis (4) 110 Jitter mitigation Throughput Time Good RTP RTP RTP RTP RTP RTP OverWiFi [bits] / Mbps Jitter Buffer is needed for both Intra-media and Inter-media Sync
  • 112. WFD on Android 112 Native Android Framework Android APP AV Chipset dependent Manufacturer dependent Android OpenSource* Framebuffer / Audio out Handling WFD Daemon (WiFi Direct / RTSP/RTP) WFD UI Early Jellybean (~4.1) JNI libstageFright/wifi-display libstageFright/foundation OMX WFD APPs SurfaceFlinger/DisplayManager/ Remote Display Device Since Late Jellybean (4.2~) +ɑ +ɑWFD APP Hard to Dev.APPs & Poor inter-operability across manufacturers AV DSP / WiFi Chipset Kernel/Driver Media Player H/W Codec H/W Codec {pre-standard} *As of Android 4.4.4WFD APIs a part of AOSP but not a part Android Framework , the operation ofWFD APIs is highly depend upon device capability
  • 113. *WFD on Android: Key Components DisplayManagerServi ce WifiDisplayAdapter WifiDisplayControll er WifiDisplay WifiDisplayDevice RemoteDisplay RemoteDisplay WifiDisplaySourceANetworkSession MediaSender RTPSender RepeaterSource NuMediaExtractor MediaPuller Converter MediaRouter WifiP2pManager NuPlayer SurfaceComposerClient OMX WFD Setting APP wpa_supplicant / wpa_cli C++ LibraryJava LibraryUI/APP Executable Presentation **Only for *Since Android 4.3 Google has removed otherWFD Sink core logics from AOSP **The component list is gathered from AOSP 4.4113
  • 114. *WFD on Android: Key Components -Code Location in AOSP- $(BASESVC)/display/ DisplayManagerService.j $(BASESVC)/display/ WifiDisplayAdapter.java $(BASESVC)/display/ WifiDisplayController.ja $(BASEHW)/display/ WifiDisplay.java $(BASESVC)/display/ WifiDisplayAdapter.java $(MEDIASVC) / RemoteDisplay.cpp $(BASEMDL)/ remotedisplay/ $(WFD)/source/ WifiDisplaySource.cpp $(FOUNDATION)/ ANetworkSession.cpp $(WFD)/ MediaSender.cpp $(BASEHW)/hw/ RTPSender.java $(WFD)/source/ RepeaterResource.cpp $(AVLIB)/nuplayer/ NuMediaExtractor.cpp $(WFD)/source/ MediaPuller.cpp $(WFD)/source/ Converter.cpp $(SUPP)/v7/media/ MediaRouter.java $(NET)/wifi/p2p/ WifiP2pManager.java $(AVLIB)/nuplayer/ NuPlayer.cpp $(GUI)/ SurfaceComposerClient.cpp $(OMX)/OMX.cpp $(PKG)/wfd/WifiDisplaySettings.java $(ETERNAL)/wpa_supplicant_8/wpa_supplicant/src/ C++ LibraryJava LibraryUI/APP Executable $(CORE)/Presentation.java **Only for *Since Android 4.3 Google has removed otherWFD Sink core logics from AOSP **The component list is gathered from AOSP 4.4114
  • 115. Case Study: How to Discover WFD Devices (1) 115 DisplayManagerServi ce WifiDisplayAdapter WifiDisplayControll er WifiMonitor MediaRouter WifiP2pManager WFD Setting APP wpa_supplicant Getting Lock / Register Callback ::startWifiDisplayScan ::requestStartScanLocked ::requestStartScan ::discoverPeers via Async Message : WifiP2pManager.DISCOVER_PEERS WifiP2pService JNI:WifiNative WifiNative ::p2pFind ::doBooleanCommand(P2PFIND) Wifi (wifi.c) ::doCommand(P2PFIND) via UNIX_SOCKET by wpa_cli: P2PFIND WiFi DR/FW via ioctl by chipset dependent kernel/user interface ::setWfdInfo ::startMonitoring ::waitForEvent Q: WHY Only Single APP?
  • 116. Case Study: How to Discover WFD Devices (2) 116 DisplayManagerServi ce WifiDisplayAdapter WifiDisplayControll er WifiMonitor MediaRouter WifiP2pManager WFD Setting APP wpa_supplicant Getting Lock / Register Callback ::startWifiDisplayScan ::requestStartScanLocked ::requestStartScan ::discoverPeers via Async Message : WifiP2pManager.DISCOVER_PEERS WifiP2pService JNI:WifiNative WifiNative ::p2pFind ::doBooleanCommand(P2PFIND) Wifi (wifi.c) ::doCommand(P2PFIND) via UNIX_SOCKET by wpa_cli: P2PFIND WiFi DR/FW via ioctl by chipset dependent kernel/user interface ::setWfdInfo ::startMonitoring ::waitForEvent via MSG_Broadcast (MSG_SEND_STATUS _CHANGE_BROADCAST) WifiDisplay[]
  • 117. Case Study: How to Discover WFD Devices (3) 117 DisplayManagerServi ce WifiDisplayAdapter WifiDisplayControll er WifiMonitor MediaRouter WifiP2pManager WFD Setting APP wpa_supplicant Getting Lock / Register Callback ::startWifiDisplayScan ::requestStartScanLocked ::requestStartScan ::discoverPeers via Async Message : WifiP2pManager.DISCOVER_PEERS WifiP2pService JNI:WifiNative WifiNative ::p2pFind ::doBooleanCommand(P2PFIND) Wifi (wifi.c) ::doCommand(P2PFIND) via UNIX_SOCKET by wpa_cli: P2PFIND WiFi DR/FW via ioctl by chipset dependent kernel/user interface ::setWfdInfo ::startMonitoring ::waitForEvent via MSG_Broadcast (MSG_SEND_STATUS _CHANGE_BROADCAST) WifiDisplay[] WiFi Direct Native SubLayer
  • 118. Case Study: How to Connect WFD Sink (1) 118 WifiDisplayAdapter WifiDisplayControll er WifiP2pManager WFD Setting APP ::connectWifiDisplay ::requestConnectLocked ::connect ::connect ::setMiracastMode SRC) onGroupInfo Available RemoteDisplay WiFi Direct Native SubLayer ::connect ::listen (INTF: PORT) JNI:RemoteDisplay RemoteDisplay ::startListen ::nativeListen WifiDisplaySource ::start Sync MSG kWhatStart ANetworkSession ::createRtspSession Session ASync MSG kWhatStart, … M1…MX onM6RxNoError PlaybackSession ::init ::play, ::pause,… upon MX MediaSender videoTrackaudioTrack RTPSender WFD Source AV/Codec SubLayer tsPkt cfg tsPkt Socket RTSPServer DisplayManagerSer vice
  • 119. Case Study: How to Connect WFD Sink (2) 119 WifiDisplayAdapter WifiDisplayControll er DisplayManagerSer vice WifiP2pManager WFD Setting APP ::connectWifiDisplay ::requestConnectLocked ::connect ::connect ::setMiracastMode SRC) onGroupInfo Available RemoteDisplay WiFi Direct Native SubLayer ::connect ::listen (INTF: PORT) JNI:RemoteDisplay RemoteDisplay ::startListen ::nativeListen WifiDisplaySource ::start Sync MSG kWhatStart ANetworkSession ::createRtspSession Session ASync MSG kWhatStart, … M1…MX onM6RxNoError PlaybackSession ::init ::play, ::pause,… upon MX MediaSender videoTrackaudioTrack RTPSender WFD Source AV/Codec SubLayer tsPkt cfg tsPkt Socket RTSPServer Only for WFD Source Capability
  • 120. Case Study: Extension for WFD Sink 120 WifiDisplayAdapter WifiDisplayControll er WifiP2pManager WFD Setting APP ::connectWifiDisplay ::requestConnectLocked ::connect ::connect::setMiracastMode (SINK) onGroupInfo Available WifiDisplaySink WiFi Direct ::connect ::connect (INTF: PORT) JNI:WifiDisplaySink ::connect WifiDisplaySink ::start Sync MSG kWhatStart ANetworkSession ::createRtspSession Session ASync MSG kWhatStart, … M1…MX onM6RxNoError BnMediaPlayerClient ::init ::connect ::play, ::pause,… upon MX TunnelRenderer videoTrack audioTrack RTPSink tsPkt Socket RTSPServer Reuse Android 4.2 AOSP Code Small Modification Create Your Own DisplayManagerSer vice
  • 121. Case Study: User Input Back Channel (1) 121 Video Player Transparent Layer Touch Screen WFD Sink App H/W Abstract Transparent Activity - Programmatically detect User Action (TOUCH)
  • 122. Case Study: User Input Back Channel (2) 122 Transparent Activity UIBC Translater Video Player (minX, minY) (maxX, maxY) WFD AV Session Config (minX, minY) Action, x, y (|Src-X|, |Src-Y|) Dismiss for invalide action Action, NewX, NewY @ WFD Src - Check the validity of User Action UIBC Data over TCP/IP Dismissed Dismissed UIBC Session RX UIBC Session TX @ WFD Sink
  • 123. Case Study: User Input Back Channel (3) 123 UIBC Session TX UIBC Session RX @ WFD Src - Apply UIBC Data at WFD SRC UIBC Data over TCP/IP InputEvent *InputManager *./frameworks/base/core/java/android/ hardware/input/InputManager.java Virtual Touch Event Application Running on WFD SRC has no idea whether the action comes from itself (by user) or from WFD Sink via UIBC. Transparency! @ WFD Sink
  • 124. Case Study: Use of TCP Transport (1) 124 If the source frame rate is not 60 fps, the End-to-End latency is anyway not enough for realtime gaming experience, The Tradeoff - If we recover packet loss, we have to be tolerant with Quality degradation -You have to explain why this is happening to you QA manager and to the customer - TCP slower than UDP, but guarantee the PER=0. - Why not to use TCP?
  • 125. Case Study: Use of TCP Transport (2) 125 There is code for using TCP in the Android Source. If your WFD sink can handle “RTP/AVP/TCP”, you can put it into M3 Response The certification? Certification is okay as long as you can handle “RTP/AVP/UDP”
  • 126. Case Study: Noticeable Lollipop’s new API - android.media.projection - android.bluetooth.le - Allow you to capture screen at API-level - No audio capturing supported - Allow your device works as BLE Peripheral - Your head unit can advertise the location over BLE like a beacon - You may be able to build your own Android App to screencast
  • 128. Case Study:WFD Source & Sink on Linux (1) • Streaming one’s display output to another is not “NEW” for Linux - VNCTM supports for WFD’s UIBC like functionalities for keyboard and mouse • Open source tools for capture, compress, and streaming of Desktop’s frame buffer - FFmpegTM is the best IMO • Open source RTP/RTSP Streaming clients are readily available - VLCTM (Video Lan Client) is commercial-quality streaming client (and server) • Most Linux distribution uses wpa_supplicant for WiFi controls & managements as AndroidTM does BUT why there is no “WORKING” Linux WFD Source & Sink ?
  • 129. • No WiFi Direct support by default in the most Linux distribution • Not all WiFi chipsets for Desktop/Laptop support WiFi Direct feature (at F/W level) - List of IntelTM WiFi Chipset for WiFi Direct Support (link) That is… • Recall HOW WFD Devices distinguish WFD Devices from other WiFi Direct Devices in discovery process • Can the vendor-specific WiFi F/W allow to insert “WFD IE (Information Element)” into IEEE 802.11 control packets? You may be able to active WiFi Direct … but Case Study:WFD Source & Sink on Linux (2)
  • 130. Inside of WFD IE (1) • TLV as other IEs • 11 types of WFD Subelements are defined (D 1.44) • WFD Device Information (Type=0) is the most useful for discovering WFD Devices WFD IE Header WFD Subelements WFD IE ID=0 Length=6 WFD Device Information Session Management Control Port WFD Device Maximum Throughput 2 2 221Octets
  • 131. Inside of WFD IE (2) 131 ID=0 Length=6 WFD Device Information Session Management Control Port WFD Device Maximum Throughput 2 2 221Octets ... Audio Only supported bit @ SRC Audio unsupported bit @ SINK ... WFD Session Availability ... Device Type Bits 1 1 2 2 2Byte TCP Server Port @ SRC WFD Device’s maximum tolerable throughput 0b00 SRC 0b01 P-SINK 0b10 S-SINK 0b11 Dual 0b00 Not Avail. 0b01 Available 0b10 Reserved 0b11 Reserved SRC can only send Audio SINK can only render video
  • 132. Discover Non-AP P2P STA • In scan phase, a Probe. Req is transmitted all supported channels • In search phase, a Probe. Req is transmitted only to social channels (CH#1, CH#6, CH#11) • Q: How to find GO established in 5GHz band? DS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA DS with miDLS • No • We pr suppo to oth comeb • No ad netwo • Averag based CHA CHA CHB Listen Search or Scan P2PWildcard SSID P2P IE Wildcasrd BSSID Probe Req. Probe Resp. WPS/RSN/SR IE P2PWildcard SSID P2P IE Wildcasrd BSSID WPS/RSN/SR IE Broadcast or Unicast Unicast 132
  • 133. Discover WFD Device • WFD uses Wi-Fi Direct • WFD IE carries • device-type: SRC? or SINK? • device-status: Busy? or Ready? DS • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrate to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the AP • Average switching duration in MadWiFi- based implementation < 20ms CHA DS with miDLS • No • We pr suppo to oth comeb • No ad netwo • Averag based CHA CHA CHB Listen Search or Scan P2PWildcard SSID P2P IE + WFD IE Wildcasrd BSSID Probe Req. Probe Resp. WPS/RSN/SR IE P2PWildcard SSID P2P IE + WFD IE Wildcasrd BSSID WPS/RSN/SR IE Broadcast or Unicast Unicast 133
  • 134. • L3 Connectivity in WiFi Direct Group may not be working correctly • Need to change the DHCP Server operations when WiFi Direct is running And… Case Study:WFD Source & Sink on Linux (3) “DHCP Storm Scenario” Ethernet DHCP Server DHCP Server P2P-GO P2P-GC 192.168.0.1 192.168.0.2 192.168.10.1 192.168.10.2 192.168.10.3 ???? WiFi
  • 135. • MiracleCast (link) • Started from OpenWFD project • Portable P2P Link management via “adhoc” version of DHCP Server • As of now (OCT 2014), • Only WiFi Direct Link Control and Management works • Local Sink and Source Control is under development Latest Opensource Activity Updates Case Study:WFD Source & Sink on Linux (4)
  • 136. V2X with Multiple Wireless Connectivity 136
  • 137. Wi-Fi/LTE Multipath Aggregation (1) *LTE/WiFi Multipath Aggregation 기술 동향 2014,TTA Wi-Fi LTE 137 • Better throughput • Seamless connection • Lower price for communication BD… AC… ABCD… +
  • 138. Wi-Fi/LTE Multipath Aggregation (2) *LTE/WiFi Multipath Aggregation 기술 동향 2014,TTA 138 • Application Driven • MPTCP (Multipath TCP) • RAN (RADIO Access Network) Aggregation Normal WebserverMultipath-aware HTTP MPTCP-patched WebserverNormal App using TCP Normal App Normal Webserver No H/W Infra change No H/W Infra change HUGE H/W Infra change S/W patch for web server iOS Siri! Samsung download booster
  • 139. Wi-Fi/LTE Multipath Aggregation (3) *LTE/WiFi Multipath Aggregation 기술 동향 2014,TTA 139 $$$$$ Normal WebserverMultipath-aware HTTP MPTCP-patched WebserverNormal App using TCP Normal App Normal Webserver No H/W Infra change No H/W Infra change HUGE H/W Infra change S/W patch for web server 높은 범용성! $ 특정 App 에 제한 적! $($$ with Proxy) 모든 TCP 사용 응용!
  • 140. Wi-Fi/LTE Aggregation forV2I 140 USE Intermittent Wi-Fi Hotspot at much as possible! Stay Connected with LTE with wider coverage! Prioritise theV-to-I traffic and choose effective one!
  • 141. Wi-Fi/LTE Aggregation forV2V 141 Be prepared: Link disconnection Get Diversity for emergent information
  • 142. MPTCP Performance Field Test Result (1) 142 - DUT: Quadcore / LTE Cat6 / 802.11ac (2x2) - 2014/12 - Measure Throughput for 200 sec and compute contribution ratio for Wi-Fi and LTE M: 도곡역 플렛폼 M: 도곡역/zVolti Office S: zVolti Office S: 도심 아파트 상가
  • 143. MPTCP Performance Field Test Result (2) 143 M: 도곡역 플렛폼 Wi-Fi Disconnected Tput Aggr. Tput for LTE and Wi-Fi RSSI for LTE and Wi-Fi Wi-Fi Linkspeed
  • 144. MPTCP Performance Field Test Result (3) 144 M: 도곡역/zVolti Office Tput Aggr. Tput for LTE and Wi-Fi RSSI for LTE and Wi-Fi Wi-Fi Linkspeed
  • 145. MPTCP Performance Field Test Result (4) 145 S: zVolti Office Tput Aggr. Tput for LTE and Wi-Fi RSSI for LTE and Wi-Fi Wi-Fi Linkspeed
  • 147. WiFi Tech Evolutionary • Floods of new tech. standards from IEEE fuels to industrial standards driven by WiFi Alliance 802.11 802.11b 802.11a 802.11g 802.11e 802.11i 802.11n 802.11r 802.11s 802.11k 802.11u 802.11ac WiFi Direct WiFi Display WiFi WiFi WPS WiFi TDLS Time PHY MACWFA Complexity Performance Hotspot 2.0 802.11ad 147
  • 148. Complexity to other chan comeback • No additional network inter • Average switc based implem 802.11b 802.11a 802.11g 802.11e 802.11n WiFi DirectWiFi 3Q/2012 148miDLS 802.11b 802.11a 802.11g 802.11e 802.11n WiFi Direct WiFi WiFi Display WiFi TDLS 802.11k 802.11u 4Q/2014 Concurrency 802.11ac Multi-User MIMO Beam-forming WFA Filesharing
  • 149. Situation 149 ** * BT/BLE GPS ManyVendors & Models Connected Car! with multiple wireless connectivity [Bloomberg] Hyundai Connects With Verizon to Bring Wireless to Its U.S. Cars 2014. 01.21 Many Services
  • 150. User Scenario depends on “Smartness” 150 - WiFi Only - Custom *“Screencasting” APP ** The feature is yet feasible in mobiles * For each vendor and model - P2P Only - Standard Miracast - No value for “Connected Car” - No value for “Connected Car” - S/W Updates - Hotspot Only - Custom *“Screencasting” APP - **Hotspot & P2P Concurrent - Standard Miracast Most Latest Android Mobile supports WiFi/P2P Concurrent Mode
  • 151. Expected Radio Components 151 WiFi (SoftAP) WiFi (P2P) WiFi (Legacy) 2.4GHz/5GHz RF for WiFi 700MHz ~ 3.6GHz RF for Cellular 2.4GHz/2.3GHz for Satellite Radio 13.56MHz for NFC 1.5GHz for GPS V2V/V2I (802.11p)3G/4G Cellular Digital Radio (Satellite) BT/BLE GPS NFC Chipset RF V2V Radar Single chip solution?
  • 152. Quality? 152 • Durability • Stability • Performance • Interoperability * BT/BLE GPS [Bloomberg] Hyundai Connects With Verizon to Bring Wireless to Its U.S. Cars 2014. 01.21 *
  • 153. Learn from Mobile Industry: Durability 153 BT/WiFi Combo chip SDIO BUS Application Processor (Core)WiFi Chip SDIO Module RF Power I/O (bits) I/O (signal) On/Off - The module damaged by 10,000 times of radio on/off The life time of Mobile vs. Auto?
  • 154. Learn from Mobile Industry: Stability 154 BT/WiFi Combo chip SDIO BUS Application Processor (Core) WiFi Chip SDIO Module RF I/O (bits) I/O (signal) - Performance degradation by non-WiFi issue LinkQ Time Good Core Temperature Time High Core Clock Time Good Throughput Time Good
  • 155. Learn from Mobile Industry: Interoperability 155 - So many counterpart devices - Simple Lab-test is not enough - So much user complains from the market after the product releases 100+ Different configuration for each AP - 80211 mode - Security - Channel Interference from others Link-state btw TX/RX
  • 156. Learn from Mobile Industry: Metal… 156 - One RF engineer says: adopting the metal body is the most challenging task ever since the first WiFi integration into the mobile phone Same Distance btw. TX/RX but …
  • 157. Learn from Mobile Industry:Too Strong Signal 157 - Muti-path MIMO, performance degradation happens when the signal btw. TX/ RX is too high Not desirable! • Measured received throughput performance • Latest Android Mobile Phone (No interfering devices (shield env) • Injecting attenuation to the communication signal between mobile and AP Distance to Attenuation?
  • 158. Learn from Mobile Industry: UDP Packet Reordering 158 The problem hard to produce in old age! 2 DS h miDLS both are empty • Not to loose packets from AP • We propose and implement miDLS support two mobile WiFi devices migrat to other channel for short time and comeback • No additional H/W support by both the network interface card (NIC) and the A • Average switching duration in MadWiFi- based implementation < 20ms CHA HB DS with miDLS both a • No • We pr suppo to oth comeb • No ad netwo • Avera based CHA CHA CHB 13 . . . 4 For maximum performance, modern WiFi Driver/ Firmware buffering incoming packets from upper layer and scheduling them 4 13 . . . 2 TX-Order RX-Order Without RX-side pre-buffering, P2 and P3 are lost and discarded upon receiving P1 and P4.
  • 159. Learn from Mobile Industry: RX/TX Stalls 159 Lazy Link Adaptation ; Connected but can’t TX/RX
  • 160. Learn from Mobile Industry: RX/TX Stalls 160 Lazy Link Adaptation ; Connected but can’t TX/RX Typical mid-quality link
  • 161. Learn from Mobile Industry:Try and Errors (1) 161 2. P2P Group Operating Channel selection 3. Softap Operating Channel selection for Tethering Service 4.WiFi Direct / WFD User Scenario 1) Softap / P2P Group Timeout if no activity sensed 2) Maximum size of P2P Group 3) Vendor specific behaviour 1.WiFi chipset selection?
  • 162. Learn from Mobile Industry:Try and Errors (2) 162 5. Leveraging with NFC and BLE 1) Auto WiFi Direct pairing with BLE 2) Auto WFD Session kicking with NFC tagging 3) Authentication 7. System parameter tuning 1) TCP Windows size 2) Read/Write buffer length 3) Kernel-side socket operation tuning 6.WiFi MAC/PHY Parameter tuning 1) Retransmission control 2) Link-adaptation policy 3) BT/BLE Coex parameters
  • 163. Learn from Mobile Industry: TCP ParameterVs Tput 163 TCP Windows Size (Mbyte) Parallel Stream Count In order to find the best system default In order to know the ground performance
  • 164. Challenges & Possible Approaches • Resource intensive • Certification doesn’t promise the performance • Large volume of test cases • Field-test vs. Lab-test • To much test results 164 • Test automation • Field-to-Lab tests • Quantitative analysis • Ageing and interoperability test
  • 165. Test Automation 165 R&D Phase Field Test with Prototype Installation Bench Mark the Performance w.r.t., - Different positions of antenna installation - Different counter part device (i.e., mobile) - User scenario (BT/BLE-Coex, Hotspot, Miracast) - Environments (Channel, Interference) Measurement under real environment - Link-quality variation - Level of congestion - User scenario Feedback Field-to-Lab Test - Recreation of recorded link-quality - Injection of congestion and Interference - System parameter tunes (TX/RX gain, Core Clock Speed, UX guides) Bench Mark and Ageing Test with
  • 166. Summary • WiFi Display runs across AV Processing,AV Streaming,and WiFi Direct wireless connectivity • AndroidTM provides WFD Source functionality since the version of JellyBean • We review end-to-end interaction of AndroidTM WiFi Display Stack implementation • Troubles to bring up WiFi Direct make it hard to implement WiFi Display on Linux platform • Test automation is a key for Quality Assurance 166