Traffic Backfilling: Subsidizing Lunch for Delay-TolerantApplications in UMTS Networks

H. Andrés Lagar-Cavilla, Kaustubh Joshi, Alexander Varshavsky,Jeffrey Bickford† and Darwin Parra∗

AT&T Labs – Research, †AT&T Security Research Center, ∗AT&T Mobility

ABSTRACTMobile application developers pay little attention to the interactionsbetween applications and the cellular network carrying their traffic.This results in waste of device energy and network signaling re-sources. We place part of the blame on mobile OSes: they do notexpose adequate interfaces through which applications can inter-act with the network. We propose traffic backfilling, a techniquein which delay-tolerant traffic is opportunistically transmitted bythe OS using resources left over by the naturally occurring burstscaused by interactive traffic. Backfilling presents a simple inter-face with two classes of traffic, and grants the OS and networklarge flexibility to maximize the use of network resources and re-duce device energy consumption. Using device traces and networkdata from a major US carrier, we demonstrate a large opportunityfor traffic backfilling.

Categories and Subject DescriptorsC.2.1 [Computer Communication Networks]: Network Archi-tecture and Design

General TermsDesign, Performance

Keywords3G, UMTS, Traffic Scheduling

1. INTRODUCTIONWide adoption of mobile devices along with ubiquitous cellular

data coverage has resulted in an explosive growth of mobile ap-plications that expect always-accessible wireless networking. Thisexplosion has placed strains on resources that are scarce in the mo-bile world: handheld battery life and cellular network capacity. Onthe user side, poor battery life due to unoptimized mobile apps hasbeen blamed for user dissatisfaction and phone returns [7]. On thenetwork side, the growth rate of mobile data is outstripping the rateat which new cellular wireless capacity is being added [6], leadingto proposals for optimization of data use through techniques suchas WiFi offloading [3].

Little attention, however, has been paid by OS designers to theefficiency of the interactions between cellular networks and mobileapplications. Because the acquisition of cellular network resourcesincurs large signaling and latency costs (up to 2 seconds), resourcesare reserved for several seconds once in use. The extra time atthe end of a reservation is usually called “tail”, and is a mecha-nism used to minimize signaling costs when traffic is intermittentyet somewhat closely spaced. Thus, depending on the precise tim-ing of data streams, network usage characteristics such as energyrequirements, latency and bandwidth vary widely, even within asingle location. Ignoring these dynamics can result in significantwaste of scarce network resources and energy - e.g., it has recentlybeen shown that for a popular music streaming mobile application,3.6% of the traffic consumes 64.1% of the network device energyand produces the vast majority of the network signaling [12].

Proposals to address this issue fall in two camps: a) “tail-optimization”approaches [12, 11] that modify the allocation of network resourcesto more closely match predicted traffic patterns, or b) traffic schedul-ing approaches that accumulate traffic into highly-efficient bursts [13,4]. However, we contend that the opportunities for both tail predic-tion and traffic shaping are fundamentally limited by one factor:users are unpredictable. They will not prefetch content, or followperfectly regular patterns to benefit the overall health of the net-work. Furthermore, delaying traffic from interactive applicationscan significantly degrade user experience.

An additional problem is that socket-based network APIs pro-vided by current OSes are inadequate for optimizing either networkresource allocation or traffic patterns. Sockets hide all the charac-teristics of the underlying network and provide the abstraction of apipe over which “instantaneous communication” is available. Thisabstraction leads to a situation in which applications introduce traf-fic onto the network at-will, without regard to its impact on deviceenergy, networking signaling, and overall load. Even if a consci-entious application were to try and optimize its transmissions, theOS provides no hints on how and when to do so. Further, applica-tions’ expectation of instantaneous communication severely limitsthe OS’s or network’s ability to schedule traffic. Delays in messagedelivery can be construed as an indication of failure, and triggerundesirable responses such as quality degradation or failover.

