WO2010087865A1 - Efficient data processing for protocols in multiple layers of a protocol stack - Google Patents

Abstract

Techniques for processing data for a set of protocols at a transmitter and a receiver are described. In one exemplary embodiment, the receiver decodes received frames to obtain decoded MAC frames, obtains un-ordered RLC frames from the decoded MAC frames, and deciphers the un-ordered RLC frames to obtain deciphered RLC frames. In another exemplary embodiment, the receiver computes partial checksums for RLC frames, computes checksums for IP headers, and computes checksums for TCP/UDP frames based on the partial checksums for the RLC frames and the checksums for the IP headers. In yet another exemplary embodiment, the transmitter generates MAC and RLC headers in a fast memory, transfers these header to an internal memory, retrieves a block of data from an external memory in a single transaction, moves the block of data and the RLC headers to form RLC frames, and moves the RLC frames and MAC headers to form MAC frames.

Description

EFFICIENT DATA PROCESSING FOR PROTOCOLS IN MULTIPLE LAYERS OF A PROTOCOL STACK

I. Claim of Priority under 35 U.S.C. §119

[0001] The present Application for Patent claims priority to Provisional U.S. Application

Serial No. 61/032,355, entitled "EFFICIENT DATA PROCESSING WITH HARDWARE ACCELERATORS," filed February 28, 2008, assigned to the assignee hereof, and expressly incorporated herein by reference.

BACKGROUND

I. Field

[0002] The present disclosure relates generally to communication, and more specifically to techniques for processing data in a communication system.

II. Background

[0003] In a communication system, data is typically processed in accordance with a set of protocols for different layers in a protocol stack at both a transmitter and a receiver. At each entity, the protocol at each layer typically processes data in a sequential order and does not start processing until all data needed to generate a complete frame is received by that protocol. Thus, for data transmission, each protocol typically processes complete frames received in sequential order from the next higher layer and provides complete frames in sequential order to the next lower layer. Correspondingly, for data reception, each protocol typically processes complete frames received in sequential order from the next lower layer and provides complete frames in sequential order to the next higher layer. This processing on complete frames in sequential order may be sub-optimal for various reasons described below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 shows a wireless communication system.

[0005] FIG. 2A shows example protocol stacks at various entities in FIG. 1 for UMTS.

[0006] FIG. 2B shows example protocol stacks at various entities in FIG. 1 for cdma2000.

[0007] FIG. 3 A shows encapsulation of data by protocols at a transmitter for UMTS.

[0008] FIG. 3B shows encapsulation of data by protocols at a transmitter for cdma2000. [0009] FIG. 4 shows computation of a checksum for a TCP/UDP frame.

[0010] FIG. 5 A shows ciphering of a frame at a transmitter.

[0011] FIG. 5B shows deciphering of a frame at a receiver.

[0012] FIG. 6 shows a block diagram of a UE and a Node B.

[0013] FIG. 7 shows a block diagram of a receiver that sequentially performs processing for multiple protocols in a protocol stack. [0014] FIGS. 8 and 9 show block diagrams of two exemplary designs of a receiver that performs processing out of order for multiple protocols to improve performance. [0015] FIGS. 1OA and 1OB show computation of a checksum for a TCP/UDP frame based on partial checksums. [0016] FIG. 11 shows a block diagram of a receiver that efficiently processes frames for multiple protocols. [0017] FIG. 12 shows a block diagram of a transmitter that efficiently generates frames for multiple protocols.

[0018] FIG. 13 shows a process for processing data at a receiver.

[0019] FIG. 14 shows a process for performing checksum computation by a receiver.

[0020] FIG. 15 shows a process for performing deframing by a receiver.

[0021] FIG. 16 shows a process for performing routing by a receiver.

[0022] FIG. 17 shows a process for processing data at a transmitter.

DETAILED DESCRIPTION

[0023] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other designs.

[0024] The techniques described herein may be used for various wireless and wireline communication systems. The terms "system" and "network" are often used interchangeably. For example, the techniques may be used for wireless communication systems such as Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal FDMA (OFDMA) systems, Single-Carrier FDMA (SC-FDMA) systems, etc. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. cdma2000 covers IS-2000, IS-95, and IS-856 standards. A TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.16, IEEE 802.20, Flash-OFDM®, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). Long Term Evolution (LTE) is an upcoming release of UMTS that uses E-UTRA. UTRA, E-UTRA, UMTS, LTE and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). cdma2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). For clarity, certain aspects of the techniques are described below for UMTS, and 3GPP terminology is used in much of the description below.

[0025] FIG. 1 shows a wireless communication system 100, which includes (i) a radio access network (RAN) 120 that supports radio communication for user equipments (UEs) and (ii) network entities that perform various functions to support communication services. RAN 120 may include any number of Node Bs and any number of Radio Network Controllers (RNCs). For simplicity, only one Node B 130 and one RNC 132 are shown in FIG. 1. A Node B is generally a fixed station that communicates with the UEs and may also be referred to as an evolved Node B, a base station, an access point, etc. RNC 132 couples to a set of Node Bs and provides coordination and control for the Node Bs under its control.

[0026] An Internet Protocol (IP) gateway 140 supports data services for UEs and may also be referred to as a Serving GPRS Support Node/Gateway GPRS Support Node (SGSN /GGSN), an Access Gateway (AGW), a Packet Data Serving Node (PDSN), etc. IP gateway 140 may be responsible for establishment, maintenance, and termination of data sessions for UEs and may further assign dynamic IP addresses to the UEs. IP gateways 140 may couple to data network(s) 150, which may comprise a core network, the Internet, etc. IP gateway 140 may be able to communicate with various entities such as a server 160 via data network(s) 150. Wireless system 100 may include other network entities not shown in FIG. 1.

[0027] A UE 110 may communicate with RAN 120 to exchange data with other entities such as server 160. UE 110 may be stationary or mobile and may also be referred to as a mobile station, a terminal, a subscriber unit, a station, etc. UE 110 may be a cellular phone, a personal digital assistant (PDA), a wireless communication device, a wireless modem, a handheld device, a laptop computer, etc. UE 110 may communicate with Node B 120 via the downlink and uplink. The downlink (or forward link) refers to the communication link from the Node B to the UE, and the reverse link (or uplink) refers to the communication link from the UE to the Node B. The techniques described herein may be used for data transmission on the downlink as well as the uplink.

[0028] UE 110 may be coupled to a terminal equipment (TE) device 112 via a wireline connection (as shown in FIG. 1) or a wireless connection. UE 110 may be used to provide or support wireless data services for TE device 112. TE device 112 may be a laptop computer, a PDA, or some other computing device.

[0029] FIG. 2A shows example protocol stacks at various entities in FIG. 1 for communication between UE 110 and server 160 in UMTS. The protocol stack for each entity may include a transport layer, a network layer, a link layer, and a physical layer.

[0030] UE 110 or TE device 112 may communicate with server 160 using Transmission

