Download PPT Version

Issues and Requirements of IP
over Low Power WPAN
Brijesh Kumar
[email protected]
Content
•
•
•
•
IEEE 802.15.4 Basics
Use Case Scenario
Key IP over MAC Issues and Requirements
Implementation specific requirements
IEEE 802.15.4
•
A LR-WPAN is a simple, low-cost communication network :
– with limited power and relaxed throughput requirements. wireless connectivity in
applications
– Focus on ease of installation, reliable data transfer, short-range operation,
extremely low cost, and a reasonable battery life, while maintaining a simple and
flexible protocol.
•
Two different device types can participate in an LR-WPAN network:
– Full-function device (FFD)- The FFD can operate in three modes serving as a
personal area network (PAN) coordinator, a coordinator, or a device. An FFD can
talk to RFDs or other FFDs.
– Reduced-function device (RFD)- An RFD can talk only to an FFD. An RFD is
intended for applications that are extremely simple, such as a light switch or a
passive infrared sensor; they do not have the need to send large amounts of data
and may only associate with a single FFD at a time. Consequently, the RFD can be
implemented using minimal resources and memory capacity.
Key Features
Some of the characteristics of an LR-WPAN are
•
•
•
•
•
•
•
•
•
•
Over-the-air data rates of 250 kb/s, 40 kb/s, and 20 kb/s
Star or peer-to-peer operation
Allocated 16 bit short or 64 bit extended addresses
Allocation of guaranteed time slots (GTSs)
Carrier sense multiple access with collision avoidance (CSMA-CA) channel access
Fully acknowledged protocol for transfer reliability
Low power consumption
Energy detection (ED)
Link quality indication (LQI)
16 channels in the 2450 MHz band, 10 channels in the 915 MHz band, and 1
channel in the 868 MHz band
Network Topologies
Star Topology
P2P Topology
PAN Coordinator
FFD
RFD
PAN Coordinator
Use Case Scenarios
Use case: Integration of Home Control Using Wireless
PANs
Home
Computing
Network
802.15.3
802.11
a/b/g
Home
Home Server Entertainment 480 Mbps
Network
O
11-54 Mbps
Control
Device
Appliance 802.15.4
/Sensor
Control
Network
20- 250
Kbps
Typical Use Case Data Scenarios
Typical Traffic Types:
•
•
•
•
•
Periodic data (Auto-monitoring)
Application defined rate (e.g., sensors)
Intermittent data
Application/external stimulus defined rate (e.g., light switch)
Repetitive low latency data
Data Frame Format
1.
A MHR, which comprises frame control, sequence number, and address information.
2.
A MAC payload, of variable length, which contains information specific to the frame
type. Acknowledgment frames do not contain a payload.
3.
A MFR, which contains a FCS.
Address length and format varies depending upon the frame type.
Preamble
(4)
SoF (1)
Frame
length (1)
Frame
Control
(2)
Frame
Seq (1)
Data Frame
Address
(4/20)
Payload (n)
FCS(2)
Data Frame Format
The destination/src address field is either 16 bits or 64 bits in length, according to the value specified
in the destination addressing mode subfield of the frame control field, and specifies the address
of the intended recipient of the frame. A 16 bit value of 0 x ffff in this field shall represent the
broadcast short address, which shall be accepted as a valid short address by all devices
currently listening to the channel.
The source/ Dest PAN identifier field is 16 bits in length and specifies the unique PAN identifier of
the originator of the frame. This field shall be included in the MAC frame only if the source
addressing mode and intra-PAN subfields of the frame control field are nonzero and equal to
zero, respectively.
0/2
0/2/8
Dest PAN ID
Preamble
(4)
SoF (1)
Frame
length (1)
Frame
Control
(2)
Dest Address
Frame
Seq (1)
Data Frame
0/2
0/2/8
Src PAN ID
Address
(4/20)
Src Address
Payload (n)
FCS(2)
What do we want
• Assuming we need IP – do we need IPv6 alone or we need
IPv4 too?
• Technically, problems are similar though IPv6 has lot more
issues than defining a solution for IPv4.
Key Issues
•
Need Ability to inter-network with Other IP devices which leads to a number
of issues to deal with:
– IP address mapping to MAC frames (Short addresses and Long
Addresses)
– Link layer address resolution (ARP/ ND)
– Link local IP addresses/ Address Assignment Procedures
– Duplicate address detection
– MTU considerations
– DNS name resolution (?)
– IP QoS/ Priority support (?)
– Header Compression
– Multicast and Broadcast Support
– Energy Efficient Operation in ad-hoc routing environment
Some Requirements and Open Issues
1.
2.
Determine Topology Context for topology context for creating IPv6 over 15.4?
In the context of creating a light IPv6 over 15.4. Will every node need to be Internet ready?
3.
If the answer to #2 is YES - will every node be required to have internet HW interface? If the
answer to #2 is YES - then
a) the price for each node will go up comparatively HW- wise. It means that more uP complexity
and Ethernet interface support
b) the stack still has to be quite big, and the 40 byte header is too much of an overhead for the
128 byte packet capability of 15.4.
4.
IPv6 is a complex protocol addressing many problems earlier identified for IPv4:
- For our goal and objective, low cost or dollar figure is not necessary
- Technology Goals are clear that solution needs to be supported by 8 bit uP with no more than
32K byte flash for everything.
- Two aspects – Limits on Memory and Processing abilities to make solution practical.
5.
We need to make sure that this goal can be achieved? How do we benchmark / verify this?
6.
We will still need one node operating as gateway to the Internet. This node while being compatible
to fully IPv6 at the Internet level; also have to play a role as a coordinator / router to all the other
nodes who are only "light" IPv6. This node will be expensive comparatively with other nodes.
7.
We need to agree on IP (v6/v4 ) profile that can meet above target. We don’t need entire IPv6 here.
IPv6 Specific Issues
•
•
•
•
•
IPv6 Node Requirements draft-ietf-ipv6-node-requirements-11.txt defines some of
the mandatory functions
These requirements weren’t necessarily written with low power WPAN with low
footprint requirements.
An analysis is needed if current node requirements make sense for this kind of
environment.
A full implementation of IPv6 includes implementation of the following headers:
IPv6 Header, Hop-by-Hop Options Header, Routing Header, Fragment
Header, Destination Options, Authentication, Encapsulating Security Payload
We surely don’t need many of these headers.
Lastly …
• Questions?
• Future Actions?