1. <month year>
doc.: IEEE
July 2014
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [L2 Final Proposal]
Date Submitted: [ 12 July, 2014]
Source1: [Noriyuki Sato, Kiyoshi Fukui] Company [OKI]
Address [2-5-7 Hommachi chuo-ku, Osaka, Japan]
Voice:[ ], FAX: [ ],
Re: [This is the original document.]
Abstract: [This documents describes OKI’s L2R proposal responding to CfFP.]
Purpose: [To make a proposal]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
N. Sato and K. Fukui (OKI)
<author>, <company>

2. L2R Final Proposal TG10 presentation 15th July 2014 San Diego CA
<month year>
doc.: IEEE
July 2014
L2R Final Proposal
TG10 presentation
15th July 2014 San Diego CA
Noriyuki Sato / Kiyoshi Fukui
OKI Electric Industry Co., Ltd.
N. Sato and K. Fukui (OKI)
<author>, <company>

3. Summary of proposal Mapping to the functional requirements of TGD
July 2014
Summary of proposal
Mapping to the functional requirements of TGD
Boot strap / key management / security
Proposal of L2R commands / messages
Metrics exchange, diagnostics, status notification,
Proposal of L2R PIBs
Outline of multiple subnets operation
Routing protocol operation details
Use cases – Initializing, Add a node, Coordinator down, local link repair
Miscellaneous Functionalities
RF power control, FA, E2E ACK, Priority
Simulation Result
N. Sato and K. Fukui (OKI)

4. Mapping functional requirement
July 2014
Mapping functional requirement
Functions described in functional requirement 
Mapping to this proposal
Deployment architecture  BS switch, Multiple subnets
Mesh Topology Discovery  Bootstrapping
Mesh Routing Protocol  L2Routing procedure
Extensible Mesh Routing Architecture  Frame format
Mesh Broadcast Data Delivery  Broadcast, Multicast
Mesh Unicast Data Delivery  L2R procedure, Frame format
Route discovery  L2R procedure
Low power operation  Checking in the simulation (TBD)
Mesh Security  Bootstrap, Key management command (Frame format)
Routing Metrics  L2R procedure, Routing Metrics (Frame format)
Discovery and Association  Bootstrapping
Frequency Agility  Command Frame
N. Sato and K. Fukui (OKI)

5. Boot strapping procedure
July 2014
Boot strapping procedure
6.9, 6.11
Beacon (Passive / Active scan)
Association / Address assignment / DAD
KMP (Authentication & Key exchange)
Alternatives
Authentication between joiner and PAN coordinator
Authentication between joiner and parent router
Starting L2R routing
Key exchange
Key exchange protocol may be extended if various type of key is managed
Shared link key (Network Key)
Individual link key
Combination of authentication and key exchange may provide variety of solutions
May be switched or nested
We propose providing KMP relay command and key exchange command to support extension.
N. Sato and K. Fukui (OKI)

6. An example of bootstrap
July 2014
An example of bootstrap
Jonier
Parent
PAN coordinator
Very EUI-64 and DAD
Association
Join request / DAD
KMP
KMP Relay
Authentication method is out-of-scope
・PANA
・HIP
・IKEv2
・IEEE802.1x
・Vendor-specific
Etc…
Key transport
Key transport
Association response
Join Response / Address assignment
KMP
Authentication method is out of scope
・PANA
・HIP
・IKEv2
・IEEE802.1x
・Vendor-specific
Etc..
Authentication process is invoked by Authenticator triggered by join request
Key transport
Hello Request
Hello
Hello
Required commands (routing protocol independent)
Join Req/Res
Key transport Req/Res
KMP Relay
N. Sato and K. Fukui (OKI)

7. L2R procedure (Revisit Pre Proposal)
July 2014
L2R procedure (Revisit Pre Proposal)
2 steps routing establishment
1) Establishment of upward path
2) Inform the relation of parent and child to the PAN coordinator
Devices to PAN Coordinator
Using 1), send a frame to the parent
PAN coordinator to device
Using 2), PAN coordinator send a frame by source routing
P2P
Mixture of “Devices to PAN coordinator” and “source routing from PAN coordinator”
N. Sato and K. Fukui (OKI)