Control Protocol (TCP), User Datagram Protocol (UDP), and/or other protocols at the transport layer. Transport layer data may be encapsulated in IP packets, which may be exchanged between UE 110 or TE device 112 and server 160 via RAN 120, IP gateway 140, and possibly other entities. The link layer between UE 110 and TE device 112 may be Ethernet or some other protocol. The link layer between UE 110 and RAN 120 is typically dependent on the radio technology used by the RAN. For UMTS, the link layer is implemented with Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC), which may be terminated at UE 110 and RAN 120. UE 110 further communicates with RAN 120 via an air-link interface (e.g., WCDMA) at the physical layer (PHY). RAN 120 may communicate with IP gateway 140 via a technology- dependent interface for the link and physical layers. IP gateway 140 may communicate with server 160 via IP over a link layer and a physical layer.

[0031] FIG. 2B shows example protocol stacks at various entities in FIG. 1 for communication between UE 110 and server 160 in cdma2000. UE 110 or TE device 112 may communicate with server 160 using TCP, UDP, and/or other protocols at the transport layer. Transport layer data may be encapsulated in IP packets, which may be exchanged between UE 110 or TE device 112 and server 160 via IP gateway 140 and possibly other entities. For cdma2000, the link layer is implemented with High-Level Data Link Control (HDLC) and Point-to-Point Protocol (PPP), Radio Link Protocol (RLP), and MAC. HDLC performs framing for PPP. PPP may be terminated at UE 110 and IP gateway 140 whereas RLP and MAC may be terminated at UE 110 and RAN 120. UE 110 further communicates with RAN 120 via an air-link interface (e.g., CDMA2000 IX or IxEV-DO) at the physical layer. RAN 120 may communicate with IP gateway 140 via a technology-dependent interface for the link and physical layers. IP gateway 140 may communicate with server 160 via IP over a link layer and a physical layer.

[0032] FIGS. 2A and 2B show exemplary protocol stacks for UMTS and cdma2000, respectively. Other systems may use other sets of protocols for the various layers in the protocol stacks.

[0033] In general, processing for each protocol is performed by a transmitter and a receiver for that protocol. The transmitter and receiver for each protocol may be located at the entities shown in FIGS. 2A and 2B. For clarity, much of the description below is for processing by UE 110, which may be a transmitter for all protocols for data transmission on the uplink and a receiver for all protocols for data transmission on the downlink.

[0034] FIG. 3A shows encapsulation of data by protocols in various layers at a transmitter for UMTS. In the description herein, a data unit for each protocol is referred to as a frame. A data unit may also be referred to as a packet, a protocol data unit (PDU), etc. A frame may include a header and a payload. The header may contain routing and other pertinent information for the frame and is shown with diagonal hashing in FIG. 3A. The payload may contain data being sent in the frame. The encapsulation shown in FIG. 3A may be performed by UE 110 for data transmission on the uplink or by server 160, IP gateway 140, and RAN 120 for data transmission on the downlink.

[0035] Data from one or more applications may be sent in TCP/UDP frames. Each

TCP/UDP frame includes a checksum that is computed across the header and the payload of that TCP/UDP frame. The checksum may be used by a receiver to detect for error in the TCP/UDP frame. Each TCP/UDP frame may be encapsulated in an IP frame. Each IP frame includes a checksum that is computed over only the header of that IP frame and is used to detect for routing error in the IP frame. Each IP frame may be processed by PDCP (e.g., for header compression) and mapped to one or more RLC frames. Each RLC frame includes a sequence number that indicates the position of that RLC frame in a stream of RLC frames. The sequence number may be used by the receiver to re-order RLC frames received out of sequence from the transmitter. Each RLC frame may be processed (e.g., ciphered), and one or more ciphered RLC frames may be mapped to a MAC frame. Each MAC frame may be processed (e.g., encoded) and mapped to one or more PHY frames. For UMTS, ciphering may be performed (i) on each RLC frame if UE 110 is operating in a non-transparent RLC mode or (ii) on each MAC frame if UE 110 is operating in a transparent RLC mode. For clarity, much of the description below assumes ciphering of RLC frames by RLC. [0036] FIG. 3B shows encapsulation of data by protocols in various layers at a transmitter for cdma2000. The encapsulation shown in FIG. 3B may be performed by UE 110 for data transmission on the uplink or by server 160, IP gateway 140, and RAN 120 for data transmission on the downlink.

[0037] Data from one or more applications may be sent in TCP/UDP frames. Each TCP/UDP frame may be encapsulated in an IP frame. Each IP frame may be processed by HDLC (e.g., for framing) to generate PPP frames, which may then be mapped to one or more RLP frames. The RLP frames may be processed (e.g., ciphered) and mapped to MAC frames, which may be processed (e.g., encoded) and mapped to PHY frames (not shown in FIG. 3B). For cdma2000, ciphering may be performed on each PPP frame or each RLP frame.

[0038] In general, the frames of a given protocol may or may not be aligned with the frames of a higher protocol and may or may not be aligned with the frames of a lower protocol. The header of each frame typically includes a length field that indicates the length of that frame.

[0039] FIG. 4 shows computation of a checksum for a TCP/UDP frame at a transmitter.

For checksum computation, a checksum field in the header of the TCP/UDP frame is replaced with zeros, and a pseudo header is pre-appended to the TCP/UDP frame. A register 414 is initialized to all zeros at the start of the checksum computation. A unit 410 partitions the TCP/UDP frame and the pseudo header into 16-bit words. For each 16-bit word, a unit 412 computes one's complement sum of the 16-bit word and a stored word from register 414 and provides the result back to the register. After all 16-bit words have been summed, a unit 416 provides the one's complement of the final result from register 414 as the checksum for the TCP/UDP frame. This checksum may replace the zeros in the checksum field of the header of the TCP/UDP frame.

[0040] A receiver may compute a checksum for each received TCP/UDP frame in the same manner as the transmitter, as shown in FIG. 4. The output of unit 416 will be all zeros if the checksum passes and non-zero if the checksum fails. Checksum verification at the receiver thus entails checking the computed checksum whereas checksum generation at the transmitter entails inserting the computed checksum in the header of the TCP/UDP frame.

[0041] As shown in FIG. 4, the checksum computation for a TCP/UDP frame is cumulative.

The checksum may be computed over different parts of the TCP/UDP frame in any order as long as the entire TCP/UDP frame is used to compute the checksum.

[0042] A checksum for an IP frame may be computed in the manner shown in FIG. 4.

However, the checksum for the IP frame is computed over only the header of the IP frame and not across the entire IP frame. [0043] A transmitter may cipher data to prevent unauthorized acquisition of data. A receiver may perform deciphering to recover the data sent by the transmitter. Ciphering is synonymous with encryption, and deciphering is synonymous with decryption.

[0044] FIG. 5A shows ciphering of an RLC frame at a transmitter, which may be UE 110 for uplink transmission or RNC 132 for downlink transmission in UMTS. A unit 510 receives a cipher key, a crypto-sync (Count-C), a bearer identifier, a direction bit, and a length indicator. The cipher key may be generated based on a user-specific secret key that is known to both UE 110 and a security center. The crypto-sync acts as a time -variant input for the ciphering algorithm and may include an RLC sequence number if ciphering is performed at RLC. The bearer identifier indicates the bearer of the data being ciphered. The direction bit is set to '0' for uplink transmission and to ' 1 ' for downlink transmission. The length indicator indicates the length of a random keystream to be generated by unit 510. Unit 510 generates a keystream of the desired length based on all of the inputs and in accordance with an f8 ciphering algorithm defined by 3GPP. An exclusive-OR gate 512 performs bit- wise modulo-2 addition of input data bits and the keystream bits from unit 510 and provides ciphered data bits for the RLC frame.

