[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
CCAMP WG                                                      J. Ahlberg
Internet-Draft                                               Ericsson AB
Intended status: Informational                             LM. Contreras
Expires: January 9, 2017                                             TID
                                                               A. Ye Min
                                                                  Huawei
                                                             M. Vaupotic
                                                          Aviat Networks
                                                             J. Tantsura
                                                              Individual
                                                               K. Kawada
                                                         NEC Corporation
                                                                   X. Li
                                                 NEC Laboratories Europe
                                                             I. Akiyoshi
                                                                     NEC
                                                            July 8, 2016


A framework for Management and Control of microwave and millimeter wave
                interface parameters - problem statement
                 draft-mwdt-ccamp-problem-statement-00

Abstract

   To ensure an efficient data transport, meeting the requirements
   requested by today's transport services, the unification of control
   and management of microwave and millimeter wave radio link interfaces
   is a precondition for seamless multilayer networking and automated
   network wide provisioning and operation.

   This document describes the required characteristics and use cases
   for control and management of radio link interface parameters using a
   YANG Data Model.  It focuses on the benefits of a standardized
   management model that is aligned with how other packet technology
   interfaces in a microwave/millimeter wave node are modeled, the need
   to support core parameters and at the same time allow for optional
   product/feature specific parameters supporting new, unique innovative
   features until they have become mature enough to be included in the
   standardized model.

   The purpose is to create a framework for identification of the
   necessary information elements and definition of a YANG Data Model
   for control and management of the radio link interfaces in a
   microwave/millimeter wave node.






Ahlberg, et al.          Expires January 9, 2017                [Page 1]


Internet-Draft              Problem Statement                  July 2016


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 January 9, 2017.

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions used in this document . . . . . . . . . . . . . .   5
   3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   5
   4.  Application . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Network Management Solutions  . . . . . . . . . . . . . .   7
     4.2.  Software Defined Networking . . . . . . . . . . . . . . .   7
       4.2.1.  SDN example of radio link configuration . . . . . . .   7
   5.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Configuration Management  . . . . . . . . . . . . . . . .   9
       5.1.1.  Understand the capabilities and limitations . . . . .  10
       5.1.2.  Initial Configuration . . . . . . . . . . . . . . . .  10
       5.1.3.  Radio link re-configuration and optimization  . . . .  10
     5.2.  Inventory . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.1.  Retrieve logical inventory and configuration from



Ahlberg, et al.          Expires January 9, 2017                [Page 2]


Internet-Draft              Problem Statement                  July 2016


               device  . . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.2.  Retrieve logical inventory and configuration from
               device  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Status and statistics . . . . . . . . . . . . . . . . . .  10
       5.3.1.  Actual status and performance of a radio link
               interface . . . . . . . . . . . . . . . . . . . . . .  11
     5.4.  Performance management  . . . . . . . . . . . . . . . . .  11
       5.4.1.  Configuration of historical measurements to be
               performed . . . . . . . . . . . . . . . . . . . . . .  11
       5.4.2.  Collection of historical performance data . . . . . .  11
     5.5.  Fault Management  . . . . . . . . . . . . . . . . . . . .  11
       5.5.1.  Configuration of alarm reporting  . . . . . . . . . .  11
       5.5.2.  Alarm management  . . . . . . . . . . . . . . . . . .  11
       5.5.3.  Troubleshooting and Root Cause Analysis . . . . . . .  11
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Network requirements vary between operators globally as well as
   within individual countries.  The overall goal is however the same -
   to deliver the best possible network performance and quality of
   experience in a cost-efficient way.

   Microwave/millimeter wave (hereafter referred to as microwave, but
   including the frequency bands represented by millimeter wave) are
   important technologies to fulfill this goal today, but also in the
   future when demands on capacity and packet features increases.
   Microwave is already today able to fully support the capacity needs
   of a backhaul in a radio access network and will evolve to support
   multiple gigabits in traditional frequency bands and beyond 10
   gigabit in the millimeter wave.  L2 packet features are normally an
   integrated part of microwave nodes and more advanced L2 and L3
   features will over time be introduced to support the evolution of the
   transport services to be provided by a backhaul/transport network.

   The main application for microwave is backhaul for mobile broadband.
   Those networks will continue to be modernized using a combination of
   microwave and fiber technologies.  The choice of technology is a
   question about fiber presence and cost of ownership, not about
   capacity limitations in microwave.  In 2020, more than 65% of all
   cell sites are expected to be connected with microwave solutions.




Ahlberg, et al.          Expires January 9, 2017                [Page 3]


Internet-Draft              Problem Statement                  July 2016


   Open and standardized interfaces are a pre-requisite for efficient
   management of equipment from multiple vendors.  This framework
   addresses management and control of the radio link interface(s) and
   the relationship to other packet interfaces, typically to Ethernet
   interfaces, in a microwave node.  A radio link provides the transport
   over the air, using one or several carriers in aggregated or
   protected configurations.  Managing and controlling a transport
   service over a microwave node involves both radio link and packet
   functionality.

   Already today there are numerous IETF data models, RFCs and drafts,
   with technology specific extensions that cover a large part of the
   packet domain.  Examples are IP Management [RFC7277], Routing
   Management [I-D.ietf-netmod-routing-cfg] and Provider Bridge [PB-
   YANG].  They are based on RFC 7223 [RFC7223], which is the IETF YANG
   model for Interface Management, and is an evolution of the SNMP IF-
   MIB [RFC 2863].

   Since microwave nodes will contain more and more packet functionality
   and the interfaces for those technologies are expected to be managed
   using those models, there are advantages if radio link interfaces can
   be modeled and be managed using the same structure and the same
   approach, specifically for use cases in which a microwave node are
   managed as one common entity including both the radio link and the
   packet functionality, e.g. at installation, initial setup, trouble
   shooting, upgrade and maintenance.  All interfaces in a node,
   irrespective of technology, would then be accessed from the same core
   model, i.e. RFC 7223, and could be extended with technology specific
   parameters in models augmenting that core model.  The relationship/
   connectivity between interfaces would be given by the equipment
   configuration and slot positions or be configured via management
   systems or controllers.



















Ahlberg, et al.          Expires January 9, 2017                [Page 4]


Internet-Draft              Problem Statement                  July 2016


   +------------------------------------------------------------------+
   | Interface [RFC7223]                                              |
   |                +------------------+                              |
   |                |Ethernet Port     |                              |
   |                +------------------+                              |
   |                      \                                           |
   |                    +-----------------------+                     |
   |                    |Radio link terminal    |                     |
   |                    +-----------------------+                     |
   |                               \                                  |
   |                            +------------------------+            |
   |                            |Carrier termination     |            |
   |                            +------------------------+            |
   +------------------------------------------------------------------+

            Figure 1: Relationship between interfaces in a node

   There will always be certain implementations that differ among
   products and it is therefore practically impossible to achieve
   industry consensus on every design detail.  It is therefore important
   to focus on the parameters that are required to support the use cases
   applicable for centralized, unified, multi-vendor management and to
   allow other parameters to be optional or to be covered by extensions
   to the standardized model.  Furthermore, a standard that allows for a
   certain degree of freedom encourages innovation and competition which
   is something that benefits the entire industry.  It is therefore
   important that a radio link management model covers all relevant
   functions but also leaves room for product/feature-specific
   parameters.

   For microwave radio link functionality work has been initiated (ONF:
   Microwave Modeling [ONF-model], IETF: Radio Link Model [I-D.ahlberg-
   ccamp-microwave-radio-link]).  This effort is expected to take these
   initiatives into consideration and complement them on the gaps
   identified with the ambition to reach consensus within the industry
   around one common approach.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

3.  Terminology and Definitions

   Software Defined Networking (SDN) is an emerging architecture that
   decouples the network control and forwarding functions enabling the
   network control to become directly programmable and the underlying



Ahlberg, et al.          Expires January 9, 2017                [Page 5]


Internet-Draft              Problem Statement                  July 2016


   infrastructure to be abstracted for applications and network
   services.  This results in an extremely dynamic, manageable, cost-
   effective, and adaptable architecture that gives administrators
   unprecedented programmability, automation, and control.  The SDN
   concept is widely applied for network management, the adoption of SDN
   framework to manage and control the microwave and millimeter wave
   interface is one of the key applications of this work.

   Microwave is a band of spectrum with wavelengths ranging from 1 meter
   to 1 millimeter and with frequencies ranging between 300 MHz and 300
   GHz.  Microwave radio technology is widely used for point-to-point
   telecommunications because of their small wavelength that allows
   conveniently-sized antennas to direct them in narrow beams, and their
   comparatively higher frequencies that allows broad bandwidth and high
   data transmission rates.

   Millimeter wave is also known as extremely high frequency (EHF) or
   very high frequency (VHF) by the International Telecommunications
   Union (ITU), which can be used for high-speed wireless broadband
   communications.  Millimeter wave is an undeveloped band of spectrum
   that can be used for a broad range of services on mobile and wireless
   networks including high-speed, point-to-point wireless local area
   networks (WLANs) and broadband access.  This band has short
   wavelengths that range from 10 millimeters to 1 millimeter, namely
   millimeter band or millimeter wave.  The 71 - 76 GHz, 81 - 86 GHz and
   92-95 GHz bands are used for point-to-point high-bandwidth
   communication links, which allows for higher data rates up to 10
   Gbit/s but requires a license.  Unlicensed short-range data links can
   be used on 60 GHz millimeter wave.  For instance, the upcoming IEEE
   Wi-Fi standard 802.11ad will run on the 60 GHz spectrum with data
   transfer rates of up to 7 Gbit/s.

   Carrier Termination is an interface for the capacity provided over
   the air by a single carrier.  It is typically defined by its
   transmitting and receiving frequencies.

   Radio Link Terminal is an interface providing packet capacity and/or
   TDM capacity to the associated Ethernet and/or TDM interfaces in a
   node and used for the capacity required for setting up a transport
   service over a microwave/millimeter wave link.

4.  Application

   This framework addresses the definition of an open and standardized
   interface for the radio link functionality in a microwave/millimeter
   wave node.  The application of such an interface used for management
   and control of nodes and networks typically vary from one operator to




Ahlberg, et al.          Expires January 9, 2017                [Page 6]


Internet-Draft              Problem Statement                  July 2016


   another, in terms of the systems used, what they are called and how
   they interact.

4.1.  Network Management Solutions

   The classic network management solutions, with vendor specific domain
   management combined with cross domain functionality for service
   management and analytics, still dominates the market.

   These solutions are expected to evolve and benefit from an increased
   focus on standardization by simplifying multi-vendor management,
   remove the need for vendor/domain specific management, and enabling
   use of open source systems.

4.2.  Software Defined Networking

   SDN is another application emerging on the market.  The main drivers
   for SDN introduction from an operator perspective is simplification
   and automation of network provisioning as well as E2E network
   services.  The vision is to have a global view of the network
   conditions spanning across different vendors' equipment and multiple
   technologies.  A variety of different SDN architectures and functions
   are being discussed and proposed within the industry, but they all
   have in common a very clear relationship to network management.  In
   some proposals the SDN controller completely replaces the role of a
   network management system while in some cases the SDN controller is
   seen as an entity managed by the NMS.  In any case the SDN functions
   shall be seen as part of an overall NMS strategy, no matter how the
   functionality is partitioned across units and no matter what
   terminology is used.

   If nodes from different vendors shall be managed by the same SDN
   functions, without the extra effort of introducing mediation layers,
   all nodes must align their interfaces.  Hence, open and standardized
   node interfaces are closely associated with the introduction of SDN.

4.2.1.  SDN example of radio link configuration

   Radio link terminals comprising a group of carriers are widely used
   in microwave technology.  There are several kinds of groups:
   aggregation/bonding, 1+1 protection/redundancy, etc.  To avoid
   configuration on each carrier termination, a logical control provides
   flexible management without configuring parameters on each carrier
   termination directly.  An operator using SDN manages radio links by
   selecting an allowed operation mode.  Alternatively, an operator can
   prefer the complete configuration of all the parameters of interest.
   Such case is not described in the document for simplicity).  The
   operation mode is a set of logical metrics or parameters describing a



Ahlberg, et al.          Expires January 9, 2017                [Page 7]


Internet-Draft              Problem Statement                  July 2016


   complete radio link configuration, such as capacity, availability,
   priority and power consumption.

   +------+       +-----+                 +-----+       +-------+
   |      |-------| CT1 |   ~~~~~~~~~~~   | CT1 |-------|       |
   |      |       +-----+                 +-----+       |       |
   | RLT1 |                                             | RLT2  |
   |      |       +-----+                 +-----+       |       |
   |      |-------| CT2 |   ~~~~~~~~~~~   | CT2 |-------|       |
   +------+       +-----+                 +-----+       +-------+


                       Figure 2: Radio link example

   Example of an operation mode table is shown Table 1.  One mode (ID =
   1) provides high capacity but requires high power consumption;
   another mode (ID = 2) provides low power consumption but low
   capacity.  SDN controller selects one of the operation modes
   dynamically, according to the actual capacity need.

   +------+--------------+-----------+--------------+----------+-------+
   | ID   | Description  | Capacity  | Availability | Priority | Power |
   +------+--------------+-----------+--------------+----------+-------+
   | 1    | High capacity|    400    |    99.9%     |   Low    | High  |
   +------+--------------+-----------+--------------+----------+-------+
   | 2    | High avail-  |    100    |   99.999%    |   High   | Low   |
   |      | ability      |           |              |          |       |
   +------+--------------+-----------+--------------+----------+-------+

               Figure 3: Example of an operation mode table

   The procedure of logical control is as following:

   1/ SDN controller gets the supported operation modes by reporting
   from the node NE or by other means, e.g., NMS.

   2/ According to its operation policy, SDN controller selects one
   operation mode from the table and translates that into the required
   configuration of the individual parameters for the radio link
   terminals and the associated carrier terminations.

   The operation mode could be selected based on power consumption.

   Nowadays, more and more operators have strong requirement to decrease
   the node power consumption.  The SDN controller can monitor the real
   time traffic distribution, and generated corresponding policy: to set
   the operation mode to high capacity on the radio links with heavy




