Design and Implementation of the HiperLan/2 Protocol

Transcription

1 Design and Implementation of the HiperLan/2 Protocol E. P. Vasilakopoulou a G.E. Karastergios b G.D. Papadopoulos a aapplied Electronics Laboratory, Department of Electrical and Computer Engineering University of Patras, Campus of Rio, Patras 26500, Greece bindustrial Systems Institude, University Campus of Rio, Patras 26500, Greece In recent years, wireless communication systems have experienced an enormous development, leading to the emergence of various wireless networks standards. These standards are characterized by different properties, such as their coverage, data rates, mobility and QoS support. Among them the HiperLan/2 standard is distinguished of its performance, supporting the provision of high-speed integrated services. Its centralized Medium Access Control protocol though is the most critical and complex functional entity, enabling the management of the air-interface in real time and the efficient allocation of the bandwidth resources to the users. In this paper we will present the architecture and implementation of the HiperLan/2 MAC protocol, placing special emphasis on its timing requirements that define the hardware~software partitioning scheme of the developed system. The proposed architecture relieves the network upper layers of processing time critical events, enforcing the emergence of HiperLan/2 commercial products. I. Introduction Wireless networking is a rapidly emerging technology that allows its users to maintain connectivity to their offices and homes, while being mobile. Two major factors have influenced this fact. The first is the advances in the fields of digital communications and semiconductor technology, while the second is the explosive growth and usage of the Internet. Moreover, as home appliances and consumer electronics devices are becoming more intelligent, with built-in computing and communication capabilities, an increasing demand for the development of wireless home networks is placed. The main concept behind home networks is the provision of an infrastructure that will enable the connection of several PCs, the resource sharing between them as well as the connection of the electronic devices to the PC and the Internet, avoiding the need of installing extra cabling. However, many difficulties should be overcome, such as the limitations of the air interface, to make wireless home networks a reality. Considerable research and standardization efforts have been dedicated to form the appropriate network protocols and transmission techniques to face these problems, providing interoperability to the existing communication networks. A first standard, dedicated to wireless home networking, was proposed by the HomeRF group in early HomeRF focused on the development of a protocol in the 2.4 GHz band supporting data rates up to 2 Mbps using a hybrid TDMA/CSMA mechanism [1]. Although HomeRF is simple and can easily be implemented with low cost, it faces major difficulties when connected to the existing wired networks. Moreover, the protocols used, seem to neglect the effect of multipath interference in indoor environments, significantly increasing the frame error rates that degrades the overall performance of the home network [2]. Another, very active industry consortium is the Bluetooth consortium, funded in The Bluetooth standard however, aims at providing cheap and quick solutions to eliminate the use of interconnection cables and connect one device to another using a universal radio link in the 2.4 GHz band [3]. Therefore it can not be used to provide high-speed integrated services to the user. On the other hand, the demand for broadband, high-speed services, lead to a second generation for wireless local area (WLAN) standards in the 5 GHz band. These standards support data rates up to 54 Mbps and can be applied to indoor environments, such as offices, homes, exhibition halls, airports, etc. Presently, two such standards are competing, the IEEE la and the ETSI HiperLan/2. The IEEE a standard is derived form the most popular WLAN standard, the b, sharing the same medium access mechanisms. Although the la standard quickly gained a lot of interest due to its simplicity, it seems that it has 20 Mobile Computing and Communications Review, Volume 7, Number 2