[0045] FIG. 5B shows deciphering at a receiver, which may be UE 110 for downlink transmission or RNC 132 for uplink transmission in UMTS. A unit 550 receives the cipher key, the crypto-sync, the bearer identifier, the direction bit, and the length indicator. Unit 550 generates a random keystream based on all of the inputs and in the same manner as unit 510 at the transmitter. An exclusive-OR gate 552 performs bit- wise modulo-2 addition of the ciphered data bits and the keystream bits from unit 550 and provides deciphered data bits for an RLC frame.

[0046] As shown in FIGS. 5A and 5B, ciphering and deciphering are bit-wise operations.

Ciphering and deciphering may be performed on different frames in any order as long as the proper keystreams are used for the input data bits and the ciphered data bits.

[0047] FIG. 6 shows a block diagram of an exemplary design of UE 110 and Node B 130 in

FIG. 1. In this exemplary design, UE 110 includes a data processor 610, an external memory 660, a radio transmitter (TMTR) 652, and a radio receiver (RCVR) 654. Data processor 610 includes a controller/processor 620, a transmit processor 630, a receive processor 640, and an internal memory 650. A bus 612 may facilitate data transfers between processors 620, 630 and 640 and memory 650. Data processor 610 may be implemented on an application specific integrated circuit (ASIC), and memory 660 may be external to the ASIC. [0048] For data transmission on the uplink, transmit processor 630 may process traffic data in accordance with a set of protocols and provide output data. Radio transmitter 652 may condition (e.g., convert to analog, filter, amplify, and frequency upconvert) the output data and generate an uplink signal, which may be transmitted to Node B 130. For data reception on the downlink, radio receiver 654 may condition (e.g., filter, amplify, frequency downconvert, and digitize) a downlink signal received from Node B 130 and provide received data. Receive processor 640 may process the received data in accordance with a set of protocols and provide traffic data. Controller/processor 620 may direct the operation of various units at UE 120. Internal memory 650 may store program codes and data for processors 620, 630 and 640. External memory 660 may provide bulk storage for data and program codes for UE 110.

[0049] FIG. 6 also shows a block diagram of an exemplary design of Node B 130. A radio transmitter/receiver 664 may support radio communication with UE 110 and other UEs. A controller/processor 670 may process data for data transmission on the downlink and data reception on the uplink. Controller/processor 670 may also perform various functions for communication with the UEs. Memory 672 may store data and program codes for Node B 130. A communication (Comm) unit 674 may support communication with other network entities.

[0050] FIG. 7 shows a block diagram of an exemplary design of a receiver 700, which may be part of UE 110 for downlink transmission. Receiver 700 includes a receive processor 710 that processes received PHY frames and an external memory 760 that provides bulk storage for data. Receive processor 710 may correspond to receive processor 640 in FIG. 6 and may be implemented on an ASIC. Memory 760 may correspond to memory 660 in FIG. 6 and may be external to the ASIC.

[0051] Within receive processor 710, a receive (RX) PHY processor 720 may receive PHY frames from a transmitter (e.g., Node B 130), process the received PHY frames in accordance with the radio technology (e.g., WCDMA) used by the RAN, and provide received MAC frames. A decoder 730 may decode the received MAC frames and provide decoded MAC frames to external memory 760. The transmitter may send MAC frames in sequential order and may send one or more transmissions for each MAC frame until the MAC frame is decoded correctly by the receiver. Because different numbers of transmissions may be sent for different MAC frames, the receiver may obtain decoded MAC frames out of order. The receiver may extract RLC frames from each decoded MAC frame, detect for missing RLC frames based on the sequence number included in each RLC frame, wait for missing RLC frames, and re-order the RLC frames in sequential order. [0052] A decipherer 740 may receive RLC frames in sequential order from external memory 760, decipher each RLC frame, and provide deciphered RLC frames back to external memory 760. The receiver may form IP frames based on the deciphered RLC frames and may extract TCP/UDP frames from the IP frames. A checksum computation unit 750 may receive TCP/UDP frames from external memory 760, compute the checksum for each TCP/UDP frame based on its header and payload, and provide the checksums for the TCP/UDP frames. Because the checksum for each TCP/UDP frame is computed over the entire TCP/UDP frame, unit 750 may receive each TCP/UDP frame in its entirely from external memory 760.

[0053] Other processing may also be performed for the received frames but not shown in

FIG. 7 for simplicity. In the exemplary design shown in FIG. 7, four memory accesses may be performed to write data to and read data from external memory 760. One memory access may be performed to write decoded MAC frames to external memory 760, two memory accesses may be performed for deciphering, and one memory access may be performed for checksum verification. These memory accesses may increase bus bandwidth and power consumption of receiver 700.

[0054] In an exemplary embodiment, deciphering may be performed on RLC frames obtained from decoded MAC frames, prior to re -ordering the RLC frames and prior to writing to the external memory. This deciphering scheme may save two memory accesses - one memory access to read decoded data from the external memory and another memory access to write deciphered data back to the external memory. Furthermore, deciphering may be performed on RLC frames as decoded MAC frames become available, without having to wait until the RLC frames are available in sequential order.

[0055] In another exemplary embodiment, checksum computation may be performed on deciphered RLC frames prior to writing data to the external memory. This may save one memory access to read TCP/UDP frames from the external memory for checksum computation. Partial checksums may be obtained for the deciphered RLC frames as these frames become available. A final checksum may be computed for each TCP/UDP frame based on the partial checksums for all deciphered RLC frames carrying that TCP/UDP frame.

[0056] FIG. 8 shows a block diagram of an exemplary design of a receiver 800, which may be part of UE 110 for downlink transmission. Receiver 800 includes a receive processor 810 (e.g., an ASIC) and an external memory 860. Receive processor 810 may correspond to receive processor 640 in FIG. 6 and may be implemented on an ASIC. Memory 860 may correspond to memory 660 in FIG. 6 and may be external to the ASIC.

[0057] Within receive processor 810, an RX PHY processor 820 may receive and process

PHY frames and provide received MAC frames. A decoder 830 may decode the received MAC frames and provide decoded MAC frames. A decipherer 840 may receive the decoded MAC frames, extract RLC frames from the decoded MAC frames, decipher each RLC frame, and provide deciphered RLC frames. Decipherer 840 may generate a proper keystream for each RLC frame based on applicable information such as a sequence number for that RLC frame. Decipherer 840 may perform deciphering on each MAC or RLC frame as it becomes available, without having to wait for the MAC or RLC frames to be available in sequential order. Decipherer 840 may be implemented as shown in FIG. 5B.