Ahlberg, et al.          Expires January 9, 2017                [Page 8]


Internet-Draft              Problem Statement                  July 2016


   traffic load; to set the operation mode to low power consumption on
   the radio links with light traffic load

   Radio link aggregation/bonding is widely used in microwave: multiple
   carriers are used to carry the traffic in cases where the needed
   capacity is beyond the capability of single carriers.  During night
   time, the actual traffic load may be 1/3 of the peak day time.  The
   operation mode of low power consumption could be set to turn off some
   of the radios within the group to save power consumption.

   The operation mode could also be configured based on traffic
   priority.

   For high priority traffic, it is necessary to assure high
   availability.  On the other hand, low priority traffic is often high
   volume and requires high capacity.  The SDN controller can generate
   corresponding policy based on the priority of traffic: to set the
   operation mode to high availability on the radio links with high
   priority traffic; to set the operation mode to high capacity on the
   radio links with low priority traffic.

   Radio protection/redundancy like a 1+1 Hot Standby is used to
   increase overall availability of links between nodes while radio link
   aggregation is used to achieve higher capacity.  If traffic is
   predominately TDM traffic, high availability is required on radio
   links.  In this case, SDN controller set operation mode as high
   availability.  On the other hand, if traffic is packet traffic, e.g.,
   LTE traffic, capacity is more of a concern.  In this case, SDN
   controller set the operation mode as high capacity.