In this paper, we propose traffic backfilling, a novel traffic schedul-ing approach that is exposed by the OS in the form of a separateservice. The idea is to allow applications to differentiate networktransfers into interactive traffic (e.g., web browsing, instant mes-saging) and delay-tolerant traffic (e.g., advertisement downloads,synchronization). Today, both kinds of traffic consume the mobiledevice’s energy and network resources with equal priority. In con-trast, we propose to exploit naturally occurring network bursts dueto interactive traffic, and utilize the network resources reserved by

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, to republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee. MobiHeld '11, October 23, 2011, Cascais, Portugal. Copyright © 2011 ACM 978-1-4503-0980-6/11/10 ... $10.00.

1

����

�������� ��������������

����������������������� !"����#��

$��%!���������$�������!#�� !"����#��

���������&'�������� !"����#��

Figure 1: The RRC state machine for “Carrier 1”

those bursts to interject delay-tolerant backfill traffic into the gapsbetween the bursts. The aim is to obtain a “subsidized lunch” inwhich a large amount of delay-tolerant traffic can utilize resourcesleft over by interactive and unpredictable bursts at a low marginalcost, in terms of device energy and network signaling overhead.

Our primary contributions in this position paper are in quanti-fying the scope of the backfilling opportunity, sketching the broadoutlines of an OS backfill API, and illustrating how existing andnew applications may leverage it. Using traces collected from a va-riety of user devices (phones, laptops with 3G dongles) and operat-ing systems (Mac OS X, Windows, Android), we show that tens ofadditional MiBs can be transmitted via backfilling even assumingnominally low bitrates (i.e. 256 Kbps). We refine this estimate froma network perspective by analyzing aggregate data from a large ur-ban area on a major carrier’s UMTS network comprising 1853 cellsites. We find that aggregate traffic patterns at the per-cell level arehighly bursty at small timescales, and are thus amenable to back-filling. For tens of thousand of short-term bursts of network trafficseen by a single cell, with a median length of 16 seconds, the ra-tio of estimated utilized network resources clusters heavily aroundonly 25% of the peak. With appropriate support, the extra 75% canbe reused for backfill traffic.

2. BACKGROUNDWe begin by providing an overview of how resource allocation

works on UMTS (Universal Mobile Telecommunications System)networks, and its implications for mobile device energy usage andnetwork signaling load. Although we focus on the most widelyused 3G technology, the basic principles remain the same for re-lated technologies such as LTE.

UMTS mobile devices establish network connectivity through aUMTS Terrestrial Radio Access Network (UTRAN) consisting ofbase stations (or Node-Bs) and Radio Network Controllers (RNCs).Each RNC handles a number of base stations and is responsiblefor controlling network resources. The RNC allocates these re-sources using per-device RRC (Radio Resource Control) state ma-chines whose transitions are triggered by device traffic exchangesand carrier-determined inactivity timers. For example, Figure 1shows the state machine for a major US carrier with its parameterssummarized in Table 1. This state machine was inferred by the au-thors of [12] without any carrier help, using measurements madefrom mobile devices.

This state machine has an IDLE state, in which the mobile de-vice consumes no energy on its radio, and no network resources.Upon network use, the mobile device is promoted into a high-

FACH → IDLE 12 sDCH → FACH 5 s

FACH threshold UL 540RLC drain UL 0.0014t2 + 1.6t+ 20 ms

Buffer threshold DL 475(bytes) drain DL 0.1t+ 10 msIDLE → DCH signaling 2.0±1.0 sFACH → DCH signaling 1.5±0.5 s

Table 1: State machine parameters for “Carrier 1”bandwidth, high energy consumption DCH state, in which it isallocated a “dedicated” channel by the network. Typical signal-ing latency for moving to DCH is two seconds, while devices con-sume between 570 mW to 800 mW in this state [12]. After a fewseconds of inactivity, the mobile is demoted to a shared channel,FACH, in the hopes of satisfying marginal network use with a low-bandwidth shared channel, and lower energy usage (450mW in av-erage). Eventually, after a second threshold of inactivity, the mobileis downgraded from FACH back to the IDLE state. If, on the otherhand, the mobile networking activity overflows a buffer (in the Ra-dio Link Control layer or RLC), it is promoted again to the DCHstate.

Thus, each state of the RRC state machine dictates the device’senergy consumption and the network channels it can use. Transi-tions between low-power states to high-power states are triggeredby network activity, whereas transitions between high-power statesto low-power states are triggered by inactivity timers. The inac-tivity timers are necessary to preclude spurious state transitions,which add extra delays and impose non-trivial network signalingoverheads. They are tuned by network engineers to provide a healthydose of hysteresis. There are as many variations on this state ma-chine as there are carriers - with different states, different transi-tions, and different thresholds for triggering them. But two keyelements, staged resource acquisition and hysteresis via inactivitytimers, remain across all variations [12].

With HSPA, the latest revision to UMTS, channel capacity canbe allocated at a finer granularity within the DCH state. Channelscheduling of devices in the DCH state, both up and downlink, isperformed by RNCs with a granularity of 10ms or 2ms [14]. Thus,once in DCH, devices use as many 10ms/2ms scheduling periodsas their traffic demands, with little spectrum waste. However, thestate machine still remains important because it determines the en-ergy state of the mobile device modem, and the signaling caused bytransitions still places non-trivial demands on the network’s controlplane.

3. TRAFFIC BACKFILLINGWe propose backfilling as a new traffic scheduling technique

that reuses unutilized gaps between bursts of traffic from interac-tive applications to send delay tolerant traffic. The OS tracks RRCstate machine transitions that result from interactive traffic alone,and transmits backfill traffic during periods of inactivity within theDCH state. Such unused DCH periods exist because of the hys-teresis imposed by the RRC state machine inactivity timers. Fig-ure 2 shows unused periods both between gaps in bursty traffic, andduring the whole duration of the “DCH tail,” before the demotionto the FACH state. By using such gaps profitably, the device canexchange large amounts of additional data with little additional en-ergy usage and signaling load.

To achieve the lowest incremental cost, backfilling should closelytrack the state machine transitions that would have occurred withinteractive traffic only. Backfill traffic must be ignored when com-puting the state machine trigger conditions (Table 1). Although thestate machine is maintained within the RNC, the trigger conditions

2

Figure 2: Backfilling reuses unused gaps between interactivetraffic bursts

we need can also be controlled, indirectly, entirely from the de-vice itself through the use of fast dormancy [1]. Fast dormancy isa mechanism to allow devices to signal an immediate DCH to theIDLE transition to the RNC. When the OS detects that the RRCstate machine would have down-transitioned if backfill traffic wereabsent, it can initiate fast dormancy to transition to the IDLE state,thus emulating the state machine’s behavior in absence of backfilltraffic.

Improper use of fast dormancy can substantially increase the fre-quency of RRC state changes, and overload the network controlplane by increasing signaling load [8]. Therefore, network carri-ers often work with vendors to disable or significantly restrict theuse of fast dormancy. Preliminary investigation shows that noneof the UMTS USB dongles available for a major US carrier hada fast dormancy API that was exposed to the OS; however, an un-documented AT command was discovered for Infineon chipsets [9].Unlike tail optimization approaches [12, 11, 4] that advocate short-ening of DCH tails, our approach is compatible with such carrierrestrictions on fast dormancy since we seek to use it to preserve theoriginal state-machine transitions.

Delaying traffic within the mobile device only covers outboundtraffic. Handling inbound traffic entails the complexity of requir-ing the remote sender to pause the network flow when there is noopportunity for backfilling. For short durations, this can be accom-plished without cooperation from the sender by using the TCP per-sist condition [5]. Specifically, the mobile OS can “stall” (resume)a TCP flow by advertising a zero (non-zero) length TCP receiverwindow. Since the mobile device is unreachable when the flowsare stalled, network support for responding to sender probe packetsfor stalled flows may be required. While all TCP implementationsare required to support zero-sized windows [5], firewalls or appli-cations can sometimes terminate long-lived stalled connections toreclaim resources. For such situations or UDP flows, more exten-sive network staging of inbound flows may be needed.

The resulting delay-tolerant backfill service is an “eventuallycomplete” best-effort service that, at the OS or network’s discre-tion, makes arbitrary progress in reliably transmitting a stream ofbytes to the receiver. Progress is not guaranteed - for instance, withthe proper network support, the network can ask to delay trans-mission of backfill traffic in periods of network congestion. Con-versely, the OS may batch and efficiently send a large chunk ofbackfill traffic even in the absence of any interactive traffic. In re-turn for the flexibility it provides in handling network congestion,network providers may choose to provide economic incentives forbackfill data either by charging lower per-byte rates, or by countingonly a fraction of the transfer towards a user’s data cap.

4. API PROPOSALOne important advantage of backfilling is the simplicity of the

API exposed by the OS. At its core, the backfilling API allowsapplications to discriminate between interactive and delay-toleranttraffic. We outline here a proposal for such API; without loss ofgenerality, we focus on Linux.

The traditional method for establishing network connections isthe socket interface, which allows for fine-grained control via thesetsockopt family of system calls. An initial setsockoptcan be used by applications to tag sockets as transmitting delay-tolerant traffic. An application can move the connection out ofdelay-tolerant queues through an explicit flag setting, or as a side-effect of other socket control settings such as disabling Nagle’s al-gorithm.

Unbounded wait is never desirable for delay-tolerant traffic. Mostdelay-tolerant traffic expects to be transmitted “soon” as opposedto “right now”, and perhaps a more accurate term would be “non-urgent” traffic. Two bounds to trigger transmission of the accu-mulated delay-tolerant traffic are wait time and bytes accumulated.The former will trigger transmission if the oldest packet has waitedfor more than N seconds; the latter will transmit once the bytecount exceeds a B threshold. Bounds will also cause the same traf-fic aggregation effect sought by application modification in [12],and the “taps” and “preserves” primitives of Cinder [13]. Boundscan be applied globally, or on a per-socket basis.

So far, our discussion has been application centric. Yet, the OScan easily detect periods of active resource reservation for whichthere is no pending traffic to backfill. A callback mechanism allowsthe OS to signal to applications this transient opportunity to pushfurther payloads on a backfilling window. The select family ofsystem calls provides a good conduit: it allows applications to (i)decide when to wait, (ii) aggregate multiple events in a single waitpoint, and (iii) read from the OS via a pipe additional information,such as the size of the current backfilling window.

In the interest of successful upstreaming, particularly for a ker-nel like Linux, we can stay away from changes to the core kernelsocket routines. Instead, we can manage buffering of payloads, ag-gregation, and completion notification entirely within the boundsof a user-space toolkit. The responsibilities of the kernel are lim-ited to prioritizing packets from interactive sockets, tracking of theRRC state machine, and notifying state changes to user-space.

4.1 ApplicationsOn top of the OS interface, a toolkit can expose multiple user-

space primitives to simplify application interaction with the back-filling machinery. Applications can set up staging areas for out-bound payloads; they can set up a publish-subscribe mechanismto be alerted of arrival of messages. Or, more generally, they canstructure themselves as event-driven loops with callbacks reactingto backfilling activity. While existing applications can benefit fromtransferring “subsidized” delay-tolerant data, we also believe back-filling will enable applications that users may be reluctant to runotherwise. We outline four applications and the primitives they canleverage:

Participatory Sensing: The plethora of sensors (GPS, accelerome-ter, camera, etc) on contemporary smart phones has resultedin the birth of participatory sensing applications, in whichphones upload sensor readings to data-mining repositories.Such uploads can use a staging area to aggregate data until abackfilling opportunity arises.

Backup and Synchronization: With backfilling, backup can beperformed opportunistically and at a possibly lower price.This is a classical example of an event-driven application,triggering backup cycles upon availability of backfilling win-dows.

Email and RSS: Periodic email and RSS polling have been usedfrequently in the literature [4, 13] as examples of delay-tolerant

3

0

50

100

150

200

250

300

350

400

1 10 100

Glo

bal D

CH

Kbp

s

Trace Time in DCH (min)

Figure 3: DCH utilization vs. DCH time for 15 traces of varyingduration.

traffic that can be optimized for 3G networks, through the useof staging areas (for outbound email) and publish-subscribepools (for inbound RSS and email).

Cloud offload: Recent proposals [10] have recommended offload-ing security checking to cloud services, at a high data trans-mission cost. Backfilling can turn such services into event-driven loops and lower or eliminate transmission costs. Theamount of tolerable delay for security responses can be easilytuned through the API.

5. THE BACKFILLING OPPORTUNITYWe build support for backfilling by measuring the size of the

