throbber
MINIMIZING ENERGY CONSUMPTION OF SECURE WIRELESS SESSION
`WITH QOS CONSTRAINTS
`
`Ramesh Karri Piyush Mishra
`Department of Electrical and Computer Engineering
`Polytechnic University, Brooklyn, NY, US 11201
`
`Abstract: In this paper we will investigate techniques to minimize the
`energy consumed by a secure wireless session without compromising
`the security of the session. While it has been shown in [8] that
`compressing the session negotiation messages, the protocol header,
`and the data reduces the energy consumed by a secure session [8], in
`this paper we show that matching the block size of compression to the
`data cache size of the device is important. We also investigate the
`choice of a bulk encryption algorithm (3DES vs. AES) and a key
`exchange protocol (Diffie-Hellman vs. RSA) based on the energy
`consumed by a secure session. These techniques yield energy savings
`of 1.3x during data transmission and 1.2x during data reception
`beyond that obtained by techniques in [8]. These techniques
`complement and supplement those proposed in [8] and when
`combined yield an overall energy savings of 2.1× during data
`transmission and 4.35× during data reception.
`
`1.
`
`exchange. Finally, the client and the server exchange
`messages to activate the session with the negotiated
`security association, and encryption and MAC keys are
`generated independently at the server and the client
`using the exchanged secrets.
`After successfully establishing the secure session,
`either the client or the server takes the plain text
`messages, computes the MAC, encrypts the data and
`transmits it. At the other end, the received data is
`decrypted and verified. Either end can terminate the
`session at any
`time. Periodically refreshing
`the
`encryption and the MAC keys (key refresh) and the
`secure session parameters (session refresh) enhances the
`security of the session.
`There has been substantial research in the field of
`wireless
`communication
`energy management.
`Techniques to minimize the energy consumed by a
`communication unit include modulating the energy used
`by the mobile transmitter during active communication
`[5, 21], adapting communication according to the
`application
`requirements
`[18], suspending device
`operation during idle periods [6, 20] and transitioning
`between different modes of operation [7, 4]. Energy-
`aware network protocols optimize the WLAN card
`activities [22], reduce energy-expensive retransmission
`of lost messages [17] and employ energy-efficient error
`control schemes [19]. In this paper we extend the scope
`of this research to include security protocols and
`introduce techniques for reducing the energy consumed
`by secure wireless sessions carried over public
`networks.
`
`2. Motivation
`Energy consumed by secure wireless sessions on
`mobile devices is very significant. It is a function of the
`size of data transferred and the security level of the
`session, as shown in Figure 1.
`7%3%
`
`18%
`3%
`
`3DES
`encryption
`SHA-256
`
`44%
`
`Introduction
`The rapidly increasing trend of “anytime-anywhere”
`access of sensitive data together with the emerging m-
`commerce applications has fueled a tremendous growth
`of secure wireless sessions to ensure data integrity,
`privacy and authenticity over public networks [1, 2].
`Such applications consume significant energy while (a)
`establishing the secure session, (b) performing the secure
`data transactions, and (c) periodically refreshing the
`session security parameters for higher security. Mobile
`computing and communication devices used
`for
`providing
`these services have
`limited computing
`resources and battery life. Therefore, a successful merger
`of shrinking device sizes and increasing secure wireless
`data access demands efficient management of battery
`energy.
`A secure session is established between the client and
`the server using security protocols such as Secure Socket
`Layer (SSL) [24], Internet Security Protocol (IPSEC)
`[23] or Wireless Transport Layer Security protocol
`(WTLS) [3]. We extracted features common to these
`security protocols, such as the handshake for mutual
`authentication and for secret key exchanges, to study the
`performance and energy consumption characteristics of a
`secure session.
`Client initiates the handshake by sending a list of
`cryptographic parameters it supports, such as the key
`exchange
`protocols,
`the
`private-key
`encryption
`algorithms and the message authentication code (MAC)
`algorithms. Server responds with the acceptable security
`association, authenticates itself to the client, sends
`necessary
`information
`for performing secret key
`exchange and requests authentication from the client. The
`client, in return, authenticates itself and sends the
`remaining
`information
`to complete the secret key
`
`50
`%
`
`35%
`
`40
`%
`
`Transmissi
`on
`idle system
`Figure 1: Energy consumed by secure wireless data
`transmission of 64 KB data using (a) DES and (b) 3DES
`encryption
`
`
`MOBILEIRON, INC. - EXHIBIT 1008
`Page 001
`
`

`

`SHA-256 sign
`SHA-256 verify
`3DES encrypt
`3DES decrypt
`Transmit
`
`Receive
`
`Key refresh
`
`Receive
`
`Security of a private-key encryption algorithm is
`expressed in terms of user key size and the number of
`encryption rounds. 3DES encryption uses a 192-bit key
`as opposed to DES encryption that uses a 64-bit key and
`involved 3× more processing,
`thereby consuming
`significantly more energy.
`We considered a Symbol PPT2800 Pocket PC
`(32-bit, 206 MHz StrongArm SA-1110
`device
`processor, 32 MB flash ROM, 32 MB RAM, 16 KB
`instruction cache and 8 KB data cache [16]) running
`Windows CE 3.0 operating system and equipped with
`an 11 Mbps Spectrum24 wireless LAN adapter card
`[9], operating in the P1 polling mode, as the mobile test
`bed.
`Table 1 summarizes the energy consumed by various
`tasks during a secure wireless session while transmitting
`and receiving 2.56 MB data1. We use Diffie-Hellman
`(DH) protocol for secret key exchange [25], triple-Data
`Encryption Standard (3DES) for encryption [15], SHA-
`256 for message authentication, a key refresh rate that
`entails regenerating the encryption and MAC keys every
`128 KB of data and a session refresh rate that entails
`renegotiating the security association every 2 MB of data.
`Therefore, during this data transaction the security
`association is renegotiated once and the encryption and
`MAC keys are recomputed 19 times, as shown in Table
`1. The idle system energy due to overheads, such as the
`back off period, channel access time and other network
`conditions is more than 40% of the entire system energy.
`Secure session energy (mJ)
`
`1062 mJ/handshake× 2560/2000
`2124
`DH handshake
`SHA-256 sign
`SHA-256 verify 0.0552 µJ/bit × 2.56 × 106 × 8 bits
`1130
`3DES encrypt
`0.3349 µJ/bit × 2.56 × 106 × 8 bits
`(3)
`6858
`3DES decrypt
`0.6582 µJ/bit × 2.56 × 106 × 8 bits
`(4)
`13480
`Transmit
`0.2833 µJ/bit × 2.56 × 106 × 8 bits
`(5)
`5803
`Receive
`12.895 mJ/key-refresh ×
`(6)
`245
`Key refresh
`(2000/128 + 560/128)
`(7)
`16604
`Idle system
`
`40441
`Total transmit
`(1)+(2)+(3)+(4)+(6)+(7)
`32764
`Total receive
`(1)+(2)+(3)+(5)+(6)+(7)
`Table 1: Energy consumed by tasks of a secure session
`Table 2 shows the energy savings for the above data
`transfer using data and protocol header compression and
`protocol optimization techniques proposed in [8]. Due to
`the area restrictions of small mobile devices, such as the
`Symbol PPT 2800, we do not consider hardware
`implementation
`based
`techniques
`for
`energy
`minimization for this work. A combination of adaptive
`handshake and data and header compression operating on
`64KB data block size (with compression parameters that
`
`1 Refer to [8] for complete description of the mobile test bed
`and energy measurement methodology.
`
`(1)
`(2)
`
`(1)
`
`(2)
`
`(3)
`
`(4)
`
`(5)
`
`(6)
`
`261.2
`
`1595
`
`3116
`
`1342
`
`51.56
`
`yield a compression ratio of 4.3) reduced the secure
`session energy by 1.59× during transmission and 3.49×
`during reception.
`
`DH Handshake2
`
`Optimized session energy (mJ)
`724.3 mJ/handshake ×
`724.3
`(2560/4.3) /2000
`0.0552 µJ/bit × 2.56 × 106 ×
`8 / 4.3 bits
`0.3349 µJ/bit × 2.56 × 106 × 8
`/ 4.3 bits
`0.6582 µJ/bit × 2.56 × 106 ×
`8/ 4.3 bits
`0.28335 µJ/bit × 2.56 × 106
`× 8/ 4.3 bits
`12.895mJ/key-refresh ×
`(2560/4.3) / 128
`(7)
`3838
`16604/4.3
`Idle system
`(8)
`15832
`
`DEFLATE compr
`(9)
`1590
`
`DEFLATE decomp
`25422.5
`(1)+(2)+(3)+(4)+(6)+(7)+(8)
`Transmit
`Total
`1.59 ×
`
`Save
`9402.5
`(1)+(2)+(3)+(5)+(6)+(7)+(9)
`Total
`3.49 ×
`
`Save
`Table 2: Energy savings due to protocol optimization
`and compression of protocol header and data
`3. Optimizing secure wireless session energy
`In this section we will present three new techniques
`to further reduce the energy consumed by a mobile
`device during a secure wireless session while satisfying
`all the security requirements.
`3.1 Matching compression block size to device data cache size
`Data compression has been shown to reduce (a) the
`transmission, reception, encryption and decryption
`energy during a secure data transaction (b) the number
`of key refreshes required and the corresponding energy,
`and (c) the energy consumed by the idle system [8].
`Energy consumed by a secure session is reduced if the
`energy savings due to compression and decompression
`are more than the energy consumed by compression and
`decompression. For a secure session operating on a
`fixed energy budget, compression improves security by
`affording larger encryption key size and higher key
`refresh rate.
`Previous research [8] showed that an optimized C
`implementation
`of DEFLATE
`loss-less
`data
`compression algorithm [11] with medium compression
`level (level 5), medium memory level (level 5) and
`maximum history window size (15 bits) yields a
`compression ratio close to the best while consuming the
`least energy on a device with a large data cache.
`8 KB
`1 KB
`128 KB 64 KB
`
`Energy (mJ)
`709.62
`395.79
`31.69
`14.76
`Compression ratio
`4.4815
`4.3256
`3.4782
`2.8254
`Table 3: Energy consumed by DEFLATE compression
`
`2 Refer to [8] for detailed discussion of protocol optimization.
`
`MOBILEIRON, INC. - EXHIBIT 1008
`Page 002
`
`

`

