Internet DRAFT - draft-deng-lmap-collaboration
draft-deng-lmap-collaboration
LMAP Working Group L. Deng
INTERNET-DRAFT China Mobile
Intended Status: Informational R. Huang
Expires: April 20, 2016 Huawei
S. Duan
CATR
October 19, 2015
Use-cases for Collaborative LMAP
draft-deng-lmap-collaboration-06
Abstract
This document discusses the motivation and use-cases for
collaborative LMAP practices, where multiple autonomous measurement
systems collaborate together in performing large scale performance
measurements to help with QoE enhancement by ICPs, network
performance monitory to guide ISP/Regulator coordination between
autonomous network domains and/or regulatory policies and cross-
boundary troubleshooting for complaints from end consumers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
<Deng, et al.> Expires April 20, 2016 [Page 1]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Motivations for Collaborative LMAP . . . . . . . . . . . . . . . 5
4 Use-cases for Collaborative LMAP . . . . . . . . . . . . . . . . 7
4.1 Use-cases for Regulators . . . . . . . . . . . . . . . . . . 7
4.1.1 within a regulator's own region . . . . . . . . . . . . 7
4.1.2 peering performance between ISPs . . . . . . . . . . . . 7
4.2 Use-cases for the ISP . . . . . . . . . . . . . . . . . . . 8
4.2.1 measurements within a single domain . . . . . . . . . . 8
4.2.2 measurements for multi-domain ISP networks . . . . . . . 9
4.3 Use-cases for the ICP . . . . . . . . . . . . . . . . . . . 9
4.3.1 QoE-oriented performance enhancement . . . . . . . . . . 9
4.3.2 Trouble-shooting initiated by end consumers . . . . . . 10
5 Derived Requirements . . . . . . . . . . . . . . . . . . . . . . 10
6 Extension Discussions . . . . . . . . . . . . . . . . . . . . . 11
6.1 Adding Another Layer of Management/Aggregation . . . . . . . 11
6.1.1 Initiator-Controller exchange for task instruction . . . 12
6.1.2 Reporter-Collector exchange for data aggregation . . . . 12
6.1.3 Initiator-Reporter exchange for output instruction . . . 12
6.2 Extension over Existing Management/Aggregation Layer . . . . 12
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1 Normative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
<Deng, et al.> Expires April 20, 2016 [Page 2]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
1 Introduction
With the rapid development of Internet technology and the increasing
complexity of broadband network architecture, it is becoming
difficult to do large scale network measurements due to the lack of
the unified measurement system and cooperative protocols. Therefore,
the Large-Scale Measurement of Broadband Performance (LMAP) working
group is formed to standardize a large scale measurement system for
the performance measurements of all kinds of broadband access
methods.
There are 3 types of entities proposed in the LMAP architecture: [I-
D.ietf-lmap-framework]
o Measurement Agents (MAs), implemented in network to perform
measurement tasks;
o Controller, responsible for creating and assigning the measurement
tasks; and
o Collector, in charge of collecting and storing measurement
results.
LMAP's current focus is to specify the information model, the
associated data models, the control protocol for the secure
communication between Controller and MA, and the report protocol for
the secure communication between MA and Collector.
On the other hand, for a large network, collaboration between
multiple Controllers may also be needed for performing local
measurement tasks, either because there is a practical limit on the
number of MAs a single Controller can manage simultaneously for
scalability considerations, because that a local task may involve
multiple MAs that are speaking different languages (i.e. different
control/report protocols), or because different organizations want to
interconnect their measurement systems.
Current LMAP protocols are designed under the following assumptions.
o All the involved entities are under the control of a single
organization.
o An MA can only be controlled by a single controller at any given
time.
<Deng, et al.> Expires April 20, 2016 [Page 3]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
o There is no communication between Controllers, between Collectors,
or between a Controller and a Collector.
However, cross-organization collaborations are increasingly common.
For example, accurate troubleshooting for mobile services usually
involves two or more organizations, and end-to-end performance
measurement may be conducted across multiple ISPs. How to utilize
LMAP practice to address these scenarios is still unsolved.
This document discusses the motivation and use-cases for
collaborative LMAP practices, where multiple autonomous measurement
systems collaborate together to help with QoE enhancement by ICPs,
network performance monitoring to guide planning for network
infrastructure and cross-boundary troubleshooting for SLA complaints
from end consumers, as well as performing regulatory supervision by
national regulators.
2 Terminology
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 RFC 2119 [RFC2119].
The following acronyms are used extensively in this document.
o ICP, Internet Content Provider.
o QoE, Quality of Experience.
o QoS, Quality of Service.
o ISP, Internet Service Provider, or shortly Operator.
o SLA, Service Level Agreement.
o UE, User Equipment.
o MAN, Metro Area Network.
o WAN, Wide Area Network.
The following definitions are borrowed from LMAP framework [I-D.ietf-
lmap-framework], and used to describe the corresponding entities
within a participating LMAP system.
o Controller: A function that provides a Measurement Agent with its
Instruction.
<Deng, et al.> Expires April 20, 2016 [Page 4]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
o Collector: A function that receives a Report from a Measurement
Agent.
o Measurement Agent (MA): The function that receives Instruction
Messages from a Controller and operates the Instruction by executing
Measurement Tasks (using protocols outside the initial LMAP work
scope and perhaps in concert with one or more other Measurement
Agents or Measurement Peers) and (if part of the Instruction) by
reporting Measurement Results to a Collector or Collectors.
o Measurement Method: The process for assessing the value of a
Metric; the process of measuring some performance or reliability
parameter associated with the transfer of traffic.
o Measurement Task: The action performed by a particular Measurement
Agent that consists of the single assessment of a Metric through
operation of a Measurement Method role at a particular time, with all
of the role's Input Parameters set to specific values.
o Measurement Result: The output of a single Measurement Task (the
value obtained for the parameter of interest or Metric).
o Metric: The quantity related to the performance and reliability of
the network that we'd like to know the value of.
The following definitions are used in this document to describe
corresponding entities for a collaborative performance measurement
among multiple LMAP systems.
o Initiator, the instructor for collaborative Measurement Tasks,
potentially on behalf of a regulator, a third party ICPs or an end
consumer.
o Reporter, the reporting party that aggregates partial Measurements
Reports from collaborative LMAP task participants and produces the
ultimate report to the task Initiator.
o Region, a geographical area or administrative domain under the
regulation of a single regulator.
o Domain, a collection of network devices and their interconnections
under the operation of a single administrative entity.
3 Motivations for Collaborative LMAP
End-to-end performance measurement and trouble-shooting are important
<Deng, et al.> Expires April 20, 2016 [Page 5]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
for multiple parties, including: (1) Internet Service Providers, in
solving end user's QoE issues by better managing and optimizing their
networks, (2) Internet Content Providers, for enhance its service
logic and application design, (3) regulators in examining the status
of and guiding future regulation.
From ISP's perspective, the importance of supporting LMAP for its own
network construction and operation is without doubt. But taken into
account the potential impact of introducing third-party LMAP MAs into
key network entities, a sensible ISP would prefer to build its own
LMAP system based on MAs embedded into its local network devices.
It is hence expected that the majority of end-to-end performance
measurements will be conducted in a collaborative manner involving
multiple autonomous LMAP systems, for the following reasons:
On one hand, for the regulator, in order to stimulate network
development, it is necessary to have a clear picture of ISPs' peering
performance for interconnection points in addition to their own local
network construction. Considering the prohibitive cost of a unified
third-party deployment for LMAP MAs at various peering links among
ISPs for a large geographic area, it may be more practical to make
use of ISPs' autonomous LMAP systems for collaboration.
Let us take the example in China for instance. China's networks are
complex, with more than 31 provinces and 300 regions come to
hierarchical networks deployments. There are 3 ISP giants (CMCC,
CTCC, CUCC) in mainland China, managing nationwide hierarchical
networks, each is consisted of 3-4 national center points for
interconnecting on the top, more than 30 provincial backbone networks
in the middle, and more than 300 regions' local networks on the
bottom. In other words, the national regulator must know the network
status of the 3 networks in each region of a province, of a province,
and finally the whole country. It would be prohibitive for the
national regulator authority, MIIT to deploy its own dedicated probes
nationwide(900+).
Furthermore, regulators in different countries may want to
interconnect their measurement systems to perform cross-border
measurements.
On the other hand, for the ICP or user, it does not help much for
service optimization or trouble shooting if the end-to-end
performance measurement is conducted via a simple client-server model
while treating the network as a black box. In the meantime, for the
purpose of providing more value-added service to the ICPs as well as
subscribers, there is motive for an ISP to open its LMAP system to
<Deng, et al.> Expires April 20, 2016 [Page 6]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
some extent and collaborate with the ICP/user in understanding the
bottleneck and exploiting better network servicing for end-to-end
QoE.
In the following sections, more specific use-cases and derived
requirements of collaborative LMAP practices for end-to-end
performance measurement are presented.
4 Use-cases for Collaborative LMAP
As stated above, there are motivations from the regulator, ISP/ICP
and users to conduct collaborative measurements at the different
levels in order to know if the current network conditions meet the
expectations from the regulator policy, the ISP's resource provision
agreement or the ICP's service provision agreement. In particular,
the following usecases are identified.
4.1 Use-cases for Regulators
A regulator may want to monitor the current status and the future
deployment of network construction and operation of its region. In
order to promote network development, the regulator needs to monitor
the status of interconnection between different ISPs as well as the
overall network status.
4.1.1 within a regulator's own region
Understanding the current situation of its own region is necessary
for a regulator to form guiding policies for stimulating further
growth in high-speed networks. In order to get a clear picture of a
large geographic area, the regulator may choose to not deploy a
dedicated LMAP system on its own, while it's necessary to deploy a
large number of MAs. The regulator may achieve this goal by means of
the ISP's LMAP and the third-party LMAPs.
In that case, multiple organizations would simultaneously deploy
their dedicated MAs for private LMAP systems within their network
boundary in the same region, and by combining them together a
measurement system can mainly cover the whole region's network
infrastructure. Through collaboration, MAs from multiple
organizations can perform comprehensive measurement for the whole
regional network in great depth, which can reflect the network's
operational state.
4.1.2 peering performance between ISPs
<Deng, et al.> Expires April 20, 2016 [Page 7]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
Low performance of peering links between different ISPs not only has
great impact on ICP services, but also on an access ISPs relying on
transit ISPs for Internet connectivity. For example, a mobile
operator lacking access to an Internet resource will have to pay
interconnections to other operators. The regulator can formulate
policies to promote information sharing between ISP networks and
investigate the user QoE problem by understanding the interconnection
performance. For the same reason, an ISP/ICP can also benefit from a
more clear understanding of the performance of the interconnection.
For example, the data flow for a service request from a mobile
terminal to an ICP first goes through the access ISP network and then
into the Internet via a transit ISP network. Similarly, before
entering the ICP's own private data-center, it may traverse another
transit ISP network. As shown in Figure 1, the measurement can be
implemented between ISP#1 MA and ISP#2 MA to understand the
interconnection quality.
UE<=>access ISP<=>transit ISP #1<=>Internet<=>transit ISP #2<=>ICP
Figure 1 Cross-Domain data flow path
In a single administrative domain, there are also scenarios for
collaborative measurement.
4.2 Use-cases for the ISP
4.2.1 measurements within a single domain
For one side, if the network scale is large enough, with many MAs,
scalability of the Controller may become an issue [I-D.ooki-lmap-
internet-measurement-system]. It would be a simple and scalable
manner to construct an effective LMAP system by dividing the huge
number of MAs into groups, and assign a Controller separately to
manager each subset of MAs. The size of the MA groups are dependent
on the number of MAs that a single Controller can manage at a time
during the real deployment.
On the other hand, even the network scale is small, if there are many
heterogeneous network devices as functioning MAs, the corresponding
LMAP protocols/interface may be diverse. For example, browser built-
in MAs can be conveniently implemented as HTTP clients, the CPE
devices usually support TR.069 as their management protocol and
network devices residing in the core network generally support and
<Deng, et al.> Expires April 20, 2016 [Page 8]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
runs SNMP protocol by default. In other words, different Controllers
speaking different LMAP protocols may be needed to respectively
manage different groups of MAs in the real deployment.
If a measurement task involves MAs that belong to different groups,
collaboration among corresponding Controllers is needed for
instructing the MAs with the task configuration and report
collection.
4.2.2 measurements for multi-domain ISP networks
For a large ISP, it is common practice to divide its global network
into several autonomous domains, each operated and managed by a
regional branch. It is therefore, very likely that separate LMAP
systems would be deployed into these autonomous domains, resulting in
a call for collaborative measurement scenarios even within the same
ISP's network.
Take the case in China for instance, there are multiple nationwide
ISP networks. Within these ISPs, relatively independent local
branches, separated by physical territorial scope such as the
province, operate their local network which has an autonomous domain
or multiple autonomous domains. Each Provincial branch can deploy its
own LMAP system to monitor its local network states.
4.3 Use-cases for the ICP
4.3.1 QoE-oriented performance enhancement
New applications or updated applications with newly-added
functions/features are being pushed to the end user every day, with
an increasing requirement for constant performance optimization based
on realistic network utilization resultant from application dynamics.
It is important to understand the practical performance and impact of
various network segments (e.g. access network, transit network and
Internet) on the end-to-end traffic path. For the design,
experimental and operational phases of a new feature/technology
introduction to an application is also of great importance. However,
it is expensive and non-economic for each ICP to build its own
dedicated LMAP system into various ISPs' networks.
At the same time, with the transition of ISPs' mindset from
subscriber-centered charging for network access to ICP-centered
<Deng, et al.> Expires April 20, 2016 [Page 9]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
charging, ISPs are motivated to offer assistance to ICPs' exploration
for better QoE through more efficient usage of network resources
provisioned under the guidance of real-time performance measurements
and optimization to accommodate application dynamics.
With ISPs' cooperation, various network segments are no longer hidden
behind the black box to end-to-end performance measurements. By
combining inputs from both its own end-based LMAP system with ISPs'
measurement data, it is possible for an ICP to identify the
bottleneck of service provision and develop corresponding enhancement
via better guided technology introduction to the application as well
as more targeted SLA negotiation with ISPs.
4.3.2 Trouble-shooting initiated by end consumers
With the growing influence of broadband access nowadays, more and
more traditional ICPs are extending to the market of home gateways,
as a result of the popularity of intelligent TVs and intelligent
STBs. The services of end users in their home network are probably
controlled by ICPs which may collaborate with the broadband access
service providers to guarantee users the promised QoE. When
malfunctions influencing user QoE occur in these types of services,
it is necessary to have a mechanism with which the diagnostic
measurement can be launched from the user side and identify the
faulty party.
Generally the home gateway(such as a home WLAN router) is the border
between the ISP network and the home network. The ISP network
includes the access network, MAN and WAN. The home network includes
home gateway, TV, STB, etc.
For a broadband access user who buys a third-party home gateway
device, the typical service access path is shown in Figure 2. The
home network between home gateway and UE is private and is not
controlled by any ISP. However, the user may want to measure the link
quality between the UE and the home gateway, the UE and the access
ISP, or the UE to the ICP, separately. Thus in this scenario, it is
difficult to deploy a single LMAP system which completely covers the
whole path for accurate end-to-end QoE measurements and assists fault
identification.
UE <=>home net<=>home GW<=>access ISP<=>transit ISP<=>Internet<=>ICP
Figure 2 Cross-Domain data traffic from home network to ICP
5 Derived Requirements
<Deng, et al.> Expires April 20, 2016 [Page 10]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
To make the requirements more clear, the following terms are defined:
LMAP domain: One LMAP domain is equal to one LMAP system specified
in [i.d-ietf-lmap-framework], where all the MAs are controlled by
a single controller.
This section presents derived requirements for LMAP protocols to
enable the above collaborative use-cases across multiple LMAP
domains. In particular:
* Current LMAP architecture MUST be extended to allow the MAs of a
LMAP domain to accept the legal external measurement tasks initiated
outside of the LMAP domain.
* When carrying out the outside measurement tasks, an LMAP domain
MUST be able to coordinate the relevant controllers, MAs, and
collectors of other LMAP domains for status updating or dynamical
control.
* Current LMAP architecture MUST be extended to have a mechanism to
gather and aggregate the measurement results from participating LMAP
domains.
* An LMAP domain MUST be able to authenticate and authorize the
measurement requests from outside of the LMAP domain.
* The extended mechanisms required above SHOULD NOT affect the
current LMAP mechanisms in [i.d-ietf-lmap-framework]. If changes have
to be made, they MUST be kept as small as possible.
6 Extension Discussions
In general, there are two basic approaches to extend the existing
LMAP framework for the above requirements: the first is to add
another layer of MA management and report collection for the
additional information exchange; the other is to extend the existing
controller/reporter's function and make one of the relevant
controller/reporter to take the responsibility of collaborative task
instruction/data aggregation.
6.1 Adding Another Layer of Management/Aggregation
In particular, two entities for the general coordination of cross-
organization interactions for collaborative LMAP tasks are
introduced: the Initiator and the Reporter, for cross-domain
measurement task assignment and result aggregation, respectively.
Three protocols for interactions for the newly-introduced entities
<Deng, et al.> Expires April 20, 2016 [Page 11]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
and existing LMAP entities are discussed too.
6.1.1 Initiator-Controller exchange for task instruction
The globally trusted and verifiable Initiator instructs each
participating LMAP Controller with corresponding Measurement Tasks to
be performed within the LMAP system, indicating the corresponding
Reporter, to whom the results of the Measurement Tasks are to be
submitted. A globally unified identifier may be required for each
collaborative Measurement Task.
6.1.2 Reporter-Collector exchange for data aggregation
A Collector from each participating LMAP system interacts with the
corresponding Reporter to report local measurement results.
6.1.3 Initiator-Reporter exchange for output instruction
The Initiator also notifies the Reporter with instructions on how to
create the final measurement report (e.g. data aggregation methods to
be used) as well as the identities of the participating Controllers.
6.2 Extension over Existing Management/Aggregation Layer
Another straightforward manner of extending the current LMAP
framework to support collaborative measurements from multiple domains
is to break the assumption that "any MA can only be controlled by a
single Controller", and allow the MA within an LMAP domain to carry
on the instructions from another Controller outside the domain,
and/or report the measurement results to another outside Collector.
Note that it is expected that such collaborative measurement
instructions are not meant to change the ownership of the
participating MA to its home LMAP domain.
As long as there is not conflict of interest or competition of local
resources at the MA, the outside measurement tasks (from an outside
Controller outside the local LMAP domain) as well as all the inside
measurement tasks (from the inside Controller in the local LMAP
domain) can be carried on simultaneously.
Otherwise, the MA may refer to static priority policies (e.g. the
inside tasks have the top priority, etc.) or report to its local
<Deng, et al.> Expires April 20, 2016 [Page 12]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
Controller/a third party for conflict resolution and task adaptation.
7 Security Considerations
The security threats elaborated in [I-D.ietf-lmap-use-cases] also
apply to collaborative LMAP scenarios.
It is assumed that the security issues within a participating LMAP
system can be addressed by its local security mechanisms, as
specified in [I-D.ietf-lmap-framework], and out of scope of this
document.
Each participating LMAP system may have its own consideration and
policy regarding its local network and/or subscriber private
information. In performing collaborative task, it is still possible
for a Collector to enforce local protection schemes, e.g. filtering
algorithms, onto local measurement data before submission to the
Reporter, hence providing protection to sensitive information for
both the subscriber and the network operator.
It is important for a participating LMAP system to be able to
authenticate the Initiator/outside-controller and the
Reporter/outside-collector for a given collaborative Measurement
Task, provide differentiated service provision according to its local
policies (e.g. flexible authorization based on the Initiator's
identity, the type of Measurement Task, Measurement Method,
frequency, etc.), and protect itself from service abuse of malicious
Initiators or information leakage to malicious Reporters.
A task/data verification scheme is needed for the Reporter to exclude
un-authorized or non-intended Collectors from tampering the
measurement report or blocking the Reporter/outside-collector from
proper functioning with corrupted/forged/replayed local reports.
8 IANA Considerations
There is no IANA action in this document.
9 Acknowledgements
The authors would like to thank Charles Cook, Gregory Mirsky and
Frode Sorensen for their valuable comments and input to this
document.
<Deng, et al.> Expires April 20, 2016 [Page 13]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
10 References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-lmap-framework] Eardley, P., Morton, A., Bagnulo, M.,
Burbridge, T., Aitken, P., and A. Akhter, "A framework for
large-scale measurement platforms (LMAP)", draft-ietf-
lmap-framework-11 (work in progress), February 2015.
[I-D.ietf-lmap-information-model] Burbridge, T., Eardley, P.,
Bagnulo, M., and J. Schoenwaelder, "Information Model for
Large-Scale Measurement Platforms (LMAP)", draft-ietf-
lmap-information-model-03 (work in progress), January
2015.
[I-D.ooki-lmap-internet-measurement-system] Ooki M., Kamei, S.,
"Internet Measurement System", draft-ooki-lmap-internet-
measurement-system-01(work in progress), December 2014.
[I-D.ietf-lmap-use-cases] Linsner M., Eardley, P., Burbridge, T.,
Sorensen, F., "Large-Scale Broadband Measurement Use
Cases", draft-ietf-lmap-use-cases-06(work in progress),
Feburary, 2015
<Deng, et al.> Expires April 20, 2016 [Page 14]
INTERNET DRAFT <Use-cases for Collaborative LMAP> Oct 19, 2015
Authors' Addresses
Lingli Deng
China Mobile
Email: denglingli@chinamobile.com
Rachel Huang
Huawei
Email: rachel.huang@huawei.com
Shihui Duan
China Academy of Telecommunication Research of MIIT
Email: duanshihui@catr.cn
<Deng, et al.> Expires April 20, 2016 [Page 15]