2 been optimized for data communications, placing little emphasis on the transfer of multimedia applications to the user. Time-bounded traffic, such as voice or video, served by the a PCF (Point Coordination Function) medium access mechanism has been shown that it can not be handled efficiently due to the overhead imposed in the transmitted frame [4]. Combing multiple voice packets in a frame is even worse, introducing additional latency to the communication [5], [6]. Examining the latter medium access mechanism, the DCF (Distributed Coordination Function) with or without the RTS/CTS scheme, it has been proven that as the number of stations in the network increases, the performance of the is degraded due to the reduction of the successfully transmitted packets as well as the increase of the transmission latency [4], [7], [8]. Furthermore la faces a major problem with real-time data, since it doesn't support any QoS features. To solve this problem, the IEEE organization at the moment is in the process of adding such features to the standard. The HiperLan/2 standard on the other hand, has higher performance than it's major opponent a, supporting multimedia applications while it provides high quality services to the user as well as better utilization of the air interface [8]. In advance, it has the ability to interface with multiple protocols, allowing the potential for the deployment of a fully integrated network. These characteristics of the HiperLan/2 standard make it suitable for a wireless home network. However, the high complexity of the proposed protocols suspend the emergence of HiperLan/2 commercial products, posing a main obstacle for the wide spread of the standard. The most attractive but most complicated at the same time, is the medium access control (MAC) protocol within the data link control layer (DLC) of the HiperLan/2 standard [9]. The MAC protocol performs centralized control, supporting operation in a connection-oriented manner. QoS features are used to monitor the link quality of each channel providing the ability to alter the modulation scheme based on the measured link quality. So, it is apparent that not only the implementation of the HiperLard2 MAC protocol is of great importance but it is also very challenging. In this paper, we will present the architecture and the implementation of the HiperLan/2 MAC protocol that was accomplished during the development of a HiperLan/2 prototype. The proposed architecture relieves the network upper layers of processing time critical events, enabling the management of the air-interface in real-time while it enables as well the implementation of a complete HiperLan/2 system. II. The HiperLan/2 MAC Protocol The HiperLan/2 MAC protocol is based on a TDMA/TDD (Time Division Multiple Access~Time Division Duplex) scheme that is centralized to an access point (AP) station [9]. Centrally controlled means that the AP schedules and controls the transmissions of all the associated mobile terminals (MTs) over the air interface. More information regarding the procedures followed during association can be found in [10]. The basic structure of a frame, generated by the MAC, has a fixed duration of 2 msec, is divided into time slots of 400 nsec and is depicted in Figure 1. Each frame comprises of several phases that dynamically adapt to the traffic situation. The broadcast phase consists of three fields that are used for broadcast control, frame control and access feedback control. The broadcast control channel (BCH) has a fixed length of 15 bytes (12 bytes payload and 3 bytes CRC') and is used by the AP to announce the structure of the frame, specifying the radio parameters. The cyclic redundancy check (CRC) bytes are used to detect transmission errors. The frame control channel (FCH) is organized into information blocks of 27 bytes (24 bytes payload and 3 bytes CRC) and contains the resource allocations to the MTs for the current MAC frame, while the access feedback channel (ACH) transfers the acknowledge map for the contention phase of the previous frame. The downlink phase (DL) carries user data and control information from an AP to an MT. As shown in Figure 1, a DLC user connection can be served using two types of packets. The short packets (Short Channels, SCH's) have a fixed size of 9 bytes (7 bytes payload and 2 bytes CRC) and convey control information produced either by the DLC or the radio link control layer (RLC). The long packets (Long Channels, LCH's) on the other hand, have a size of 54 byte (51 bytes payload and 3 bytes CRC) and contain control information and user data. Traffic from several MTs connections can be multiplexed into one protocol data unit (PDU) train that is used by the physical layer to form a physical burst, as can be seen in Figure 1 [11]. Mobile Computing and Communications Review, Volume 7, Number 2 21

3 2 msec i Direct Link Broadcast Phase ~ I ~ Downlink Phase _ ipha~l ]~BCHI FCH ] ACIJ I - I ]DL -] 5iI~ V ~S~eeeISCH] LCH ]eeel LCH I SCHI''" One DLC User Connection A PDU Train Uplink Phase Randon~l Access., Phase. ul -I c.:l Figure 1: The HiperLan/2 Frame Structure. The inclusion of a direct link phase (DiL) in a frame is optional and it is used to enable direct communication between the MTs in the network without the intervention of the AP. Following the DiL phase is the uplink phase (UL). As in the case of the downlink phase, during the uplink phase control and user data are transferred from the MTs to an AP based on the scheduled resources. Once more the communication is being carried out using the LCH and the SCH packets. Finally the random access phase (RCH) is a contention period, where all MTs to which no resources have been granted in the UL phase, can content to transmit their resource requests (RRs) to the AP for upcoming frames. The RCH phases is also used during the association of an MT to an AP or during handover where the active connections are switched to a new AP. Collisions in this phase are detected and are reported in the ACH field of the next frame. To support QoS features the HiperLan/2 MAC protocol enables the dynamic selection of the communication parameters by the AP so as to fulfill the demands of the MTs established connections. The access point can regularly poll the status of the MTs traffic queues and taking in account the status of its own queues, it determines how much data and control signaling is going to be used in the current MAC frame, setting the boundaries of each frame phase as well as selecting the physical mode and the number of SCHs and LCHs for the serviced connections. In this way, real-time traffic can be serviced very quickly and efficiently. The MAC frame format is a little different when multiple sectored antennas are supported in order to reduce interference in the network. The HiperLan/2 MAC protocol supports up to eight sectors. Closely examining the HiperLan/2 MAC frame, it can be seen that the frame is similar to ATM cells using 54 bytes PDUs with a payload of 49.5 bytes. Since the frame size is small, HiperLard2 is best suited for transferring digitized voice packets. In addition, a variety of data rates are supported, ranging from 6 Mbps up to 54 Mbps. In a study that was conducted by A. Doufexi et al. and Telia Research [8] the HiperLan/2 performance has been examined under varying data rates, calculating its throughput. Owing to the fixed frame size of the HiperLard2, incoming data is segmented so as to fit in. Transmitting at the highest data rate of 54 Mbps, the research has shown that a maximum throughput of approximately 42 Mbps, while at the lowest data rate of 6Mbps a throughput of 5 Mbps can be achieved. Comparing these results to those presented for an la network [8], we realize that the HiperLan/2 MAC protocol is more efficient supporting greater throughput. On the other hand, the HiperLan/2 MAC protocol was built having multimedia applications in mind, thus supporting a variety of QoS features. For that reason, HiperLan/2 is the best choice for supporting real-time data applications. III. Design Methodology The design and implementation of the HiperLan/2 MAC protocol that imposes the management of the air-interface in real-time with an accuracy of submicroseconds, poses challenges in performance estimation, functionality mapping into hardware or software as well as verification of the developed systems. The proposed architecture that will be analyzed in more detail in the following paragraphs must fulfill the requirements of real-time systems for accuracy and calculation of not only correct results but within prescribed time constraints. An efficient methodology that could be used for the implementation of the MAC protocol could be based on the synthesis of digital circuits using a behavioral model of the system. However, due to the high complexity of the system reflecting to an increased number of gates, the use of semi-custom or custom technologies is required. Therefore, such a solution could not be employed since the overall cost as well as the design turn around time increases significantly. On the other hand, the prototype could be designed by creating software programs that run on a processor using a general purpose programming language. Although in this scheme the development time decreases, the timing constraints imposed by the MAC protocol can not be met. However, from practical experience we can say that all cost-effective designs use a combination of hardware and software [12]. The partitioning of the 22 Mobile Computing and Communications Review, Volume 7, Number 2

