1 / 40

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 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]

juliet
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 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:[+81-6-6260-0700], FAX: [+81-6-6260-0770], E-Mail:[sato652@oki.com, fukui535@oki.com] 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 P802.15. 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 P802.15. N. Sato and K. Fukui (OKI)

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

  3. 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 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 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 Jonier Parent PAN coordinator Very EUI-64 and DAD Association Join request / DAD KMP Relay KMP Authentication method is out-of-scope ・PANA ・HIP ・IKEv2 ・IEEE802.1x ・Vendor-specific Etc… Key transport Key transport Join Response / Address assignment Association response 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) • 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) • 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)

  9. How to set a incoming link cost (Re) • 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: Number of Address AD: Address LC:Link Cost N. Sato and K. Fukui (OKI)

  10. 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 f b 1 2 1 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) • 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)

  12. 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 f ⇒ a 5 f b 1 2 1 3 e i ⇒ f 4 i c 2 4 2 2 j ⇒ i g 3 2 j d 1 h ⇒ j NOA: Number of Address AD: Address 2 1 h N. Sato and K. Fukui (OKI)

  13. 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 IEEE802.15.4 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) • 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) • 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 • 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)

  17. GW GW Hello Hello BS2 BS1 BS2 BS1 BS3 BS4 BS3 BS4 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. Example of self healing functionality N. Sato and K. Fukui (OKI)

  18. 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 Format of Payload IEs • Assign a new Payload Group ID (0x3) for L2R Content field of the L2R 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 or long N. Sato and K. Fukui (OKI)

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

  21. Sub-ID for L2R Payload IE Sub-ID for short format of L2R Nested IE Sub-ID for long format of L2R Nested IE N. Sato and K. Fukui (OKI)

  22. Data Frame Upward data frame If DST or SRC are same to MAC SRC DST,these fields can be omitted. Downward data frame • Downwarddata frameincludes address lists used by source routing L: Length T: Type N. Sato and K. Fukui (OKI)

  23. E2E-ACK Frame ACK for Upward data frame • ACK for Upward data should be Downward and it needs address list for source routing ACK for Downward data frame 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 • 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 • 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. N. Sato and K. Fukui (OKI)

  26. Hello command Frame • Neighbor metrics container carries all neighbor’s metric. • 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 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 • 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 RRRECaggregation. Slide 28 N. Sato and K. Fukui (OKI) N. Sato and K. Fukui (OKI)

  29. MGT-request command Frame • 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 GET or PIB SET is designated by command ID. PIB SET • 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 • PIB Value can be omitted when Command ID = MGT SET N. Sato and K. Fukui (OKI)

  31. KMP Relay command Frame • Address list appear only when it downward forwarding • 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 • Status is used for informing channel condition N. Sato and K. Fukui (OKI)

  33. FA Channel update command Frame • For source routing • When and what channel are sent. N. Sato and K. Fukui (OKI)

  34. L2R PIBs definition N. Sato and K. Fukui (OKI)

  35. Simulation Result • 11×11=121 • 1hop28 • 2hop72 • 3hop20 • 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)

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

  37. Simulation Result (100x100) • 100×100=10000 nodes • Average: 14.30hop • 1/4Image (Top left part) is shown N. Sato and K. Fukui (OKI)

  38. Simulation Condition • Radio Range 3 hops radius • Link error as described in TGD simulation scenario (PER 10^-1 to 10^-6) • HELLOInterval 64(sec) • RREC Not applied • L2R Hop by hop Retry Yes • Transmission Delay by hop10 (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)

  39. Simulation result N. Sato and K. Fukui (OKI)

  40. Topology difference between ‘just established’ and ‘took enough time’ N. Sato and K. Fukui (OKI)

More Related