[0058] A checksum computation unit 850 may receive deciphered RLC frames from decipherer 840, compute partial checksums for the deciphered RLC frames, compute a checksum for the header of each IP frame, and provide the deciphered RLC frames to external memory 860. Because the checksum for each TCP/UDP frame is cumulative, unit 850 may compute a partial checksum for each part of a TCP/UDP frame when that part becomes available, without having to wait for the entire TCP/UDP frame to be available. In one exemplary design, unit 850 computes a partial checksum for each RLC frame. In one exemplary design, unit 850 stores partial checksums for RLC frames and checksums for IP headers locally in an internal memory 852 and thereafter computes a final checksum for each TCP/UDP frame based on the partial checksums for all RLC frames carrying that TCP/UDP frame and the checksum for the header of an IP packet carrying that TCP/UDP frame. In another exemplary design, unit 850 provides the partial checksums and the IP header checksums to another entity (e.g., software), which may compute the final checksum for each TCP/UDP frame.

[0059] FIG. 9 shows a block diagram of an exemplary design of a receiver 900, which may also be part of UE 110 for downlink transmission. Receiver 900 includes a receive processor 910 (e.g., an ASIC) and an external memory 960. Receive processor 910 may correspond to receive processor 640 in FIG. 6 and may be implemented on an ASIC. Memory 960 may correspond to memory 660 in FIG. 6 and may be external to the ASIC.

[0060] Within receive processor 910, an RX PHY processor 920 may receive and process

PHY frames and provide received MAC frames. A decoder 930 may decode the received MAC frames and provide decoded MAC frames to a decoder output buffer 940. Buffer 940 may be within receive processor 910 (as shown in FIG. 9) or may be external to receive processor 910 (e.g., may be part of internal memory 650 in FIG. 6).

[0061] A unit 950 may retrieve RLC frames encapsulated in the decoded MAC frames from buffer 940 and may decipher each RLC frame. Unit 950 may also compute a partial checksum for each deciphered RLC frame, compute a checksum for the header of each IP frame, store the partial checksums and IP header checksums locally in buffer 940, and provide the deciphered RLC frames to buffer 940 (as shown in FIG. 9) or to external memory 960 (not shown in FIG. 9). Unit 950 may compute a final checksum for each TCP/UDP frame based on the partial checksums for all RLC frames carrying that TCP/UDP frame and the checksum for the header of an IP packet carrying that TCP/UDP frame. Alternatively, unit 950 may provide the partial checksums and the IP header checksums to another entity, which may compute the final checksum for each TCP/UDP frame. The deciphered RLC frames from buffer 940 may be provided to external memory 960.

[0062] FIGS. 1OA and 1OB show an exemplary design for computing a checksum for a

TCP/UDP frame based on partial checksums. The TCP/UDP frame may be sent in the payload of an IP frame, and the IP frame may be sent in L RLC frames, where L may be any integer value, as shown in FIG. 1OB. A partial checksum may be obtained for each RLC frame when that RLC frame becomes available. A summer 1012 may compute a one's complement sum of the L partial checksums for the L RLC frames carrying the IP frame and may provide a checksum for the IP frame. A summer 1014 may subtract a checksum for the header of the IP frame from the checksum for the IP frame and provide a checksum for the TCP/UDP frame. The computation in FIG. 1OA may be performed by checksum computation unit 850 in FIG. 8, by checksum computation unit 950 in FIG. 9, by software or firmware, etc.

[0063] In the exemplary designs shown in FIGS. 8 and 9, the receiver may perform deciphering of data while it is present in the receive processor before writing the data to the external memory. This may avoid having to copy the data back and forth between the external memory and the receive processor for deciphering, as is the case in FIG. 7. Performing deciphering before writing the data to the external memory may reduce processing, bus bandwidth, and power consumption at the receiver.

[0064] In the exemplary designs shown in FIGS. 8 and 9, the receiver may compute partial checksums for TCP/UDP frames in lower layers before writing data to the external memory. The receiver may compute the partial checksums as part of lower layer processing while the data is present in the receive processor. In one exemplary design, the receiver may compute a final checksum for each TCP/UDP frame based on all partial checksums for that TCP/UDP frame and may pass the final checksum to TCP/UDP. In another exemplary design, the receiver may pass the partial checksums for each TCP/UDP frame to TCP/UDP, which may compute the final checksum for the TCP/UDP frame. The exemplary designs in FIGS. 8 and 9 avoid computation of entire checksums in TCP/UDP and avoid another transfer of data from the external memory to the receive processor in order to compute these checksums.

[0065] The exemplary designs in FIGS. 8 and 9 perform deciphering and checksum computation on data on the fly before writing the data to the external memory. Performing deciphering and checksum computation in this manner may reduce the number of data copies, bus bandwidth, and power consumption, all of which are desirable.

[0066] An RLC frame may be segmented into multiple partial RLC frames (or RLC segments), and a sequence number may be included in only the first partial RLC frame. The multiple partial RLC frames may be sent in multiple MAC frames, as shown in FIG. 3A. These multiple MAC frames may be decoded correctly after different numbers of transmissions and may thus be available at different times, which may be hundreds of milliseconds apart. For example, an RLC frame may be sent in two MAC frames 1 and 2, MAC frame 2 may be decoded correctly after one transmission, MAC frame 1 may be decoded correctly after multiple transmissions, and MAC frame 2 may be available much earlier than MAC frame 1. The RLC frame may be deciphered when all partial RLC frames have been received because the sequence number is present only in the first partial RLC frame.

[0067] To improve bus bandwidth efficiency, a partial RLC frame from a MAC frame decoded earlier may be stored in a low latency memory (e.g., buffer 940 in FIG. 9 or internal memory 650 in FIG. 6) that is within or close to the receive processor. There may be a large number of MAC frames with partial RLC frames, and a large low latency memory may be required to store all of the partial RLC frames in the worst case. Alternatively, these partial RLC frames may be stored in the high latency external memory in order to avoid storing them in the low latency memory. However, writing the partial RLC frames to the external memory and subsequently reading these partial RLC frames from the external memory may be expensive in terms of bus bandwidth and latency.

[0068] In another exemplary embodiment, a limited number of partial RLC frames may be stored in a low latency memory. The partial RLC frames may be processed as soon as complete RLC frames are available, without having to access the external memory. The number of RLC frames that can be stored in the low latency memory may be selected based on a tradeoff between memory size and bus usage and may be large enough to cover common scenarios. If the low latency memory becomes full, then additional partial RLC frames may be stored in the external memory. A relatively small low latency memory may be sufficient to cover many or most scenarios and may be implemented with relatively low cost. The unlikely scenarios in which the low latency memory runs out may be handled by writing the additional partial RLC frames to the external memory. This may then reduce bus bandwidth and power consumption at relatively low cost.

[0069] FIG. 11 shows a block diagram of an exemplary design of a receiver 1100, which may be part of UE 110 for downlink transmission in cdma2000. Receiver 1100 includes an external memory 1110 that provides bulk storage of data, a receive processor 1120 that processes received data, and an internal memory 1140 that stores processed data. Receive processor 1120 may correspond to receive processor 640 in FIG. 6, and internal memory 1140 may correspond to internal memory 650. Receive processor 1120 and internal memory 1140 may be implemented on an ASIC 1112. Memory 1110 may correspond to memory 660 in FIG. 6 and may be external to ASIC 1112.

