PHY / MAC Task Group Network / Transport Presentation

1. PHY / MAC Task GroupNetwork / Transport Presentation Christian Herzog zog at stg.com Co-chair, SP100.11a PHY/MAC TG President, Software Technologies Group • This document is provided strictly for the purpose of gathering information leading to the development of an ISA standard, recommended practice or technical report. Copies may be reproduced and distributed, in whole or in part, but only for the following purposes: • Review of and comment on the ISA-SP100 draft proposal • Submission to the ISA-SP100 Committee • Informing and educating others about the ISA-SP100 draft standard development process.

2. Agenda • 20 minute overview, 10 minute discussion • What you are going to hear now is the “opposite” of what I personally talked about at STG’s RTP Proposers Conference • Sensicast talked mostly about the MAC • STG talked mostly about the Network and above layers • I’m here in a PHY / MAC Task Group role • What will the PHY/MAC Task Group cover • Consider it a “black box” • Simplify and clarify the network and transport design considerations

3. PHY / MAC Task Group Considerations • Frequency control • TDMA • Network joining • N-casting • Quality of Service • Backbone Tunneling • Time • Security • Miscellaneous

4. Frequency Control • The MAC will manage frequency control or “hopping” • Higher layers do not need to concern themselves with this aspect • They can “see” what is happening via management interfaces and in some cases “control” this aspect if they choose and are authorized • This covers several areas: • Synchronization with other parts of the network as needed • Hop schedules and patterns • Driven by the network manager • In compliance with regulatory requirements • “Blacklisting” happens in the MAC • Active adaptation in reaction to conditions • Configured channel “lock outs” • Again, considering regulatory requirements for the respective PHY

5. TDMA – Slots, slots, and more slots • TDMA slot management is the responsibility of the MAC • This covers several areas: • Overall TDMA slot management • Supporting both centralized and decentralized approaches with a continuum between them • Can run entirely in one mode or the other • Can run in a mode where things are mostly decentralized with specifically managed and coordinated slots as well • Synchronization of slots • Make sure all nodes shared the same “slot context” • Know when slots “start” and share the same notion as to when slot “X” will occur • Includes QoS and other optimizations covered in later slides

6. Network joining – “Knock, knock…” • Devices will join or associate over a radio connection • Primarily via radio (SP100 link) • Associations could also occur over a non-SP100 link (Backbone Tunnel) • Joins originate from the MAC layer • Result of various active and passive strategies • Nodes “ask” to join • It’s an incoming operation • Having all incoming operations come over a single defined interface keeps the upper layers simpler and isolated from underlying PHY changes • Isolates the upper layers from the underlying joining mechanics • All joining requests come over a single virtual “interface”

7. N-casting • Obviously the MAC handles unicasts • Other “casts” are also handled by the MAC • Broadcasts • N-casts • Dou-casts • Multicasts • Isolates upper layers from MAC and PHY specifics • Addresses • Built-in N-cast support • Abstractions are good

8. QoS – “More gruel please” • QoS is heavily influenced by the use and management of the TDMA slots • Slots are already handled by the MAC • QoS is really slot “aggregation” and management into multi slot “groups” • This covers several potential areas: • Allocation of individual slots into groups to meet requested QoS requirements • QoS “coordination” among devices through the network happens at the MAC • Support for “Bandwidth on Demand” • “May I have ‘A’ bandwidth for ‘B’ time please?” • “I can make ‘X’ bandwidth over ‘Y’ time period available, is this OK?” • “Thank you, I will take it.” or “No thank you, please consider my request withdrawn” or“No thanks, let me state my requirements another way.” • Higher layers request bandwidth as desired but it’s handled at the MAC layer • Allocated and managed • Recovery support as practical

9. Backbone Tunneling • This is not “application” tunneling • Covering this in the MAC greatly simplifies the network layer • Tunnels just look like “really good” RF links within the network • Fast • Reliable • “Low cost” • Keep the need to include tunneling backbone supportout of the network layer • It stays “pure” SP100 • Not impacted by the various backbone orPHY technologies • Successful model from ZigBee Bridge Device design • Network only deals with SP100 “links” and does not actually “see” tunnels

10. Does anyone really know what time it is? • The “Matrix” does • Typically flowing from the Network Manager which supplies the master clock for network • Distributed and managed by services in the MAC layer • These are utility services not directly related to the operation of the MAC but… • the time service is distributed at this level and… • the MAC makes this time available to the rest of the node via a utility function • A good sense of time is needed for several functional areas • MAC will need on the order of 1 ms accuracy in a network clock to support some modes of TDMA • Security needs “reasonable” time access as well • Nodes may have to act as a time “server”, time “client”, or both

11. Security • Security is pervasive to the design but… • It’s likely the network layer doesn’t need to deal with the many direct security operations • It’s likely these will happen primarily at the link or application ends of the communications • It’s likely that these functions can be encapsulated in a way that the network layer does not need to deal with them • This will require coordination and guidance from the Security TG • “We’ll just add security later; don’t worry about it.” • That was a joke.

12. Miscellaneous – Catch alls • Link quality • The MAC will handle the determination of the “quality” of links and report that in an abstract manner to interested entities • This can be used to determine the “cost” and “reliability” of communications over specific paths • Management Access • Individual layers • PHY • MAC • Utility Functions • The network layer probably will not do a great deal with the adjacent layer(s) via the management interface – certainly not commonly used capabilities