`(1)
`
`(2)
`
`(3)
`
`(4)
`
`(5)
`
`(6)
`
`324.9
`
`1972
`
`3876
`
`1668
`
`64.45
`
`Table 3 summarizes the energy consumed by
`
`DEFLATE while compressing 1KB, 8 KB, 64 KB, and
`128 KB block size benchmarks from Calgary corpus [12]
`on the Symbol device with an 8KB data cache.
`the
`
`Compression energy
`increases sharply as
`compression data block size increases beyond the data
`cache size (8 KB). Matching the compression block size
`to the data cache size yields the optimum compression
`energy although it uses a low compression ratio. Table 4
`shows that sacrificing the compression ratio by matching
`the compression block size to the data cache size reduces
`the energy consumed during data transmission. On the
`other
`hand,
`energy
`consumed
`by DEFLATE
`decompression is approximately one-tenth of the energy
`consumed by compression since decoding is simple and
`fast. Hence, sacrificing
`the compression ratio for
`compression energy while sending data to mobile device
`increases its energy consumption.
`
`Optimized session energy (mJ)
`724.3 mJ/handshake ×
`724.3
`DH Handshake
`(2560/3.4782) /2000
`0.0552 µJ/bit × 2.56 × 106 ×
`8 / 3.4782 bits
`0.3349 µJ/bit × 2.56 × 106 × 8
`/ 3.4782 bits
`0.6582 µJ/bit × 2.56 × 106 ×
`8/ 3.4782 bits
`0.28335 µJ/bit × 2.56 × 106
`× 8/ 3.4782 bits
`12.895mJ/key-refresh ×
`(2560/3.4782) / 128
`(7)
`4773
`16604 / 3.4782
`Idle system
`(8)
`10141
`
`DEFLATE compr
`(9)
`1014
`
`DEFLATE decomp
`21862.8
`(1)+(2)+(3)+(4)+(6)+(7)+(8)
`Transmit
`Total
`1.16 ×
`
`Save
`10538.9
`(1)+(2)+(3)+(5)+(6)+(7)+(9)
`Total
`0.89 ×
`
`Save
`Table 4: Impact of matching compression block size to
`device data cache size
`Therefore, while transmitting data the compression
`block size should be matched to the device data cache
`size and while receiving data large compression block
`size (larger the better) should be used to reduce the client
`energy. Such an asymmetric compression arrangement
`can be agreed upon during the secure session negotiation.
`3.2 Choice of a bulk encryption algorithm
`Table 5 shows that the energy consumed by
`Advanced Encryption Standard (AES) [10] in software is
`5× less than the energy consumed by 3DES. This is due
`to the elegant design of AES to better exploit features
`like pipelining and parallel processing and due to the
`larger data block size.
`A client also has a choice of either reducing the
`encryption key size or the number of encryption rounds
`while increasing the key refresh rate or vice versa to
`
`SHA-256 sign
`SHA-256 verify
`3DES encrypt
`3DES decrypt
`Transmit
`
`Receive
`
`Key refresh
`
`Receive
`
`reduce the system energy while maintaining the desired
`security level. The tradeoff depends upon the relative
`energy consumption of the key refreshes and the data
`encryption algorithm. For example, for a secure session
`transmitting 2.56 MB data using 3DES encryption,
`reducing the number of rounds of encryption by 2×, and
`correspondingly increasing the key refresh rate by 2×
`reduces the session energy by 1.05×. On the other hand,
`for a secure session using 192-bit key AES encryption
`session energy is reduced by 1.01× by increasing the
`encryption key size to 256 bits and reducing the key
`refresh rate by 2×.
`Encryption software implementation
`AES
`3DES
`
`(192-bit)
`256-bit
`128-bit
`192-bit
`Energy/bit (µJ)
`0.075
`0.0666
`0.3349
`0.07
`I
`I
`24.1
`25.963
`4.976
`24.58
`Throughput (Mbps)
`Table 5: Energy consumed by optimized software
`implementations of 3DES and AES encryption
`3.3 Choice of key exchange protocols
`Energy consumed by
`the handshake protocol
`depends upon the level of security of the session (size of
`certificates and secret keys exchanged, size of
`encryption and MAC keys generated) and the number
`and size of messages exchanged.
`A client using Deffie-Hellman key exchange
`protocol during handshake generates and exchanges
`large secret keys with the server. For example, for
`WTLS security protocol the size of these key exchange
`messages can be as large as 64KB. Therefore, a secure
`session using Deffie-Hellman key exchange protocol
`consumes 1062 milli Joules, 90% of which is consumed
`during the generation and exchange of the certificates
`and the secret keys, as shown in Table 6. Numbers in
`bold correspond to the client.
`Messages
`Energy consumed (mJ)
`Exchanged
`
`D-H
`RSA
`
`Comm.
`Comm.
`Tx
`Rx
`Tx
`Rx
`6.8
`16
`6.8
`16
`682 294
`682
`294
`
`Initiation
`Server CERTIFICATE
`+ KEY EXCHANGE
`Client CERTIFICATE
`+ KEY EXCHANGE
`Activation
`KEYENC+MAC
`@ client
`KEYENC+MAC
`@ server
`CLIENT
`295
`358
`31.55
`295
`693
`74.3
`SERVER
`154.8
`685
`46.55
`298
`685
`73.8
`Table 6: Energy consumed by handshake protocols
`using D-H and RSA key exchange protocols
`
`
`61.9
`
`677 292
`
`19.21
`
`-
`12.33
`
`12.33
`
`2.6
`-
`
`-
`
`1.3
`-
`
`-
`12.33
`
`-
`
`45.33
`
`34
`
`2.6
`-
`
`-
`
`148
`
`1.3
`-
`
`-
`
`I
`
`I
`
`Crypto-
`comp.
`0.01
`1.22
`
`Crypto
`-comp.
`0.01
`61.4
`
`MOBILEIRON, INC. - EXHIBIT 1008
`Page 003
`
`

`

`On the other hand, for a system using a RSA [13]
`based handshake the server sends its public key to the
`client. The client encrypts a small random value (20
`bytes for WTLS protocol) using the server public key and
`transmits the result back to the server. Table 6 shows that
`due to the small key exchange message size the
`handshake energy
`is
`reduced by 35% without
`compromising the session security.
`Optimizing the handshake protocol and compressing
`the handshake messages, as suggested in [8], reduces the
`client energy by another 1.86×, as shown in Table 7.
`Reducing the session negotiation energy has significant
`impact upon short secure sessions involving relatively
`smaller data exchanges.
`
`
`Energy consumed by the RSA
`handshake protocol (mJ)
`Un-optimized
`Optimized
`
`358
`20.9
`Transmit
`295
`83.392
`Receive
`31.554
`31.554
`Crypto-computations
`-
`50.704
`Decompression
`347.454
`186.55
`TOTAL
`1.86 ×
`
`Energy saving factor
`Table 7: Energy saved by optimizing the handshake
`protocol
`4. Summary
`Let us study the overall impact of our previous work
`and these new techniques on the energy consumed by the
`secure session.
`Let us consider the same secure session example
`from section 1 for securely transmitting and receiving
`2.56 MB data. We assume a compression block size of
`8KB (data cache size) at client and 64KB at the server,
`medium compression level (level 5), medium memory
`level (level 5) and maximum history window size (15
`bits). DEFLATE compression with these configurations
`yields relatively
`lower compression but consumes
`significantly less energy, as shown in Table 3.
`Session negotiation is carried out using RSA key
`exchange based optimized handshake protocol. The
`server looks up the client certificate from its own source
`and compresses the messages before transmitting them to
`the client. Besides, the optimized secure session uses
`256-bit key AES encryption, SHA-256 MAC, key refresh
`rate that entails re-computation of the encryption and
`MAC key every 256 KB data and session renegotiation
`every 2 MB data.
`Table 8 shows an energy savings of more than 1.3×
`during transmission and 1.25× during reception over [8]
`while satisfying all
`the security and performance
`requirements. Combining these techniques with those
`proposed in [8] results in an overall 2.1× energy savings
`in the transmit mode and 4.35× in the receive mode.
`
`
`
`RSA
`
`Receive
`
`Key refresh
`
`Receive
`
`5.
`
`324.9
`
`441.6
`
`3876
`
`1342
`
`(2)
`
`(3)
`
`(4)
`
`(5)
`
`32.22
`
`(6)
`
`
`Optimized
`Handshake
`SHA-256 sign
`SHA-256 verify
`AES-192 encrypt
`AES-192 decrypt
`Transmit
`
`Optimized secure session energy (mJ)
`186.55 mJ/handshake ×
`186.5
`(1)
`(2560/3.4782) /2000
`0.0552 µJ/bit × 2.56 × 106 ×
`8 / 3.4782 bits
`0.072 µJ/bit × 2.56 × 106 × 8 /
`3.4782 bits
`0.6582 µJ/bit × 2.56 × 106 ×
`8/ 3.4782 bits
`0.28335 µJ/bit × 2.56 × 106
`× 8/ 4.3 bits
`12.895mJ/key-refresh ×
`(2560/3.4782) / 256
`(7)
`4181
`16604 / 3.4782
`Idle system
`(8)
`10141
`
`DEFLATE compr
`(9)
`1014
`
`DEFLATE decomp
`19177.3
`(1)+(2)+(3)+(4)+(6)+(7)+(8)
`Transmit
`Total
`1.33 ×
`
`
`7516.3
`(1)+(2)+(3)+(5)+(6)+(7)+(9)
`Total
`1.25 ×
`
`Save
`Table 8: Energy savings from optimized secure session
`5. Acknowledgement
`We thank Symbol Technologies Inc. for providing
`us with the necessary equipments for the mobile test
`bed. We would also like to thank Jacob Sharony and
`Amy Wang of Symbol Technology Inc. for their
`valuable suggestions and discussions.
`
`
`6. References
`1.
`J. A. Senn, “The emergence of M-Commerce”, IEEE
`Computer, December 2000, pp. 148-150.
`2. D. Clark, “Encryption advances
`to meet Internet
`challenges”, IEEE Computer online magazine, December
`2000.
`http://www.computer.org/computer/articles/August/techn
`ews800.htm
`3. Wireless Application Protocol: Wireless Transport Layer
`Security Specifications, February 2000.
`http://www.wapforum.org
`4. S. Udani, J. Smith, “The power broker: Intelligent power
`management for mobile computers”, Technical Report
`MS-CIS-96-12, CS Department, University
`of
`Pennsylvania, May 1996.
`J. M. Rulnick, N. Bambos, “Mobile power management
`for maximum battery life in wireless communication
`networks”, Proceedings, IEEE INFOCOM, 1996.
`6. R. Kravets, P. Krishnan,“Power management techniques
`for mobile communication”, Proceedings, ACM/IEEE
`MOBICOM, 1999.
`7. A. Kamerman, L. Monteban, “WaveLAN-II: A high
`performance wireless LAN for the unliscensed band”,
`Bell Labs Technical Journal, 1997.
`8. R. Karri, P. Mishra, “Energy management of secure
`wireless session”, Submitted to IEEE INFOCOM, 2002.
`http://cad.poly.edu/publications/infocom2002.pdf
`9. Spectrum24® High Rate LA 41X1 PC Card.
`http://www.symbol.com/products/wireless/la41x1.html
`10. http://csrc.nist.gov/encryption/aes
`
`MOBILEIRON, INC. - EXHIBIT 1008
`Page 004
`
`