8. Upward routing establishment (Re)
<month year>
doc.: IEEE
July 2014
Upward routing establishment (Re)
All nodes broadcast “HELLO” frame to the neighbor nodes periodically.
“HELLO” frame carries link costs between its neighbor nodes and itself. In the other words, outgoing link cost is told from the other side. (a)
Each node decides incoming link cost. (b)
A node decide the mutual link costs from the outgoing (a) and the incoming (b).
HELLO frame also carries path cost. The Originator (concentrator, PAN coordinator or L2R former)’s cost is zero.
A node receives path costs from its neighbors and its own path cost is calculated by using the derived mutual link cost.
A node chooses the lowest one from them and broadcast to the neighbor nodes.
N. Sato and K. Fukui (OKI)
<author>, <company>

9. How to set a incoming link cost (Re)
July 2014
Node B has no neighbor information.
Just after receiving a first hello from node A and C, node B sets a highest value as incoming link costs from these nodes.
After receiving enough hellos, incoming link costs are updated to appropriate values.
Node A
Node B
Node C
NOA ①
NOA AD LC 2 A 15 C ②
NOA AD LC 2 A 1 C ③
NOA: Number of Address
AD: Address
LC: Link Cost
N. Sato and K. Fukui (OKI)

10. Calculation of path cost & parent selection (Re)
July 2014
Calculation of path cost & parent selection (Re)
A node calculates path costs between each neighbor node.
It selects the node which has the lowest path cost as the parent node. a
LC = 2 1
Node h’s candidate parents 5 b f
Neighbor
ADDR PC LC
My PC d 6 2 8 g 5 1 j 4 1 1 2 3 e 4 i c 2 4 2 2 g 3
PC: Path Cost
LC: Link Cost 2 j d 1 2 1 h
N. Sato and K. Fukui (OKI)

11. Downward routing establishment (Re)
<month year>
doc.: IEEE
July 2014
Downward routing establishment (Re)
A node start to send RREC (route record) frame to its parent node periodically after upward routing is established.
RREC carries the parent-child relationship information.
Merged RREC is sent if RREC from a child is received.
PAN coordinator gathers all parent-child relationship from the network.
For the downward transmission, PAN coordinator send a frame by source routing.
N. Sato and K. Fukui (OKI)
<author>, <company>

12. Establishment of downward route (Re)
July 2014
Establishment of downward route (Re)
PAN coordinator (node A) achieve path to h by following steps.
Node h send RREC to the Parent node (node j).
When the node receives a route record, it creates new route record attaching its own address and send it to its parent (node i  f  a).
PAN coordinator gets path information to node h.
Address list of RREC a
LC = 2 1
NOA
AD1
AD2
AD3
AD4 4 h j i f 5
f ⇒ a b f 1 1 2 3
NOA
AD1
AD2
AD3 3 h j i e
i ⇒ f 4 i c 2 4
NOA
AD1
AD2 2 h j 2 2 3 g
j ⇒ i 2 j d 1
NOA
AD1 1 h 2 1
h ⇒ j
NOA: Number of Address
AD: Address h
N. Sato and K. Fukui (OKI)

13. Miscellaneous functionality
July 2014
Miscellaneous functionality
RF transmission power control
Summary
By reducing RF power, it reduces number of neighbor node to avoid congestion
What we should do
PIB is already defined in IEEE PHY
New PIB for L2R
Number of neighbor
Transmission power needs to be exchanged among the neighbors
Adding as metrics which is carried by HELLO frame
N. Sato and K. Fukui (OKI)

14. Miscellaneous functionality (2)
July 2014
Miscellaneous functionality (2)
Frequency Agility
Summary
Provides change channel operated in the L2R network to avoid confliction
What we should do
Create a new command to tell how often a node detects channel busy to the PAN coordinator on L2R layer
Create a new command to tell the new channel and when to all the nodes in network on L2R layer
N. Sato and K. Fukui (OKI)

