WO2014085693A1 - Clientless method for quality of service measurements - Google Patents

Abstract

The methods and apparatuses described herein relate to providing quality of services and throughput measurements for services supported by Wireless Receive Transmit Units (WRTUs) including but not limited to traditional wireless phones, smartphones, cameras, tablets, PC, USB-modem, PCMCIA modems, telemetry modems, and test modems. Measurements of quality of service in terms of throughput and latency that may be minimally disruptive on wireless devices are described herein. In an aspect, the system may allow the testing of the quality of service to WRTUs that may not support background tasks. A Network Quality Measurement Entity (NQME) may perform a QoS measurement by starting a timer, transmitting a proxy auto-configuration (PAC) file to a WRTU; and measuring a time associated with completing transfer of the PAC file.

Description

CLIENTLESS METHOD FOR QUALITY OF SERVICE MEASUREMENTS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application

Serial No. 61/731,938 filed November 30, 2012, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] Wireless receive/transmit units (WRTUs) have evolved significantly from early cellular phones. Advanced WRTUs not only carry voice traffic, but also receive/transmit text (SMS) messages and access various sources of data content. WRTUs may provide the mechanism by which information is reached on the go whether from the World Wide Web, application stores, or corporate resources. Smartphones, laptops, tablets, cameras, sensors often include wide area 3G, 4G, LTE and other transceivers as well as IEEE 802.11 wireless local area network (WLAN) access or WiFi.

[0003] Advanced Wireless Transmit/Receive Units (WRTU) such as smartphones using iOS, Android, and other operating systems, take a toll on wireless network resources because of the large data traffic they generate. Operations such as web surfing, accessing content written in HTML5, downloading applications, downloading mapping elements, streaming audio and video content, and video conferencing are data-intensive applications that may be found in advanced WRTUs. The advent of social media and networks that allow users to check in locations, pin pictures, upload various types of content demand increasing amounts of bandwidth.

[0004] Many WRTUs have the capability to support multiple air interfaces, both using traditional "cellular" mobile technology such as, but not limited to, UTMS, GSM, Edge, IS-95, WCDMA, TD-SCDMA, HSPDA, HSUDA, HSPA+, CDMA2000, WIMAX, LTE, 3G, 4G, TD-LTE, and "local" wireless technology such as, Bluetooth, WIFI, and the IEEE 802 series of protocols. [0005] As WIFI (aka IEEE 802.11 family) hot spots are more frequently deployed in businesses and homes, operators and consumers alike may seek to leverage their existence to manage their traffic and provide communication services with adequate and predictable Quality of Service (QoS).

[0006] Throughput (which may also be referred to as bandwidth or available bandwidth) measurements have been traditionally done by measuring the transmission time of large files to devices (See Andrew Tanenbaum, Computer Networks, Prentice Hall, 2003). One disadvantage associated with this technique is that the transmission of files for the purpose of throughput measurement conflicts with the need to keep bandwidth available for applications. Moreover, the network entity responsible for measuring the performance of the network may not be the network entity responsible for supporting an end-to-end application. Other techniques to measure throughput rely on the regular injection of probe packets (see Andreas Johnson, Bandwidth Measurements in Wired and Wireless Networks, Department of Computer Science and Electronics, Alardalen University, April 2005). There is a need for a more efficient method for QoS and throughput measurements.

SUMMARY

[0007] The methods and apparatuses described herein relate to providing quality of services and throughput measurements for services supported by Wireless Receive Transmit Units (WRTUs) including but not limited to traditional wireless phones, smartphones, cameras, tablets, PC, USB-modem, PCMCIA modems, telemetry modems, and test modems. Measurements of quality of service in terms of throughput and latency that may be minimally disruptive on wireless devices are described herein. In an aspect, the system may allow the testing of the quality of service to WRTUs that may not support background tasks. A Network Quality Measurement Entity (NQME) may perform a QoS measurement by starting a timer, transmitting a proxy auto- configuration (PAC) file to a WRTU; and measuring a time associated with completing transfer of the PAC file. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0009] FIG. 1 shows a flow diagram of shows a flow chart of an example method for performing quality of service (QoS) measurements;