`

`11. DEFLATE Compressed Data Format Specification
`version 1.3.
`http://www.kblabs.com/lab/lib/rfcs/1900/rfc1951.txt.html
`12. T.C. Bell, “Text compression”, Prentice Hall, Englewood
`Cliffs, NJ, 1990.
`13. R. L. Rivest, A. Shamir, L. M. Adelman, “A method for
`obtaining
`digital
`signatures
`and
`public
`key
`cryptosystems”, Communications of the ACM, February
`1978, Vol. 21, No. 2, pp. 120-126.
`14. http://www.tektronix.com
`15. National Bureau of Standards, NBS FIPS PUB 46, “Data
`Encryption Standard”, National Bureau of Standards, U.S.
`Department of Commerce, January 1977.
`terminal.
`16. Symbol PPT 2800 series portable pen
`http://www.symbol.com/products/mobile_computers/mobi
`le_ppc_ppt2800.html
`17. A. Chockalingam, M. Zorzi, “Energy consumption
`performance of a class of access protocol for mobile data
`networks”, Proceedings, IEEE VTC, May 1998, Vol. 2,
`pp. 820-824.
`18. R. Kravets, K. Calvert, K. Schwan, “Payoff adaptation of
`communication for distributed interactive applications”,
`Journal on High Speed Networking: Special Issue on
`Multimedia Communications, July 1998.
`19. M. Zorzi, R. R. Rao, “Error control and energy
`consumption in communications for nomadic computing”,
`IEEE Transactions on Computers, Special Issue on
`Mobile Computing, March 1997.
`20. S. Singh, C.S. Raghavendra, “PAMAS-Power aware
`multi-access protocol with signaling for ad-hoc networks”,
`ACM Computer Communications Review, July 1998.
`21. J. Ebert, B. Stremmel, E. Wiederhold, A. Wolisz, “An
`energy-efficient power control approach for WLANs”,
`Journal of Communications and Networks, September
`2000, Vol. 2, n. 3, pp. 197-206.
`22. C. Rohl, H. Woesner, A. Wolisz, “A short look on power
`saving mechanisms in the wireless LAN standard draft
`IEEE 802.11”, WINLAB Workshop on Third Generation
`Wireless Systems, NJ, March 1997.
`Charter.
`(IPSEC)
`23. IP
`Security
`Protocol
`http://www.ietf.org/html.charters/ipsec-charter.html
`24. Secure
`Shell
`Layer
`(SSL)
`Charter.
`http://www.ietf.org/html.charters/secsh-charter.html
`in
`25. W. Diffie, M. E. Hellman, “New directions
`cryptography”, IEEE Transactions on Information Theory,
`November 1976, Vol. 22, No. 6, pp. 644-654.
`
`MOBILEIRON, INC. - EXHIBIT 1008
`Page 005
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket