1 / 14

Issues and Requirements of IP over Low Power WPAN

Issues and Requirements of IP over Low Power WPAN. Brijesh Kumar Kumarb@research.panasonic.com. Content. IEEE 802.15.4 Basics Use Case Scenario Key IP over MAC Issues and Requirements Implementation specific requirements. IEEE 802.15.4.

anaya
Télécharger la présentation

Issues and Requirements of IP over Low Power WPAN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Issues and Requirements of IP over Low Power WPAN Brijesh Kumar Kumarb@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. Star Topology P2P Topology PAN Coordinator PAN Coordinator FFD RFD Network Topologies

  6. Use Case Scenarios Use case: Integration of Home Control Using Wireless PANs Home Computing Network 802.15.3 Home Entertainment Network 802.11 a/b/g O 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. Preamble (4) SoF (1) Frame length (1) Frame Control (2) Frame Seq (1) Address (4/20) Payload (n) FCS(2) Data Frame 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. Preamble (4) SoF (1) Frame length (1) Frame Control (2) Frame Seq (1) Address (4/20) Payload (n) FCS(2) Dest PAN ID Dest Address Src PAN ID Src Address Data Frame 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 don’t need entire IPv6 here.

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

  14. Lastly … • Questions? • Future Actions?

More Related