Hyundai NGV invites me again to talk about the latest trends in Wi-Fi Direct and Wi-Fi Display (Miracast) in mobile industries. The most audiences were engineers from Hyundai/Kia Motors related to the in-vehicle infotainments and V2X connectivities. This year, I was responsible for two sessions. What we discussed is as below: 1) Wi-Fi Direct Specifications 2) Wi-Fi Direct Implementation on Androids (History and State-of-art) 3) Wi-Fi Direct case studies across framework/wpa_supplicant/driver 4) Wi-Fi Display Implementations on Android/Linux 5) Wi-Fi / LTE combinations (MPTCP) and its field performance test results 6) Try and errors what mobile industries have gone through - BLE/NFC in conjunction with Wi-Fi/Wi-Fi Direct

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

14. Case Study
14

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

43. Android Wi-Fi Direct
Application Development
43

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)

52. Revisit:WiFi Performance
52

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

68. WiFi QoS Effort
68

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

75. WMM: QoS Differentiation
75

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))

83. WiFi Display Control Plane
83

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

111. Case Study:Android
111

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

127. Case Study: Linux
127

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

146. WiFi Device
Quality Assurance
146

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