15. Miscellaneous functionality (3)
July 2014
Miscellaneous functionality (3)
Broadcast, Multicast
Flooding in the network needs rate control and jitter adjustment
The more neighbor cause the more contention
Some simple mechanism is required
For example, how about adding random jitter up to (aMaxPHYPacketSize)*8/(Bitrate)/1000*(l2rBroadcastJitterNeighborMagnitude) * (l2rNumberOfNeighbor) + l2rBroadcastJitterBaseValue
Multicast
Application layer filtering based on the group ID with flooding – simple implementation
Real multicast provides efficiency only for special case though it requires many of complex protocol (ex. Advertisement, Subscribe / Unsubscribe, multicast routing etc.)
N. Sato and K. Fukui (OKI)

16. Hop-by-hop retry Hop-by-hop retransmission Change routing
<month year>
doc.: IEEE
July 2014
Hop-by-hop retry
Hop-by-hop retransmission
Retransmission timing is determined by macMinBE and macMaxBE is up to 2^(macMaxBE) * aUnitBackoffPeriod, which is intend to avoid neighbor collision
L2R provides retransmission so that it retries after longer period than MAC provides.
Change routing
If transmission is failed to the parent, a node may change next hop to transmit. Next hop is chosen from candidates of parent which were obtained during upward route establishment / update
Limited number of retry
Through E2E transmission, those of retry can be done up to designated number (Number of Retry)
This number is attached like TTL. If retry happens, this value is decremented.
N. Sato and K. Fukui (OKI)
<author>, <company>

17. BS switch consideration
<month year>
doc.: IEEE
July 2014
BS switch consideration
GW works as PAN coordinator
Each BSs are connected to GW on the wires.
A BS is downward next hop of GW.
Even if one of BS is down, a node automatically updates routing information so that it connect to another BS.
Hello GW
BS1
BS2
BS3
BS4
Example of self healing functionality
N. Sato and K. Fukui (OKI)
<author>, <company>

18. Another solution for multiple subnet
July 2014
Another solution for multiple subnet
Overview
Have multiple roots associated with instance ID
Path cost for each instance is calculated and delivered by HELLO
A node choses instance which has lower path cost and it doesn’t necessarily propagate higher path cost to the neighbor. It may propagate to allow redundancy.
What we should do
Have an instance ID and individual path cost for each instance
N. Sato and K. Fukui (OKI)

19. L2R Information Element
July 2014
L2R Information Element
Format of Payload IEs
Assign a new Payload Group ID (0x3) for L2R
Content field of the L2R IE
Octets: variable
variable …
L2R HDR
Nested IE
Use same format as the Nested IE for MLME IE
Define Nested IE needed for each frame type (commands or data frame).
Format of Nested IEs
2047
long or
N. Sato and K. Fukui (OKI)

20. L2R HDR Field <month year> doc.: IEEE 802.15-14-0286-00-0010
July 2014
L2R HDR Field
Upper Layer protocol ID
vender specific,
6lowpan,
diagnostic
Routing Protocol ID
vender specific,
method A,
method B, …
Frame Type
Data, Rout Record,
E2E-ACK, KMP Relay
Hello, MGT-request,
Hello request, MGT-response
N. Sato and K. Fukui (OKI)
<author>, <company>

21. Sub-ID for L2R Payload IE
May 2014
Sub-ID for L2R Payload IE
Sub-ID for short format of L2R Nested IE
Sub-ID for long format of L2R Nested IE
Sub-ID value
Name
0x00
Vendor Specific IEs
0x1
Hello parameter IE
0x2
Routing Instance IE
0x3
Hello request parameter IE
0x04
Route Record parameter IE
0x05
MGT request parameter IE
0x06
MGT response parameter IE
0x07
KMP Relay parameter IE
0x08
FA Notification parameter IE
0x09
FA Channel update IE
0x0a
Multicast request parameter IE
0x0b
Multicast response parameter IE
0x0c-0x7f
Reserved
Sub-ID value
Name
0x0
Vendor Specific IEs
0x1
Address List IE
0x2
Neighbor Metrics Container IE
0x3
PIB ID List IE
0x4
PIB value List IE
0x05
KMP content IE
0x5-0xf
Reserved
N. Sato and K. Fukui (OKI)

22. Data Frame Upward data frame Downward data frame July 2014 L2R HDR
Payload
Octets: 3
0/2
0/2/8 1
variable
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
If DST or SRC are same to MAC SRC DST, these fields can be omitted.
Downward data frame
L2R HDR
Nested IE
Payload
Octets: 3
0/2
0/2/8 1
variable
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
Address list
Downward data frame　includes address lists used by source routing
Address list
Octets:2 1
2/8 L
SID=
0x01
T=1
Num. of
Addr
Node 1
Addr. Mode
Addr. …
Node n
L: Length
T: Type
N. Sato and K. Fukui (OKI)

