Module:3

Integrating Physical and Cyber Space

01
Machine-to-Machine (M2M)
technologies
Fleet management is an example “Smart metering” is an example
of such an application, where of such an application where
devices are, for example, trucks, the devices are smart meters
and the communication network and the communication network
is a mobile network. can be a mobile network or the
public Internet.
8
 IEEE 802.15.4
and Zigbee Overview
 802.15.4 General
Characteristics
• Data rates of 250 kb/s, 40 kb/s and 20 kb/s.
• Star or Peer-to-Peer operation.
• Support for low latency devices.
• Low power consumption.
Frequency Bands of Operation
o 16 channels in the 2.4GHz ISM* band
o 10 channels in the 915MHz ISM band
o 1 channel in the European 868MHz band.

* ISM: Industrial, Scientific, Medical

9/27/05
802.15.4 / ZigBee Architecture

Applications

ZigBee

IEEE 802.15.4 MAC

• Packet generation
IEEE 802.15.4 IEEE 802.15.4 • Packet reception
868/915 MHz 2400 MHz • Data transparency
PHY PHY • Power Management
 IEEE 802.15.4 PHY Overview
Packet Structure

PHY Packet Fields

• Preamble (32 bits) – synchronization
• Start of Packet Delimiter (8 bits)
• PHY Header (8 bits) – PSDU length
• PSDU (0 to 1016 bits) – Data field

Start of PHY PHY Service

Preamble Packet Header Data Unit (PSDU)
Delimiter

6 Octets 0-127 Octets

IEEE 802.15.4 MAC Overview
Typical Network Topologies
 IEEE 802.15.4 MAC Overview
Device Classes

● Full function device (FFD)

○ Any topology

○ Network coordinator capable

○ Talks to any other device

● Reduced function device (RFD)

○ Limited to star topology

○ Cannot become a network coordinator

○ Talks only to a network coordinator

6LowPAN : IPv6 over Low-Power
Wireless Personal Area Networks
● 6LoWPAN stands for IPv6 over Low-Power Wireless Personal Area
Networks.

● It is a networking protocol designed to enable the transmission of IPv6

packets over low-power wireless networks, particularly those based on the
IEEE 802.15.4 standard.

● This protocol is essential for the Internet of Things (IoT) as it allows small,
low-power devices to communicate directly with the Internet using
standard IP protocols.
● Adaptation Layer: 6LoWPAN provides an adaptation layer that allows IPv6
packets to be transmitted over the constrained environments of low-
power wireless networks.
● This includes mechanisms for fragmentation and reassembly of packets,
which is crucial given the small maximum transmission unit (MTU) of IEEE
802.15.4 networks
❖ Addressing: Each device in a 6LoWPAN network can
have its own unique IPv6 address, enabling direct
communication with other devices on the Internet
without the need for a gateway. This facilitates the
integration of low-power devices into the broader
Internet ecosystem
● Security: 6LoWPAN supports link layer security through
AES-128 encryption, ensuring that data transmitted over
the network is secure.
 CoAP
● CoAP, or Constrained Application Protocol, is a specialized web
transfer protocol designed for use in resource-constrained
environments, particularly within the Internet of Things (IoT). It is
defined in RFC 7252 and is optimized for devices with limited
processing power, memory, and energy resources, such as sensors
and actuators in smart devices
• Client-Server Model: CoAP model is essentially a
client/server model enabling the client to request for service
from server as needed and the server responds to client’s
request.
• Resource-Oriented: CoAP treats various objects in the
network as resources, each uniquely identified by a URI
(Uniform Resource Identifier). Clients can request information
about these resources, and servers provide responses
• Methods: CoAP supports several methods similar to HTTP:
• GET
• POST
• DELETE
• PUT
• Asynchronous Messaging: CoAP messages are asynchronous because it uses the User
Datagram Protocol (UDP). Unlike TCP-based protocols, CoAP does not require
acknowledgments for every message, which helps conserve energy in resource-
constrained devices.
• Energy Efficiency: CoAP is designed to minimize energy consumption while simplifying
communication between clients and devices. It achieves this by managing resources,
providing device descriptions, and supporting mechanisms to determine if a device is
powered on or off.
● Confirmable Messages (CON)
• Definition: Confirmable messages are designed to
ensure reliable communication. When a client sends a
CON message, it expects an acknowledgment (ACK)
from the server.
• Behavior: If the sender does not receive an ACK within
a specified timeout period, it will retransmit the CON
message. This process continues until the sender
receives an ACK or exhausts its retransmission
attempts.
● Non-confirmable Messages (NON)
• Definition: Non-confirmable messages do not
require an acknowledgment from the server.
They are sent without the expectation of a
response.
• Behavior: Since NON messages are not
acknowledged, they are considered unreliable.
However, they still include a unique message ID
to help detect duplicates.
• Use Case: NON messages are suitable for
scenarios where timely delivery is more
important than reliability, such as sending
periodic sensor readings or updates that do not
require confirmation.
● Acknowledgment Messages (ACK)
• Definition: ACK messages are sent in response to a
CON message to confirm receipt. They do not carry any
payload but include the same message ID as the CON
message they acknowledge.
• Behavior: An ACK message indicates that the server
has successfully received the CON message. If the
server is unable to process the request immediately, it
may send an ACK first and then follow up with a
separate CON message containing the actual response.
 Issues integrating the

02
heterogeneous physical systems
with existing cyberspace
● Interoperability Challenges
• Diverse Protocols and Standards: Physical systems often operate using different
communication protocols and standards. For instance, industrial control systems may
use protocols like Modbus or OPC, while consumer devices might rely on Wi-Fi or
Bluetooth. This diversity complicates the integration process, as systems must be
able to communicate effectively despite differing protocols.
• Data Formats: Different systems may use various data formats, making it difficult to
share and interpret information across platforms. Standardizing data formats is
essential for seamless integration but can be challenging due to legacy systems and
proprietary technologies.
● Scalability Issues
• Growing Number of Devices: As more devices are connected to
cyberspace, the volume of data generated increases exponentially.
Managing this data flow and ensuring that systems can scale to
accommodate new devices without performance degradation is a
significant challenge.
• Resource Constraints: Many physical systems, especially in IoT applications,
are resource-constrained in terms of processing power, memory, and
energy. Integrating these systems with more powerful cyberspace
infrastructures requires careful consideration of resource management and
optimization.
● Security and Privacy Concerns
• Vulnerabilities in Integration: Integrating physical systems with cyberspace
can introduce new vulnerabilities. For example, if a physical device is
compromised, it could serve as an entry point for cyberattacks on the
broader network. Ensuring robust security measures during integration is
critical to protect both physical and digital assets.
• Data Privacy: The integration often involves collecting and transmitting
sensitive data from physical systems. Ensuring that this data is protected
from unauthorized access and breaches is a significant concern, particularly
in sectors like healthcare and finance.
● Cultural and Organizational Barriers
• Resistance to Change: Organizations may face resistance from employees and stakeholders when
integrating new technologies with existing systems. This resistance can stem from a lack of
understanding of the benefits of integration or fear of job displacement.
• Skill Gaps: There may be a shortage of skilled professionals who understand both the physical
systems and the digital technologies involved in integration. Bridging this skill gap is essential for
successful implementation.
● Regulatory and Compliance Issues
• Evolving Regulations: The integration of physical systems with cyberspace often falls under
various regulatory frameworks, which can vary by region and industry. Navigating these
regulations and ensuring compliance can be complex and time-consuming.
• Standardization Efforts: There is a need for industry-wide standards to facilitate integration.
However, achieving consensus on standards can be difficult due to competing interests among
stakeholders.
[Link] communication stack in
node operating system for cps
● The Hardware Abstraction Layer (HAL) is essential
for Cyber-Physical Systems (CPS) due to the diversity
of hardware components, including various types of
processors (e.g., Power PC, MIPS, ARM, x86, Atmel).
The HAL serves to hide the complexities of
heterogeneous hardware, allowing the node
operating system to function uniformly across
different hardware platforms.
• The HAL is designed with two layers:
• Architecture-Independent Code: This upper layer provides transparent
services to the node operating system modules, ensuring that software can
interact with hardware without needing to know the specifics of the
underlying architecture.
• Architecture-Dependent Code: The lower layer is hardware-oriented and
contains various hardware drivers that directly interact with the physical
components.
• Scheduling Methods: Node operating systems typically utilize two main scheduling
methods:
• Event-Driven Scheduling: More suitable for CPS due to its predictability and
reliability, but it requires developers to manually manage application states,
which can be complex.
• Multithreaded Scheduling: While easier to implement and familiar to developers,
it poses challenges in terms of predictability, which is crucial for CPS applications.
 CPS Communication
• Cross-Domain Communication: A defining characteristic of Cyber-Physical
Systems (CPS) is their ability to communicate across various domains.
Unlike traditional systems that often rely on standardized TCP/IP protocol
stacks, CPS lacks a uniform communication framework. This results in a
diverse array of protocols being utilized, which span multiple layers of the
OSI Seven-Layer Reference Model and the TCP/IP model.
• Variety of Protocols: CPS employs numerous protocols at different levels,
including IEEE 802.15.3/4, ZigBee, WirelessHART, ISA100.11, IETF 6LoW-
PAN, and others. These protocols cater to specific communication needs
and vary even within different areas of the same CPS, necessitating support
for multiple protocols in the nodes.
 Design of the Communication Module
• Open Communication Module: This term refers to a communication framework that
is accessible and can be modified or extended by developers. An open module allows
for collaboration and integration with various technologies and protocols, making it
easier to adapt to different applications and environments within CPS.
• Reconfigurable: The ability to reconfigure means that the communication module can
be adjusted or customized to meet the specific needs of various CPS applications. This
flexibility is crucial because different CPS applications may require different
communication protocols depending on their operational context, such as industrial
automation, smart homes, or healthcare systems.