5.  Use cases

   The use cases described should be the basis for identification and
   definition of the parameters to be supported by a YANG Data model for
   management of radio links, applicable for centralized, unified,
   multi-vendor management.

   Use cases addressing installation, on-site trouble shooting, fault
   resolution and other activities not performed from a centralized
   system and which in most cases are product specific are outside the
   scope of this framework.

5.1.  Configuration Management

   Configuration of a radio link terminal, the constituent carrier
   terminations and when applicable the relationship to packet/Ethernet
   interfaces.




Ahlberg, et al.          Expires January 9, 2017                [Page 9]


Internet-Draft              Problem Statement                  July 2016


5.1.1.  Understand the capabilities and limitations

   Exchange of information between a manager and a device about the
   capabilities supported and specific limitations in the parameter
   values and enumerations that can be used.

   Support for the XPIC feature or not and the maximum modulation
   supported are two examples on information that could be exchanged.

5.1.2.  Initial Configuration

   Initial configuration of a radio link terminal, enough to establish
   L1 connectivity over the hop to an associated radio link terminal on
   a device at far end.  It MAY also include configuration of the
   relationship to a packet/Ethernet interface, unless that is given by
   the equipment configuration.

   Frequency, modulation, coding and output power are examples of
   parameters typically configured for a carrier termination and type of
   aggregation/bonding or protection configurations expected for a radio
   link terminal.

5.1.3.  Radio link re-configuration and optimization

   Re-configuration, update or optimization of an existing radio link
   terminal.  Output power and modulation for a carrier termination and
   protection schemas and activation/de-activation of carriers in a
   radio link terminal are examples on parameters that can be re-
   configured and used for optimization of the performance of a network.

5.2.  Inventory

5.2.1.  Retrieve logical inventory and configuration from device

   Request from manager and response by device with information about
   radio interfaces, their constitution and configuration.