[0010] FIG. 2 illustrates an example of an example system for performing

QOS measurement, highlighting only key elements;

[0011] FIG. 3 is a block diagram of a WRTU that may be used to implement features described herein; and

[0012] FIG. 4 is a block diagram of a server computer that may be used to implement features described herein.

DETAILED DESCRIPTION

[0013] The methods and apparatuses described herein focus on measuring

QoS and throughput to wireless receive/transmit units (WRTUs) by leveraging the way proxy configuration information is sent. As used in the embodiments described hereinafter, a WRTU may include, but is not limited to, a mobile station (STA), a UE, a communication device, a traditional wireless phone, a smartphone, a camera, a tablet, a PC, a USB-modem, a PCMCIA modems, a telemetry modem, or a test modem. The embodiments described herein provide examples of WRTUs that may be controlled using the methods and apparatuses disclosed.

[0014] Certain terminology is used throughout the application for convenience only and is not limiting.

[0015] As used herein, "connected" means that elements within the system are connected physically or through a remote connection such that they are functionally connected. This connection may be temporary or permanent. As a non-limiting example, a remote connection may be through a localized Radio Frequency (RF) link. It may also be a wired connection through dedicated network or the ubiquitous Internet.

[0016] The terms QoS, throughput, effective bandwidth may be used interchangeably herein.

[0017] The words "a" and "one," as used in the claims and in the corresponding portions of the specification, are defined as including one or more of the referenced item unless specifically stated otherwise. The phrase "at least one" followed by a list of two or more items, such as "A, B, or C," means any individual one of A, B, or C as well as any combination thereof. Further, as used herein, the singular forms "a," "an," and "the" include plural referents unless expressly and unequivocally limited to one referent.

[0018] The references cited throughout this application, are hereby incorporated by reference herein as if each reference was fully set forth. Specific references are cited at particular locations herein to indicate examples in which the teachings of the reference are incorporated. However, a citation of a reference at a particular location does not limit the manner in which all of the teachings of the cited reference are incorporated for all purposes.

[0019] The methods and apparatuses described herein may use the Proxy

Auto- Configuration (PAC) file used to support HTTP on any browser or mobile application (app) using hypertext transfer protocol (HTTP) as a transport mechanism. The methods and apparatuses described herein may focus on traffic operating on a single radio air interface technology (RAT), but they also may apply to bandwidth or RAT aggregation in which traffic is handled by multiple channels of the same air interface technology or spread across multiple air interface technologies.

[0020] The example embodiments described herein may be implemented by a network quality measurement entity (NQME). The NQME may be placed in a radio access network (RAN), a core network (CN), or an application server connected therein. The NQME may set the content of the PAC file used to set

HTTP born communication. This may be done without changing the software in the WRTU and is thus backward compatible with current WRTUs. A PAC file defines how an Internet browser or other applications using HTTP may automatically choose the appropriate proxy server for fetching a given URL. A PAC file may contain the JavaScript function "FindProxyForURL(url, host)". This function may return a string with one or more access method specifications. These specifications cause the user agent to use a particular proxy server or to connect directly.

[0021] FIG. 1 shows a flow chart of an example method for performing QoS measurements 100 in accordance with a first embodiment, which may be used in combination with any of the other embodiments described herein. The NQME may receive a QoS measurement request from an Authentication, Authorization, and Accounting Management Entity (AAAME) 101. The NQME may then start a timer 102. The NQME may then transmit or send a PAC file to a WRTU 103. The PAC file may be of a known size or length. The WRTU may be associated with the AAAME after sending a request for access point (AP) association to the AAAME, which may respond by generating a WRTU association profile and transmitting it to the WRTU. The NQME may then measure the time when PAC file transfer is complete 104. The time associated with completing transfer of the PAC file may be based on an acknowledgment (ACK) received from the WRTU [0022] Taking a measurement in accordance with the method described above may provide a calculation of the speed of the network. The PAC file uniform resource locator (URL) may respond with a correctly formatted and valid PAC file. The PAC file may include only one command, "proceed directly," which commands the recipient to not use any proxies on the network. However, the PAC file may also include a large body of commented text. Even though the text may be meaningless, it must be downloaded before the file may be processed. The speed of throughput may be stored and used to evaluate if the network is suitable for a connection or not.

[0023] Accordingly, one benefit of this method is that it does not rely on a timestamp being sent from the WRTU. It may also be implemented within network element server. Timestamps are not required and thus synchronization or near synchronization between a client and server is also not required. Power consumption at the device may also be reduced because this method is implemented at the server. It may not require any specific software to be implemented on the client (WRTU) and thus may allow a wide range of devices to be measured (e.g. WIFI enabled single-lens reflex (SLR) cameras). This method may be described as "clientless" because it may extends the core functionality of devices.

[0024] Another benefit of this method is that the measurement is being made when no other traffic is flowing between the WRTU and server, thus reducing throughput measurement noise. The connection throughput may be measured without contention from other services on the WRTU attempting to access the Internet. High accuracy in measurements, which results in a smaller oversize file, may be used.

[0025] FIG. 2 shows an example system for performing QoS measurements

200 in accordance with the method of the first embodiment, which also may be used in combination with any of the other embodiments described herein. The example system of FIG. 2 includes WRTUs 214, 216, 217, and 218, APN 201a, 201b, 201c, and 201d, Radius Server 202, RANs 203a, 203b, 203c, and 205, and NQME 209a, and Radius Server 206 that includes NQME 209b. A WRTU 214, 216, 217, or 218 managed by AAAME 208 may interface through the network 207 with a push server supporting the operating system supported by the WRTU. After initial connection, the AAAME VPN configuration profile may be transferred to the push server for forwarding (after potential modifications) to WRTUs 214, 216, 217, or 218. Based upon the response from the WRTU, additional configuration profile(s) may be sent to the WRTUs 214, 216, 217, or 218.

[0026] FIG. 3 is a block diagram of an example WRTU 300 that may be used to implement method described above in accordance with the first embodiment, which may also be used in combination with any of the other embodiments described herein. The WRTU includes one or more transceivers 301, a processor 302, a memory device 303, a data storage device 304, and a display device 305. These components may be connected via a system bus in the WRTU and/or via other appropriate interfaces within the WRTU.

[0027] The memory device 303 may be or include a device such as a

Dynamic Random Access Memory (D-RAM), Static RAM (S-RAM), other RAM, or flash memory. The data storage device may be or include a hard disk, a solid- state disk (SSD), or any other type of device for persistent data storage.

[0028] The one or more transceivers 301 may implement various radio access technologies, including any combination of the radio access technologies mentioned herein, including but not limited to UMTS, GSM, Edge, IS-95, WCDMA, TD-SCDMA, HSPDA, HSUDA, HSPA+, CDMA2000, IEEE 802.16 (WiMAX), LTE, 3G, 4G, TD-LTE, Bluetooth, Wireless Local Area Network (WLAN) technology, and 802. llx technology (including 802.11a/b/g/n).

[0029] The display device 305 may be a Liquid Crystal Display (LCD) or

Organic Light- Emitting Diode (OLED) display device, or any other appropriate type of display device. The display may be a touchscreen display, which may be based on one or more technologies such as resistive touchscreen technology, surface acoustic wave technology, surface capacitive technology, projected capacitive technology, and/or any other appropriate touchscreen technology.

[0030] The WRTU of FIG. 3 may be configured to perform any feature, features, or methods described herein as performed by a WRTU. Alternatively or additionally, the memory device 303 and/or the data storage device 304 in the WRTU may store instructions which, when executed by the processor 302 in the WRTU (in conjunction with the other components in the WRTU such as the one or more transmitter, receivers, or transceivers 301, memory device 303, display device 305, and/or data storage device 304), may cause the WRTU to perform any feature, method or combination of features or methods described herein as performed by a WRTU.

[0031] FIG. 4 is a block diagram of an example server computer 400 that may be used to implement features and methods described herein. The server computer includes one or more network interfaces 401, a processor 402, a memory device 403, and a data storage device 404. These components may be connected via a system bus in the server computer, and/or via other appropriate interfaces within the server computer.

[0032] The memory device 403 may be or include a device such as a

Dynamic Random Access Memory (D-RAM), Static RAM (S-RAM), or other RAM or a flash memory. The data storage device may be or include a hard disk, a solid-state disk (SSD), or any other type of electronic device for persistent data storage.

[0033] The one or more network interfaces 401 may be or include one or more wired and/or wireless transceivers, and/or may implement various wired and/or wireless data communication technologies, including any combination of the radio access technologies mentioned herein. Alternatively or additionally, the one or more network interfaces 401 may implement technologies such as IEEE 802.3 and/or Digital Subscriber Line (DSL) technology.

[0034] The server computer of FIG. 4 may be configured to perform any feature or method or combination features or methods described herein as performed by a server computer, and/or any feature or combination of features or methods described herein as performed by an AAME, AS, and/or WS.

Alternatively or additionally, the memory device 403 and/or the data storage device 404 in the server computer may store instructions which, when executed by the processor 402 in the server computer (in conjunction with the other components in the server computer such as the one or more network interfaces

401, memory device 403, and/or data storage device 404), may cause the server computer to perform any feature or method or combination of features or methods described herein as performed by an AAME, AS, and/or WS.

[0035] There are multiple ways to provide a fallback when a proxy fails to respond as described in the method of the first embodiment. For example, the browser may fetch the PAC file before retrieving other pages. The URL of the

PAC file may either be configured manually or determined automatically by the web proxy web auto-discovery protocol (WPAD). WPAD lets the browser guess the location of the PAC file through dynamic host configuration protocol

(DHSCP) and domain name system (DNS) lookup. Once detection and download of the PAC file is complete, it may be executed to determine the proxy for a specified URL.

[0036] PAC files may execute simplified JavaScript to perform their functions. Modern browsers and mobile applications accept PAC files, and are likely to continue doing so for a long time. When the browser detects a PAC file URL has been assigned, it may download and process the PAC file before attempting to fetch, download, or process any of the content, elements, or assets in a given webpage.

[0037] In another embodiment, the NQME may be part of the AAAME such as the one taught by Thompson et al. in U.S. Patent Application No. 61/579,761. The AAAME may manage access to one or more WiFi Networks, which may include a collection of APs. For each network managed by the NQME, it may generate a specific PAC file URL. When providing WiFi credentials and connection parameters, a NQME may insert a PAC file URL.

[0038] In yet another embodiment, the NQME may be collocated with a

VPN server. VPNs typically require remote users of the network to be authenticated, and often secure data with encryption technologies to prevent disclosure of private information to unauthorized parties. Authentication protocols include but are not limited to the following: AKA, CAVE-based authentication, Challenge-handshake authentication protocol (CHAP), MS- CHAP, MS-CHAPv2, CRAM-MD5, Host Identify Protocol (HIP), Kerberos, Microsoft NT LAN Manager (NTLM), Password-authenticated key agreements, password Authentication Protocol (PAP), Secure Remote Password (SRP) protocol, TACACS, TACACS+, Woo-Lam (92) protocol and often used in wireless systems Diameter, RADIUS, and Extensible Authentication Protocol (EAP).

[0039] PAC files may be used for load balancing in accordance with yet another embodiment, which may be used in combination with any of the other embodiments described herein. The NQME may leverage the fact that PAC files are cacheable on the device that requests them. The NQME may maintain a database identifying which WRTU has downloaded a PAC file URL. As a result, it may restrict how often a specific WRTU is used to measure throughput in a given time period (for example, per day).

[0040] Without the need to track whether a client has been at a specific location on the server side, the local caching of the PAC file may allow a client to avoid requesting this QOS.

[0041] In another embodiment, the NQME may preset a new PAC file at one or more from of a plurality of APs to force re-measurement of the QOS.

[0042] In another embodiment, the NQME may change the text (the content of the PAC File URL) based on the time of day. For example, at one moment the PAC file may be the following: function FindProxyForURL(url, host) {

// Lorem ipsum dolor sit amet, consectetur adipisicing elit

// sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

//carpe culinam, coquina coniuncta et Kitchology

// Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. if (shExpMatch(host, "*. example. com"))

{

return "DIRECT";

}

// URLs within this network are accessed through

// port 8080 on fastproxy.example.com:

if (isInNet(host, "10.0.0.0", "255.255.248.0"))

{

return "PROXY fastproxy. example. com:8080";

}

// All other requests go through port 8080 of proxy.example.com.

// should that fail to respond, go directly to the WWW:

return "PROXY proxy.example.com:8080; DIRECT";

} [0043] At another moment, the PAC file may be the following: function FindProxyForURL(url, host) {

return "DIRECT";

}

[0044] In another embodiment, the NQME may set a PAC file size or PAC file length (or range of PAC file sizes or PAC file lengths) of the PAC file based on the expected or predicted QoS on the managed networks: faster networks may be configured with larger PAC files, while slower networks may be configured with smaller PAC files. If the download takes a very long time, the PAC file may not complete the loading process and may instead instruct the device to disconnection.

[0045] In another embodiment, the size or length of the PAC file is set based on a cost of accessing a wireless network.

[0046] In another embodiment, the size or length of the PAC file is set based on a model associated with the WRTU.

[0047] In another embodiment, the size or length of the PAC file is set based on a storage capacity associated with the WRTU.

[0048] In another embodiment, the size or length of the PAC file is set based on a time of day, a day of a week, a network utilization, or location.

[0049] In another embodiment, the NQME may collect statistics associated with a network operation for setting QoS.

[0050] In yet another embodiment, the NQME may trigger the use of compression services to improve overall throughput.

[0051] Embodiments:

1. A method for measuring throughput in wireless network, the method comprising:

sending, by a wireless receive/transmit unit (WRTU), a request for access point association to a Authentication, Authorization, and Accounting Management entity (AAAME).

2. The method of embodiment 1, further comprising: generating, by the AAAME, an WRTU Association Profile.

3. The method of any of the preceding embodiments, further comprising:

notifying, by the AAAME, WRTU of association by transmitting Said Association Profile.

4. The method of any of the preceding embodiments, further comprising:

requesting, by the AAAME, a measurement to Network Quality Measurement Entity (NQME).

5. The method of any of the preceding embodiments, further comprising:

starting, by the NQME, a timer.

6. The method of any of the preceding embodiments, further comprising:

sending, by the NQME, a proxy-auto configuration (PAC) file to the WRTU.

7. The method of any of the preceding embodiments, further comprising:

measuring, by the NQME, a time when transfer of the PAC file is complete.

8. The method of any of the preceding embodiments, wherein the AAAME is a RADIUS Server.

9. The method of any of the preceding embodiments, wherein the NQME is a RADIUS Server.

10. The method of any of the preceding embodiments, wherein the PAC file length is set on a per application basis.

11. The method of any of the preceding embodiments, wherein the PAC file length is set based on a cost of using one or more wireless networks, a cost of accessing one or more wireless networks, a profile of the WRTU, an application making request in the WRTU, an operating system of the WRTU, a model of the WRTU, a storage capacity of the WRTU, a time of day, a day of week, a current networks utilizations, or a location.

12. A system comprising:

at least one WRTU.

13. The system of embodiment 12, further comprising:

at least one Authentication, Authorization, and Accounting Management entity (AAAME).

14. The system of any of the preceding embodiments, further comprising:

at least one Network Quality Management Entity (NQME).

15. The system of any of the preceding embodiments, further comprising:

at least one wireless receive/transmit unit (WRTU) configured for sending a request for access point association to the at least one AAAME, wherein the at least one AAAME is configured for generating an WRTU Association Profile and for notifying the at least one WRTU of association by transmitting Said Association Profile.

16. The system of any of the preceding embodiments, further comprising:

