Issues and Requirements of IP over Low Power WPAN

1
Issues and Requirements of IP over Low Power WPAN

• Brijesh Kumar
• Kumarb_at_research.panasonic.com

2
Content

• IEEE 802.15.4 Basics
• Use Case Scenario
• Key IP over MAC Issues and Requirements
• Implementation specific requirements

3
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.

4
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

5
Network Topologies
6
Use Case Scenarios
Use case Integration of Home Control Using
Wireless PANs
Home Computing Network
802.15.3
Home Entertainment Network
O
802.11 a/b/g
480 Mbps
Home Server
11-54 Mbps
Control Device
Appliance/Sensor Control Network
802.15.4
20- 250 Kbps
7
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

8
Data Frame Format

• A MHR, which comprises frame control, sequence
  number, and address information.
• A MAC payload, of variable length, which
  contains information specific to the frame type.
  Acknowledgment frames do not contain a payload.
• A MFR, which contains a FCS.
• Address length and format varies depending upon
  the frame type.

9
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
0/2
0/2/8
10
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.

11
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

12
Some Requirements and Open Issues

• 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?
  
• 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.
• 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.
• We need to make sure that this goal can be
  achieved? How do we benchmark / verify this?
• 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.
• We need to agree on IP (v6/v4 ) profile that can
  meet above target. We dont need entire IPv6
  here.

13
IPv6 Specific Issues

• IPv6 Node Requirements draft-ietf-ipv6-node-requir
  ements-11.txt defines some of the mandatory
  functions
• These requirements werent 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 dont need many of these headers.

14
Lastly

• Questions?
• Future Actions?