5.2.2.  Retrieve logical inventory and configuration from device

   Request from manager about physical and/or equipment inventory
   associated with the radio link terminals and carrier terminations

5.3.  Status and statistics








Ahlberg, et al.          Expires January 9, 2017               [Page 10]


Internet-Draft              Problem Statement                  July 2016


5.3.1.  Actual status and performance of a radio link interface

   Manager requests and device responds with information about actual
   status and statistics of configured radio link interfaces and their
   constituent parts.

5.4.  Performance management

5.4.1.  Configuration of historical measurements to be performed

   Configuration of historical measurements to be performed on a radio
   link interface and/or its constituent parts is a subset of the
   configuration use case to be supported.  See 5.1 above.

5.4.2.  Collection of historical performance data

   Collection of historical performance data in bulk by the manager is a
   general use case for a device and not specific to a radio link
   interface.

   Collection of an individual counter for a specific interval is in
   same cases required as a complement to the retrieval in bulk as
   described above.

5.5.  Fault Management

5.5.1.  Configuration of alarm reporting

   Configuration of alarm reporting associated specifically with radio
   interfaces, e.g. configuration of alarm severity, is a subset of the
   configuration use case to be supported.  See 5.1 above.

5.5.2.  Alarm management

   Alarm synchronization, visualization and handling, and notifications
   and events are generic use cases for a device and not specific to a
   radio link interface an should be supported accordingly.

5.5.3.  Troubleshooting and Root Cause Analysis

   Information and actions required by a manager/operator to investigate
   and understand the underlying issue to a problem in the performance
   and/or functionality of a radio link terminal and the associated
   carrier terminations.







Ahlberg, et al.          Expires January 9, 2017               [Page 11]


Internet-Draft              Problem Statement                  July 2016


6.  Requirements

   This is a placeholder for a separate chapter about requirements.

7.  Security Considerations

   TBD.

8.  IANA Considerations

   N/A.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
              November 1997, <http://www.rfc-editor.org/info/rfc2234>.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
              <http://www.rfc-editor.org/info/rfc2863>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

9.2.  Informative References

   [I-D.ahlberg-ccamp-microwave-radio-link]
              Ahlberg, J., Carlson, J., Lund, H., Olausson, T., Ye, M.,
              and M. Vaupotic, "Microwave Radio Link YANG Data Models",
              draft-ahlberg-ccamp-microwave-radio-link-01 (work in
              progress), May 2016.

   [I-D.ietf-netmod-routing-cfg]
              Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", draft-ietf-netmod-routing-cfg-22 (work in
              progress), July 2016.






Ahlberg, et al.          Expires January 9, 2017               [Page 12]


Internet-Draft              Problem Statement                  July 2016


   [ONF-model]
              "Microwave Modeling - ONF Wireless Transport Group", May
              2016.

   [PB-YANG]  "IEEE 802.1X and 802.1Q YANG models, Marc,H.", October
              2015.

   [RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
              <http://www.rfc-editor.org/info/rfc7227>.

Authors' Addresses

   Jonas Ahlberg
   Ericsson AB
   Lindholmspiren 11
   Goeteborg  417 56
   Sweden

   Email: jonas.ahlberg@ericsson.com


   Luis M. Contreras
   Telefonica I+D
   Ronda de la Comunicacion, S/N
   Madrid  28050
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com


   Ye Min (Amy)
   Huawei Technologies CO., Ltd
   No.1899, Xiyuan Avenue
   Chengdu  611731
   P.R.China

   Email: amy.yemin@huawei.com


   Marko Vaupotic
   Aviat Networks
   Motnica 9
   Trzin-Ljubljana  1236
   Slovenia

   Email: Marko.Vaupotic@aviatnet.com



Ahlberg, et al.          Expires January 9, 2017               [Page 13]


Internet-Draft              Problem Statement                  July 2016


   Jeff Tantsura
   Individual

   Email: jefftant.ietf@gmail.com


   Koji Kawada
   NEC Corporation
   1753, Shimonumabe Nakahara-ku
   Kawasaki, Kanagawa   211-8666
   Japan

   Email: k-kawada@ah.jp.nec.com


   Xi Li
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Email: Xi.Li@neclab.eu


   Ippei Akiyoshi
   NEC
   1753, Shimonumabe Nakahara-ku
   Kawasaki, Kanagawa  211-8666
   Japan

   Email: i-akiyoshi@ah.jp.nec.com




















Ahlberg, et al.          Expires January 9, 2017               [Page 14]