23. E2E-ACK Frame ACK for Upward data frame ACK for Downward data frame
July 2014
E2E-ACK Frame
ACK for Upward data frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
Address list
ACK for Upward data should be Downward and it needs address list for source routing
ACK for Downward data frame
L2R HDR
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
TGD requires this functionality. Do we really need this??
It can be implemented on the upper layer.
N. Sato and K. Fukui (OKI)

24. Hello command Frame July 2014 L2R HDR Nested IE Payload … variable
Octets: 3
0/2
0/2/8 1 …
variable
Frame
Control
SRC
PAN
ADDR
TTL =1 SN
Hello
Param.
Routing
Instance
Neighbor
Metric Container
Hello Param.
Octets:2 1 L
SID=
0x01
T=0
Node
Type
Hello
Inteval
This nested IE always appear in HELLO command frame.
Node type represents what L2R node type is running (e.g. Host, Sleep host, Sleep router etc.)
Hello Interval represents how often this node issue HELLO command periodically.
N. Sato and K. Fukui (OKI)

25. Hello command Frame July 2014 L2R HDR Nested IE Payload … variable
Octets: 3
0/2
0/2/8 1 …
variable
Frame
Control
SRC
PAN
ADDR
TTL =1 SN
Hello
Param.
Routing
Instance Information
Neighbor
Metric Container
Path cost for each Routing Instance is carried by each routing instance info.
Max Hello Interval carries maximum Hello interval on the path between the root.
Root update sequence number and it is propagated from the root . Each node pick up Root SN from parents’ hello and copy it into its own hello.
Routing Instance Info.
Octets:2 1
2/8 2 L
SID=
0x02
T=0
Addr Mode
Instance ID
Path
Cost
Max
Hello Interval
Root SN
N. Sato and K. Fukui (OKI)

26. Neighbor Metrics container
July 2014
Hello command Frame
L2R HDR
Nested IE
Payload
Octets: 3
0/2
0/2/8 1 …
variable
Frame
Control
SRC
PAN
ADDR
TTL =1 SN
Hello
Param.
Routing
Instance
Neighbor
Metric Container
Neighbor Metrics container
Octets:2 1
Variable
variable L
SID=
0x0x
T=1
Num. of
Neighbors
Neighbor 1
Metrics …
Neighbor n
Neighbor metrics container carries all neighbor’s metric.
Metrics
Octets:1
2/8 1
variable
Addr.
Mode
Num. of
Metric 1 ID
Value …
Metric n
Neighbor metrics carries all metrics related this neighbor.
Metric ID ={Hop count, RSSI, Link Error Rate,…}
N. Sato and K. Fukui (OKI)

27. Hello Request command Frame
July 2014
Hello Request command Frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
SRC
PAN
ADDR
TTL =1 SN
Hollo req.
Param.
Hello Param.
Octets:2 1 L
SID=
0x03
T=0
Node
Type
This command is issued when a node want a hello immediately from the neighbors. (E.g. Joining)
N. Sato and K. Fukui (OKI)

28. Route Record command Frame
July 2014
Route Record command Frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL =1 SN
Route Record
Param.
Address list
Route Record Param.
Octets:2 1 L
SID=
0x0x
T=0
RREC
Mode
RREC is issued to the parent node.
The parent attach its address and issue it to its parent. Information is propagated to the root.
The root is assemble the information for the source routing.
RREC mode is to designate mode operation of RRREC aggregation.
Slide 28
N. Sato and K. Fukui (OKI)
N. Sato and K. Fukui (OKI)

29. MGT-request command Frame
July 2014
MGT-request command Frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
Address
list
MGT req.
Param.
PIB ID/value List
MGT req. Param.
Octets:2 1 L
SID=
0x0x
T=0
Command ID
For the source routing
PIB GET
When command ID = PIB GET, PIB ID list follows.
When command ID = PIB SET, set of PIB ID and value list follows.
PIB ID List
Octets:2 1 L
SID=
0x0x
T=1
Num. of
PIB
PIB 1 ID …
PIB n
PIB GET or PIB SET is designated by command ID.
PIB SET
PIB value List
Octets:2 1
Variable L
SID=
0x0x
T=1
Num. of
PIB
PIB 1 ID
Value …
PIB n
PIB ID is required not only for L2R PIB but also for PHY/MAC.
N. Sato and K. Fukui (OKI)
Slide 29

30. MGT-response command Frame
July 2014
MGT-response command Frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
MGT res.
Param
PIB value List
MGT res. Param.
Octets:2 1 L
SID=
0x0x
T=0
Command ID
PIB Value can be omitted when Command ID = MGT SET
PIB value List
Octets:2 1
Variable L
SID=
0x0x
T=1
Num. of
PIB
Status 1
PIB 1 TLV …
Status n
PIB n
TLV
PIB TLV
Octets: 1 1
Variable
PIB ID L
PIB Value
N. Sato and K. Fukui (OKI)

31. KMP Relay command Frame
July 2014
KMP Relay command Frame
L2R HDR
Nested IE
NestedIE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
Address
list
KMP Relay
Param.
KMP Content
Address list appear only when it downward forwarding
KMP content
Octets:2
Variable L
SID=
0x05
T=1
KMP Content
KMP Relay Param.
Octets:2 1
2/8 L
SID=
0x07
T=0
Addr.
Mode
Target
An address of the node which is trying to communicate to the authenticator is carried
N. Sato and K. Fukui (OKI)

32. FA Notification command Frame
July 2014
FA Notification command Frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
FA Notification
Param
FA Notificaiton Param.
Octets:2 1 L
SID=
0x0x
T=0
Status
Status is used for informing channel condition
N. Sato and K. Fukui (OKI)

33. FA Channel update command Frame
July 2014
FA Channel update command Frame
L2R HDR
Nested IE
Octets: 3
0/2
0/2/8 1
Frame
Control
DST
PAN
ADDR
SRC
TTL SN
Address
list
FA CH Update
Param.
For source routing
FA CH UpdateParam.
Octets:2 1 2 L
SID=
0x0x
T=0 CH
Page
Time
Info.
When and what channel are sent.
N. Sato and K. Fukui (OKI)

34. L2R PIBs definition July 2014 Attribute Type Range Description Default
l2rNodeType
Enumeration
Router,
Sleep router,
Host,
Sleep host,
Indicates the type of node. -
l2rHelloInterval
Integer
0x0000-0xffff
Hello Frame Interval (milliseconds)
0x0040
l2rNumberOfNeighbor
0x00-0xff
Number of neighbor nodes
0x00
l2rLinkCostTable
TBD (address – integer) list
Link cost for each neighbor node
l2rPathCostTable
TBD
(address – integer) list
Path cost for each instance
l2rRouteRecordAggregation
Boolean
True or False
Indicate that a node should aggregate route record message
False
l2rRouteRecordInterval
Route Record interval (milliseconds)
0x1000
l2rBroadcastJitterNeighborMagnitude
Transmission of broadcast is applied with random jitter up to (aMaxPHYPacketSize)*8/(Bitrate)/1000*(l2rBroadcastJitterNeighborMagnitude) * (l2rNumberOfNeighbor) + l2rBroadcastJitterBaseValue
0x3
l2rBroadcastJitterBaseValue
Same as above
0x0a
N. Sato and K. Fukui (OKI)

35. Simulation result of 11x11 Number of nodes Distance from concentrator
July 2014
Simulation result of 11x11
Number of nodes
11x11 = 121
Distance from concentrator
28 nodes on 1 hop distance.
72 on 2hops distance
20 on 3 hops distance
Average 1.93hops
N. Sato and K. Fukui (OKI)

36. Simulation result of 33x33 Number of nodes Distance 33×33=1089
July 2014
Simulation result of 33x33
Number of nodes
33×33=1089
Distance
28 nodes on 1 hop
76 nodes on 2 hops distance
124 nodes on 3hops distance
172 nodes on 4 hops dist.
220 nodes on 5 hops dist.
244 nodes on 6 hops dist.
160 nodes on 7 hops dist.
64 nodes on 8 hops dist.
Average distance 4.99hops
N. Sato and K. Fukui (OKI)