[0070] Within receive processor 1120, an RX PHY processor 1122 may receive PHY frames from a transmitter (e.g., Node B 130), process the received PHY frames in accordance with the radio technology (e.g., CDMA2000 IX or IxEV-DO) used by the RAN, and provide received MAC frames. A MAC/RLP receiver 1124 may further process (e.g., decode and decipher) the received MAC frames and provide recovered RLP frames.

[0071] An HDLC deframer 1126 may receive the recovered RLP frames from MAC/RLP receiver 1124. Each recovered RLP frame may include a partial PPP frame, one complete PPP frame, or multiple partial/complete PPP frames. Each complete PPP frame may include (i) an HDLC flag octet indicating the start of an HDLC frame (ii) a PPP header, (iii) a payload carrying an IP frame and padding, and (iv) a frame check sequence (FCS) that may be used for error detection of the HDLC frame, and (v) an optional flag indicating the end of the HDLC frame. The flag indicates the start or end of an HDLC framed PPP frame and has a value of "0x7e". An FCS is also commonly referred to as a cyclic redundancy check (CRC).

[0072] HDLC deframer 1126 may process the recovered RLP frames and provide HDLC deframed PPP frames to internal memory 1140. PPP deframing may be performed in accordance with HDLC and may include the following tasks:

• Remove flag bytes ("0x7e") marking the start/end of HDLC frames,

• Remove escape bytes ("0x7d") encountered in HDLC frames and restore subsequent bytes that follow the escape bytes by XORing the subsequent bytes with "0x20",

• Check the FCS of each complete HDLC framed PPP frame, and • Perform byte alignment and write deframed PPP frames to internal memory 1140.

[0073] In another exemplary embodiment, HDLC deframing may be performed on recovered RLP frames, which may include partial PPP frames as shown in FIG. 3B, instead of waiting for complete PPP frames to be received. HDLC deframer 1126 may perform deframing on each recovered RLP frame provided by MAC/RLP receiver 1124 to obtain one or more partial and/or complete PPP frames, which may be stored in internal memory 1140. HDLC deframer 1126 may also compute partial FCS as each RLP frame is processed and may provide a final FCS once a complete PPP frame has been processed. Performing PPP deframing on recovered RLP frames (instead of waiting for complete PPP frames to be received) may save two memory accesses - one memory access to write the recovered RLP frames to internal memory 1140 after RLC processing is completed, and another memory access to read complete PPP frames from internal memory 1140 for HDLC deframing.

[0074] HDLC deframer 1126 may provide a predetermined number of beginning bytes of each PPP frame a controller/processor 1130. These beginning bytes of each PPP frame may include headers for an IP frame and a TCP/UDP frame encapsulated in that PPP frame. These beginning bytes may be stored in a fast tightly coupled (TC) memory 1132, which may be readily accessible to controller/processor 1130. Tightly coupled memory 1132 is a memory that is dedicated to controller/ processor 1130 and may have very low latency. A filter/routing accelerator 1134 may also receive the beginning bytes of each PPP frame from internal memory 1140 (as shown in FIG. 11) or from HDLC deframer 1126 (not shown in FIG. 11).

[0075] In another exemplary embodiment, controller/processor 1130 or accelerator 1134 may use the beginning/header bytes of each PPP frame to make routing decisions before sending out IP frames. For example, controller/processor 1130 or accelerator 1134 may determine whether to send an IP frame to external memory 1110, or to TE device 112 via an external port such as USB, or to some other device or another processor running an IP stack in the same device. A data mover 1136 may move the IP frame from internal memory 1140 to external memory 1110, or TE device 112, or another device, or another processor on the same device based on the routing decision. Writing the IP frame from internal memory 1140 directly to a recipient device may save two memory accesses - one memory access to write the IP frame from internal memory 1140 to external memory 1110 after PPP deframing and another memory access to write the IP frame from external memory 1140 to the recipient device after a routing decision is made. This mechanism may also avoid delaying copying of entire IP packet to external memory 1110 until the final destination of the IP packet can be determined.

[0076] In another exemplary embodiment, controller/processor 1130 or accelerator 1134 may perform filtering on IP frames and/or TCP/UDP frames still encapsulated in a PPP frame using the header information provided by HDLC deframer 1126. A filter template containing one or more filters may be defined. Each filter may include one or more parameters and a specific value for each parameter. Each parameter may correspond to a specific field of a header for IP, TCP, UDP or some other protocol. The parameters of a filter may include, for example, any one or any combination of the following fields:

• IPv4 - version, source IP address, destination IP address, address ranges, protocol, and type of service (TOS) fields;

• IPv6 - version, source IP address, destination IP address, address ranges, traffic class, flow label, and next header fields;

• UDP - source port, destination port, and port ranges;

• TCP - source port, destination port, and port ranges; and

• ICMPv4 and ICMPv6 - type and code values.

[0077] For example, a filter may be defined to detect for TCP frames for destination port x and sent in IPv4 packets. The filter may include three parameters that may be set as follows: version = IPv4, protocol = TCP, and destination port = x. In general, any field in any protocol header may be used as a filter parameter. Any number filters may be defined, and each filter may be associated with any set of parameters. Different filters may be defined for different applications, sockets, etc., and may be defined with different sets of parameters.

[0078] Each filter may also be associated with an action to perform if there is a match and an action to perform if there is no match. An action may relate to routing an IP frame to a specific recipient device, e.g., external memory 1110, TE device 112, or some other device. An action may also relate to other processing on an IP frame.

[0079] For filtering, the received values of an IP/TCP/UDP frame may be compared against the specified values for a filter. A match may be declared if the received values match the specified values, and a no match may be declared otherwise. A specified action may then be performed on the IP/TCP/UDP frame depending on the outcome of the comparison. For example, a filter may be defined to detect for IP frames destined for TE device 112. An IP frame may be sent to TE device 112 if there is a match for the filter and may be sent to external memory 1110 otherwise. [0080] For data transmission in UMTS, a transmitter may generate a header for each RLC frame and a header for each MAC frame. The transmitter may then read the payload for each RLC frame from the external memory into an internal memory and provide the header for the RLC frame to the internal memory. Similarly, the transmitter may read the payload for each MAC frame from the external memory into the internal memory and provide the header for the MAC frame to the internal memory. The transmitter may thus write the RLC and MAC headers individually to the internal memory per frame and may also retrieve data payload per frame from the external memory, which may be inefficient.

[0081] FIG. 12 shows a block diagram of an exemplary design of a transmitter 1200, which may be part of UE 110 for uplink transmission in UMTS. Transmitter 1200 includes an external memory 1210 that provides bulk storage of data, a transmit processor 1220 that processes data for transmission, and an internal memory 1230 that stores data for processing. Transmit processor 1220 may correspond to transmit processor 630 in FIG. 6 and internal memory 1230 may correspond to internal memory 650. Internal memory 1230 may also be referred to as an encoder input buffer. Transmit processor 1220 and internal memory 1230 may be implemented on an ASIC 1212. Memory 1210 may correspond to memory 660 in FIG. 6 and may be external to ASIC 1212.

[0082] In one exemplary design, transmit processor 1220 may process multiple (M) RLC frames to be encapsulated in one or more (N) MAC frames. A controller/ processor 1280 may generate M RLC headers Ri through R_M for the M RLC frames and N MAC headers Mi through M_N for the N MAC frames using a fast tightly coupled (TC) memory 1282. A data mover 1270 may move all of the RLC and MAC headers in one transaction from TC memory 1282 to internal memory 1230. Data mover 1270 may also retrieve a block of data for the payloads of the M RLC frames in a single transaction from external memory 1210 and may store the block of data in internal memory 1230. A transaction may be performed with a single command and may also be referred to as a burst. Controller/processor 1280 may provide commands to data mover 1270 to move the RLC and MAC headers from TC memory 1282 to internal memory 1230 and to retrieve the block of data from external memory 1210.

[0083] A copy engine 1260 may segment the block of data in internal memory 1230 into payloads for the M RLC frames and may attach each RLC header to its payload to form an RLC frame. Copy engine 1260 may also form MAC frames by attaching the header for each MAC frame to its payload, which may include one or more RLC frames. Copy engine 1260 may operate at a bit level to support arrangement with non-byte aligned headers or payloads. The RLC and MAC frames may thus be formed in internal memory 1230 by segmenting and shuffling the block of data and attaching the RLC and MAC headers to their payloads. Controller/processor 1280 may provide commands for assembling headers and payloads, and copy engine 1260 may perform the actual frame assembly. After the MAC frames have been formed, an encoder 1240 may encode each MAC frame and provide a corresponding encoded MAC frame. A transmit (TX) PHY processor 1250 may process the encoded MAC frames and provides PHY frames, which may be further processed to generate an uplink signal.

[0084] The exemplary design shown in FIG. 12 may provide certain advantages.

Generating the RLC and MAC headers in TC memory 1282 may reduce latency. Moving the RLC and MAC headers in one transaction from TC memory 1282 to internal memory 1230 may reduce programming overhead of data mover 1270. Moving a block of data for all RLC and MAC frames in one transaction from external memory 1210 to internal memory 1230 may improve bus efficiency.

[0085] The transmitter processing shown in FIG. 12 may also be used for uplink transmission in cdma2000.

[0086] FIG. 13 shows an exemplary design of a process 1300 for processing data at a receiver, which may be a UE for data transmission on the downlink or a Node B for data transmission on the uplink. The receiver may decode received frames to obtain decoded frames for a first protocol (e.g., MAC) in a protocol stack (block 1312). The receiver may obtain un-ordered ciphered frames for a second protocol (e.g., RLC or PDCP) in the protocol stack from the decoded frames (block 1314). The receiver may decipher the ciphered frames to obtain deciphered frames for the second protocol, with the ciphered frames not being re -ordered in sequential order prior to the deciphering (block 1316). The receiver may write the deciphered frames to an external memory (block 1318). The receiver may avoid writing the decoded frames and the ciphered frames to the external memory in order to reduce the number of external memory accesses.

[0087] In one exemplary design of block 1312, the receiver may receive at least one transmission for each received frame. The receiver may then decode each received frame based on all transmissions for that received frame. In one exemplary design of block 1316, the receiver may decipher the ciphered frames in each decoded frame when that decoded frame becomes available, without waiting for the ciphered frames to be available in sequential order. The receiver may extract the ciphered frames from the decoded frames, generate a keystream for each ciphered frame based on a sequence number for that ciphered frame, and decipher each ciphered frame based on its keystream to obtain a corresponding deciphered frame. The receiver may decipher each ciphered frame sent in multiple decoded frames whenever these decoded frames are available and may store partial ciphered frames in an internal memory. The receiver may store up to a predetermined number of partial ciphered frames in the internal memory and may store additional partial ciphered frames in the external memory.

[0088] FIG. 14 shows an exemplary design of a process 1400 for performing checksum computation by a receiver. The receiver may compute partial checksums for frames of a first protocol (e.g., RLC) below a second protocol (e.g., TCP or UDP) in a protocol stack (block 1412). The receiver may compute checksums for headers of frames of a third protocol (e.g., IP) in the protocol stack, with the third protocol residing between the first and second protocols (block 1414). The receiver may compute checksums for frames of the second protocol based on the partial checksums for the frames of the first protocol and the checksums for the headers of the frames of the third protocol, e.g., as shown in FIGS. 1OA and 1OB (block 1416). The receiver may write the frames of the first protocol to an external memory after computing the partial checksums. The receiver may compute the checksums for the frames of the second protocol without retrieving these frames from the external memory.

[0089] FIG. 15 shows an exemplary design of a process 1500 for performing deframing by a receiver. The receiver may obtain frames of a first protocol (e.g., RLP in cdma2000) in a protocol stack (block 1512) and may perform deframing on the frames of the first protocol to obtain frames of a second protocol (e.g., PPP) in the protocol stack (block 1514). Each frame of the first protocol may carry one or more partial and/or complete frames of the second protocol. The deframing may be performed on each frame of the first protocol without waiting for a complete frame of the second protocol to be received. The receiver may compute a partial FCS as each frame of the first protocol is deframed (block 1516). The receiver may provide a complete FCS for each frame of the second protocol when all frames of the first protocol carrying that frame of the second protocol have been deframed (block 1518).

[0090] For UMTS, the receiver may be part of a UE that supports a TE device (e.g., a laptop). In this case, the receiver may obtain frames of a first protocol (e.g., RLC in UMTS) in a protocol stack and may perform framing on the frames of the first protocol to obtain frames of a second protocol (e.g., PPP) in the protocol stack. The receiver may then send the frames of the second protocol to the TE device.

[0091] FIG. 16 shows an exemplary design of a process 1600 for performing routing by a receiver. The receiver may perform processing on frames of a first protocol (e.g., RLP) in a protocol stack to obtain frames of a second protocol (e.g., PPP) in the protocol stack (block 1612). The receiver may store payload of the frames of the second protocol to an internal memory (block 1614). The payload may comprise frames of at least one higher protocol (e.g., IP, TCP, UDP, etc.) in the protocol stack. The receiver may make routing decisions for the frames of the at least one higher protocol based on a beginning portion of the payload of the frames of the second protocol (block 1616). This beginning portion may comprise an IP header, a TCP header, a UDP header, and/or some other protocol header. The receiver may move the beginning portion to a fast tightly coupled memory (e.g., memory 1132 in FIG. 11), and may access the tightly coupled memory to make routing decisions for the frames of the at least one higher protocol. The receiver may write the frames of the at least one higher protocol from the internal memory to recipient devices based on the routing decisions (block 1618). The receiver may also perform filtering for the frames of the at least one higher protocol based on the beginning portion of the payload (block 1620).