opportunity in two phases. We first focus on device-centric mea-surements, and then later extend the study to incorporate networkwide metrics.

5.1 Device-Centric MeasurementWe harvested fifteen traces of UMTS networking traffic. We uti-

lized a Windows 7 laptop with an Infineon-based LG Adrenalinedata card, a Macbook Air laptop with an Option data card, and anAndroid-based Samsung Captivate phone with an Infineon built-inmodem. All modems are HSPA+ capable. In each case, these de-vices already had an owner with established usage patterns. Wesimply turned on tracing, disabled WiFi and Ethernet to ensure theUMTS network was used, and let the user continue life as usual.The durations of the traces were randomly distributed between aslittle as five minutes, to over an hour (77 minutes), to three full-daytraces (around 1420 minutes).

We used libpcap-based utilities (tcpdump, wireshark, etc) to har-vest our data traces. Because libpcap presents packets as seen bythe OS, HSPA-level MAC headers and retransmissions are not cap-tured. We then fed the traces to an emulated UMTS radio re-source state machine, following the parameters of Figure 1 andTable 1 [12]. Assuming the traffic had occurred in the Carrier 1network (we do not know whether that is the case), we calculatedthe time spent by the network devices in DCH and FACH modes,as well as the bytes transmitted in each case.

The numbers obtained are consistent with measurements in theliterature [12, 11]. DCH tail times hover around 20%. Backfillingopportunities are not limited to DCH tails – any significant gap innetwork use during a DCH state can be used. For example, one ofour traces corresponds to roughly 75 minutes of watching a Huluvideo. The UDP traffic from Hulu peers prevents the modem fromever leaving the DCH state. Yet, packet inter-arrival times of twoseconds are not uncommon.

In Figure 3 we plot each trace, sorted by the amount of time spent

0

0.2

0.4

0.6

0.8

1

22:1319:2616:4013:5311:0608:2005:3302:46

Rat

io o

f Max

Cap

acity

Use

d

Time (24hr format)

Figure 4: Ratio of data demand per sec in a single cell to thepeak demand per sec over 24 hours.

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

02:5102:5002:4902:4802:4702:46R

atio

of M

ax C

apac

ity U

sed

Time (24hr format)

Figure 5: Random five second period in Figure 4.

in DCH state, against the global DCH bitrate in Kbps (i.e. bits sentand received in DCH, divided by DCH time). Rarely does a traceexceed 150 Kbps of global DCH bitrate. Most traces accumulatelonger than 10 minutes of DCH time, with a trace showing as littleas 25 Kbps over 11 minutes. Clearly, the opportunity for backfill-ing while spending marginal additional energy is present, even fornominal channel capacity as low as 384 Kbps, which was alreadyachievable a decade ago [2]. At that capacity, most of our tracescould push over 20 MiBs of backfill traffic.

5.2 Network-Centric MeasurementsTo complement the view from the device perspective, we now

turn to network traces. We show results from a UMTS provider ina major US urban area for May 15th 2011. The data feed we ob-tained is decomposed by RNC, by Node-B within each RNC, andby mobile within each cell, totaling 1853 Node-Bs and 130653 mo-bile users. The data for each mobile consists of the number of kilo-bits sent and received for every second for which there was DCHactivity (i.e., the data demand). Due to business reasons, we can-not reveal the urban area, nor the absolute capacity measurements– hence all numbers are expressed as ratios and percentages.

In Figure 4 we chose a particular cell that experienced a highdegree of activity. We plot the demand per second over the fullday, expressed as a ratio of the peak, which is achieved at about7:42pm. We note the high short term variance in demand, whichreveals a substantial opportunity for backfilling. Figure 5 zoomsinto a five second period (starting at 10 thousand seconds) to revealthe abundance of short-term valleys of low utilization.

Feeding the data harvested for each individual mobile to a statemachine emulator gives a finer-grained picture. For each mobileand each DCH period, we can calculate spare capacity that can bereused for backfilling. The individual peak bitrate actually achieved

4

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 5K 10K 15K 20K 25K 30K 35K

Rel

ativ

e C

apac

ity U

sed

Mobile Device DCH Time (seconds)

