A protocol stack in a wireless communication system, such as a universal mobile telecommunications system (UMTS) frequency division duplex (FDD) system, is a collection of inter-related system components. The protocol stack takes data, (application data or network data), re-formats and packetizes it for transmission over an air interface, and re-builds the data on the receive side of the air interface. The protocol stack is also responsible for control, configuration and maintenance of air interface parameters. For example, the protocol stack controls the parameters related to data rate, physical channel configuration, timing, in-sequence delivery of data, and the like.
As an example, the access stratum (AS) portion 100 of the UMTS FDD protocol stack is shown in FIG. 1. As shown in FIG. 1, the UMTS AS 100 includes radio resource control (RRC) 102, radio access bearer management (RABM)/packet data convergence protocol (PDCP) 104, broadcast/multicast control (BMC) 106, radio link control (RLC) 108 and medium access control (MAC) 110.
The RRC 102 performs initial cell selection and reselection (mobility), establishment, maintenance and release of RRC (signaling) connections with the UMTS terrestrial radio access network (UTRAN), establishment, maintenance and release of radio bearers, transport channels (TrCH) and physical channels, (i.e. configuration of the WTRU Layer 2 and Layer 1 based on UTRAN commands), including a control of high speed downlink packet access (HSDPA) and high speed uplink packet access (HSUPA) channels, and measurement reporting.
The RABM/PDCP 104 performs IP header compression in accordance with Internet Engineering Task Force (IETF) request for comments (RFC) 2507 and RFC 3095, lossless serving radio network controller (SRNC) relocation, management of NSAPI/packet data protocol (PDP) context mappings to radio access bearer (RAB) channels, including quality of service (QoS) management and RAB re-establishment, (i.e., RABM functions).
The BMC 106 performs delivery of cell broadcast messages to the non-access stratum (NAS) (i.e., upper layers), cell broadcast schedule evaluation, and configuration of cell broadcasting services (CBS) for discontinuous reception.
The RLC 108 performs translation of application data units, (i.e., service data units (SDUs)), between air interface efficient transport blocks, (i.e., protocol data units (PDUs)), in both the control and data planes, (i.e. segmentation and concatenation), network configurable retransmission, and ordered delivery of data units based on a specific mode, (i.e., an acknowledged mode (AM), unacknowledged mode (UM), and transparent mode (TM)).
The MAC 110 performs mapping of logical channels to transport channels, selecting the appropriate uplink transport format combinations based on instantaneous data rates within the WTRU, prioritization of transport channels within the WTRU, implementation of MAC-e/es protocols (HSUPA), and implementation of the MAC-hs protocols (HSPDA) including MAC-hs reordering queues, MAC-hs PDU multiplexing, or the like. Implementation of the MAC-e/es protocols includes processing of scheduling grants, buffer occupancy calculation, rate request mechanisms, transport formation combination (TFC) recovery and elimination, and MAC-e/es PDU construction.
A physical layer (PHY) 112 abstracts the specific implementation of the UMTS Layer 1 from the UMTS AS stack, allowing the stack to be easily ported to alternative UMTS Layer 1 implementations.
Conventional implementations of the protocol stack are all-software implementations running on standard processors and standard real-time operating systems. As wireless communication standards evolve to support ever higher data rates, the requirements placed on the protocol stack software increase. With the emergence of high data rate services, (such as HSDPA, HSUPA, mobile broadcast multicast services (MBMS)), implementation of the protocol stack in software on standard processors will require a significant amount of computing power. The power requirements of such standard processors become a prohibitive drain on the power consumption of the battery-powered devices and are not viable. Accordingly, it would be desirable to seek alternatives to implementation of the protocol stack.