the NQME configured for starting a timer and for transmitting a proxy- auto configuration (PAC) file to the WRTU file to the at least one WRTU.

17. The system of any of the preceding embodiments, further comprising:

the NQME configured for measuring a time for the PAC file to be transferred;

18. The system of any of the preceding embodiments, further comprising:

the AAAME configured for transmitting said second Association Profile to WRTU.

19. The system of any of the preceding embodiments, further comprising: the NQME configured for generating the PAC file URL messages based on a cost of using one or more wireless networks, a cost of accessing one or more wireless networks, a profile of the WRTU, an application making a request in the WRTU, an operating system of the WRTU, a model of the WRTU, a storage capacity of the WRTU, a time of day, a day of week, a current network utilization, or a location.

20. The system of any of the preceding embodiments, further comprising:

the NQME configured for collecting statistics about network operation for the purpose of setting quality of services.

[0052] It is understood, therefore, that this the methods and apparatuses described herein are not limited to the particular embodiments disclosed, but is intended to cover all modifications which are within the spirit and scope of the subject matter as defined by the appended claims; the above description; and/or shown in the attached drawings.

[0053] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. Although the solutions described herein consider 802.11 specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WRTU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is claimed is:

1. A method for performing quality of service (QoS) measurements, the method comprising:

receiving, by a Network Quality Measurement Entity (NQME), a QoS measurement request;

starting, by the NQME, a timer;

sending, by the NQME, a proxy auto-configuration (PAC) file to a wireless transmit/receive unit (WRTU); and

measuring, by the NQME, a time associated with completing transfer of the PAC file.

2. The method of claim 1, wherein the WRTU is associated with a Authentication, Authorization, and Accounting Management Entity (AAAME).

3. The method of claim 2, wherein the QoS measurement request is received from the AAAME.

4. The method of claim 1 wherein the NQME is a RADIUS Server.

5. The method of claim 2 wherein the AAME is a RADIUS Server.

6. The method of claim 1 wherein a length of the PAC file is set for each application.

7. The method of claim 1 wherein a length of the PAC file is set based on a cost of accessing a wireless network from a plurality of wireless networks or a profile associated with the WRTU.

8. The method of claim 1 wherein the time associated with completing transfer of the PAC file is based on an acknowledgment (ACK) received from the WRTU.

9. The method of claim 1 wherein the QoS measurement request is received from the WRTU.

10. The method of claim 9 wherein a length of the PAC file is set based on a request made by an application associated with the WRTU.

11. The method of claim 9 wherein a length of the PAC file is set based on an operating system associated with the WRTU.

12. The method of claim 9 wherein a length of the PAC file is set based on a model associated with the WRTU.

13. The method of claim 9 wherein a length of the PAC file is set based on a storage capacity associated with the WRTU.

14. The method of claim 1 wherein a length of the PAC file is set based on a time of day, a day of a week, a network utilization, or location.

15. The method of claim 1, further comprising:

collecting, by the NQME, statistics associated with a network operation for setting QoS.

16. A Network Quality Measurement Entity (NQME) configured for performing quality of service (QoS) measurements, the NQME comprising:

a receiver configured to receive a QoS measurement request;

a processor configured to start a timer; a transmitter configured to transmit a proxy auto-configuration (PAC) file to a wireless transmit/receive unit (WRTU); and

the processor configured to measure a time associated with completing transfer of the PAC file.

17. The NQME of claim 16 wherein the QoS measurement request is received from a Authentication, Authorization, and Accounting Management Entity (AAAME).

18. The NQME of claim 16 wherein the time associated with completing transfer of the PAC file is based on an acknowledgment (ACK) received from the WRTU.

19. The NQME of claim 16 wherein the QoS measurement request is received from the WRTU.

20. A wireless transmit/receive unit (WRTU) configured for performing quality of service (QoS) measurements, the WRTU comprising:

a processor configured to set a proxy auto-configuration (PAC) file length; a transmitter configured to transmit a QoS measurement request; and a receiver configured to receive the PAC file.