Figure 6: Relative capacity used (per-mobile).

by each mobile device in each DCH period is used as a proxy forthe maximum achievable bitrate. This is a conservative estimate,and therefore our estimates of the backfilling opportunity are alsoconservative. Figure 6 plots the ratio of the used capacity to totalcapacity for each DCH period in each mobile. The relative capacityutilized is largely independent of the length of the DCH periods,and clusters heavily around 25%. In other words, for most DCHperiods, three additional bytes could have been backfilled for eachbyte transmitted over UMTS, at marginal additional energy cost forthe device.

Finally, Figure 7 shows a cumulative distribution function (CDF)of the ratio of the unused DCH capacity represented by DCH tails.The plot shows that over half the opportunities for backfilling liebeyond the DCH tails, with unused capacity available in the “spacesin between” in a transmission stream. The median ratio representedby DCH tails is slightly over 40% of the unused DCH capacity. TheCDF shows that for roughly 15% of the DCH periods, the DCH tailrepresents all unused capacity. For such instances, the period of ac-tive DCH use is the minimum quantum recorded by our tracing ma-chinery, thus representing isolated single-shot bursts of networkingactivity.

6. CONCLUSIONSIn this position paper we have argued for traffic backfilling as

a means to allow applications to optimize their interactions withwireless cellular networks. With backfilling, delay-tolerant traf-fic can be transmitted leveraging the unused resources left over bybursts of interactive and urgent foreground application traffic. Wehave shown through device traces and network data from a majorUS carrier that there is ample opportunity for traffic backfilling to-day, at a marginal cost both from a network signaling and deviceenergy standpoint. Our future work focuses on realizing the impli-cations of this position paper, and enabling new mobile applicationsotherwise thought to be impractical.

7. REFERENCES[1] 3GPP. Fast Dormancy: a Way Forward.

http://bit.ly/itBSjj.[2] 3GPP. Release 1999. http://bit.ly/lMYpxT.[3] A. Balasubramanian, R. Mahajan, and A. Venkataramani.

Augmenting Mobile 3G Using WiFi. In Proc. Mobisys, June2010.

[4] N. Balasubramanian, A. Balasubramanian, andA. Venkataramani. Energy Consumption in Mobile Phones:A Measurement Study and Implications for NetworkApplications. In Proc. IMC, Chicago, IL, Nov. 2009.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

CD

F

Ratio of DCH Tail to Total Unused DCH Capacity

Figure 7: CDF of ratios that DCH tails represent out of thetotal unused capacity in DCH periods.

[5] R. Braden. Requirements for Internet Hosts -Communication Layers. RFC 1122, Oct. 1989. Updated byRFCs 1349, 4379, 5884, 6093.

[6] F. C. Commission. Mobile Broadband: The Benefits ofAdditional Spectrum. http://bit.ly/9ia36u, Oct.2010.

[7] Electronista. Motorola Chief Pins Android Phone Returns onPoor Apps. http://bit.ly/lMByCF.

[8] FierceWireless.com. What’s Really Causing the CapacityCrunch? http://bit.ly/bUN9MX.

[9] Ofono.org. Adding Fast Dormancy Support to InfineonModem. http://bit.ly/lrthJy.

[10] G. Portokalidis, P. Homburg, K. Anagnostakis, and H. Bos.Paranoid Android: Versatile Protection For Smartphones. InProc. 26th ACSAC, 2010.

[11] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, andO. Spatscheck. TOP: Tail Optimization Protocol for CellularRadio Resource Allocation. In Proc. ICNP, Tokyo, Japan,Oct. 2010.

[12] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, andO. Spatscheck. Profiling Resource Usage for MobileApplications: a Cross-layer Approach. In Proc. of Mobisys,Washington, DC, June 2011.

[13] A. Roy, S. M. Rumble, R. Stutsman, P. Levis, D. Mazieres,and N. Zeldovich. Energy Management in Mobile Deviceswith the Cinder Operating System. In Proc. of Eurosys,Salzburg, Austria, Apr. 2011.

[14] Wikipedia. Transmission Time Interval.http://bit.ly/kNIyMH.

5

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles false /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /DocumentCMYK /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice