Internet-Draft N. Kong
Intended status: Experimental CNNIC
Expires: November 10, 2016 May 9, 2016

Data Aggregation Unit for LP-WAN


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

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

2. Problem Statemate

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

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

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:

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  

                           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

[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013.
[RFC7228] Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014.
[RFC7661] Fairhurst, G., Sathiaseelan, A. and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015.
[RFC7796] Jiang, Y., Yong, L. and M. Paul, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)", RFC 7796, DOI 10.17487/RFC7796, March 2016.

6.2. Informative References

[PPSP-Charter] Y, Yan., "simulated-annealing algorithm", December 2009.

Authors' Addresses

Xiaowei Qin CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3689 EMail: qinxiaowei@cnnic.cn
Ning Kong CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3147 EMail: kongning@cnnic.cn