Data Aggregation Unit for LP-WAN
draft-qin-lpwan-dau-00

Abstract

Connecting LP-WANs(Low-Power Wide Area Networks) to the Internet is expected to provide significant benefits to these networks in terms of interoperability, application deployment, and management,among others. However, the specific characteristics of LP-WANs, such as very limited data unit size, and large-scale data sets make the network operation more complex: using one IP packet to send one LP-WAN data unit is a waste of bandwidth(because the packet header is much bigger than payload), and the large-scale LP-WAN data sets can also increase the Internet burden. This specification defines a Data Aggregation Unit(DAU) for LP-WANs to aggregate small-size date units into bigger data chains so they can be sent through the Internet more efficiently.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 10, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 1.2. Abbreviations
• 2. Problem Statemate
• 3. L-DAU Scheme
• 3.1. L-DAU Format
• 4. Security Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

The existing pilot deployments of LP-WANs have shown the huge potential and the industrial interest in their capabilities, such as in control and monitoring applications. Examples of LPWAN technologies include LoRa, SigFox, IEEE 802.15.4k LECIM, DASH-7, Weightless, etc. [I-D.minaburo-lp-wan-gap-analysis]. Connecting these LP-WANs to the Internet is expected to provide significant benefits to these networks in terms of interoperability, application deployment, and management, among others. For these reasons, more and more LP-WAN owners are connecting their own LP-WANs to the Internet.

It is generally desirable that a given Data Unit(DU) generated by any LP-WANs can be sent through the Internet efficiently and quickly. However, the intrinsic characteristics of LP-WANs, very limited DU size and large-scale DU sets make the data transmission through Internet more complex. In a nutshell, that may be a terrible waste of bandwidth if use one IP packet to send one LP-WAN Data Unit(LDU), because the packet header is much bigger than payload.And what's more, the LP-WAN usually consists of many nodes, so the large-scale data may increase the Internet burden. This is the motivation for aggregating these small-size LDUs into a bigger data chain to improve the percentage of the payload in IP packet to make the information retrieval and dissemination more efficient. For example,a ZigBee Cluster can aggregate several LDUs into a LDU chain and send them together as an atomic payload of the IP packet. By doing this, the ZigBee Cluster doesn't need to initiate the transmission for every LDU as well as improve the proportion of the payload in the IP packet to increase the transmission efficiency.

During transmission, the aggregator cannot do any processing on the LDUs and just encapsulates them into an aggregation chain. During reception, the de-aggregator just opens the data chain and separately forwards them to the applications.

This arrangement provides numerous benefits for LP-WAN applications(both transmitter and receiver): increased delivery efficiency, reduced transmission/receiving times, and improved quality of experience for LP-WAN Users. Considering that a vast number of LP-WAN devices are,as of today,battery-powered,the DAU is also helpful for saving battery consumption.

1.1. Terminology

This document uses the following terms:

Aggregator: Software entity which resides either in the system kernel or hardware aggregating one or more LDUs into an aggregation chain, the payload of the IP packet that is sent through the internet. The aggregator is usually placed into transmitter device with cache capacity.

De-aggregator: Software entity which resides either in the system kernel or hardware de-aggregating the LDU chain into seperate LDU, which comes from aggregator. De-aggregator is usually placed into receiving device with cache capacity.

Data Unit: Refers to data packets generated by LP-WANs in general, for example generated by LoRa, SigFox, IEEE 802.15.4k LECIM, etc.

1.2. Abbreviations

• DU:Data Unit
• LDU: LP-WAN Data Unit
• L-DAU: LP-WAN Data Aggregation Unit

2. Problem Statemate

LP-WAN technologies are a kind of constrained and challenged networks [RFC7228].

• very small frame payload as low as 12 bytes. Typical traffic patterns are composed of a large majority of frames with payload size around 15 bytes and a small minority of up to 100 byte frames.
• ultra dense networks with thousands to tens of thousands of nodes.

On the other side, the existing Internet technologies have their specific characteristics:

• IP header is usually more than 20 bytes[RFC6864],[RFC6973], and the Ethernet header is at least 14 bytes[RFC7796].
• TCP is a reliable and connection oriented transport mechanism[RFC7661].

Therefore, it is obviously unwise to just encapsulate one LDU into the IP packet. That's a waste of bandwidth and also increases Internet burdens. However, no standards or open specifications currently exist to solve above problems.

In the terminology of [RFC7228], these characteristics put LP-WANs into the "challenged network" category, and the intrinsic characteristics, current usages and architectures will allow the group to make and justify the design choices. However, there also some desired properties:

• preserve the end-to-end communication principle.
• maintain independence from L2 technology.
• use or adapt protocols defined by IETF to this new environment that could be less responsive.
• use existing addressing spaces and naming schemes defined by IETF.
• small message size, with potentially no L2 fragmentation.
• optimize the protocol stack in order to limit the number of duplicated functionalities; for instance acknowledgements should not be done at several layers.

So,the L-DAU is proposed in this document to make the information retrieval and dissemination of LP-WANs more efficient as well as fully conforms to the principles proposed in [RFC7228].

3. L-DAU Scheme

The L-DAU service architecture is shown in Figure 1. During transmission, a LDU is passed down from LPWAN application, and stored temporarily by the aggregator, then aggregated into a L-DUA. During reception, a received L-DAU is de-aggregated into seperate LDUs and forwarded to the LP-WAN application.

                            


         +--------------------+             +--------------------+ ^
       | |      LPWAN         | Frame Flow  |       LPWAN        | |
      S| | Application Lawer  |<----------->|    application     | |
      e| +--------------------+             +--------------------+ |g
      n| |       L-DAU        |             |       L-DAU        | |
      d| |    Aggregation     |             |     Aggregation    | |i
      i| +--------------------+             +--------------------+ |v      
      n| |      Network       |             |      Network       | |i
      g| |       Layer        |             |       Layer        | |e
       | +--------------------+             +--------------------+ |c
       | |        PHY         |             |         PHY        | |e
       | |       Layer        |             |        Layer       | |R
       V +--------------------+             +--------------------+ 
                     Figure 1 L-DAU service architecture

                       

3.1. L-DAU Format

A L-DAU consists of a sequence of one or more L-DAU subframes as shown in Figure 2.

                            
                                                                            
          +------------------+-----------------+------+------------------+                    
          | L-DAU subframe 1 | L-DAU subframe 2|  ... | L-DAU subframe n |
          +------------------+-----------------+------+------------------+                    
   Octets:     variable          variable                 variable


                           Figure 2 L-DAU format

                       

Each L-DAU subframe consists of a LDU delimiter followed by a LDU. Except when a L-DAU subframe is the last one in a L-DAU. The L-DAU length should be less than 65535 octets. The LDU delimiter is 2 octets in length and the structure of the LDU delimiter is defined in Figure 3.

                            
   Bits:     B0    B1    B2   B7      B8          B15                                                              
          +-----------+-----------+---------------------+---------------+                    
          |  Reserved | LDU length| Delimiter Signature |       LDU     | 
          +-----------+-----------+---------------------+---------------+                   
 
                              L-DAU Delimiter
 Octets:  <--------------------------------------------->     variable  
                                   2

                           Figure 3 L-DAU subframe format

                       

The fields of the L-DAU delimiter are defined in Table 1.

                            
               Table 1: L-DAU delimiter fields
     +-----------+--------+---------------------------------------------+
     |  Field    |  Size  |              Description                    |
     |           | (Bits) |                                             |
     +-----------+--------+---------------------------------------------+
     | Reserved  |   2    |                                             |
     +-----------+--------+---------------------------------------------+
     | LDU Length|   6    |  Length of the LDU in octets                |
     +-----------+--------+---------------------------------------------+
     |           |   8    |  Pattern that may be used to detect an L-DAU|
     | Delimiter |        |  delimiter when scanning for a delimiter.   |
     | Signature |        |  The unique pattern is set to the value     |
     |           |        |   0x7E.                                     |
     |           |        |                                             |
     +-----------+--------+---------------------------------------------+
                       

The purpose of the L-DAU delimiter is to locate the LDUs within the L-DAU.

4. Security Considerations

This document focuses on approach and the motivational for L-DUA, and does not analyze the associated threats. Those threats will be discussed in future.

5. Acknowledgments

The authors wish to thank Linlin Zhou for her invaluable comments.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses