<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.draft-ietf-lmap-framework-11 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lmap-framework-11.xml">
]> 
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!--rfc category="info" docname="draft-bovo-lmap-mobile-00" ipr="trust200902"-->
<rfc
   category="info"
   ipr="trust200902"
   docName="draft-bovo-lmap-mobile-01">

<!-- category values: std, bcp, info, exp, and historic -->
<!-- ***** FRONT MATTER ***** -->
	<front>
		<title>
			Mobile LMAP Use Cases 
		</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
		<author fullname="Antonio Bovo" initials="A." surname="Bovo">
			<organization>
				independent
			</organization>
			<address>
				<postal>
					<street>
					</street>
					<city>
					</city>
					<region>
					</region>
					<code>
					</code>
					<country>
						Italy 
					</country>
				</postal>
				<phone>
				</phone>
				<email>
					Antonio Bovo 
				</email>
			</address>
		</author>
<!-- uri and facsimile elements may also be added -->
		<author fullname="Roger Marks" initials="R.M." surname="Marks">
			<organization>
				EthAirNet Associates 
			</organization>
			<address>
				<postal>
					<street>
						4040 Montview Blvd. 
					</street>
<!-- Reorder these if your country does things differently -->
					<city>
						Denver 
					</city>
					<region>
						CO 
					</region>
					<code>
						80207 
					</code>
					<country>
						UAS 
					</country>
				</postal>
				<phone>
					+1-619-393-1913 
				</phone>
				<email>
					roger@ethair.net 
				</email>
			</address>
		</author>




		<date month="July" year="2015" />
<!-- Meta-data Declarations -->
		<area>
			Operations &amp; Management 
		</area>
		<workgroup>
			Large-Scale Measurement of Broadband Performance 
		</workgroup>
		<keyword>
			LMAP 
		</keyword>
		<keyword>
			protocol 
		</keyword>
		<keyword>
			criteria 
		</keyword>
