Discussing the Industrial Internet and the crucial role that low-power wireless sensor networks will play to gather these vast amounts of data. Describing how existing industrial wireless technologies must be extended to reach higher scales at lower costs (albeit, with lower guarantees), and the architectural approach and standards that are being developed at 6TiSCH, which encompasses work at IETF, IEEE, and industrial standard bodies.
The document discusses key trends in industrial networking including deterministic networking, clock synchronization, software-defined networking (SDN), and fog computing. It focuses on 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) which provides deterministic IPv6 networking over low-power wireless networks. 6TiSCH aims to converge industrial control networks to IP, make IP operations more efficient, and emulate existing industrial protocols to support the industrial internet. It leverages standards like RPL, 6LoWPAN, and TSCH to provide both deterministic routing for critical flows and stochastic routing for large-scale monitoring.
The document discusses the evolution of wireless networks and the emergence of the "fringe" of the internet. The fringe consists of wireless networks that extend the reach of the internet in a decentralized manner using various protocols and technologies. Key aspects of the fringe discussed include the route-over fringe using protocols like RPL to allow devices to route over multi-hop topologies, the mesh-under fringe using technologies like ISA100 for industrial wireless sensor networks, and the RPL fringe protocol used to route in low-power and lossy networks.
The document discusses the fringe of the Internet, which includes low power lossy networks (LLNs) connected by radio links. It describes characteristics of LLNs like highly constrained devices, small frame sizes, and energy efficiency requirements. The routing protocol for LLNs needs to be adapted to these types of links. The document outlines different approaches for connecting LLNs to the Internet, including mesh under, route over, and overlay models. It introduces RPL as an IETF routing protocol designed for routing over radio in LLNs.
The document discusses routing concepts for low-power and lossy networks (LLNs). It outlines several standards organizations and working groups developing protocols in this area, including IEEE 802.15.4 and various IETF working groups. It also summarizes the RPL and 6TiSCH routing protocols which allow IPv6 connectivity in LLNs using technologies like 6LoWPAN.
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGSpijans
While smart factories are becoming widely recognized as a fundamental concept of Industry 4.0, their implementation has posed several challenges insofar that they generate and process vast amounts of security critical and privacy sensitive data, in addition to the fact that they deploy IoT heterogeneous and constrained devices communicating with each other and being accessed ubiquitously through lossy networks. In this scenario, the routing of data is a specific area of concern especially with the inherent constraints and limiting properties of such devices like processing resources, memory capacity and battery life. To suit these constraints and to provide the required connectivity, the IETF has developed several standards, among them the RPL routing protocol for Low powerand Lossy Networks (LLNs). However, and even though RPL provides support for integrity and confidentiality of messages, its security may be compromised by several threats and attacks. We propose in this work TRM-RPL, a Trust based Routing Metric for the RPL protocol in an IIoT based environments. TRM-RPL uses a trust management mechanism to detect malicious behaviors and resist routing attacks while providing QoS guarantees. In addition, our model addresses both node and link trust and follows a multidimensional approach to enable
an accurate trust assessment for IoT entities. TRM-RPL is implemented, successfully tested and compared with the standard RPL protocol where its effectiveniness and resilience to attacks has been proved to be better.
3 hours course on IEEE and IETF protocols introducing the 6TiSCH architecture and the RPL routing protocol. Course given at telecom Bretagne on Feb 12th 2014
This document discusses several topics related to IPv6 and low power and lossy networks (LLNs):
1. It outlines the agenda for discussing IPv6 neighbor discovery for point-to-point and transit links, wireless neighbor discovery, RPL routing, and RPL extensions.
2. It notes that LLNs comprise billions of constrained devices interconnected by wireless links, and several standards groups are working on protocols for these networks, including 6LoWPAN, ROLL, and 6TiSCH at the IETF.
3. It argues that IPv6 is necessary for the Internet of Things given the tens of billions of additional smart objects that will be connected, and that the RIPE NCC has now
The document discusses the Time Synchronized Channel Hopping (TSCH) mode of the IEEE 802.15.4e standard for low-power and lossy networks. It provides an overview of how TSCH enables deterministic communication through time synchronization, channel hopping, and scheduled transmissions. It also outlines the role of the ROLL working group in developing an architecture that integrates 6LoWPAN, RPL, and other standards with the TSCH mode at the MAC layer to provide IPv6 connectivity over low-power and lossy networks.
The document discusses key trends in industrial networking including deterministic networking, clock synchronization, software-defined networking (SDN), and fog computing. It focuses on 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) which provides deterministic IPv6 networking over low-power wireless networks. 6TiSCH aims to converge industrial control networks to IP, make IP operations more efficient, and emulate existing industrial protocols to support the industrial internet. It leverages standards like RPL, 6LoWPAN, and TSCH to provide both deterministic routing for critical flows and stochastic routing for large-scale monitoring.
The document discusses the evolution of wireless networks and the emergence of the "fringe" of the internet. The fringe consists of wireless networks that extend the reach of the internet in a decentralized manner using various protocols and technologies. Key aspects of the fringe discussed include the route-over fringe using protocols like RPL to allow devices to route over multi-hop topologies, the mesh-under fringe using technologies like ISA100 for industrial wireless sensor networks, and the RPL fringe protocol used to route in low-power and lossy networks.
The document discusses the fringe of the Internet, which includes low power lossy networks (LLNs) connected by radio links. It describes characteristics of LLNs like highly constrained devices, small frame sizes, and energy efficiency requirements. The routing protocol for LLNs needs to be adapted to these types of links. The document outlines different approaches for connecting LLNs to the Internet, including mesh under, route over, and overlay models. It introduces RPL as an IETF routing protocol designed for routing over radio in LLNs.
The document discusses routing concepts for low-power and lossy networks (LLNs). It outlines several standards organizations and working groups developing protocols in this area, including IEEE 802.15.4 and various IETF working groups. It also summarizes the RPL and 6TiSCH routing protocols which allow IPv6 connectivity in LLNs using technologies like 6LoWPAN.
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGSpijans
While smart factories are becoming widely recognized as a fundamental concept of Industry 4.0, their implementation has posed several challenges insofar that they generate and process vast amounts of security critical and privacy sensitive data, in addition to the fact that they deploy IoT heterogeneous and constrained devices communicating with each other and being accessed ubiquitously through lossy networks. In this scenario, the routing of data is a specific area of concern especially with the inherent constraints and limiting properties of such devices like processing resources, memory capacity and battery life. To suit these constraints and to provide the required connectivity, the IETF has developed several standards, among them the RPL routing protocol for Low powerand Lossy Networks (LLNs). However, and even though RPL provides support for integrity and confidentiality of messages, its security may be compromised by several threats and attacks. We propose in this work TRM-RPL, a Trust based Routing Metric for the RPL protocol in an IIoT based environments. TRM-RPL uses a trust management mechanism to detect malicious behaviors and resist routing attacks while providing QoS guarantees. In addition, our model addresses both node and link trust and follows a multidimensional approach to enable
an accurate trust assessment for IoT entities. TRM-RPL is implemented, successfully tested and compared with the standard RPL protocol where its effectiveniness and resilience to attacks has been proved to be better.
3 hours course on IEEE and IETF protocols introducing the 6TiSCH architecture and the RPL routing protocol. Course given at telecom Bretagne on Feb 12th 2014
This document discusses several topics related to IPv6 and low power and lossy networks (LLNs):
1. It outlines the agenda for discussing IPv6 neighbor discovery for point-to-point and transit links, wireless neighbor discovery, RPL routing, and RPL extensions.
2. It notes that LLNs comprise billions of constrained devices interconnected by wireless links, and several standards groups are working on protocols for these networks, including 6LoWPAN, ROLL, and 6TiSCH at the IETF.
3. It argues that IPv6 is necessary for the Internet of Things given the tens of billions of additional smart objects that will be connected, and that the RIPE NCC has now
The document discusses the Time Synchronized Channel Hopping (TSCH) mode of the IEEE 802.15.4e standard for low-power and lossy networks. It provides an overview of how TSCH enables deterministic communication through time synchronization, channel hopping, and scheduled transmissions. It also outlines the role of the ROLL working group in developing an architecture that integrates 6LoWPAN, RPL, and other standards with the TSCH mode at the MAC layer to provide IPv6 connectivity over low-power and lossy networks.
Mobility, traffic engineering and redundancy using RPLMaxime Denis
Master thesis presentation. Design and implementation of a solution to improve mobility between two physical WSNs using RPL. Based on the 6LBR implementation of the CETIC.
Towards the Internet of Relevant Things: the IEEE 802.15.4e StandardGiuseppe Anastasi
The document discusses the IEEE 802.15.4 standard and its limitations for Internet of Things applications with stringent requirements. It introduces the IEEE 802.15.4e standard, which amends 802.15.4 to add two new MAC modes - DSME and TSCH. DSME aims to provide bounded latency while TSCH uses channel hopping to improve reliability. The document surveys the literature on both new modes and discusses open issues and how 802.15.4e can help realize the vision of the Internet of Things.
The document discusses Internet of Things (IoT) networks and routing protocol RPL. It provides an agenda for covering open standards, IEEE and IETF work on low-power lossy networks (LLNs) and 6LoWPAN, concepts of RPL including DODAG, instances, objective functions and messages. It also discusses putting the pieces together including backbone routers and data packet flows. The goal is to reconsider basic Internet structures and expectations to support trillions of constrained devices connecting in IoT applications.
Low-power wide area networking technology offers long-range communication, enabling new types of IoT services. LoRaWAN is one of the most adopted solutions, providing ubiquitous connectivity for outdoor applications. However, its capabilities and limitations are not well understood. The authors provide an impartial overview of LoRaWAN's limitations to avoid unrealistic expectations, discussing use cases where it works and does not work, and listing open research questions.
This document proposes a new platform called CAAP (Cluster As Application Platform) that allows distributed applications to run on wireless device clusters. The key aspects are:
1. Replacing wired links between high-performance computing nodes with wireless D2D (device-to-device) links between mobile devices.
2. Allowing user-programmable networking beyond traditional protocols by programming RDMA verbs.
3. Pooled mobile device clusters can join multiple clusters simultaneously, running multiple applications and instances on shared resources. This opens new opportunities for distributed and edge computing applications.
Wireless IoT connections fall into two low-power camps: local area and wide area. Historically the two have not overlapped but advances in networking technologies make it possible for wide area technologies to perform the same functions as local area technologies with no additional cost or feature "sacrifice".
- Research has shown that LoRa experiences significant degradation in environments with heavy multipath interference like dense urban or indoor settings due to Rayleigh flat fading.
- Experimentation in an airport parking lot exhibiting Rayleigh flat fading validated this, showing Haystack XR2 encoding provided roughly 30 dB gain to packet error rate over default LoRaWAN encoding.
- This gain allows LoRa networks using Haystack XR2 to achieve much higher quality of service, efficiency, and channel density in challenging multipath environments.
LPWAN Technology ~ What is Weightless-P? Jay Wey 魏士傑
Weightless-P is a narrowband LPWAN technology that enables high device density, long range communication, years of battery life, and true bi-directional communication. It supports more devices per base station than other LPWAN technologies and provides low latency, reliable communication in both uplink and downlink directions through its synchronous network design. Weightless-P also features robust channel coding, bi-directional communication including over-the-air firmware updates, and is an open standard technology.
This document provides a technical overview of LoRa and LoRaWAN. It defines LoRa as the physical layer modulation that enables long-range communication, while LoRaWAN is the communication protocol and network architecture. Key aspects of LoRaWAN covered include the star network topology, support for multiple device classes to optimize battery life and latency, adaptive data rates for high network capacity, and security features. Regional variations of the LoRaWAN specification are described for Europe and North America. Comparisons are made between LoRaWAN and other LPWAN technologies, highlighting LoRaWAN's advantages in areas like battery life, coverage, cost, and ability to support a variety of IoT applications.
This document summarizes new developments in 5G NR user plane protocols:
1) It introduces the work plan for 5G NR and describes non-standalone and standalone 5G NR architectures.
2) It describes new 5G NR user plane protocols including the Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) layers.
3) Key enhancements in 5G NR include support for multiple numerologies, reduced latency through changes like removal of concatenation, and improved hybrid automatic repeat request (HARQ) through code block groups.
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
IoT Field Area Network Solutions & Integration of IPv6 Standards
Abstract: http://www.gogo6.com/profiles/blogs/my-presentation-at-gogolive-integration-of-ipv4-and-non-ip
Presentation video: http://www.gogo6.com/video/iot-field-area-network-solutions-integration-of-ipv6-standards-by
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Patrick Grossetete - Technical Marketing Engineer (IoT), Cisco
Bio/Profile: http://www.gogo6.com/profile/PatrickGrossetete
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
LoRa is a long range wireless radio technology for low power wide area networks (LPWANs) used in IoT and M2M applications. It uses license-free sub-GHz frequency bands and spreads signals over a wide bandwidth for long-range transmissions of up to 5-15 km in rural areas and 2-5 km in urban areas using low power consumption from battery-powered devices. The LoRa Alliance oversees the LoRaWAN standard to enable interoperability.
This document discusses NetSim software for simulating Internet of Things (IoT) networks. It describes how NetSim supports the 6LoWPAN and RPL protocols which are important standards for IoT. NetSim can be used to model large-scale IoT networks and evaluate routing protocols, energy efficiency, and other aspects of integrating heterogeneous IoT devices. RPL protocol implemented in NetSim forms the routing basis for IoT and establishes a routing topology using DODAG formation through control messages.
The document describes a Virtex-4 FPGA implementation of a Resilient Packet Ring (RPR) Media Access Control (MAC) solution that provides full compliance with the IEEE 802.17 standard for RPR networks. The implementation utilizes the Virtex-4 FPGA to create a compact dual-ring RPR MAC that requires only 11,000 slices and 80 block RAMs. The document also provides background on RPR networks and discusses applications like metro networks and wireless backhaul.
Zigbee Based Wireless Sensor Networks for Smart CampusIJMER
The document discusses simulations of Zigbee-based wireless sensor networks using different topologies with static and dynamic positioning of the Zigbee coordinator node. The simulations analyzed the effect on throughput and end-to-end delay. Results showed that a tree topology with a mobile coordinator had the highest throughput. A mesh topology, whether with static or dynamic coordinator, produced the lowest end-to-end delay. The document concludes that making the coordinator node mobile generally provides better network performance than a static coordinator configuration.
This document discusses enabling interoperability and scalability for the Internet of Things. It proposes using open standards like IPv6 adapted for constrained devices (6LoWPAN) and a lightweight HTTP-like protocol called CoAP. CoAP allows web technologies to be used in constrained environments and integrated with existing web services through proxies and resource directories. This approach aims to avoid vendor lock-in, connect IoT devices to the internet, and allow the web of things to scale through standard interfaces.
This document summarizes an approach called RINA (Recursive InterNetwork Architecture) for simplifying multi-layer network management. RINA proposes a common, repeating structure across layers with only two protocols - one for data transfer and one for layer management. This significantly reduces the complexity of management models compared to the IP protocol suite, which has unique protocols at each layer. A case study shows how RINA could simplify network management in a large-scale data center network by reducing the number of required addresses, forwarding entities, and management protocols. The consistent structure of RINA opens the door to increased network automation by making management models simpler and more standardized.
Advanced network experiments in FED4FIREARCFIRE ICT
1) The document discusses past and present experiments on the Fed4FIRE testbed for advanced network experiments, including experiments on carrier-grade SDN, network resilience, quality of service differentiation, and clean-slate networking approaches like RINA.
2) It describes experiments testing restoration and protection in SDN networks, quality of service differentiation across multiple autonomous systems, and validation of RINA concepts like recursive networking, shim-based virtual machine networking, and programmability.
3) It introduces the ARCFIRE project which aims to enable large-scale experimentation with RINA on Fed4FIRE+ through innovations like seamless node renumbering and the RUMBA experiment management framework.
Haystack is introducing a new mode called DASH7 XR Mode that can triple the range of LoRa networks. It utilizes advanced error correction techniques as well as automated receipt responses. Testing shows it can achieve 2-3x the range of LoRaWAN networks while preserving multi-year battery life. Private beta testing of XR Mode is now underway.
Backplane Technology Overview for AdvancedTCAhuichenphd
This document provides an overview of backplane technologies for AdvancedTCA systems. It introduces AdvancedTCA and describes its chassis and board specifications. Five interconnect protocols - Ethernet, InfiniBand, StarFabric, PCI Express, and RapidIO - are then summarized in terms of their features, topologies, packet formats, and support for quality of service. The document concludes with a comparison of these protocols on various characteristics.
1. The document discusses routing algorithms for wireless sensor networks, focusing on RPL (IPv6 Routing Protocol for Low Power and Lossy Networks).
2. It provides an example to illustrate how RPL constructs a Destination Oriented Directed Acyclic Graph (DODAG) routing structure based on link metrics like distance and expected transmissions.
3. Nodes broadcast DODAG Information Object (DIO) messages to advertise their ranks and select preferred parents, building the DODAG over multiple rounds as nodes adjust their ranks and parents.
Mobility, traffic engineering and redundancy using RPLMaxime Denis
Master thesis presentation. Design and implementation of a solution to improve mobility between two physical WSNs using RPL. Based on the 6LBR implementation of the CETIC.
Towards the Internet of Relevant Things: the IEEE 802.15.4e StandardGiuseppe Anastasi
The document discusses the IEEE 802.15.4 standard and its limitations for Internet of Things applications with stringent requirements. It introduces the IEEE 802.15.4e standard, which amends 802.15.4 to add two new MAC modes - DSME and TSCH. DSME aims to provide bounded latency while TSCH uses channel hopping to improve reliability. The document surveys the literature on both new modes and discusses open issues and how 802.15.4e can help realize the vision of the Internet of Things.
The document discusses Internet of Things (IoT) networks and routing protocol RPL. It provides an agenda for covering open standards, IEEE and IETF work on low-power lossy networks (LLNs) and 6LoWPAN, concepts of RPL including DODAG, instances, objective functions and messages. It also discusses putting the pieces together including backbone routers and data packet flows. The goal is to reconsider basic Internet structures and expectations to support trillions of constrained devices connecting in IoT applications.
Low-power wide area networking technology offers long-range communication, enabling new types of IoT services. LoRaWAN is one of the most adopted solutions, providing ubiquitous connectivity for outdoor applications. However, its capabilities and limitations are not well understood. The authors provide an impartial overview of LoRaWAN's limitations to avoid unrealistic expectations, discussing use cases where it works and does not work, and listing open research questions.
This document proposes a new platform called CAAP (Cluster As Application Platform) that allows distributed applications to run on wireless device clusters. The key aspects are:
1. Replacing wired links between high-performance computing nodes with wireless D2D (device-to-device) links between mobile devices.
2. Allowing user-programmable networking beyond traditional protocols by programming RDMA verbs.
3. Pooled mobile device clusters can join multiple clusters simultaneously, running multiple applications and instances on shared resources. This opens new opportunities for distributed and edge computing applications.
Wireless IoT connections fall into two low-power camps: local area and wide area. Historically the two have not overlapped but advances in networking technologies make it possible for wide area technologies to perform the same functions as local area technologies with no additional cost or feature "sacrifice".
- Research has shown that LoRa experiences significant degradation in environments with heavy multipath interference like dense urban or indoor settings due to Rayleigh flat fading.
- Experimentation in an airport parking lot exhibiting Rayleigh flat fading validated this, showing Haystack XR2 encoding provided roughly 30 dB gain to packet error rate over default LoRaWAN encoding.
- This gain allows LoRa networks using Haystack XR2 to achieve much higher quality of service, efficiency, and channel density in challenging multipath environments.
LPWAN Technology ~ What is Weightless-P? Jay Wey 魏士傑
Weightless-P is a narrowband LPWAN technology that enables high device density, long range communication, years of battery life, and true bi-directional communication. It supports more devices per base station than other LPWAN technologies and provides low latency, reliable communication in both uplink and downlink directions through its synchronous network design. Weightless-P also features robust channel coding, bi-directional communication including over-the-air firmware updates, and is an open standard technology.
This document provides a technical overview of LoRa and LoRaWAN. It defines LoRa as the physical layer modulation that enables long-range communication, while LoRaWAN is the communication protocol and network architecture. Key aspects of LoRaWAN covered include the star network topology, support for multiple device classes to optimize battery life and latency, adaptive data rates for high network capacity, and security features. Regional variations of the LoRaWAN specification are described for Europe and North America. Comparisons are made between LoRaWAN and other LPWAN technologies, highlighting LoRaWAN's advantages in areas like battery life, coverage, cost, and ability to support a variety of IoT applications.
This document summarizes new developments in 5G NR user plane protocols:
1) It introduces the work plan for 5G NR and describes non-standalone and standalone 5G NR architectures.
2) It describes new 5G NR user plane protocols including the Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) layers.
3) Key enhancements in 5G NR include support for multiple numerologies, reduced latency through changes like removal of concatenation, and improved hybrid automatic repeat request (HARQ) through code block groups.
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
IoT Field Area Network Solutions & Integration of IPv6 Standards
Abstract: http://www.gogo6.com/profiles/blogs/my-presentation-at-gogolive-integration-of-ipv4-and-non-ip
Presentation video: http://www.gogo6.com/video/iot-field-area-network-solutions-integration-of-ipv6-standards-by
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Patrick Grossetete - Technical Marketing Engineer (IoT), Cisco
Bio/Profile: http://www.gogo6.com/profile/PatrickGrossetete
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
LoRa is a long range wireless radio technology for low power wide area networks (LPWANs) used in IoT and M2M applications. It uses license-free sub-GHz frequency bands and spreads signals over a wide bandwidth for long-range transmissions of up to 5-15 km in rural areas and 2-5 km in urban areas using low power consumption from battery-powered devices. The LoRa Alliance oversees the LoRaWAN standard to enable interoperability.
This document discusses NetSim software for simulating Internet of Things (IoT) networks. It describes how NetSim supports the 6LoWPAN and RPL protocols which are important standards for IoT. NetSim can be used to model large-scale IoT networks and evaluate routing protocols, energy efficiency, and other aspects of integrating heterogeneous IoT devices. RPL protocol implemented in NetSim forms the routing basis for IoT and establishes a routing topology using DODAG formation through control messages.
The document describes a Virtex-4 FPGA implementation of a Resilient Packet Ring (RPR) Media Access Control (MAC) solution that provides full compliance with the IEEE 802.17 standard for RPR networks. The implementation utilizes the Virtex-4 FPGA to create a compact dual-ring RPR MAC that requires only 11,000 slices and 80 block RAMs. The document also provides background on RPR networks and discusses applications like metro networks and wireless backhaul.
Zigbee Based Wireless Sensor Networks for Smart CampusIJMER
The document discusses simulations of Zigbee-based wireless sensor networks using different topologies with static and dynamic positioning of the Zigbee coordinator node. The simulations analyzed the effect on throughput and end-to-end delay. Results showed that a tree topology with a mobile coordinator had the highest throughput. A mesh topology, whether with static or dynamic coordinator, produced the lowest end-to-end delay. The document concludes that making the coordinator node mobile generally provides better network performance than a static coordinator configuration.
This document discusses enabling interoperability and scalability for the Internet of Things. It proposes using open standards like IPv6 adapted for constrained devices (6LoWPAN) and a lightweight HTTP-like protocol called CoAP. CoAP allows web technologies to be used in constrained environments and integrated with existing web services through proxies and resource directories. This approach aims to avoid vendor lock-in, connect IoT devices to the internet, and allow the web of things to scale through standard interfaces.
This document summarizes an approach called RINA (Recursive InterNetwork Architecture) for simplifying multi-layer network management. RINA proposes a common, repeating structure across layers with only two protocols - one for data transfer and one for layer management. This significantly reduces the complexity of management models compared to the IP protocol suite, which has unique protocols at each layer. A case study shows how RINA could simplify network management in a large-scale data center network by reducing the number of required addresses, forwarding entities, and management protocols. The consistent structure of RINA opens the door to increased network automation by making management models simpler and more standardized.
Advanced network experiments in FED4FIREARCFIRE ICT
1) The document discusses past and present experiments on the Fed4FIRE testbed for advanced network experiments, including experiments on carrier-grade SDN, network resilience, quality of service differentiation, and clean-slate networking approaches like RINA.
2) It describes experiments testing restoration and protection in SDN networks, quality of service differentiation across multiple autonomous systems, and validation of RINA concepts like recursive networking, shim-based virtual machine networking, and programmability.
3) It introduces the ARCFIRE project which aims to enable large-scale experimentation with RINA on Fed4FIRE+ through innovations like seamless node renumbering and the RUMBA experiment management framework.
Haystack is introducing a new mode called DASH7 XR Mode that can triple the range of LoRa networks. It utilizes advanced error correction techniques as well as automated receipt responses. Testing shows it can achieve 2-3x the range of LoRaWAN networks while preserving multi-year battery life. Private beta testing of XR Mode is now underway.
Backplane Technology Overview for AdvancedTCAhuichenphd
This document provides an overview of backplane technologies for AdvancedTCA systems. It introduces AdvancedTCA and describes its chassis and board specifications. Five interconnect protocols - Ethernet, InfiniBand, StarFabric, PCI Express, and RapidIO - are then summarized in terms of their features, topologies, packet formats, and support for quality of service. The document concludes with a comparison of these protocols on various characteristics.
1. The document discusses routing algorithms for wireless sensor networks, focusing on RPL (IPv6 Routing Protocol for Low Power and Lossy Networks).
2. It provides an example to illustrate how RPL constructs a Destination Oriented Directed Acyclic Graph (DODAG) routing structure based on link metrics like distance and expected transmissions.
3. Nodes broadcast DODAG Information Object (DIO) messages to advertise their ranks and select preferred parents, building the DODAG over multiple rounds as nodes adjust their ranks and parents.
This document discusses IEEE 802.15.4 and Zigbee wireless communication standards. It provides an overview of 802.15.4, including its applications, characteristics, frequency bands, and MAC and PHY specifications. It also describes Zigbee's architecture and how it works with 802.15.4 at higher protocol layers to provide networking and routing functionality. Typical network topologies for 802.15.4 like star, peer-to-peer, and combined are also covered.
The document describes the oLAF algorithm for building Available Routing Constructs (ARCs) in a network. oLAF is a variation of the SPF algorithm that creates ARCs by connecting shortest path trees. It identifies mono-connected zones in the network and provides redundancy within these zones by forming ARCs. The algorithm works by picking nodes in order of closest to the root and building dependent sets for each node to form ARCs between safe nodes that have multiple paths to different parts of the network. This allows traffic to be rerouted within ARCs in the event of failures while avoiding forwarding loops.
Mise à jour de la carte mentale structure d'un rapport de projet de fin d'études. Cette carte est pour apporter de l'aide aux étudiants Bac+5 Ingénierie et Master.
Vous souhaitant bonne lecture et bonne continuation.
Vos remarques et suggestions sont les bienvenues
Energy consumption study of a WSN using 6TiSCH architectureFederico Sismondi
Motivated by the active developments on the industrial automated world and the new technologies arising in the
area of Internet of Things, the IETF, based on IEEE’s existing standards, and some already accepted protocols,
propose a new architecture to satisfy the needs of both fields.
6tisch, the new IETF’s architecture to be studied during our project, aims to give a convergent solution for both
fields that have plenty of common points. It aims to satisfy the requirements of the wireless low powered lossy networks. Among them, we can point out: energy management policy, energy efficient design, link reliability,
robustness, scalability support, interoperability, self organization, end to end reliability, security and mobility
support, as the most noticeable ones.
The project proposed aims to obtain a well founded experience on how the newly developed architecture 6tisch performs in the OpenWSN project. The partner enterprise wants to quantify the energy consumed by the motes in a real use case, with special detail on how the different parameterizations of the protocol stack would affect it.
Due to the increasing need of networks relying on low energy consumption, our project will analyze from the
lowest layers of the protocol stack how 6tish architecture performs energywise and how the different mechanisms like routing table construction, message forwarding function, scheduling of the TSCH slots, and many others will perform.
Current state of IEEE 802.1 Time-Sensitive Networking Task Group Norman Finn,...Jörgen Gade
The document discusses the current state of the IEEE 802.1 Time-Sensitive Networking Task Group. It provides details on deterministic networking features like time synchronization, resource reservation, and extremely low packet loss ratios. It describes work being done in the task group on standards for time synchronization, bandwidth reservation, queuing models, and other technologies to enable deterministic networking capabilities in Ethernet networks.
This document discusses how integrating time-sensitive networking (TSN) with a data-centric connectivity approach using the Data Distribution Service (DDS) can improve industrial control systems. TSN provides real-time and deterministic networking over Ethernet, while DDS enables loose coupling, plug-and-play integration, and data sharing through its publish-subscribe model. Together, TSN and DDS can address challenges with traditional connectivity approaches by leveraging commodity hardware, simplifying integration, and allowing for improved data usage. The document outlines relevant TSN standards and how DDS quality of service policies can map to TSN priorities to provide deterministic networking.
The document describes the design and implementation of a new high performance data transport protocol called UDT. UDT is implemented at the application layer over UDP to provide reliable, high-speed data transfer capabilities. It includes a new congestion control algorithm based on AIMD with decreasing increases that aims for efficiency, fairness and friendliness. Experimental results show UDT achieves high throughput and good fairness compared to TCP. The document also introduces a configurable framework called Composable UDT that allows new congestion control algorithms to be easily implemented and evaluated.
A Platform for Data Intensive Services Enabled by Next Generation Dynamic Opt...Tal Lavian Ph.D.
The new architecture is proposed for data intensive enabled by next generation dynamic optical networks
Offers a Lambda scheduling service over Lambda Grids
Supports both on-demand and scheduled data retrieval
Supports bulk data-transfer facilities using lambda-switched networks
Provides a generalized framework for high performance applications over next generation networks, not necessary optical end-to-end
Supports out-of-band tools for adaptive placement of data replicas
Intelligent Network Services through Active Flow ManipulationTal Lavian Ph.D.
Active Flow Manipulation Abstractions:
Aggregate data into traffic flows
Flows whose characteristics can be identified in real-time
E.g., “all UDP packets to a particular service”, “all TCP packets from a particular machine”.
Actions to be performed in the traffic flows
Actions that can be performed in real-time
E.g., “Change the priority of all traffic destined to a particular service on a particular machine”, “Stop all traffic out of a particular link of a router”.
A Platform for Data Intensive Services Enabled by Next Generation Dynamic Opt...Tal Lavian Ph.D.
The new architecture is proposed for data intensive enabled by next generation dynamic optical networks
Encapsulates “optical network resources” into a service framework to support dynamically provisioned and advanced data-intensive transport services
Provides a generalized framework for high performance applications over next generation networks, not necessary optical end-to-end
Supports both on-demand and scheduled data retrieval
Supports a meshed wavelength switched network capable of establishing an end-to-end lightpath in seconds
Supports bulk data-transfer facilities using lambda-switched networks
Supports out-of-band tools for adaptive placement of data replicas
Offers network resources as Grid services for Grid computing
This document outlines the thesis project of Satya Prakash Rout, a student pursuing an M.Tech in Applied Optics. The project involves emulating different Dynamic Bandwidth Allocation algorithms to monitor the performance of a 10G-EPON network implementing Triple Play. Specific aspects that will be studied include implementing Triple Play with a new scheduling algorithm called TD-Sense, generating different traffic models, comparing the performance of DBA-Gated, DBA-Linear and DBA-Max algorithms, and potential future work involving long-reach PONs and green networking techniques. The document concludes by acknowledging the contributions of the student's guide, advisors and classmates to the successful completion of the project.
9.) audio video ethernet (avb cobra net dante)Jeff Green
Replacing a crossbar switch with ‘virtual’ IP packet switching - The ability to expand video-over-IP systems ‘one piece at a time’ and the decentralized nature of the matrix makes the technology very compelling for any size or scope of AV project.. AV-over-IP is the transport of AV signals over a standard Ethernet network, including…
HD Video (e.g. HDMI, DVI)
Audio
Control Signals (e.g. IR)
Peripheral Signals (e.g. USB)
Does Dante require special switches? No. We strongly recommend that Gigabit switches be used due to the clear advantages in performance and scalability.
Does Dante require a dedicated network infrastructure? No, a dedicated network infrastructure is not required. Dante-enabled devices can happily coexist with other equipment making use of the network, such as general purpose PCs sending and receiving email and other data.
Does Dante require any special network infrastructure? No, special network infrastructure is not required. Since Dante is based upon universally accepted networking standards, Dante-enabled devices can be connected using inexpensive off-the-shelf Ethernet switches and cabling.
What features are important when purchasing a switch? Dante makes use of standard Voice over IP (VoIP) Quality of Service (QoS) switch features, to prioritize clock sync and audio traffic over other network traffic. VoIP QoS features are available in a variety of inexpensive and enterprise Ethernet switches. Any switches with the following features should be appropriate for use with Dante:
Gigabit ports for inter-switch connections
Quality of Service (QoS) with 4 queues
Diffserv (DSCP) QoS, with strict priority
Totally new to AV over IT? This may help. If you have worked with any of the popular protocols, your time is better spent in other sessions. AV over IT methods vary in application of OSI model. Audio Networking - One RJ45 and CAT5 cable for dozens of signal paths. Switches can provide hardware time stamping which allows synchronization, offsets, and corrections. All covered in IEEE 1588.
Ethernet Timing & Priority Standards - All audio over Ethernet protocols require Priority, Sequence, & Sync
Differentiated Services / Quality of Service (DiffServ, QoS)
Priority by data type (Clock Sync and Audio Packets over Email)
Traffic prioritized based upon tags in IP Header (Layer 3)
Priority number assigned by manage switch to each packet
Real-time Transport Protocol (RTP)
Keeps data sequenced in the right order
Time stamp on UDP header
Works with RTCP (Real Time Control Protocol) for QoS and Sync
Variation: RTSP (Real Time Streaming Protocol) works on TCP and not UDP
Does not reserve resources or provide for quality of service
Precision Timing Protocol (PTP)
IEEE 1588
Sub-microsecond accuracy to synchronize subnets
Layer 2 - Switches provide hardware-based time stamping
The document summarizes the UDT protocol, which is a high performance transport protocol designed for data-intensive applications over high-speed networks. It discusses the limitations of TCP for these applications and high bandwidth-delay product networks. It then provides an overview of the design and implementation of the UDT protocol, including its congestion control algorithm, APIs, and composable framework. It evaluates UDT's performance in terms of efficiency, fairness, and stability compared to TCP. The goal of UDT is to enable efficient, fair, and friendly transport of data for distributed applications over high-speed networks.
Pre-Con Education: Recognizing Your Network's Key Performance Indicators Th...CA Technologies
Understanding key network metrics that impact end-user experience and how to leverage these key performance indicators is imperative for troubleshooting issues and restoring optimal network performance.
In this presentation, you will learn how to establish fundamental metrics for technology communications, gain an understanding of key concepts attributed to communication processes, gain an understanding of network performance metrics that actually impact end users, understand five sources of network latency and learn to use reference models as a troubleshooting tool.
For more information on DevOps solutions from CA Technologies, please visit: http://bit.ly/1wbjjqX
The document discusses how application architects traditionally focused on solving IO bottlenecks in servers by offloading processing to intelligent network interface cards. With modern distributed applications spanning thousands of servers, application architects now must consider network topology, segmentation, and control plane protocols to optimize latency and bandwidth. The rise of virtualization and cloud computing has changed traffic patterns in datacenters from north-south traffic to dominant east-west traffic between servers. This requires new datacenter fabric designs beyond the traditional three-tiered topology.
This document discusses several types of computer networks:
- Cloud interconnection networks which connect servers hierarchically and must provide scalability, low cost, low latency and high bandwidth. InfiniBand is commonly used.
- Storage area networks which connect servers to storage devices using Fiber Channel protocol and provide block storage transfers.
- Content delivery networks which replicate and deliver content from origin servers to edge caches for improved performance and scalability.
- Overlay networks which are built on top of physical networks and are used in peer-to-peer, content delivery, and client-server systems. Scale-free networks follow a power law degree distribution and many real-world networks have this property.
Do We Really Need TSN in Next-Generation Helicopters? Insights From a Case-StudyRealTime-at-Work (RTaW)
As Ethernet rapidly replaces legacy networks as the core high-speed network in helicopter’s avionics and mission systems, we ask in this paper the question of the technical benefits of migrating to Ethernet Time-Sensitive-Networking (TSN). Indeed, TSN has become a rich toolbox of mechanisms and protocols to address Quality-of-Service (QoS) requirements pertaining to timing and reliability. TSN is quickly becoming the prominent technology for wired high-speed communications in a variety of application domains like automotive, industry 4.0 and telecom. In this context, this work explores the use of TSN timing QoS mechanisms for helicopter’s avionics and mission systems on a case-study representative of the communication requirements of next-generation systems. This study aims to provide quantified insights into what can be expected from TSN in terms of timing, memory usage and extensibility. Paper available at http://hdl.handle.net/10993/48093
Communication over the kinds of Data-Links used for unmanned vehicles presents important challenges dues to the low bandwidth, intermittent, and lower reliability of these links. Classic network protocols such as TCP do not operate well in this environment forcing application developers to implement their own reliability and session management. This presentation describes he issues and alternatives.
High performance browser networking ch1,2,3Seung-Bum Lee
Presentation material including summary of "High Performance Browser Networking" by Ilya Grigorik. This book includes very good summary of computer network not only for internet browsing but also multimedia streaming.
The N3K-C31108TC-V is a Cisco Nexus 31108TC-V switch that provides 48 10GBASE-T ports, 6 QSFP28 ports, and up to 2.16 Tbps of switching capacity. It is a 1RU fixed form factor switch that supports line-rate L2 and L3 switching, VXLAN routing, 16 MB of shared buffering, and high availability features. The switch has redundant power and fans and is designed for use in data centers and cloud computing environments.
This document discusses four approaches to improving Linux performance in embedded multicore devices: 1) the Linux PREEMPT_RT patch set, which replaces kernel spinlocks with mutexes to improve real-time responsiveness but can reduce throughput; 2) LWRT, which partitions Linux into real-time and non-real-time domains to avoid using the kernel and improves both real-time performance and throughput; 3) the Open Event Machine, which partitions Linux and runs some processes on a non-Linux runtime; and 4) hypervisors or "thin kernels", which add a real-time kernel underneath Linux. The document focuses on explaining LWRT and how it compares to PREEMPT_RT in improving both real
The document discusses network design concepts for building a resilient network. It emphasizes the importance of considering redundancy at multiple levels, from the physical infrastructure to network protocols. Well-designed networks are modular, have clearly defined functional layers, and incorporate redundancy through techniques like load balancing and diverse circuit paths. Hierarchical network designs with logical areas can also improve convergence times during failures.
Presentation of IEEE Slovenia CIS (Computational Intelligence Society) Chapte...University of Maribor
Slides from talk presenting:
Aleš Zamuda: Presentation of IEEE Slovenia CIS (Computational Intelligence Society) Chapter and Networking.
Presentation at IcETRAN 2024 session:
"Inter-Society Networking Panel GRSS/MTT-S/CIS
Panel Session: Promoting Connection and Cooperation"
IEEE Slovenia GRSS
IEEE Serbia and Montenegro MTT-S
IEEE Slovenia CIS
11TH INTERNATIONAL CONFERENCE ON ELECTRICAL, ELECTRONIC AND COMPUTING ENGINEERING
3-6 June 2024, Niš, Serbia
Literature Review Basics and Understanding Reference Management.pptxDr Ramhari Poudyal
Three-day training on academic research focuses on analytical tools at United Technical College, supported by the University Grant Commission, Nepal. 24-26 May 2024
Introduction- e - waste – definition - sources of e-waste– hazardous substances in e-waste - effects of e-waste on environment and human health- need for e-waste management– e-waste handling rules - waste minimization techniques for managing e-waste – recycling of e-waste - disposal treatment methods of e- waste – mechanism of extraction of precious metal from leaching solution-global Scenario of E-waste – E-waste in India- case studies.
4. 4
New level of (Deterministic?) guarantees
A differentiator for high-end forwarding engines
Sharing physical resources with classical networking
For traffic known a priori (control loops…)
Time Synchronization and global Schedule
5. 5
End-to-End latency enforced by timed pause at station
Periodic trains along a same path and same schedule
Collision avoidance on the rails guaranteed by schedule
5
6. 6
A bus every T. minutes, Stop A to Stop B in X. minutes
Worst end-to-end delivery time < (T + X)
Every packet in an Airbus 380 takes a bus across the fabric
6
7. 7
Two classes of bleeding-edge customers, Industrial and Audio/Video.
Both have moved into the digital world, and some are using packets, but now they all
realize they must move to Ethernet, and most will move to the Internet Protocols.
1. Industrial: process control, machine control, and vehicles.
At Layer 2, this is IEEE 802.1 Time-Sensitive Networking (TSN).
Data rate per stream very low, but can be large numbers of streams.
Latency critical to meeting control loop frequency requirements.
2. Audio/video: streams in live production studios.
At Layer 2, this is IEEE 802.1 Audio Video Bridging (AVB).
Not so many flows, but one flow is 3 Gb/s now, 12 Gb/s tomorrow.
Latency and jitter are important, as buffers are scarce at these speeds.
3. Vehicule, SmartGrid: streams in live production studios
Norm Finn draft-finn-detnet-problem-statement-01 7
8. 8
Back-of-the-envelope calculations:
1. Industrial:
Automotive factory floor: 1000 networks • 1000 packets/s/network •
100,000 s/day = 1011 packets/day.
Machine fails safe when 2 consecutive packets are lost.
At a random loss ratio of 10–5, 10–10 is chance of 2 consecutive losses.
1011 packets/day • 10–10 2-loss ratio = 10 production line halts/day.
In extreme cases, lost packets can damage equipment or kill people.
2. Audio video production: (not distribution)
1010 b/s • 10 processing steps • 1000 s/show = 1014 bits = 1010 packets.
Waiting for ACKs and retries = too many buffers, too much latency.
Lost packets result in a flawed master recording, which is the user’s end product.
Norm Finn draft-finn-detnet-problem-statement-01 8
9. 9
1. Zero congestion loss.
This requires reserving resources along the path. (Think, “IntServ” and “RSVP”) You cannot guarantee
anything if you cannot say, “No.”
This requires hardware in the form of buffers, shapers, and schedulers. Overprovisioning not useful: its
packet loss curve has a tail.
Circuits only scale by aggregation in to larger circuits. ( MPLS? Others?)
0 congestion loss goes hand-in-hand with finite guaranteed latency, also of importance to the users.
2. Seamless redundancy.
1+1 redundancy: Serialize packets, send on 2 (or more) fixed paths, then combine and delete extras.
Paths are seldom automatically rerouted.
0 congestion loss means packet loss is failed equipment or cosmic rays.
Zero congestion loss satisfies some customers without seamless redundancy. The reverse is not true in a
converged network—if there is congestion on one path, congestion is likely on the other path, as well.
draft-finn-detnet-problem-statement-01Norm Finn 9
10. 10
It’s all about
Real boxes and links
Real buffers and queues
Real packets
Real Time
10
It’s not about
Classical Layers
Standard bodies
QoS and stat mux
11. 11
• Single nailed-up path
Sender
(Talker)
NIC
NIC
Flow ID
Receiver
(Listener)
Per-Flow State
11
12. 12
Replication & Elimination of individual packets
Sender
(Talker)
NIC
NIC
Flow ID
Receiver
(Listener)
Per-Flow State
12
16. 16
Same as normal networking, but with the following features for critical data streams:
1. Time synchronization for network nodes and hosts to better than 1 µs.
2. Software for resource reservation for critical data streams (buffers and
schedulers in network nodes and bandwidth on links), via configuration,
management, and/or protocol action.
3. Software and hardware to ensure extraordinarily low packet loss ratios, starting
at 10–6 and extending to 10–10 or better, and as a consequence, a guaranteed
end-to-end latency for a reserved flow.
4. Convergence of critical data streams and other QoS features (including ordinary
best-effort) on a single network, even when critical data streams are 75% of the
bandwidth.
Norm Finn draft-finn-detnet-problem-statement-01 16
17. 17
• IEEE Std 802.1BA-2011 “Audio Video Bridging (AVB) Systems”
A profile of a number of standards, picking out required options, special initialization parameters, etc., required for AVB-compliant
bridges and end stations.
An “AVB Device” is a device conforming to 802.1BA.
• IEEE Std 802.1AS-2011 “Timing and Synchronization for Time-Sensitive Applications in Bridged Local
Area Networks”
A plug-and-play profile of IEEE 1588, including master clock selection, link discovery, and automatic creation of a tree to distribute
the clock signal.
• IEEE Std 802.1Qat-2010 “Stream Reservation Protocol (SRP)”
The software protocol for making stream reservations
Has been rolled into 802.1Q as Clauses 34 and 35 of IEEE Std 802.1Q-2011.
• IEEE Std 802.1Qav-2009 “Forwarding and Queuing Enhancements for Time-Sensitive Streams”
A special credit-based hardware shaper for bridges and end stations that gives better latency guarantees than the usual shapers.
Has been rolled into 802.1Q as Clause 34 of IEEE Std 802.1Q-2011.
• IEEE Std 1722-2011 “Layer 2 Transport Protocol for Time Sensitive Applications in a Bridged Local Area
Network”
A Layer 2 transport protocol carrying a time-to-display stamp on each packet.
• (All 802 standards (not 1722) are free 6 months after publication at http://standards.ieee.org/about/get.)
Norm Finn draft-finn-detnet-problem-statement-01 17
18. 18
• P802.1AS-REV* “Timing and Synchronization”
Revision of 802.1AS making it clear that it can run on a router as easily as on a bridge.
• P802.1Qbu* “Frame Preemption”
Amends 802.1Q to support 802.3br
• P802.3br “Interspersed Express Traffic”
One level of transmission preemption – interrupts transmission of an ordinary frame to transmit an “express” frame, then resumes the
ordinary.
802.3 document, not an 802.1 document.
• P802.1Qbv* “Enhancements for Scheduled Traffic”
Runs the 8 port output queues of a bridge on a rotating schedule.
• P802.1Qca* “Path Control and Reservation”
Enhances 802.1 ISIS to create multiple paths through a network.
• P802.1CB* “Seamless Redundancy”
Defines the sequence-split-recombine method for reliability improvement.
Stand-alone document. NOT an amendment to 802.1Q.
• P802.1Qcc* “Stream Reservation Protocol (SRP) Enhancements and Performance Improvements”
For more streams, faster convergence, less chattiness, and maybe more.
* For the necessary password, Google “p802.1 username password”
Norm Finn draft-finn-detnet-problem-statement-01 18
20. 20
Challenge: harness innovation
More efficient operations
New and/or improved experience
Beyond Control and Automation
Optimize processes (by 1%?)
Leveraging IT, Live big data and Analytics
21. 21
Control Loops
global optimization of routes for jitter an latency – thus computed by a PCE -,
flow (over) provisioning, duocast for 1 hop (1Hz and 4Hz, no routing) with static multipath hard slot allocation.
Control Loop plan B
self-healing -thus distributed- routing, RPL
Supervisory Flows
no goal: requires determinism up into the backbone
Management
a separate topology – a RPL instance - that does not break.
OF?, root selection?
Alerts
bursty, unexpected, on-demand slot allocation, prioritization
22. 22
Large Scale Monitoring / Live Big Data
stuff like corrosion? low cost scalability – this distributed routing, soft slots?
Device (Limited) Mobility
E.g. Cranes spanning area (ship)
with linear and circular motion that are mobile within a range
Mobile Worker
additionally provision slots ready for mobile workers) does not need deterministic since human
Wide Subnets
thousands of devices– thus a backbone, multiple BBRs for 1 LLN –
within a subnet – to avoid renumbering though not always the case, sometimes isolation is wanted
Non-Production Episodes
fast and autonomic behavior – again distributed routing
Coexistence with Legacy Devices
a common management above, coarse level makes sense (channels backlisting but no more…single admin is good)
23. 23
• Not Process Control but “Missing Measurements”
Reliability and availability are important, which implies
Scheduling and admission control
• Scalability
10’s of thousands of new devices
• Deployment cost factor is key
For Emerson this is the second layer of automation:
Typically missing are the measurements you need to
monitor the condition of the equipment--temperature,
pressure, flow and vibration readings you can use to
improve site safety, prevent outages and product losses,
and reduce maintenance costs of equipment such as
pumps, heat exchangers, cooling towers, steam traps and
relief valves.
24. 24
15M to 115M Analytics
related connections*
Classical Monitoring
only doubles
Analytics related M2M
connections surge
* Source:
ABI Research
25. 25
* Source:
ABI Research
Big Data and
Analytics
“Without adequate analytics clout available, and the right practices to take advantage of it, the companies
rolling out M2M solutions will be destined to be stuck in the lower realms of applications: monitoring, reporting,
and simple rules-based actions.” *
Large Scale
monitoring
6TiSCH
27. 27
Maintenance and operation
represent 75% of the Total
equipment cost
Downtime
Maintenance & operation COST
Corrective maintenance
Preventive
Maintenance
Predictive
Maintenance
Actionable Prescriptions
Deployment of Wireless sensors is seen as an efficient solution
28. 28
Data: Capillary Wireless
Acquisition of large amounts of
live Big Data
Information: Fog DiM to add
descriptive meta-tags,
allowing for compression
and correlation
Knowledge: Prediction from
self-learned models and
Knowledge Diffusion
Wisdom: Machine Learnt
Expertise, auto-Generating
Prescriptions and Actionable
Recommendations
(Data)
ACQUISITION
(Knowledge)
DIFFUSION
(Wisdom)
OPEN LOOP
(Information)
AGGREGATION
6TiSCH Data in
Motion / Fog
Learning
Machines
/ Cloud
29. 29
• IIC website http://www.iiconsortium.org
• New York Times http://bit.ly/IIC-03272014
• IEEE http://flip.it/zbfnU
• Huge tutorial http://bit.ly/iic-319
• McRock's Industrial Internet of Things Report 2014
• AT&T, CISCO, GE, IBM AND INTEL FORM INDUSTRIAL INTERNET CONSORTIUM TO
IMPROVE INTEGRATION OF THE PHYSICAL AND DIGITAL WORLDS March 27, 2014
30. 30
Customers after next % point of operational optimization:
Requires collecting and processing of live “big data”, huge amounts of missing
measurements by widely distributed sensing and analytics capabilities.
Achievable by combination of the best of IT and OT technologies together, forming
the IT/OT convergence, aka Industrial Internet.
Architectural approach, standards, Industry adoption needed to embrace radical
changes happening in IT networking technologies. Products are following.
Secured-by-default model required throughout network lifecycle.
6TiSCH extends Deterministic Wireless Industrial Networking technologies to also
reach higher scales at lower costs (but then, guarantees as well).
Operational technology (OT) is hardware and software that detects or causes a change through the
direct monitoring and/or control of physical devices, processes and events in the enterprise.
32. 32
Link State requires full & constant topology awareness
=> 6TiSCH / RPL chose Distance Vector
Wireless scales but power constraints and fuzzy topology
=> Different risks, value in diversity
TDMA requires timesync, CSMA-CA needs idle time
Different usages, deterministic vs. best effort
Reactive mixes routing and forwarding (eg IPv6 ND)
Centralized optimizes, Distributed scales economically
=> Different usages, deterministic vs. best effort
Link State ?
Wired?
CSMA?
Reactive ?
Centralized
?
Single
Hop ?
Spatial reuse
=> Wired backhaul a good idea in any case
33. 33
Reaching farther out
New usages / types of devices
Global Coverage from Near Field to Satellite via 3/4G
BUT
Lack of trust in Industrial vs. Wired
Multiple Interferers, ISM band crowded
Issues with IPv6 for Scalability and Mobility
New level of cost effectiveness
Deploying wire is slow and costly
Low incremental cost per device
34. 34
Higher speed does not necessarily mean more energy
Energy budget: Power vs. Time
LP WiFi a contender to 802.15.4
802.11ah designing for 2 hops
Interesting developments in LowPower-WideArea
ultra narrow band (e.g. SigFox 100KHz)
802.15.4K (e.g. OnRamp Wireless)
LOng RAnge (Cycleo / Semtech, 2.4GHz
35. 35
16channeloffsets
e.g. 31 time slots (310ms)
A
BC
D
E
F
G
H
I
J
• Schedule => direct trade-off between throughput, latency and power consumption.
• A collision-free communication schedule is typical in industrial applications.
• But requires network synchronization, and de-sync means long isolation
36. 36
Channel Hopping :
retry around interference,
round robin strategy
Time Slotted (or Synchronized) :
Deterministic: through TDM, Synchronized + Time formatted in SlotFrame(s)
Tracks: below IP, can be orchestrated by a third party like virtual circuits
Slotted: benefits of slotted aloha vs. aloha => reduce chances of collisions
Battery operation: when traffic profile is known, devices only wake upon need
38. 38
Direct Communication when possible yields:
• Simpler design
• Lower OPEX
• Multipath issues and uneven transmission quality
Low Power TSCH mesh is a complex technology adapted to:
• Range extension with Spatial reuse of the spectrum
• Centralized Reservation for deterministic critical data streams.
• Separation of resources for classical IP routing (RPL)
Norm Finn draft-finn-detnet-problem-statement-01 38
40. 40
IEC based on HART 7.1.
TDMA
fixed time slots (10ms)
Mesh only
Shipped YE-2008.
Vendor driven
Emerson, E&H, ABB,
Siemens
IEC based on 2011 revision
TDMA+CSMA
Var. time slots
Star, mesh and hybrid topology
IPv6, 6LoWPAN, TCP-friendly
Shipped mid-2010
Mostly user driven
Honeywell, Yokogawa, Invensys
IEC 62601
WIA-PA
IEC 62591 IEC 62734
ISA100.11a
Alternate from China
Star, mesh and hybrid
topology
Standardization work
started in 2006.
42. 42
• Industrial requires standard-based products
• Must support equivalent features as incumbent protocols
• Must provide added value to justify migration
• 6TiSCH value proposition
Design for same time-sensitive MAC / PHY (802.15.4e TSCH)
Direct IPv6 access to the device (common network mgt)
Distributed routing & scheduling for scalability (for monitoring)
Large scale IPv6 subnet for mobility (50K +)
43. 43
Active IETF WG, 6 WG docs in or close to last call
Define an Architecture that links it all together
Align existing standards
(RPL, 6LoWPAN, PANA, RSVP, PCEP, MPLS) over 802.15.4e TSCH
Support Mix of centralized and distributed deterministic routing
Design 6top sublayer for L3 interactions
Open source implementations (openWSN…)
Multiple companies and universities participating
45. 45
Limit of IP direct connectivity
ISA100.11a ||
WirelessHART
ISA100.11a ||
WirelessHART
Sensor
Wireless Control
Loop
Actuator
PLC
Root AP
Management
Wireless Controller
NAC
/Firewall
- Control loop limited to subnet
- No end-to-end IP connectivity
- No single view management
- No Cisco presence in control loop
Mesh AP +
Manager +
App GW
VPN Concentrator
48. 48
So WHY ?
• From a technology point of view
Scheduled network + PCE
Emulate Industrial WSNs including TSN aspects and limitations (mobility, scalability)
Peristaltic Scheduling + Distributed routing and scheduling (RPL) + Efficient IPv6 ND (WiND)
Large scale monitoring for Industrial Internet in Co-Existence with Industrial WSNs
• From a user point of view
Common Network management (over IPv6)
Open standards (IETF, IEEE, IEC)
Reduced OPEX (though we suggest end-to-end pcpl & multiple apps as opposed to single protocol)
• From a market point of view
IPv6 end-to-end enable control loop virtualization
Support dynamic scheduling and deterministic on a same network
Single administration, lower OPEX
49. 49
Deterministic IPv6 over IEEE802.15.4e TimeSlotted Channel Hopping (6TiSCH)
The Working Group will focus on enabling IPv6 over the TSCH mode of the
IEEE802.15.4e standard. The scope of the WG includes one or more LLNs, each
one connected to a backbone through one or more LLN Border Routers (LBRs).
Active drafts
http://tools.ietf.org/html/draft-ietf-6tisch-terminology
http://tools.ietf.org/html/draft-ietf-6tisch-tsch
http://tools.ietf.org/html/draft-ietf-6tisch-architecture
http://tools.ietf.org/html/draft-ietf-6tisch-minimal
http://tools.ietf.org/html/draft-ietf-6tisch-6top-interface
http://tools.ietf.org/html/draft-ohba-6tisch-security
http://tools.ietf.org/html/draft-ietf-6tisch-coap
50. 50
Converged Plant Network
High availability
Flow Isolation
Guaranteed Bandwidth
IP based Control Network
Autonomic, zero touch commissioning
Time Sensitive Networking for critical apps
Packet Reliability
IPv6-based Wireless Field Network
Deterministic, Autonomic, Secure
Large Scale for Monitoring (RPL)
Backward Compatible (with ISA100 or HART)
10’s
of K
10’s
100’s
Control
network
Converged plant net
Wireless Field network
53. 53
1. Scans all channels to detect
Extended Beacon
2. Synchronizes
3. Parses beacons for schedule
4. Performs Join Process (AAA)
5. Renumbers and DADs
6. Route setup (eg RPL DAO)
6TiSCH forms a single multilink
subnet, no loss of sync, no
renumbering
Discovery steps; new/moving device:
54. 54
Neighbors are discovered at L2 from 15.4e MAC Extended Beacon
Time parent selection based on a join priority field in the EB
Join priority as a distance but no real loop avoidance
=> time loops and
=> node isolation
When a new node B joins the network
it needs to wait for an EB to align itself to the sequence of slots
EBs are sent using TSCH
Node cannot know in advance the channel to listen
it may take a long time for B before catching an EB
The problem exacerbates for bootstrapping networks with many hops
After a node joins
synchronization should be maintained using data/ack and keepalive handshakes
55. 55
One RPL instance dedicated to time parenting
RPL Rank used as join priority, set once once joined that timing instance
0xFF (Infinite) as long as not joined that instance => not a suitable time parent
RPL provides a better loop avoidance yet may let temporary loops
If DAGMaxRankIncrease is non-zero
8.2.2.4. Rank and Movement within a DODAG Version
If multiple control messages are lost
Loops will be detected reactively on traffic
3.2.7. Data-Path Validation and Loop Detection
11.2. Loop Avoidance and Detection
Q: Proscribe DAGMaxRankIncrease > 0 ?
56. 56
56
Multiple uncoordinated DODAGs with
independent roots (differing DODAGIDs)
DODAGs partition the network
No connectivity between DODAGs
to distribute time:
e.g. roots are GPS-based time sources
Nodes may jump to alternate DODAG
A single DODAG with a single root
May be used for time synchronization
Time may drift with distance if large mesh
A single DODAG with a virtual root that
coordinates LLN sinks (with the same
DODAGID) over a backbone network
May be used for time synchronization
Time can be synchronized over the backbone
e.g. Precision Time Protocol (IEC 61588, IEEE 1588v2)
6TiSCH
LLN
6TiSCH LLN
6TiSCH
LLN
Common time
source
Floating
root
59. 59
Distance Vector + stretch
Peer only with parents
DV + Non-storing mode
Lazy Update & datapath valid.
Constrained instances, TID
Req coupling with LISP/NEMO
Dynamic topologies
Peer selection
Constrained Objects
Fuzzy Links
Routing, local Mobility
Global Mobility
Low Power Lossy Nets Addressed in RPL ?
60. 60
In the context of routing, a Directed
Acyclic Graph (DAG) is formed by a
collection of vertices (nodes) and edges
(links).
Each edge connecting one node to
another (directed) in such a way that it is
not possible to start at Node X and follow
a directed path that cycles back to Node
X (acyclic).
A Destination Oriented DAG (DODAG) is
a DAG that comprises a single root node.
Here a DAG that is partitioned in 2
DODAG
Clusterhead
5
4
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4
61. 61
In Green: A’s subDAG.
Impacted if A’s connectivity is
broken
Domain for routing recovery
In Red: B’s fanout DAG
(or reverse subDAG)
Potential SPAN on B’s DAO
Thus potential return paths
Fanout must be controlled to limit
intermediate states
Clusterhead
5
4
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4
A
B
62. 62
e.g. ARC of siblings
Allows more alternates
ARCs are walked with no routing
progress
Forwarding over DAG AND ARCs
Reduces congestions of upper links
of the DAG
Still LORA for P2P
IGP subarea (bidirectional)
Link selected and oriented by TD
Potential link
Clusterhead
5
Clusterhead
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
63. 63
Either
routes in the RIB / VRF or
G-MPLS forwarding state
Indexed by tuple (IPv6, InstanceID)
Steps:
1. A needs a route to B
2. A selects a local InstanceID
3. A requests a computation from PCE
4. PCE returns route steps (and timeslots)
5. A install routing/forwarding states along
returned route or use source routing
Track
PCEP request Potential link
Clusterhead
5
Clusterhead
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
PCE
BA
64. 64
The RPL instance ID allows different routing optimizations, constraints and policies.
D Local Instance ID 0..64
0 1 2 3 4 5 6 7
0 Global Instance ID 0..128
0 1 2 3 4 5 6 7
1
The RPL instance ID is encoded in 1 octet. The first bit indicates whether Global or Local.
“A local RPLInstanceID is autoconfigured by the node that owns the DODAGID and it MUST be unique for that
DODAGID. The DODAGID used to configure the local RPLInstanceID MUST be a reachable IPv6 address of the node,
and it MUST be used as an endpoint of all communications within that Local instance.”
Inside a packet: “If the 'D' flag is set to 1, then the destination address of the IPv6 packet MUST be the DODAGID. If the
'D' flag is cleared, then the source address of the IPv6 packet MUST be the DODAGID.”
6TiSCH extends RPL’s language of DODAGID to route (reservation) endpoint.
65. 65
128 global instances per network
Indexed by tuple (IPv6, InstanceID)
Running as Ships-in-the-night
1 instance = 1 VRF = 1 « L3 vlan »
Serving different Objective Functions
Using different metrics
Can be shared between RPL and PCE
RPL along a DODAG
PCE adding orthogonal shortcuts
Clusterhead
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
Clusterhead
Constrained instance
Default instance
Potential link
A
67. 67
RPL is an extensible proactive IPv6 distance vector protocol
Supports MP2P, P2MP and P2P between devices (leaves) and a root (border router)
P2P reactive extension
RPL specifically designed for “Lossy” networks
Agnostic to underlying link layer technologies (802.15.4, PLC, Low Power Wireless)
RFC 6206: The Trickle Algorithm
RFC 6550: RPL: IPv6 Routing Protocol for LLNs
RFC 6551: Routing Metrics Used for Path Calculation in LLNs
RFC 6552: Objective Function Zero for the Routing Protocol for LLNs
RFC 6553: RPL Option for Carrying RPL Information in Data-Plane Datagrams
RFC 6554: An IPv6 Routing Header for Source Routes with RPL
RFC 6719: MRHOF Objective Function with hysteresis
RPL is pronounced
“Ripple”
71. 71
1TX
1TX
1RX
1RX
Dest MAC set to
broadcast 0xFFFF
DSCP Deterministic
Dest MAC restored by
6top at final destination
Dest MAC not changed
DSCP Deterministic
2TX 2RX
A
B
X Y
U
V
72. 72
1TX
1TX
1RX
1RXAdditional retries
Using L3 bundle
Dest MAC set to Y
DSCP Deterministic
Transmission failure
Over track slots
Retries exhausted over
Track L2 bundle
2TX 2RX
A
B
X Y
U
V
If arrival in time
Dest MAC reset to
broadcast 0xFFFF
DSCP Deterministic
Placed back on track
Dest MAC set to
broadcast 0xFFFF
DSCP Deterministic
1TX 1RX
74. 74
ISA100.11a /
WIHART
15.4e TSCH 15.4e TSCH 15.4e TSCH15.4e TSCH
15.4 PHY 15.4 PHY 15.4 PHY15.4 PHY
CoAP
UDP
IPv6
6LoWPAN-HC
6top
CoAP
UDP
IPv6
6LoWPAN-HC
6top
15.4 PHY
15.4e TSCH
CoAP
UDP
IPv6
6LoWPAN-HC
6top
15.4 PHY
15.4e TSCH
ISA100.11a /
WIHART
UDP
IPv6
6LoWPAN-HC
6top
CoAP
Dest MAC set to
broadcast
0xFFFF
Dest MAC not
changed
Dest MAC restored
by 6top
75. 75
1TX
1TX
1RX
1RX
Dest MAC restored
by 6top
Dest MAC set to X
DSCP not Deterministic
2TX 2RX
P
B
X Y
U
V
A
Q
Packet to be routed via Y
Dest MAC set to Y
Placed of deterministic track
Packet extracted from track due
to dmac == Y and/or DSCP and
then routed to a next hop != V
No frame in slot
Associated to
deterministic
79. 79
Channeloffset
Upto16channel
slotOffset, 0 .. N
The matrix repeats itself over time. CDU is defined by 6TiSCH and represents the global characteristics of the
network, channel unused, duration of the timeslot and number of timeslots per iteration.
6TiSCH defines a new global concept that is called a Channel distribution/usage (CDU) matrix; a
Channel distribution/usage (CDU) matrix is a matrix of so-called “cells” with an height equal to the
number of available channels (indexed by ChannelOffsets), and a width in timeslots that is the period of
the network scheduling operation (indexed by slotOffsets).
Timeslot width, typically 10-15ms each in 802.15.4e
Cell (slotOffset,
channelOffset)
80. 80
A Slotframe is a MAC-level abstraction that is internal but common to all nodes and contains a series of
timeslots of equal length and priority. It is characterized by a slotframe_ID, and a slotframe_size. Multiple
slotframes can coexist in a node’s schedule, i.e., a node can have multiple activities scheduled in different
slotframes, based on the priority of its packets/traffic flows. The timeslots in the Slotframe are indexed by
the SlotOffset; the first timeslot is at SlotOffset 0.
Channeloffset
Upto16channel
slotOffset, 0 .. N
TimeSlot
Slotframe
CDU
matrix
Cell (slotOffset,
channelOffset)
Timeslot width, typically 10-15ms each in 802.15.4e
81. 81
A Chunk is a well-known list of cells, well-distributed in time and frequency, within the CDU matrix; a chunk
represents a portion of the CDU. The partition of the CDU in chunks is globally known by all the nodes in the
network to support the appropriation process, which is a negotiation between nodes within an interference
domain. A node that manages to appropriate a chunk gets to decide which transmissions will occur over the
cells in the chunk within its interference domain. Ultimately, a chunk represents some amount of bandwidth
and can be seen as the generalization of a transmission channel in the time/frequency domain.
Chunk 1
Chunk 2
...
Chunk 8
CDU matrix, 6 channels, 7 timeslots, 8 chunks, represented from ASN= 0
82. 82
The chunks are defined at the epochal time but the 802.15.4e operation is an iterative process that repeats
over and over. Typically, the effective channel for a given transmission is incremented by a constant that is
prime with the number of channels, modulo the number of channels at each iteration. It results that the
channel of a given transmission changes at each iteration and the matrix virtually rotates.
To illustrate that rotation, we represent above where the transmission would happen in the second
iteration, for a CDU matrix of 8 channels if we increment the effective channel by 3 at each iteration:
Chunk 1
Chunk 2
...
Chunk 10
Effective channel offsets for chunks 1 .. 10 at the reference epoch and after one iteration
83. 83
slotOffset, 0 .. N
High Priority
RCV XMIT RCVSlotframe 1
slotOffset, 0 .. M
Low Priority
RCV RCV RCV XMIT XMITSlotframe 2
Will receive
Will receive if nothing to xmit
Will xmit
Will receive
Will receive
Decision to transmit / rcv
made at the beginning of
time slot based on
existing frames in queues
and slotframe priorities
86. 86
Parent schedule
Child 1 schedule
Child 2 schedule
Child 3 schedule
Xmit mcast rcv rcv xmit rcv xmit
rcv rcv xmit
rcv xmit rcv
rcv xmit
Slotframe
Say a parent
appropriates the
pink chunk from
the CDU matrix
above. Now the
parent gets to
decide when the
pink cells are
used and by
which node.
A device maintains a schedule that dictates its
transmissions and receptions inside the slotframe.
The RPL parent
allocates timeslots
between itself and
its children. The
parent takes the
timeslots off a
chunk that it has
appropriated.
88. 88
6TiSCH finally defines the peer-wise concept of a bundle, that is needed for the communication between
adjacent nodes.
A Bundle is a group of equivalent scheduled cells, i.e. cells identified by different [slotOffset,
channelOffset], which are scheduled for a same purpose, with the same neighbor, with the same flags, and
the same slotframe.
The size of the bundle refers to the number of cells it contains. Given the length of the slotframe, the size
of the bundle translates directly into bandwidth, either logical, or physical. Ultimately a bundle represent a
half-duplex link between nodes, one transmitter and one or more receivers, with a bandwidth that amount
to the sum of the timeslots in the bundle. Bundles thus come in pairs, an incoming and an outgoing.
A bundle is globally identified by (source MAC, destination MAC, trackID)
timeslot
bundle
89. 89
We use a well-known constant as trackId for a L3 link, that I’ll refer as NULLT.
So an IP link between adjacent nodes A and B comprises 2 bundles, (macA, macB, NULLT) and (macB,
macA, NULLT).
timeslot
bundle
timeslot
bundle
outgoingIncoming
IP layer
AA
B
90. 90
Along a that has a segment …A->B->C… , there are 2 bundles in node B,
incoming = (macA, macB, trackId) and outgoing = (macB, macC, trackId).
timeslot
bundle
timeslot
bundle
outgoingIncoming
C
B
A
95. 95
Multicast Avoidance
Registration for DAD
Binding (location, owner, MAC) to IPv6 address
Registrar hierarchy for lookups and policy enforcement
Scalable Backbone Operation
L2 routing (IS-IS) + proxy-ND in the backboneRegistration + L3 Routing in
attached networks (RPL RFC 6550)
Optional MAC address proxying to avoid MAC@ floods
New ND methods between registrars and other devices (e.g. LISP)
IETF drafts
draft-thubert-6lowpan-backbone-router
draft-chakrabarti-nordmark-6man-efficient-nd
draft-thubert-6man-wind-sail
96. 96
6LR 6LBR 6BBR Router/ServerLP Node
Any
IPv6 Radio
Mesh Ethernet
NA (~O)
NS (ARO)
NS (ARO)
DAR(ARO), DAO
Router/Server
Router/Server
Ethernet
inside
Radio (1 Hop)
NS lookup
NS DAD
NS (ARO)
Create proxy state
Classical NDRPL, others…6LoWPAN ND Efficient ND
NA (ARO)
DAC(ARO)
NA (ARO)
ML Subnet
97. 97
A new Efficient ND, aka Wireless ND
Multicast Avoidance
Registration for DAD
Binding (location, owner, MAC) to IPv6 address
Registrar hierarchy for lookups and policy enforcement
Operation
L2 routing (IS-IS) + proxy-ND in the backboneRegistration + L3
Routing in attached networks (RPL)
Optional MAC address proxying to avoid MAC@ floods
New ND methods between registrars and other devices (e.g. LISP)
98. 98
Used to resolve conflicts
Need In ND: TID to detect movement ->eARO
Need In RPL: Object Unique ID if we use RPL for DAD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|P|N| IDS |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ OUID ( EUI-64 or equivalent ) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
99. 99
Routers within subnet have a connected route
installed over the subnet backbone.
PCE probably has a static address in which
case it also has a connected route
Connected
Route to
subnet
100. 100
Gateway to the outside participate to some IGP
with external network and attracts all extra-
subnet traffic via protocols over the backbone
Default
Route
In RIB
101. 101
Directly upon NS(ARO) or indirectly upon DAR
message, the backbone router performs DAD on
behalf of the wireless device.
DAR
NS
(ARO)
DADNS DAD
(ARO)
102. 102
NA(ARO) or DAC message carry succeful
completion if DAD times out.
NA(Override) is optional to clean up ND cache
stale states, e.g. if node moved.
DAC
NA
(ARO)
Optional
NA(O)
103. 103
The BR maintains a route to the WSN node for
the DAO Lifetime over instance VRF. VFR may
be mapped onto a VLAN on the backbone.
RPL
DAO
Host
Route
Optional
NA(O)
104. 104
The BR maintains a route to the WSN node for
the DAO Lifetime over instance VRF that is
continued with RPL over backbone.
RPL
DAO
RPL DAO
Host
Route
105. 105
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
NS DAD
(ARO)
NA (ARO)
NS
(ARO)
106. 106
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
DAR
NA
(ARO)
DAD
111. 111
Control loops
global optimization of routes for jitter an latency – thus computed by a PCE -,
flow (over) provisioning, duocast for 1 hop (1Hz and 4Hz, no routing) with static multipath hard slot allocation.
control loop plan B
self-healing -thus distributed- routing, RPL
supervisory flows
no goal: requires determinism up into the backbone
management
a separate topology – a RPL instance - that does not break.
OF?, root selection?
alerts
bursty, unexpected, on-demand slot allocation, prioritization
112. 112
Monitoring of lots of lesser importance
stuff like corrosion? low cost scalability – this distributed routing, soft slots?
Cranes spanning area (ship)
with linear and circular motion that are mobile within a range
no goal some will need deterministic for coordination between cranes
Mobile worker
additionally provision slots ready for mobile workers) does not need deterministic since human
Large plants
thousands of devices– thus a backbone, multiple BBRs for 1 LLN –
within a subnet – to avoid renumbering though not always the case, sometimes isolation is wanted
Non-production episodes
fast and autonomic behavior – again distributed routing
Coexistence with legacy devices
a common management above, coarse level makes sense (channels backlisting but no more…single admin is good)
114. 114
(road, street) traffic control
increase of bandwidth allocated as more traffic in the road
Smart urban parking
redundancy of routes an over-provision as RF degrades with
cars on top of the sensors
Green zones. Monitor moisture in gardens, trigger
watering.
Toll, micro-paiment
Gargabe detection / collection path optimization
Citylights monitoring
large scale meshes
115. 115
an entity operating an "umbrella" network on
which different types of traffic flow, possibly
coming from customers of this entity.
When a new customer asks to be granted
access to the network, the network operator
can predict with pretty good granularity the
impact this new traffic on the remaining
bandwidth of the network, and on the power
consumption of individual motes, which
allows the operator to grant/deny, and
probably charge differently
116. 116
Resource management
Heating, Cooling and Lighting
Air quality, water leaks etc…
Food / Drink vending machines
Room occupancy
Security and Safety
(e.g. locate people in case of fire)
Exit signs monitoring
TSCH for improved availability
redundancy as RF degrades when
there are changes on the environment,
doors, moving metallic apparel, etc…
117. 117
Less wire / copper
Lower cost of goods
Easier assembly => lower manufacturing cost
Lower weight => lower gas consumption
Less maintenance / repair
Easier addition of second mount devices
Connected vehicule
Remote maintenance
Fleet managements
118. 118
asset tracking operations on the move (again mobility, and dynamics).
monitoring e.g. temperature of freezers, intrusion sensors, …
119. 119
Domotics & Home Automation/ Monitoring & Security
Energy and water use:
energy and water supply consumption monitoring to obtain advice on how to save cost and resources.
Intrusion Detection Systems:
Detection of window and door openings and violations to prevent intruders
Brute force & scalability to defeat tempering
121. 121
Trillion devices in the Internet
The core technologies will not change
Leakless Autonomic Fringe
Leakless Route Projection
Million devices in a Subnet
New models for the subnet protocols
IPv6 ND, ARP, Service Discovery …
Fiber + Copper + Radio Backbone
802.11 + 802.15.4 + … Fringe
Unhindered Mobility
Location / ID Separation
10’s
of K
124. 124
10s of Ks devices with multihop LLN access
No broadcast in the LLNs
No renumbering (quasi permanent IPv6 address)
Continuous reachability as a LLN device moves in Subnet
Radio conditions change cause network reorganisation
Already use cases such as handheld, cranes, small vehicles
Backward Compatibility with classical IPv4 and v6 devices
Support of discovery protocols throughout the subnet
125. 125
Cost Optimized in the backbone
Any to any traffic
Multipath and load balancing a bonus
Power Optimized in the LLNs
Most traffic flows to or from the LLN Backbone Router
Control traffic must be limited vs. Data traffic
Broadcast or scalable multicast in the backbone
Multicast or Controlled dissemination in the LLN
126. 126
LLNs Time synchronization via the backbone
to keep all LLNs in sync and
allow movement from one LLN to the next
Slow deterministic LLNs (process control)
No need for Deterministic backbone
Until scale and congestion loss becomes an issue
Upcoming faster deterministic wireless (factory automation)
deterministic loops across networks and server OS
127. 127
End-to-End time-synchronization
Synchronization via the backbone a plus
Standard time exchange, adapted precision.
Sync and schedule with the Deterministic backbone
MTU size a complex issue across networks
Ideally harmonize MTUs across multilink subnet or
at least detect discrepancies
Link Local lookups should be emulated
Proxy operation (per protocol)
Genralized hash based multicast