[0092] FIG. 17 shows an exemplary design of a process 1700 for processing data at a transmitter, which may be a UE for data transmission on the uplink or a Node B for data transmission on the downlink. The transmitter may retrieve a block of data from an external memory in a single transaction and may store the block of data in an internal memory (block 1712). The block of data may be for multiple frames of a first protocol (e.g., RLC or MAC) in a protocol stack. The transmitter may generate multiple headers for the multiple frames of the first protocol (block 1714). The transmitter may then move the block of data and the multiple headers within the internal memory to obtain the multiple frames of the first protocol, with each frame comprising a header and a payload carrying a portion of the block of data (block 1716).

[0093] The transmitter may also generate at least one header for at least one frame of a second protocol (e.g., MAC) in the protocol stack (block 1718). The transmitter may move the multiple frames of the first protocol and the at least one header within the internal memory to obtain the at least one frame of the second protocol, with each frame of the second protocol comprising a header and a payload carrying at least one frame of the first protocol (block 1720). The transmitter may encode the at least one frame of the second protocol to obtain at least one encoded frame (block 1722).

[0094] In one exemplary design of blocks 1714 and 1718, the transmitter may generate the multiple headers for the first protocol and the at least one header for the second protocol in a fast tightly-coupled memory and may transfer these headers to the internal memory in a single transaction, e.g., as shown in FIG. 12. In another exemplary design, the transmitter may generate the headers in the internal memory. [0095] For clarity, certain aspects of the techniques have been described for specific protocols used in UMTS while other aspects have been described for specific protocols used in cdma2000. In general, the techniques described herein may be used for various sets of protocols utilized in various communication systems. For example, the techniques described specifically for UMTS (e.g., ciphering, checksum computation, and frame generation) may also be applicable for cdma2000 and other systems. Similarly, the techniques described specifically for cdma2000 (e.g., deframing and routing) may also be applicable for UMTS and other systems.

[0096] Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0097] Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0098] The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. [0099] The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[00100] In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[00101] The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

WHAT IS CLAIMED IS:

Claims

1. A method of processing data at a receiver, comprising: decoding received frames to obtain decoded frames for a first protocol in a protocol stack; obtaining un-ordered ciphered frames for a second protocol in the protocol stack from the decoded frames; and deciphering the ciphered frames to obtain deciphered frames for the second protocol, the ciphered frames not being re-ordered in sequential order prior to the deciphering.

2. The method of claim 1, the first protocol comprising Medium Access Control (MAC), and the second protocol comprising Radio Link Control (RLC) or Packet Data Convergence Protocol (PDCP).

3. The method of claim 1 , further comprising: writing the deciphered frames to an external memory; and avoiding writing the decoded frames and the ciphered frames to the external memory.

4. The method of claim 1, the decoding the received frames comprises receiving at least one transmission for each received frame, and decoding each received frame based on all transmissions for the received frame.

5. The method of claim 1, the deciphering the ciphered frames comprises deciphering ciphered frames in each decoded frame when the decoded frame becomes available, without waiting for the ciphered frames to be available in sequential order.

6. The method of claim 1, the deciphering the ciphered frames comprises generating a keystream for each ciphered frame based on a sequence number for the ciphered frame, and deciphering each ciphered frame based on the keystream for the ciphered frame to obtain the corresponding deciphered frame.

7. The method of claim 1, the deciphering the ciphered frames comprises deciphering each ciphered frame sent in multiple decoded frames when the multiple decoded frames are available.

8. The method of claim 1, further comprising: storing partial ciphered frames for the second protocol in an internal memory.

9. The method of claim 1, further comprising: storing up to a predetermined number of partial ciphered frames for the second protocol in an internal memory; and storing additional partial ciphered frames in an external memory.

10. The method of claim 1 , further comprising: computing partial checksums for the deciphered frames; and computing checksums for frames of a third protocol in the protocol stack based on the partial checksums for the deciphered frames.

11. An apparatus for communication, comprising: at least one processor to decode received frames to obtain decoded frames for a first protocol in a protocol stack, to obtain un-ordered ciphered frames for a second protocol in the protocol stack from the decoded frames, and to decipher the ciphered frames to obtain deciphered frames for the second protocol, the ciphered frames not being re-ordered in sequential order prior to the deciphering.

12. The apparatus of claim 11, the at least one processor writes the deciphered frames to an external memory and avoids writing the decoded frames and the ciphered frames to the external memory.

13. The apparatus of claim 11, the at least one processor generates a keystream for each ciphered frame based on a sequence number for the ciphered frame, and deciphers each ciphered frame based on the keystream for the ciphered frame to obtain the corresponding deciphered frame.

14. The apparatus of claim 11, the at least one processor stores partial ciphered frames in an internal memory and deciphers each ciphered frame sent in multiple decoded frames when the multiple decoded frames are available.

15. An apparatus for communication, comprising: means for decoding received frames to obtain decoded frames for a first protocol in a protocol stack; means for obtaining un-ordered ciphered frames for a second protocol in the protocol stack from the decoded frames; and means deciphering the ciphered frames to obtain deciphered frames for the second protocol, the ciphered frames not being re-ordered in sequential order prior to the deciphering.

16. The apparatus of claim 15, further comprising: means for writing the deciphered frames to an external memory; and means for avoiding writing the decoded frames and the ciphered frames to the external memory.

17. The apparatus of claim 15, the means for deciphering the ciphered frames comprises means for generating a keystream for each ciphered frame based on a sequence number for the ciphered frame, and means for deciphering each ciphered frame based on the keystream for the ciphered frame to obtain the corresponding deciphered frame.

18. The apparatus of claim 15, the further comprising: means for storing partial ciphered frames in an internal memory; and means for deciphering each ciphered frame sent in multiple decoded frames when the multiple decoded frames are available.

19. A computer program product, comprising : a computer-readable medium comprising: code for causing at least one computer to decode received frames to obtain decoded frames for a first protocol in a protocol stack, code for causing the at least one computer to obtain un-ordered ciphered frames for a second protocol in the protocol stack from the decoded frames, and code for causing the at least one computer to decipher the ciphered frames to obtain deciphered frames for the second protocol, the ciphered frames not being re-ordered in sequential order prior to the deciphering.

20. The computer program product of claim 19, the computer-readable medium further comprising: code for causing the at least one computer to generate a keystream for each ciphered frame based on a sequence number for the ciphered frame, and code for causing the at least one computer to decipher each ciphered frame based on the keystream for the ciphered frame to obtain the corresponding deciphered frame.

21. A method of processing data at a receiver, comprising: computing partial checksums for frames of a first protocol in a protocol stack; and computing checksums for frames of a second protocol in the protocol stack based on the partial checksums for the frames of the first protocol.

22. The method of claim 21, the first protocol comprising Radio Link Control (RLC) and the second protocol comprising Transmission Control Protocol (TCP) or User Datagram Protocol (UDP).

23. The method of claim 21 , further comprising : writing the frames of the first protocol to an external memory after computing the partial checksums; and computing the checksums for the frames of the second protocol without retrieving the frames from the external memory.

24. The method of claim 21 , further comprising: computing checksums for headers of frames of a third protocol in the protocol stack, the third protocol residing between the first and second protocols; and computing the checksums for the frames of the second protocol based further on the checksums for the headers of the frames of the third protocol.

25. The method of claim 24, the third protocol comprising Internet Protocol (IP).

26. The method of claim 24, the computing the checksums for the frames of the second protocol comprises, for each frame of the second protocol, identifying at least one frame of the first protocol carrying a frame of the third protocol carrying the frame of the second protocol, summing at least one partial checksum for the at least one frame of the first protocol to obtain an intermediate result, and subtracting a checksum for the header of the frame of the third protocol from the intermediate result to obtain a checksum for the frame of the second protocol.

27. An apparatus for communication, comprising: at least one processor to compute partial checksums for frames of a first protocol in a protocol stack, and to compute checksums for frames of a second protocol in the protocol stack based on the partial checksums for the frames of the first protocol.

28. The apparatus of claim 27, the at least one processor writes the frames of the first protocol to an external memory after computing the partial checksums, and computes the checksums for the frames of the second protocol without retrieving the frames from the external memory.

29. The apparatus of claim 27, the at least one processor compute checksums for headers of frames of a third protocol in the protocol stack, the third protocol residing between the first and second protocols, and compute the checksums for the frames of the second protocol based further on the checksums for the headers of the frames of the third protocol.

30. The apparatus of claim 29, the at least one processor identifies at least one frame of the first protocol carrying a frame of the third protocol carrying a frame of the second protocol, sums at least one partial checksum for the at least one frame of the first protocol to obtain an intermediate result, and subtracts a checksum for the header of the frame of the third protocol from the intermediate result to obtain a checksum for the frame of the second protocol.

31. A method of processing data at a receiver, comprising: obtaining frames of a first protocol in a protocol stack; and performing de framing on the frames of the first protocol to obtain frames of a second protocol in the protocol stack, each frame of the first protocol carrying one or more frames of the second protocol, the deframing being performed on each frame of the first protocol without waiting for a complete frame of the second protocol to be received.

32. The method of claim 31, the first protocol comprising Radio Link Protocol (RLP) and the second protocol comprising Point-to-Point Protocol (PPP).

33. The method of claim 31 , further comprising : computing a partial frame check sequence (FCS) as each frame of the first protocol is deframed; and providing a complete FCS for each frame of the second protocol when all frames of the first protocol carrying the frame of the second protocol have been deframed.

34. An apparatus for communication, comprising: at least one processor to obtain frames of a first protocol in a protocol stack, and to perform deframing on the frames of the first protocol to obtain frames of a second protocol in the protocol stack, each frame of the first protocol carrying one or more frames of the second protocol, the deframing being performed on each frame of the first protocol without waiting for a complete frame of the second protocol to be received.

35. The apparatus of claim 34, the first protocol comprising Radio Link Protocol (RLP) and the second protocol comprising Point-to-Point Protocol (PPP).

36. The apparatus of claim 34, the at least one processor computes a partial frame check sequence (FCS) as each frame of the first protocol is deframed, and provides a complete FCS for each frame of the second protocol when all frames of the first protocol carrying the frame of the second protocol have been deframed.

37. A method of processing data at a receiver, comprising: performing processing on frames of a first protocol in a protocol stack to obtain frames of a second protocol in the protocol stack; storing payload of the frames of the second protocol to an internal memory, the payload comprising frames of at least one higher protocol in the protocol stack; making routing decisions for the frames of the at least one higher protocol based on a beginning portion of the payload of the frames of the second protocol; and writing the frames of the at least one higher protocol from the internal memory to recipient devices based on the routing decisions.

38. The method of claim 37, the first protocol comprising Radio Link Protocol (RLP), the second protocol comprising Point-to-Point Protocol (PPP), and the at least one higher protocol comprising at least one of Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP).

39. The method of claim 37, the beginning portion of the payload comprising at least one of an IP header, a TCP header, and a UDP header.

40. The method of claim 37, further comprising: moving the beginning portion of the payload to a fast tightly coupled memory; and accessing the tightly coupled memory to make routing decisions for the frames of the at least one higher protocol.

41. The method of claim 37, further comprising: performing filtering for the frames of the at least one higher protocol based on the beginning portion of the payload.

42. An apparatus for communication, comprising: at least one processor to perform processing on frames of a first protocol in a protocol stack to obtain frames of a second protocol in the protocol stack, to store payload of the frames of the second protocol to an internal memory, the payload comprising frames of at least one higher protocol in the protocol stack, to make routing decisions for the frames of the at least one higher protocol based on a beginning portion of the payload of the frames of the second protocol, and to write the frames of the at least one higher protocol from the internal memory to recipient devices based on the routing decisions.

43. The apparatus of claim 42, the first protocol comprising Radio Link Protocol (RLP), the second protocol comprising Point-to-Point Protocol (PPP), and the at least one higher protocol comprising at least one of Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP).

44. The apparatus of claim 42, the beginning portion of the payload of the frames of the second protocol comprising at least one of an IP header, a TCP header, and a UDP header.

45. The apparatus of claim 42, the at least one processor moves the beginning portion of the payload of the frames of the second protocol to a fast tightly coupled memory, and accesses the tightly coupled memory to make routing decisions for the frames of the at least one higher protocol.

46. The apparatus of claim 42, the at least one processor performs filtering for the frames of the at least one higher protocol.

47. A method of transmitting data, comprising: retrieving a block of data from an external memory in a single transaction and storing the block of data in an internal memory, the block of data being for multiple frames of a first protocol in a protocol stack; generating multiple headers for the multiple frames of the first protocol; and moving the block of data and the multiple headers within the internal memory to obtain the multiple frames of the first protocol, each frame comprising a header and a payload carrying a portion of the block of data.

48. The method of claim 47, further comprising: generating at least one header for at least one frame of a second protocol in the protocol stack; and moving the multiple frames of the first protocol and the at least one header within the internal memory to obtain the at least one frame of the second protocol, each frame of the second protocol comprising a header and a payload carrying at least one frame of the first protocol.

49. The method of claim 48, the multiple headers and the at least one header being generated in a fast tightly coupled memory and transferred to the internal memory in a single transaction.

50. The method of claim 48, further comprising: encoding the at least one frame of the second protocol to obtain at least one encoded frame.

51. The method of claim 48, the first protocol comprising Radio Link Control (RLC) and the second protocol comprising Medium Access Control (MAC).

52. An apparatus for communication, comprising: at least one processor to retrieve a block of data from an external memory in a single transaction and store the block of data in an internal memory, the block of data being for multiple frames of a first protocol in a protocol stack, to generate multiple headers for the multiple frames of the first protocol, and to move the block of data and the multiple headers within the internal memory to obtain the multiple frames of the first protocol, each frame comprising a header and a payload carrying a portion of the block of data.

53. The apparatus of claim 52, the at least one processor generates at least one header for at least one frame of a second protocol in the protocol stack, and moves the multiple frames of the first protocol and the at least one header within the internal memory to obtain the at least one frame of the second protocol, each frame of the second protocol comprising a header and a payload carrying at least one frame of the first protocol.

54. The apparatus of claim 53, the at least one processor generates the multiple headers and the at least one header in a fast tightly coupled memory, and transfers the multiple headers and the at least one header from the fast tightly coupled memory to the internal memory in a single transaction.