4 MAC protocol functionalities into hardware and software modules obviously determines the delay of execution. Therefore, the overall system performance and efficiency is directly affected by the latency of the communication between the hardware and the software processes as well as the utilization of the processor that is used. Thus a good partitioning scheme for the implementation of the HiperLan/2 MAC protocol, must attempt to compromise the trade-offs between hardware and software implementation of an operation. In our approach, the hardware-software partitioning was based on the requirements for the timing performance of the system. The implementation of all time-critical events was assigned to hardware whereas all other operations were assigned to software. However due to the serial execution of the software modules, a data transfer between hardware and software must be synchronized. Using a polling scheme the software can be designed to perform all data transfers based on the hardware's data requirements. In this case a static scheduling of the hardware is required that unfortunately doesn't support the dynamic nature of the HiperLan/2 MAC protocol. In order to accommodate the different data rates that are supported, and due to the execution of timebounded operations, we incorporated a dynamic scheduling based on the availability of data. The employed mechanism will be further analyzed in upcoming paragraphs. Based on the discussion about the HiperLan/2 MAC protocol and the design methodology, we elaborate further on the proposed architecture that fulfils the imposed strict timing constraints. IV. The MAC Protocol Architecture - Requirements and Analysis The medium access control functional entity of the HiperLan/2 standard comprises the most timecritical and complex unit of the data link control layer, DLC, affecting the performance of a HiperLan/2 system. Having the ability of handling a large number of connections of a large number of mobile terminals with different QoS features, the implementation of the MAC protocol requires the use of a powerful processor and intelligent hardware. Some of the main operations performed by the MAC protocol are the scheduling of resources with respect to the requests sent by the MTs, the frame construction, the synchronization of all terminals in the network to the supervising AP, the calculation of the CRC bytes, corresponding to the transmitted PDUs, the error check of the received packets via the CRC mechanism, the discarding of the error received data and the management of the air interface in real-time. To assign the execution of these operations in hardware or software, the timecritical tasks as well as the tasks requiring high processing power, must be identified. The processing of each field type of the MAC frame is one of the most demanding tasks. The calculation of the corresponding CRC bytes (as well as their check during the uplink phase) is performed in a bitby-bit basis making inefficient their implementation with software. Moreover these tasks must be accomplished very fast since a failure of the system to provide valid data packets to the baseband processor at the specified by the AP time instants, will result in the de-synchronization of the terminals in the network. On the other hand, the CRC check and the discarding of the error received packets must be completed very fast in order to facilitate the operation of the error control functional entity of the data link control layer [9]. Therefore the implementation of these tasks in hardware is imperative. Another time-critical task is the generation of the ACH field of a frame by an AP. As we have seen in the presentation of the HiperLan/2 frame structure, the ACH PDU contains the acknowledgements to the contention channels of the RCH phase of the previous frame. Since there is a little time interval between the RCH phase of the previous frame and the ACH field of the next frame (the minimum time is 20 usec) and having in mind that the granularity of frames must be preserved, the only efficient option is to implement this task in hardware. Finally, to achieve the desired operation of the HiperLan/2 standard, all terminals must be synchronized to the AP performing the transmission and reception of data packets at the predefined slots with an accuracy of sub-microseconds. Since there is no processor that can ensure the terminal's.synchronization and the management of the air interface at specific time instants with an accuracy of sub-microseconds, these operations must be implemented using hardware structures. All the other operations of the HiperLan/2 MAC protocol, such as the scheduling of resources in a frame and handling of the connection lists, are implemented using software functions that run on a general purpose processor. Taking in mind the Mobile Computing and Communications Review, Volume 7, Number 2 23

5 above discussed requirements, we depict in Figure 2 the proposed architecture that has been used for the implementation of the HiperLan/2 MAC protocol. Except from the MAC protocol functional blocks their communication with the other layers and functional entities of the HiperLan/2 standard is also shown. Figure 2: The MAC Protocol Architecture Every time a new connection with varying QoS features is established between an MT and an AP, a DLC connection identifier (DLCC-ID) is allocated by the AP. Since several MT's connections are supported a large number of such identifiers can be used, each one of them corresponding to one priority. To simplify the implementation of the prototype we defined the use of two priorities, one for delay sensitive applications and one for error sensitive applications. So the maximum number of MT connections that the system supports is equal to two, although the maximum number of MT's connections defined at the HiperLan/2 standard can be supported with minor modifications of the software module. The parameters of all the established connections, such as their identifiers, the requested and allocated system resources, the physical mode and the coding rate, are stored in a traffic table maintained in the AP (Figure 2). The traffic table structure uses for each MT, two registrations for every direction of the frame (downlink and uplink) corresponding to the different priorities. Moreover for every connection, some memory cells are reserved to store the data packets to be transmitted, produced by the upper layers, or the received packets, from the physical layer. These memory cells are referred as connection lists and are unique for each MT. Two connection lists are created for every direction, one for the SCH PDUs and one for the LCH PDUs of a coonection. The main module that is responsible for servicing the MTs requests satisfying the demands for QoS that have been set during a connection establishment is the scheduler module. The scheduler determines the distribution of the resources of the air interface in every frame. It is apparent that two such scheduler structures were developed, one for an AP and one for an MT. The scheduler that runs on an AP, according to the pending resource requests of the MTs, the agreed QoS features of every connection, contained in the traffic table, and the status of its own data queues as well as the MTs data queues, generates the allocation map of a frame. Following the extraction of the allocation map, a quick sort algorithm is used to sort the resource grants based on their execution time in the frame. With the completion of this step the software module produces and stores the broadcast control data, leaving the calculation of the CRC bytes of all the fields to the frame processor hardware module. On the other hand, an MT scheduler is simpler compared to an AP scheduler. The main task, performed by the MT scheduler in close cooperation with its own traffic table, is the mapping of the new requests with respect to the resource grants announced during the broadcast phase of the frame. When the scheduler of an AP or an MT completes its tasks, the software module generates a new list that contains the initial memory addresses of the connection list that will be serviced in the current frame. This list is updated dynamically by the software and the way of its generation is shown in Figure 3. The most challenging part in the MAC protocol architecture is the design of the frame processor hardware module that performs all the time-critical tasks, discussed above, lowering the computation effort of the software module. Although this is not a MAC related function, the frame processor interfaces to the software and the baseband processor of the physical layer, setting the rules for their communication. The design and implementation of this module will be analyzed in more detail in the next paragraph. 24 Mobile Computing and Communications Review, Volume 7, Number 2

6 ! ~7"oadcast... Phase Connection Lists Downlink Phase Uplink Phase "; II~ /'t Connection Address List [.., / N / \ / N / N 22""2222 zl - O O O O O O O O O O O "5 5"5 5 5"5 5'5 5"5 5' Figure 3: Generation of the Connection Address List. To achieve an efficient communication of the hardware and the software module an interface must be developed supporting data transfers and the management of the system. The selection of the host interface was based on the demand for dynamic scheduling of the system resources with respect to the data availability. Therefore in the developed prototype, we used an I/O port that is connected on one of the available computer ports. Several such I/O ports were examined on behalf of their throughput and their ability to support parallel processing of events, resulting to the use of an I/O port provided by AMCC that is based on the 32-bit $5933 PCI controller [13]. This controller is a powerful, interrupt-driven PCI controller that supports bus mastering capabilities on the PCI bus, providing data transfer rates up to 132 Mbytes/sec. However, since the I/O port cannot be directly accessed by the operating system, a standard API (Application Programming Interface) must be used. Therefore, a software device driver function has also been developed that aims at managing the I/O port and servicing its requests (interrupts). V. The Frame Processor Architectural Concepts Following the discussion about the HiperLan/2 MAC Protocol and its architecture, we will now focus on the development of the Frame Processor. Except from interfacing to the other components of the HiperLan/2 prototype, the frame processor undertakes the management of the air-interface in real-time, the generation of the acknowledge map to the contention phase of the previous frame, the terminals synchronization in the network and the processing of each field type that is either transmitted or received. To ensure the execution of the MAC operations in the time instants, specified by the scheduler, enabling the management of the air-interface in realtime and the synchronization of all terminals, we propose the use of some time descriptor elements (TEDs) to determine the execution time of an event and the operations that must be conducted. The format of these descriptors is d.epicted in the figure below. The Tx/Rx field indicates a transmit or receive process, the PDU type defines the type of a PDU train, the physical (PHY) mode determines the modulation scheme and the coding rate used, the sector-id refers to the antenna sector number that is enabled, the slot number refers to the execution time of the descriptor and finally the byte number defines the amount of bytes that are going to be exchanged between the upper network layers and the physical layer, through the host's PCI bus l I # of bytes to be Execution Slot Sector ID PHY I PDU Tx/ transf%red Number (Opt ona ) Mode [ Type Rx Figure 4: The Time Descriptor Elements Format. The generation of the descriptors is conducted by parsing the broadcast control data of a frame. In case of an MT, only the correctly received resource grants to the MAC-ID (MAC Identbqcation) it owns in the network result in the generation of a descriptor. Since broadcast data are placed in the beginning of a frame, all the calculated descriptors must be stored in a queue, which enforces the policy we discussed in the design methodology section for a dynamic scheduling scheme of the hardware/software resources. The depth of the descriptor queue for a single antenna sector system is equal to the maximum number of descriptors in a frame, which is: Mobile Computing and Communications Review, Volume 7, Number 2 25

7 1 TED (for the FCHfield) + 1 TED (for the RCH field) + 24(number of ]13 of the FCH field) x 3 (number of le of an IB) x 2 TED (one for the SCH PDUs and one the LCH PDUs of a user connection) = 98 TED. Therefore, the selected depth of the queue is 38-bit x 128 that is equal to 608 memory bytes. To initiate a data transfer, the slot number of a descriptor must match the current slot of a frame. To achieve this comparison as well as to synchronize the MTs to an AP we used a timer that is initialized when a BCH preamble is detected. The timer advances synchronously to the baseband's 40MHz clock, counting a time interval of 400 nsec that is equal to the duration of a time slot, as defined in the HiperLard2 standard [9]. Another time-critical task that the Frame Processor must implement is the generation of the ACH field of the next frame in response to the previously received RCH channels. Although a time gap could be used between frames to enable the generation of the RCH acknowledgements by the DLC software, in the developed prototype we preferred the frame processor to perform this task, in order to meet this strict timing constraint without the insertion of time gaps, preserving concurrently the frame granularity. Since the frame processor checks all the packets received from the physical layer, this task can easily be achieved. The concept is that in case a collision happens in an RCH channel, the CRC check of the received packet will fail; setting the appropriate bit of a 32-bit register that contains the acknowledgement map for the MTs. Thus not only the DLC software is relieved from the execution of this task, but quick computation of the ACH field is also performed. To enable parallelism on the execution of hardware and software tasks as well as to compensate the latencies introduced by the PCI bus and the baseband module, the frame processor uses data queues on each channel (downlink or uplink) to temporally store the processed packets corresponding to the MTs connections that are serviced in the current frame. The selection of the number of memory bytes that is used is very crucial, since the hardware has limited capabilities to support on-board memory. Another important issue is the management scheme of the data queues that must ensure the availability of data at the specified, by the scheduler, time instants and must avoid the overloading of the queues that will result to the rejection of the incoming packets. During the downlink period of a frame the appropriate data fields, stored in the connection lists maintained by the software, are transferred via the PCI bus, to the hardware where the calculation of their CRC bytes is performed. To meet the timing constraints of the frame the above mentioned process must be completed very fast, otherwise no valid data will be available in the transmit queue, to forward to the physical layer. Having in mind the ability of the PCI bus to achieve data rates up to 132 Mbytes/sec as well as the ability of the I/O port to perform direct memory accesses, our approach is based on the serial execution of the descriptor elements with respect to the status of the data queues. Since the physical layer performs its tasks much slower, using this scenario the transmit queue will always contain valid PDUs at least for the next connection to be serviced in the frame. Although, this scheme ensures the availability of data for the transmit direction, the fields of the descriptor elements related to the control of the air interface, such as the execution slot number, the physical mode, etc. are not available. To overcome this problem, the transmit queue is partitioned into control and data sections. To distinguish each section an indication bit is used. A control section t-- ~.i~-'~ ~ -. ~O L ~ ~ ~ oo -, " i. ~ ~ ~ ~ ~ ["-' 1: Control Section 2: Data Section 3: Section Identifier Figure 5: The Transmit Queue Structure. 26 Mobile Computing and Communications Review, Volume 7, Number 2

8 comprises of some of the fields of the descriptor element that has just been retrieved from the descriptor queue and is going to be executed. These fields contain the required information to manage the air interface for transferring the packets of a connection and are always stored in the transmit queue, prior to the corresponding processed PDUs, as shown in Figure 5. On the other hand, during the uplink period of a frame the received packets must be checked, transferring only the correct ones to the DLC software by initializing properly the I/O port to perform a direct memory write process. In this way, not only the system resources are saved but the operation of the automatic repeat request, ARQ, protocol implemented in software, is facilitated and accelerated. The main concept for handling the received packets by the baseband processor is based on the storage of all incoming PDUs in an enhanced dual port memory that has the ability of retrieving the initial address where the first byte of a PDU was written. The condition that triggers the loading of the initial memory address is determined by the result of the CRC error check. Figure 6 depicts the hardware implementation of this concept. As can be seen in Figure 6 when a new 32-bit word is constructed from the received bytes, a write enable signal is asserted to the dual port RAM. Concurrently, the write address is latched. All upcoming write processes, corresponding to the same PDU, do not affect the content of the D-latch, enabling the count-up of the write address register. As soon as the end of a PDU is detected, the level of the signal indicating the result of the CRC check is sampled. In case of an error, the write address multiplexer loads to the write register the content of the D-latch. Therefore the first 32-bit word of the next PDU will overwrite the first 32-bit word of the previous PDU, performing the discarding of the error received PDU. The frame processor of an access point and a mobile terminal has been implemented using the Field Programmable Gate Array (FPGA) technology that eases the development of a prototype and significantly reduces the design turn-around time. A Xilinx Virtex FPGA (XCV800-6-HQ240) was selected due to its high performance feature sets including the support of robust memory resources, implemented using either Block RAM cells or distributed RAM cells [14]. In the next paragraphs a more detailed analysis of the operations and the architecture of the frame processor of an access point and a mobile terminal will be presented. ~ 32-Bit UL Data Dual Port RAM I 8-Bit n c Write Enable Recmve a t Clock _ PDU End~ J~.~LL~J CRC Error g, t J Figure 6: The Management of the Uplink PDUs. VI.The Frame Processor Architecture for an Access Point The frame processor of an AP to perform its timecritical tasks communicates with the software scheduler through the host interface that consists of the $5933 PCI controller, so as to be informed about the time plan of a frame, as can be seen in Figure 2. To simplify the development of the software device driver as well as to reduce communication latencies, the number of message and data exchanges between the hardware and the software modules must be minimized as much as possible. To satisfy this requirement, we developed a DLC-MAC protocol that utilizes the capabilities of the $5933 PC! controller and the organization of the software module. To initiate the transfer of a new frame, the frame processor must be aware of the broadcast data, generated by the scheduler. Moreover in order to operate independably, the frame processor must be informed about the initial memory address where the software has saved the sorted connection address list for the current frame. Since in every frame the number of connections that are being served is not fixed, the length of the broadcast data and the address list varies, complicating the implementation of the frame processor. Therefore, the DLC-MAC protocol in order to overcome this problem as well as to enable the software to dynamically manage the system's memory, it uses the $5933's mailbox registers [13] to transfer the initial memory addresses and the byte counts of the broadcast and Mobile Computing and Communications Review, Volume 7, Number 2 27

9 II I1,, Lath * " -- -'q DMA Priorities [ DLC-PHY Commands '] C [-~... ~ Controller I' I I DMARequests l[ vl ~"-'-':-'--'!--'~'~11~/~l ~ 4 Data Multiplexer II I ~ Processed ]["'~'-] ~ _~:1 -~ I ]gr~dfa~t] ~ ~i-----i, ~Fram~l~'~l I [connectlonsllcounterlsynd,~,[ = <~ I I II lbroadcast132-b [.l l ~ ase 7 [-~...~.r-~ ] -8-~~_.._.[..[...~ ]Clocks Sychronizer ' ' i P.Gat?- Construcnon ~ ReceiVe FIG PCI Bus Scheduler Frame Control Baseband Control Figure 7: The AP's Frame Processor Structure. the connection address lists. The contents of these lists are obtained conducting a direct memory read process that is initialized and controlled by the frame processor. The architecture of an access point frame processor consisting of three blocks is shown in Error! Reference source not found. The first block, is the PCI bus scheduler module that interfaces to the $5933 controller, implements the DLC-MAC protocol, resolves the requests for performing direct memory accesses and finally discriminates the data based on which frame phase they belong. Especially the data discrimination is a very important task, directly affecting the number of messages that are exchanged between the hardware and the software so as to define the boundaries of the phases of a frame. To perform all its tasks the PCI bus scheduler module uses the PCI clock frequency of 33 MHz. As it is shown in the figure, the PCI bus scheduler module uses three different first-in, first-out (FIFO) queues to store data coming from the $5933 controller. The first FIFO is a (32-bit x 128) FIFO and is a local copy of the connection address list, maintained by the software. The second FIFO has also a length of (32-bit x 128) and stores the broadcast data of the frame, while the third FIFO is a (32-bit x 512) FIFO and is used to store the data packets corresponding to the downlink MTs connections serviced in the frame. The length of the FIFO's has been selected, estimating the maximum number of packets that will be saved in a worst case scenario. An exception has been made for the length selection of the DL data FIFO, since the maximum payload of a connection is approximately equal to 14 Kbyte. The use of such a large FIFO cannot be supported by the FPGA that is used. However, during simulation and during the experiments we performed on the developed prototype under several operational conditions we noticed that the 2 Kbyte FIFO we selected, can efficiently handle the incoming traffic, compensating the latencies introduced by the PCI bus while it avoids the emergence of overloading situations. A request for the execution of a direct memory access can concurrently originate from two different sources during the processing of the current frame. The first source is a descriptor element that may issue a request for a direct memory read or write access depending on which phase of the frame is being serviced. Such a request has the highest priority. The latter source is the software module that operates asynchronously to the frame processor and is not aware of its status. In case the current frame has not been completed and the software scheduler has decided upon the composition of the next frame, it will inform the frame processor to perform a direct memory (DMA) read cycle, providing the memory address and the byte count of the broadcast and address list of the next frame. Therefore, there is high probability that two requests for performing a direct memory access will be asserted simultaneously. To resolve this situation the PCI bus scheduler's, DMA Priority Controller monitoring the operational status of the frame processor, services the request with the highest priority. The implementation of the PCI bus scheduler module for an access point has been accomplished, resulting to an equivalent circuit of approximately logic gates (563 Look-up-Tables, LUTs) that uses the 28% of the memory blocks available in the Virtex FPGA used. 28 Mobile Computing and Communications Review, Volume 7, Number 2

10 The second building module of an AP frame processor is the frame control module that parses the broadcast control data to generate the time descriptor elements, calculates the CRC bytes for the PDUs that will be transmitted, checks the received packets, discards the error ones, initiating a forwarding mechanism of the correct PDUs to the memory cells reserved by the software and finally supervises the management of the air interface. To perform all these tasks three different clock frequencies are used. The 33 MHz PCI clock, the 40 MHz baseband clock and a variable baseband clock frequency ranging from some KHz up to 4,5 MHz that is produced based on the modulation scheme and the coding rate of each connection serviced in the frame. The start of a new frame is indicated by the status of the broadcast data FIFO of the PCI bus scheduler module. The frame parser (Error! Reference source not found.) module, reading the content of the FIFO extracts the length of the FCH field decoding the BCH field of the frame and generates the corresponding time descriptor elements that are stored in the TED FIFO. The calculation of the byte count field of every descriptor is a complex procedure imposing the fast multiplication of a fixed number that determines the length of a data field (such as the length of an SCH or an LCH field), and a variable number that defines the amount of data fields (such as the number of SCHs or LCHs). To accomplish this task in a single clock period we implemented a sequential multiplication algorithm, achieving a maximum latency of 15 nsec. Concurrently to the parsing procedure, the broadcast data are inserted on a byte-per-byte basis to the CRC calculation module, where the corresponding CRC bytes are produced in parallel, depending on the different field types of a frame. The processed data are forwarded to the transmit FIFO that has been discussed in the above paragraph and is shown in Figure 5. The processing of the data packets corresponding to the downlink phase of a frame is performed as in the case of the broadcast data with the only difference that their parsing is disabled. All the uplink period packets are checked via the CRC mechanism that re-calculates the CRC bytes of the received bytes comparing the result to the CRC bytes that are received. In case of an error reception, the CRC check will fail, informing the discarding error packets unit that supervises the write processes to the UL data FIFO. The UL data FIFO architecture has been discussed in a previous section and is shown in Figure 6. Furthermore, all the operations conducted in a frame are controlled by the Frame Flow Control module that serially executes the descriptors, forming the appropriate requests for DMA accesses to the PCI bus scheduler module, setting the parameters to calculate and check the CRC bytes, while it directs the Frame Processor's Synchronization and Baseband Control Module. The implementation of the Frame Control module for an access point has been accomplished, resulting to an equivalent circuit of approximately logic gates (1131 LUTs) that uses the 28% of the memory blocks available in the Virtex FPGA used. The third frame processor block is the synchronization and Baseband Control module that manages the air interface, performs the exchange of the PDU trains with the baseband processor of the HiperLan/2 physical layer and maintains the frame timing. To accomplish this it uses three different types of commands. The first type is configuration commands that are used to set offline some parameters of the baseband, such as the transmitter power, the operating frequency channel, etc. The second commands type is directives to the baseband processor to perform measurements indicating the channel condition that will be used by the DLC software. Such commands include the measurement of the receiving power level or the bit error rate measurement. The third type of commands is related to the transmission and reception of the frame PDU trains. The first and the second types of commands are produced by the DLC software and are transferred to the frame processor via the mailboxes of the $5933 controller. Until such a command is serviced it is latched to the Synchronization-Baseband Control nodule setting a request to the command priority controller. On the other hand, when the completion of processing the PDUs of a connection has been indicated, sampling the status of the transmit FIFO, the Control Transmit FIFO reads first the descriptor fields contained prior to data and generates either a transmit or a receive command, asserting a request to the priority controller. Based on the pending commands execution time and the slot counter value, which has been initialized by the baseband processor at the transmission of the BCH preamble to the air, the priority controller decides which command will be executed by the module that implements the MAC-PHY interface. The execution of a new command is enabled when the previous one has been completed. Mobile Computing and Communications Review, Volume 7, Number 2 29

11 < v 7 ] I ]Discard Error], ~ PDUs 7-1/1 Ill Packets I I k ~ Construction ] K~)ec dedbr adcastdata'uldffta ] UFLiFD~ta ka~ Multiplexer ~CRC Check I' s ~ T ~ s [ ~[~...,1 1~. DMA Priority,[-'~-] I. I N I ' h'~zr~ ~:fffl---.ibroadcast '~. 'T "5P"'" Datal/I._.~ I ' I // HY [~l i Controller 1 ~1 ~--1 Frame T Parsing ~ L 7 j [ i s x t't~,7.~ff~ I Management P... Data lift M up lti lexer ]]~ I ~ H Frame Flow Control I ~t. G'i~ ~ T~ TX Address II DL r-~-l~f-7~--~-~ 18 I" List II Data ~'- ~ionha... [--I/F~-~] '-' I FIFO 11 FIFO v I rlt'u I "1 I I... I DLC-PHY Command ll 11 PCI Bus Scheduler Frame Control Synchronization- Baseband Control Figure 8: The MT's Frame Processor Structure. PDU Trains ) i START RCV EOC EO~ SAMPL~ INIT. ~3alseband CMD~ 1 ~" Special care is being taken for handling the data transmitted or received during the execution of the corresponding command, so as to form the PDU trains from the processed connection packets stored in the transmit FIFO and the opposite. Moreover to overcome problems arising during the interfacing of units operating at independent clock domains, a globally asynchronous locally synchronous (GALS) architecture has been used. The analysis and design of these asynchronous interfacing circuits is out of scope of this paper. The implementation of the Synchronization- Baseband Control module for an access point has been accomplished, resulting to an equivalent circuit of approximately logic gates (311 LUTs) that uses the 3% of the memory blocks available in the Virtex FPGA used. VII. The Frame Processor Architecture for a Mobile Terminal A mobile terminal frame processor performs operations that are quite similar to those performed by an access point. However there are some differences that influence the data flow and the architecture of an MT frame processor that is shown in Figure 8. The first issue is related to the management of the active connections lists. Since the time periods of the downlink or the uplink phase dedicated to an MT by an AP, in general do not match the requests sent by an MT, the connections address list is not up to date prior to the reception of the broadcast data. Therefore a time-critical condition arises to handle the data packets of the downlink connection serviced right after the end of the broadcast phase, since the enabled MT cannot transfer the checked data to the software, unloading its UL data FIFO. To overcome this problem, accelerating the creation of the connection address lists, the frame processor after checking the received broadcast data, concurrently to the generation of the corresponding time descriptor elements, produces a set of predefined messages informing the scheduler about the detected resource grants in the current frame. These messages are temporally stored in the UL data FIFO and are transferred to the software conducting a DMA process. Selecting the FIFO depth equal to (32-bit x 512), a time interval equal to approximately 450 gsec in the worst case, is provided to the scheduler to process the broadcast information and generate the address list. Although, the frame processor waits for the generation of the address list, the execution of the descriptors is performed in the same way as in the case of an access point. To accommodate the latency, introduced by the software, to service the requests for a DMA transfer of the received packets, an additional FIFO is used by the PCI Bus Scheduler module to store all incoming DMA requests. Another troubling issue for an MT frame processor is the selection of the contention channel of the RCH phase that the MT may use, to transfer either control messages or new resource requests to an AP. After the reception of the BCH field, the MTs frame processor is aware only of the number of the RCH channels as well as the position of the RCH phase in the frame. Therefore the Frame Control's, Frame Parser module is not able to generate a descriptor, depicting the information about the contention phase. On the other hand, the decision about attempting (or not) a transmission to an RCH channel is being taken by the software module that executes a random access algorithm [9]. 30 Mobile Computing and Communications Review, Volume 7, Number 2

12 The simplest solution to this problem is the generation of an RCH descriptor by the software and its transfer to the frame processor via the $5933's mailboxes. This descriptor indicates the absolute time slot to perform an RCH transmission and has been calculated using the time slot that the RCH starts, the fixed length of an RCH channel (9 Bytes) and the modulation scheme of the RCH phase (BPSK ½). Finally of great interest is the process of association or handover to a new access point that is initiated by an MT. In case of an association, an MT waits to detect a BCH preamble in order to sense the start of a new frame. BCH parsing is used once more at the MT to find the initial time slot and the numbers of RCH channels. Using its magic number [10], the MT's DLC forms an association message and selects a contention channel to transmit it. When the AP receives such a message it acknowledges it to the corresponding field of the ACH to indicate that no collision was detected to the RCH channel used and reserves some time slots to the dedicated MAC-ID 0 and DLCC-ID 0 (also known as DUC-ID 0), to transmit the new MAC-ID of the MT. The MT until the association is completed always listens to the broadcast phase, waiting for the assignment of its MAC-ID at the reserved slots for DUC-ID 0. A similar procedure is conducted during handover. The implementation of the frame processor for a mobile terminal has been accomplished, resulting to an equivalent circuit of approximately logic gates (1753 LUTs) that uses the 57% of the memory blocks available in the Virtex FPGA used. VIII. Results - Future Work In this section we briefly report on the results we obtained for the performance of the implemented HiperLan/2 MAC protocol in the developed prototype. The main concept behind the development of a HiperLan/2 prototype for an access point and a mobile terminal is the use of an AMCC $5933 card, connected to the PCI bus of a Pentium II PC running LINUX software, and a custom-designed wireless adapter card, comprising of four Xilinx FPGAs (XCV800-6-HQ240). One FPGA is dedicated to perform the operations of the frame processor while the other FPGAs implement the operations of the physical layer's baseband processor. Experiments were conducted to verify the operation of all the major sub-systems, including the software and the hardware that implement the operations of the HiperLan/2 MAC protocol. Verification was conducted in two stages. In the first stage, VHDL (Very High Speed Integrated Circuit Language) functional models were developed for the software modules, the PCI bus, the $5933 and the baseband processor's interface to the frame processor hardware, to emulate their operation. These models were connected to the synthesized VHDL model of the frame processor, creating a complete model of the HiperLan/2 prototype. Extensive simulations were conducted proving the expected operation and performance of the HiperLan/2 MAC protocol. In the second phase that has not been completed yet, the synthesized VHDL model of the frame processor was released to the hardware and was connected to the AMCC $5933 card and the baseband processor hardware. In the prototype being under test, the MAC protocol's software as well as the DLC software runs on the PC that hosts the AMCC card. Our early testing confirms the validity of the MAC protocol design. However several tests need to be conducted to verify the good operation and performance of the developed prototype, providing measurements under varying channel conditions and traffic loads. At the moment, further work is being carried out on hardware improvements and software optimizations in order to enable the implementation of the system using the system-on-chip technology. IX. Conclusions The HiperLan/2 standard offers a much better performance, compared to the. other wireless network protocols, especially at high data rates. Moreover, its QoS support enables high quality applications, such as real-time and streaming video and audio delivery, remote monitoring or home networking of everyday appliances, to be served in a wireless LAN environment. In this paper, we have presented the architecture and implementation of the centralized HiperLan/2 MAC protocol that performs the management of the airinterface in real time. Several problems should be encountered by the proposed architecture and the partitioning scheme of the MAC protocol's operations in hardware and software, in order to provide an efficient system that is able to support high-speed multimedia services to the user with the requested QoS. Such difficulties are the scheduling of the available resources, the processing of the PDU trains in a byte-per-byte basis, the error handling scheme of the received packets, the generation of the frame acknowledgement map, as well as the control and the management of the air Mobile Computing and Communications Review, Volume 7, Number 2 31

13 interface. The developed system operation is quite satisfying, confirming the choices that have been made to implement all the MAC protocol's time-critical events and the tasks requiring high processing power with hardware. We are currently performing extensive tests on the performance of the implemented MAC protocol, with the presence of the baseband processor and the DLC software, under varying channel conditions and traffic loads, while we are considering the use of a system-on-chip technology to achieve higher data rates. X. Acknowledgements The authors would like to acknowledge 1NTRACOM S.A., Hellenic Telecommunications and Electronics Industry, which has supported this work. References [1] K. J. Negus, A. P. Stephens, J. Lansford, "HomeRF: Wireless Networking for the Connected Home", IEEE Personal Communications, Vol. 7, No. 1, pp , February [2] S. Galli, "HomeRF and Bluetooth: Assessment of the Point-to-Point Link Performance", IEEE Broadband Wireless Summit, IBWS 2001, Las Vegas, USA, May 9-10, [3] "Specification of the Bluetooth System: Core", Bluetooth SIG, Ver. 1.1, February [4] G. Anastasi, L. Lenzini, E. Mingozzi, A. Hettich, A. Kramling, "MAC Protocols for Wideband Local Access: Evolution towards Wireless ATM', IEEE Personal Communications, Vol.5, No. 5, pp.53-64, October [5] G. Sfikas, R. Tafazolli, B.G. Evans, "ATM Cell Transmission over the IEEE Wireless MAC Protocol", Seventh IEEE International Symposium on PIMRC'96, October , Taipeh. [6] M.A. Visser, M. El. Zarki, "Voice and Data Transmission over an Wireless Network", Sixth IEEE International Symposium on Personal, Indoor and Mobile Radio Communications PIMRC '95, Toronto, Canada, September , pp [7] J. Weinmiller, M. Schlager, A. Festag, A. Wolisz, "Performance Study of Access Control in Wireless LANs- IEEE DFWMAC and ETSI RES 10 HIPERLAN", Mobile Networks and Applications, Vol. 2, No.l, pp 55-67, June [8] A. Doufexi, S. Armour, P. Karlsson, A. Nix, D. Bull, "A Comparison of HIPERLAN/2 and IEEE a", White Paper, University of Bristol and Telia Research. [9] Broadband Radio Access Networks (BRAN); HIPERLAN Type 2 Functional Specification; Data Link Control (DLC) Layer; Partl: Basic Data Transport Function", ETSI Report TR , Ver , April [ 10] "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data Link Control (DLC) Layer; Part2: Radio Link Control (RLC) Sublayer", ETSI Report TR , Ver , April [11] Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Physical (PHY) Layer", ETSI Report TR , Ver , April [12] R.Gupta and G. De Micheli, "Hardware-Software Co- Synthesis for Digital Systems", IEEE Design &Test, Vol. 10, No. 3, pp , September [13] "PCI Products Data Book-S5933 PCI Controller", Applied Micro Circuits Corporation, [14] Biographies Efrosini P.Vasilakopoulou (vasilakopoulou@ee.upatras.gr) received her Diploma in Electrical Engineering from the University of Patras in Greece in 1997 and her PhD from the Department of Electrical and Computer Engineering, University of Patras in Since 1997 she has been working as a research engineer in major R&D European projects at the Applied Electronics Laboratory of the University of Patras. Her current research interests include broadband networks, wireless communications for the support of multimedia services, data link layer issues, computer architecture, parallel architectures and algorithms, System on a Chip design and VLSI CAD (simulation and test). George E. Karastergios (gkaras@isi.gr), received his Diploma in Electrical Engineering from the Department of Electrical Engineering of University of Patras, Greece in 1994, and his PhD from the Department of Electrical and Computer Engineering, University of Patras in Since 1998 he has been working as a research engineer in major R&D European projects at the Applied Electronics Laboratory of the Department of Electrical and Computer Engineering, University of Patras. From 1994 to 2001 he has held several positions in industries. Currently he is working as a research engineer at the Industrial Systems Institute. Some of his main research interests are in the areasof Embedded Systems, Systems on a Chip design, Wireless Communications and Wireless LANs, Industrial Networking, Industrial Automation Systems and Communication Protocols. George D. Papadopoulos (papadopoulos@ee.upatras.gr) is a professor in the Department of Electrical and Computer Engineering at the University of Patras and the Director of the Applied Electronics Laboratory. Recently, he has been appointed as director of the Industrial Systems Institute. His degrees, Ph.D. in E.E. and MSEE, were obtained from the Massachusetts Institute of Technology (MIT) and the BEE from the City University of New York. In the past 15 years he has, for various periods, held the positions of Chairman of the ECE Department and Head of the Electronics and Computers Division. In the period he was Visiting Professor in the ECE Department of the University of MASS in Amherst, and in the period he was Director of the Naval Research and Technology Laboratory of the Department of Defence. His main research interests include the following areas: Microprocessor-based design, DSPs, FPGAs, embedded systems, computer communication networks (protocol software and internetworking), communication electronics, fieldbus based control and programmable industrial controllers, integrated industrial information systems, real-time MAC layer kernels for industrial communications, home information systems and computer vision for industrial products inspection. 32 Mobile Computing and Communications Review, Volume 7, Number 2