<!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->
		<abstract>
			<t>
				This document discusses the use cases for broadband measurements applied to the mobile domain as an adjunct to such scenarios for the landline broadband domain. The specifics related to the mobile domain are discussed considering them as possible extensions of IETF LMAP measurements. 
			</t>
		</abstract>
	</front>
	<middle>
		<section title="Introduction">
			<t>
				Networks and services must accommodate service profiles with exponentially increasing mobile traffic. Such traffic has significantly changed the network architectures as well as the way the networks are controlled and measured. The same is true of services; service providers have to deal with specific problems related to traffic profiles coming from the mobile domain, with specific requirements different those of landline broadband access. 
			</t>
			<t>
				This draft describes a set of use cases for broadband measurements applied to the mobile domain. Some of these use cases apply to landline networks as well. The primary aim at this initial stage is to detail specific use cases that are important in the mobile domain and that are aimed to complement measurements originating from line-based networks. Mobile considerations as documented here may lead to an expanded scope for the LMAP Working Group. 
			</t>
			<t>
				This document is drawn from work done within the IEEE Project 802.16.3 on "Mobile Broadband Network Performance Measurements" 
				<xref target="P802.16.3">
				</xref>. That project considers a measurement framework for mobile broadband measurement scenarios applicable to multiple stakeholders. Such models support flexible measurements and provide the basis for a standardized framework facilitating measurement comparison and validation. 
			</t>
		</section>
		<section title="Terminology">
			<t>
				The following abbreviations are used in this document: 
			</t>
			<texttable title="Abbreviations">
				<ttcol align='left'>
					Abbreviation 
				</ttcol>
				<ttcol align='left'>
					Expansion 
				</ttcol>
				<c>
					KPI 
				</c>
				<c>
					Key Performance Indicator 
				</c>
				<c>
					NO 
				</c>
				<c>
					Network Operator 
				</c>
				<c>
					SIM 
				</c>
				<c>
					subscriber identification module 
				</c>
				<c>
					SLA 
				</c>
				<c>
					Service Level Agreement 
				</c>
				<c>
					SON 
				</c>
				<c>
					Self-Organizing Networks 
				</c>
				<c>
					UE 
				</c>
				<c>
					User Equipment 
				</c>
			</texttable>
		</section>
		<section anchor="Why" title="Rationale for mobile broadband measurements use cases">
			<t>Specifically mobile scenarios for broadband measurements are considered here for reasons including the following:
			  <list style="symbols" counter="my_count">
				<t>Mobility can be the primary cause of variations of service experience over time, with a huge impact on the user's perception</t>
				<t>Mobile networks in general are affected by varying radio conditions that impact services. Measuring radio conditions concurrently with correlated service indicators can provide a better characterization and explanation of user experience.</t>
				<t>Roaming scenarios and multiple operators are distinctive of the mobile domain.</t>
				<t>Link conditions typically vary faster in mobile domain than in landline networks due to radio aspects.</t>
			  </list>
			</t>
			<t>
				Considering specifics of the mobile domain allows completing the overall picture for broadband measurements, resulting in a more comprehensive standardization. In the absence of a standardized  mobile broadband measurements framework efforts by each stakeholder to compare network performance will continue to be complex as well as difficult to ascertain quantitatively or to compare fairly with other results. 
			</t>
		</section>

		<section title="Mobile Measurement Purposes">
			<t>
				Some measurement purposes/applications related to the mobile domain are itemized in Table 1. 
			</t>
			<texttable anchor="table_1" title="Measurement Purposes">
				<ttcol align='left'>
					Item # 
				</ttcol>
				<ttcol align='left'>
					Measurement Purposes / Applications
				</ttcol>
				<c>
					1 
				</c>
				<c>
					Assess overall data on Quality of Experience of set of networks available to consumers 
				</c>
				<c>
					2 
				</c>
				<c>
					Assess quality of Experience of a specific network 
				</c>
				<c>
					3 
				</c>
				<c>
					Identify limitations in deployment of a specific network 
				</c>
				<c>
					4 
				</c>
				<c>
					Monitor for changes in operation of a specific network 
				</c>
				<c>
					5 
				</c>
				<c>
					Diagnose problems in a specific network 
				</c>
				<c>
					6 
				</c>
				<c>
					Improve knowledge of system performance 
				</c>
				<c>
					7 
				</c>
				<c>
					Lead the market toward more effective networks 
				</c>
				<c>
					8 
				</c>
				<c>
					Encourage the redeployment of scarce spectrum using efficient technologies and implementations 
				</c>
				<c>
					9 
				</c>
				<c>
					Compare measured performance data to simulated results 
				</c>
				<c>
					10 
				</c>
				<c>
					Assess theoretical models 
				</c>
				<c>
					11 
				</c>
				<c>
					Assess technology elements proposed during standards development 
				</c>
				<c>
					12 
				</c>
				<c>
					Assess service measurements geo-located 
				</c>
			</texttable>
		</section>
		<section title="Use Cases">
			<t>
				Various use cases are summarized in Table 2 below, with cross reference measurement purposes listed in Table 1 and to relevant stakeholders. 
			</t>
			<texttable anchor="table_2" title="Use Cases and Measurement Purposes per Stakeholder">
				<ttcol align='left'>
					Use case 
				</ttcol>
				<ttcol align='left'>
					Stakeholder 
				</ttcol>
				<ttcol align='left'>
					Measurement Purposes 
				</ttcol>
				<c>
					POLICY CHECK 
				</c>
				<c>
					Governmental policy maker 
				</c>
				<c>
					1 
				</c>
				<c>
					COMPETITION CHECK 
				</c>
				<c>
					Governmental policy maker 
				</c>
				<c>
					1 
				</c>
				<c>
					STRATEGIC DIRECTION 
				</c>
				<c>
					Governmental policy maker 
				</c>
				<c>
					1,12 
				</c>
				<c>
					EFFICIENCY IMPROVEMENT 
				</c>
				<c>
					Governmental policy maker 
				</c>
				<c>
					1,12 
				</c>
				<c>
					SERVICE CHECK 
				</c>
				<c>
					User (individual or enterprise) 
				</c>
				<c>
					1,3,4,12 
				</c>
				<c>
					TRENDS 
				</c>
				<c>
					User (individual or enterprise) 
				</c>
				<c>
					1,12 
				</c>
				<c>
					COMPARISONS 
				</c>
				<c>
					User (individual or enterprise) 
				</c>
				<c>
					2,12 
				</c>
				<c>
					AUTONOMOUS NETWORK PERFORMANCE ACCESS 
				</c>
				<c>
					Cellular tower operator 
				</c>
				<c>
					2,4,5 
				</c>
				<c>
					AUTONOMOUS RADIO NETWORK ACCESS 
				</c>
				<c>
					Cellular tower operator 
				</c>
				<c>
					2,5,8 
				</c>
				<c>
					HANDOVER 
				</c>
				<c>
					Wireless carrier / Network operator 
				</c>
				<c>
					2,6 
				</c>
				<c>
					SERVICE LEVEL AGREEMENT 
				</c>
				<c>
					Wireless carrier / Network operator 
				</c>
				<c>
					1,2 
				</c>
				<c>
					RESOURCE USAGE 
				</c>
				<c>
					Wireless carrier / Network operator 
				</c>
				<c>
					2,5 
				</c>
				<c>
					TEST OF NEW RELEASE INTRODUCTION 
				</c>
				<c>
					Wireless carrier / Network operator 
				</c>
				<c>
					2,5 
				</c>
				<c>
					CHECK MODELS 
				</c>
				<c>
					Researcher 
				</c>
				<c>
					1,2,6,10 
				</c>
				<c>
					ACCESS TO REAL IN-FIELD DATA 
				</c>
				<c>
					Researcher 
				</c>
				<c>
					1,2,6,10 
				</c>
				<c>
					METRICS AVAILABILITY 
				</c>
				<c>
					Standards developer 
				</c>
				<c>
					2,10 
				</c>
				<c>
					CHECK OF OPTIONS 
				</c>
				<c>
					Standards developer 
				</c>
				<c>
					2,6,11 
				</c>
				<c>
					UE CHARACTERIZATION 
				</c>
				<c>
					User device vendor 
				</c>
				<c>
					1,2 
				</c>
				<c>
					APPLICATION CHARACTERIZATION 
				</c>
				<c>
					Application developer 
				</c>
				<c>
					1,2 
				</c>
				<c>
					MOBILE SERVICE CHARACTERIZATION 
				</c>
				<c>
					Mobile Application Service Provider 
				</c>
				<c>
					1,2,8 
				</c>
			</texttable>
			<t>These use cases are detailed below.</t>
		</section>
		<section anchor="User" title="Stakeholder: User (individual or enterprise)">
			<t>
				Use cases for the "User (individual or enterprise)" stakeholder include the following: 
			</t>
			<section title="Use Case: SERVICE CHECK">
				<t>
					Naturally, individual or enterprise users, as well as virtual network operators, are interested in getting the best service from the mobile network and from the service provider. The performance data collected using specific services can be compared by the stakeholders in relation to the measurement conditions (operator, radio interface, end service host, type of service, location, mobility, etc.). In some cases, the User is an enterprise supporting many individual end user devices over a long period of time, over a large geographic region (which may be limited to, for example, specific service routes). Standardized measurements could be enable agreement on an SLA between the enterprise and a mobile service provider. 
				</t>
				<t>
     				Mobility and radio conditions affect service delivery, so a standardized characterization of services is incomplete without consideration of those conditions.
				</t>
				<t>
					Measurement applications that are useful for these purposes are overall data on quality of experience measured by UEs but also service measurements geo-located or correlated to time-of-day, time-of-week, etc. Even measurements of changes on a specific network behaviour or on a specific service can be interesting and aid in identification of limitations on a specific network. 
				</t>
				<t>
					A simple example of network limitation could be the absence of connection continuity within a certain geographical location, so connections are dropped as soon as the UE moves into a region, possibly at predictable times. 
				</t>
			</section>
			<section title="Use Case: TRENDS">
				<t>
					Analyzing day-to-day trends is a use case relevant for example to enterprise organizations that need to assure certain connection reliability over time to their associated or customers. Checking trends is also useful for profiling the customer access and identifying bottlenecks in the service or overload conditions. 
				</t>
				<t>
					An example of such a use case is an enterprise that has to size and maintain the network resources for customers accessing its network, for example for e-commerce or customer support, and desire to measure the service experience of mobile access over time, to identify bottleneck conditions. 
				</t>
				<t>
					Measurement application that can be used for such purposes are overall data on quality of experience measured by UEs but also service measurements geo-located. All these measurements have to be analyzed as trends over time correlating also with enterprise network conditions and host behaviour. 
				</t>
			</section>
			<section title="Use Case: COMPARISON">
				<t>
					An enterprise or individual user could be interested in understand the relevance of a specific issue that it is experiencing, is comparison with other UEs (perhaps located in the same area) and accessing similar services. This could be used to check, for example, UE configuration for correct behaviour. Measurements application useful for these purposes could be an enterprise or public (anonymous) repository of end-user measurements toward specific services, geo-located and providing the type of device as possible aggregation criteria for measurements. Comparison use cases are also relevant to inter-comparison of network operators in the enterprise's service areas.
				</t>
			</section>
		</section>
		<section anchor="Tower" title="Stakeholder: Cellular tower operator">
			<t>
				Use cases for the "Cellular tower operator" stakeholder include the following: 
			</t>
			<section title="Use Case: AUTONOMOUS NETWORK PERFORMANCE ACCESS">
				<t>
					A network operator builds and develops new tower sites based significantly on customer demand; the operator has good access to data regarding such demand. The success of an access cellular tower operator, on the other hand, is dependent on building and developing new tower locations for use by multiple network operators, none of which may share operational information. Therefore, a cellular tower operator may seek access to a broad set of public mobile measurements, possible over a broad set of network operators, in order to inform tower development activities that will serve multiple network operators, ideally without expensive drive tests. 
				</t>
				<t>
					Measurement applications useful for these use cases could be the quality of experience of the specific network, the network diagnosis and the change of operation in the specific network. 
				</t>
			</section>
			<section title="Use Case: AUTONOMOUS RADIO NETWORK ACCESS">
				<t>
					A cellular tower operator is interested in getting the most from each site, checking the correctness of the configuration against the radio conditions and suggesting improvements to NO that operate the rest of the network. Getting autonomous access to the end-user experience correlated with radio conditions and cell identification helps the cell tower operator to be more proactive in suggesting network improvements. Measurements could be also used to suggest migration to other radio access technologies and otherwise upgrading the cellular site. 
				</t>
				<t>
					Measurement applications useful for these use cases could be the quality of experience of the specific network, the diagnosis of problems, and the encouragement of deployment of more efficient radio access technologies. 
				</t>
			</section>
		</section>
		<section anchor="Carrier" title="Stakeholder: Wireless carrier / Network operator">
			<t>
				Use cases for the "Wireless carrier/Network operator" include the following: 
			</t>
			<section title="Use Case: HANDOVER">
				<t>
					As usual in the mobile domain, it is necessary to characterize the broadband services during packet switched handover events. Such characterization can be correlated to specific cells and/or specific services. The adoption of measurements at end user premises can be reused even for setting proper values for handover settings. 
				</t>
				<t>
					Measurement applications are quality of experience of a specific network, correlated with radio conditions, location information, and device information. All these measurements have the consequence that the stakeholder can improve knowledge of its network performance, useful also to optimize and design better updates of the network. 
				</t>
				<t>
					Mobility characterization can be used even to characterize the radio access technology behaviour during service lifetime. Such characterization could suggest improvements of the mobile network or additional features to support better mobility in connected state. 
				</t>
			</section>
			<section title="Use Case: SERVICE LEVEL AGREEMENT">
				<t>
					The existence of a Service Level Agreement is predicated on an understanding between the parties on accurate measurement methods. Currently, SLAs are rare in the mobile domain, partially because such an understanding is difficult to reach. Standardized measurements will help enable mobile SLAs.
				</t>
				<t>
					Checking the Service Level Agreement is needed not only to be sure that the contract to customers is satisfied but also could be useful to check the performance of different NOs homogeneously. This could imply understanding limitations and trigger analysis to improve the core network or redesign radio deployment to make it more efficient or to move to new radio access technology.
				</t>
				<t>
					Measurement applications include the quality of experience of a specific network and also overall data on quality of experience of set of networks available to customers. 
				</t>
			</section>
			<section title="Use Case: RESOURCE USAGE">
				<t>
					Traffic and performance measurements are useful to optimize network parameter configuration, feeding for example optimization systems. Even if this job is typically done at the network level, the availability of the UE perspective can help especially for network technologies that do not provide a complete reporting of the UE measurements. For example, spectrum allocation and configuration parameters can be modified according to the traffic and performance measurements provided by UEs, for example to avoid network overload and congestion and reduce loss of radio contact. 
				</t>
				<t>
					Measurement applications are the quality of experience of a specific network and diagnosis of problems in a specific network. 
				</t>
			</section>
			<section title="Use Case: TEST OF NEW NETWORK EQUIPMENT">
				<t>
					Measurements provided by an end-user can be used to characterize the performance changes following new network equipment. 
				</t>
				<t>
					Aggregated per cell and radio technology, such measurements can provide KPIs that can be used to compare the network performance before and after new release changes at the access network level, from the end user perspective. 
				</t>
				<t>
					Measurement applications are the quality of experience of a specific network and diagnosis of problems in a specific network. 
				</t>
			</section>
		</section>
		<section anchor="Researcher" title="Stakeholder: Researcher">
			<t>
				Use cases for the "Researcher" stakeholder include the following: 
			</t>
			<section title="Use Case: CHECK MODELS">
				<t>
					A researcher can be interested in checking the correctness of some hypothesis or theoretical models, starting from in-field data. For example, the statistical model for service request arrival rate by customers can be checked against real conditions. Therefore, measurement applications useful for researchers can be quality of experience of a specific network or quality of experience on a set of networks available to the user. Other relevant applications include improving knowledge of system performance and checking the network behaviour against theoretical models. 
				</t>
			</section>
			<section title="Use Case: ACCESS TO REAL IN-FIELD DATA">
				<t>
					Another possible use case is getting access to real data in order to achieve additional information useful for researchers, as for example test set or traffic profiles and consistency. 
				</t>
				<t>
					Measurement applications useful for this use case are similar to the previous one. 
				</t>
			</section>
		</section>
		<section anchor="developer" title="Stakeholder: Standards developer">
			<t>
				Use cases for the "Standards developer" include the following: 
			</t>
			<section title="Use Case: METRICS AVAILABILITY">
				<t>
					End user measurements are useful to understand actual mobile performance and so make decisions on improved standards based on measured facts, as obtained in a standardized manner. For example, latency metrics available on specific radio access technology can support upgraded standards. 
				</t>
				<t>
					Measurement application useful for standards developer can be quality of experience of a specific network or comparing measured results with theoretical models. 
				</t>
			</section>
			<section title="Use Case: CHECK OF OPTIONS">
				<t>
					Performance measurements allow comparison of expected results with current results, in order to validate technical choices. An example could be the adoption of specific codec for voice or the adoption of specific protocols for data services. Another example is the impact of security on performance, because authentication and ciphering techniques could affect overall performance. 
				</t>
				<t>
					Measurement applications include performance assessment, correlated to radio, location, and technology details. Other measurement applications include the assessment of technology elements proposed during the standard development. 
				</t>
			</section>
		</section>
		<section anchor="vendor" title="Stakeholder: User device vendor">
			<t>
				Use cases for the "User device vendor" include the following: 
			</t>
			<section title="Use Case: UE CHARACTERIZATION">
				<t>
					User device manufacturers are generally interested in the range of possible network performance that their users may experience, particularly in correlation to factors such as device features. Such information informs the design decisions of the manufacturer, for example providing guidance as to which features will be most relevant to user experience.
				</t>
				<t>
					User device manufacturers can be interested in the adoption of UE broadband measurements to characterize the interoperability of the device against real networks. The adoption of KPIs divided per user device is helpful for this type of characterization. In fact, different network settings can be the reason for a variable interoperability between the network and the UE.
				</t>
				<t>
					So, measurement applications useful for user device vendors can be quality of experience of a specific network or quality of experience on a set of networks available to the user. 
				</t>
			</section>
		</section>
		<section anchor="app" title="Stakeholder: Application developer">
			<t>
				Use cases for the "Application developer" stakeholder include the following: 
			</t>
			<section title="Use Case: APPLICATION CHARACTERIZATION">
				<t>
					Mobile application (app) developers are generally interested in the range of possible network performance that their users may experience. Such information informs the design decisions of the developers, for example providing guidance as to which app features will enhance, or detract from, user experience.
				</t>
				<t>
					In case of mobile applications, it is important to characterize how well the app is performing through the network. This characterization can be also the trigger for app changes that minimize the drawbacks with the network interaction. It is possible for mobile application developers also to include monitoring callbacks that can be useful for passive measurements.  Other use cases for app developer are a sort of usage profiling, understanding when and how much an app is used by customers. Timing the app's access to services from the network is important, for example, to correlate usage drop by the user to poor quality of service experience. 
				</t>
				<t>
					Measurement application useful for app developer can be quality of experience of a specific network or quality of experience on a set of networks available to the user. 
				</t>
			</section>
		</section>
		<section anchor="ASP" title="Stakeholder: Application service provider">
			<t>
				Use cases for "Mobile application service provider" stakeholder include the following: 
			</t>
			<section title="Use Case: MOBILE SERVICE CHARACTERIZATION">
				<t>
					Mobile application service providers are interested in mobile broadband measurement characterization, particularly correlating the measurements to the specific invoked application. In fact, the service accessed by mobile has to satisfy certain conditions not relevant to services accessed from landline networks. Assessment is possible by measuring the volume of mobile application transactions and also by correlating such usage with the actual performance level. A consequence of such analysis could be encouragement of users to adopt specific radio technologies with some critical mobile apps. 
				</t>
				<t>
					In case of networks that do not support the bandwidth needed for a specific application, it may be useful to trigger modifications either in the application itself or in the network. The trade-off decision can be driven even by end user measurements. 
				</t>
				<t>
					Measurement application useful for the app developer can be quality of experience of a specific network or quality of experience on a set of networks available to the user. Measurements can be used to encourage the network operator to adopt more efficient radio technologies to support services that could be limited by network efficiency so far.
				</t>
			</section>
		</section>
		<section anchor="Governmental" title="Stakeholder: Governmental policy maker">
			<t>
				The Governmental policy maker stakeholder includes several use cases: 
			</t>
			<section title="Use Case: POLICY CHECK">
				<t>
					In order to check the behaviour of network players against current policies, the behaviour of networks must be measured from an end-user perspective. So, as an example, if current policies require that emergency calls be supported by all network operators even when the UE is SIM-less or belonging to a different operator, then measurements are required to check the compliance against this requirement. 
				</t>
				<t>
					Measurement application that can be useful for this use case are overall data on quality of experience measured by UEs across different networks. It is important to characterize the measurements with dimensions that support the policy check under test. As in the previous example, it is necessary to associate the measurements to the home network users, roamers, and SIM-less UEs. 
				</t>
			</section>
			<section title="Use Case: COMPETITION CHECK">
				<t>
					Governmental policy makers could encourage competition between NOs. In case of resources shared by different actors (e.g. shared sites, shared network entities, radio spectrum, etc.) it could be relevant to measure current behaviour for different NOs. An example could be the support of legacy services that the governmental policy maker requires be maintained (e.g. technically obsolete radio technologies to be maintained for a certain period of time with specific level of service). 
				</t>
				<t>
					In this use case the overall data on quality of experience could be measured by UEs across different networks. 
				</t>
			</section>
			<section title="Use Case: STRATEGIC DIRECTION and EFFICIENCY IMPROVEMENT">
				<t>
					Governmental policy makers could encourage the adoption of technologies with a strategic plan, for example to achieve a better environmental sustainability. Measurements with this perspective can be related for example to battery usage per services, spectrum needs, or specific geographical areas. For example, it could be specified that some specific geographical region will support at least a certain number of concurrent calls per location area. So, admission control and network allocated resources have to deal with these requirements. 
				</t>
				<t>
					Another example relates to technological evolution, such as measuring the amount of traffic for specific services encouraging the deployment of new technologies to support better usage of scarce spectrum, for example with a better spectral efficiency or operation with reduced radio signal power. In general, users may be hesitant to convert to new UE technology due to cost without unbiased reassurance of the technical benefits to the individual users of making the transition; unbiased measurements may thereby encourage individual equipment upgrades that would contribute toward a more efficient network operation. 
				</t>
				<t>
					Measurement application for these use cases include the overall data on quality of experience measured by UEs and also service measurements geo-located or correlated to radio conditions, even associated to other UE parameters (e.g. type of device, radio access technology, battery consumption,radio signal strength). 
				</t>
			</section>
		</section>
		<section anchor="Acknowledgements" title="Acknowledgements">
			<t>
				The authors acknowledge the participants in the IEEE 802.16 Working Group on Broadband Wireless Access and in IEEE 802.16's Project 802.16.3 on Mobile Broadband Network Performance Measurements. 
			</t>
		</section>
<!-- Possibly a 'Contributors' section ... -->
		<section anchor="IANA" title="IANA Considerations">
			<t>
				This memo includes no request to IANA. 
			</t>
		</section>
		<section anchor="Security" title="Security Considerations">
			<t>
				Candidate Control and Report protocols are required to meet security requirements identified in 
				<xref target="I-D.ietf-lmap-framework">
				</xref>
				. 
			</t>
		</section>
	</middle>
<!--  *****BACK MATTER ***** -->
	<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->
		<references title="Normative References">
			&I-D.draft-ietf-lmap-framework-11; 
		</references>
		<references title="Informative References">
			<reference anchor="P802.16.3" target="https://mentor.ieee.org/802.16/dcn/14/16-14-0078-00.docx">
				<front>
					<title>
						IEEE 802.16.3 Architecture and Requirements for Mobile Broadband Network Performance Measurements 
					</title>
					<author>
						<organization>
							IEEE 802.16 Working Group on Broadband Wireless Access, A. Bovo (editor) 
						</organization>
					</author>
					<date month="Oct" year="2014" />
				</front>
			</reference>
		</references>
	</back>
</rfc>