37. Condition of simulation
July 2014
Condition of simulation
Nodes within 3 units on the grid are neighbor where one unit is minimum distance between nodes on the grid.
HELLO period: 64 (s)
RREC: None
L2R retransmission: Yes
Delay of forwarding: 10 (ms)
Data
Size: 127 (Bytes)
Sending period is set so that concentrator receive it 1 times per second.
11×11 each node sends once in 120 (sec) , 33×33once in 1088 (sec)
NW establishment time
All nodes detect route to the concentrator (s) – concentrator issued first hello (s)
It may not always be optimum route.
Data are sent after 15 minutes of begin of simulation .
Number of trials
1 set consits (NW formation + data transmission 5 times)
100 sets of trials
N. Sato and K. Fukui (OKI)

38. Result of simulation 11×11 33×33 Establishment time (s) 62.35 104.51
July 2014
Result of simulation
11×11
33×33
Establishment time (s)
62.35
104.51
Data arrival ration
Average delay of data (s)
0.0446
0.1121
N. Sato and K. Fukui (OKI)

39. Simulation Result 11×11=121 1hop 28 2hop 72 3hop 20 Average: 1.93hop
July 2014
Simulation Result
11×11=121
1hop　28
2hop　72
3hop　20
Average: 1.93hop
Even with PER0.1 condition, there is no significant difference from the simulation result at Preliminary Proposal.
N. Sato and K. Fukui (OKI)

40. Simulation Result (33x33 Upstream)
July 2014
Simulation Result (33x33 Upstream)
33×33=1089
1hop 28
2hop 76
3hop 124
4hop 172
5hop 220
6hop 244
7hop 160
8hop 64
Average: 4.99hop
Even with PER0.1 condition, there is no significant difference from the simulation result at Preliminary Proposal.
N. Sato and K. Fukui (OKI)

41. Simulation Result (100x100) 100×100=10000 nodes Average: 14.30hop
July 2014
Simulation Result (100x100)
100×100=10000 nodes
Average: 14.30hop
1/4 Image (Top left part) is shown
Hop
nodes 1 28 2 76 3
124 4
172 5
220 6
268 7
316 8
364 9
412 10
460 11
508 12
556 13
604 14
652 15
700 16
748 17
782 18
711 19
617 20
520 21
424 22
328 23
232 24
136 25 41
N. Sato and K. Fukui (OKI)

42. Simulation Condition Radio Range 3 hops radius
July 2014
Simulation Condition
Radio Range 3 hops radius
Link error as described in TGD simulation scenario (PER 10^-1 to 10^-6)
HELLO Interval 64 (sec)
RREC Not applied
L2R Hop by hop Retry Yes
Transmission Delay by hop　10 (ms)
Data
Size 100B（Including PHY header）
Birth rate 1 packet /30mins　(Every node adds random jitters)　
NW Establishment time
Not necessarily means optimum.  Explaining in following slides
Trial number
1 set consists with NW establishment (1time), all nodes transmit data 5 times
100 sets
N. Sato and K. Fukui (OKI)

43. Simulation result 11×11 33×33 100×100 NW establishment time (s) 63.15
July 2014
Simulation result
11×11
33×33
100×100
NW establishment time (s)
63.15
107.28
218.66
Transmission success rate
1.000
Average delay (s)
0.0276
0.0910
0.2380
N. Sato and K. Fukui (OKI)

44. Topology difference between ‘just established’ and ‘took enough time’
July 2014
Topology difference between ‘just established’ and ‘took enough time’
hop
Just established
stable 1 28 2 76 3
124 4
170
172 5
219
220 6
262
268 7
307
316 8
353
364 9
377
412 10
421
460 11
450
508 12
499
556 13
532
604 14
539
652 15
554
700 16
561
748 17
615
782 18
622
711 19
617 20
564
520 21
437
424 22
367
328 23
279
232 24
136 25
208 41 26
162 27
126 89 29 30 47 31 33 32 34
hop
Just established
stable 1 28 2 71 72 3 21 20
hop
Just established
stable 1 28 2 74 76 3
115
124 4
161
172 5
183
220 6
244 7
160 8 90 64 9 36 10 11
N. Sato and K. Fukui (OKI)