Wireless local area networks can be suitable for remote interconnection of different data acquisition and control systems over a standardized telecommunications network, using several communication technologies, such as ISDN, ATM or IP.  This paper presents an overview of the HIPERLAN/2 specifications as well as simulation results of this system, with channel errors and mixed traffic generated by control applications

Afonso, José A.

Neves, Joaquim José Santos Esteves

Universidade do Minho: RepositoriUM

Performance Simulation of HIPERLAN/2 with Low Debit Traffic for Real Time Data Acquisition and Control Applications  José A. Afonso, Joaquim E. Neves Universidade do Minho, Campus de Azurém, 4800-058 Guimarães, Portugal  Abstract Wireless Local Area Networks can be suitable for remote interconnection of different Data Acquisition and Control Systems over a standardized telecommunications network, using several communication technologies, such as ISDN, ATM or IP.  This paper presents an overview of the HIPERLAN/2 specifications as well as simulation results of this system, with channel errors and mixed traffic generated by control applications.       I. INTRODUCTION The traffic generated and transferred to the involved processing equipment and actuator systems by distributed applications, supported by Data Acquisition and Control Systems, requires complex transmission and switching functionalities, according to private or pre-standardized protocols and interfaces. The Modular Architecture for High Flexibility ATM Based Control System, presented in [1], is able to connect several remote units over wireless links or a switched telecommunications network. In order to link a large number of data acquisition and actuator units, which can be located inside a wide area (for instance, on sparse industrial or agricultural plants), two possible technologies have been considered for the implementation of the wireless transmission module: the ETSI BRAN HIPERLAN/2 [2] and the IEEE 802.11 [3]. The Data Link Control (DLC) layer of HIPERLAN/2 [4] presents a higher complexity than its IEEE 802.11 counterpart. On the other side, it provides more functionalities to satisfy the quality of service (QoS) required by the different applications. The most critical QoS parameters for real-time applications are the delay, jitter and packet loss ratio. The later one is related with the delay because a packet that exceeds the maximum allowable delay has to be discarded.  Several authors have already published simulation results with distinct WLAN models. In [5], Li et al. present a MAC performance comparison between IEEE 802.11a and HIPERLAN/2, but the analysis considers only one connection, with 3 SCH channels reserved on all frames: one for downlink ARQ messages, one for uplink ARQ messages, and one for uplink RR messages. Kadelka et al. [6] follow a similar approach, but present results for a scenario with multiple MTs. However, the ARQ protocol is neglected. Doufexi et al. [7] present similar results concerning the MAC layer performance. All these works rely on analytical models, with simplifying assumptions in relation to the scheduling of data, resource request (RR) and ARQ messages. Besides, the results presented for the MAC layer are restricted to the aggregate throughput of all connections.  In this paper, we provide results per individual connection, concerning particularly the delay performance for time critical applications, namely for those which are supported by Data Acquisition and Control Systems. Next section presents an overview of HIPERLAN/2 specifications, while section III describes the Simulation Model, used to achieve the results depict in section IV. The main conclusions are summarized on section V.  II. OVERVIEW OF HIPERLAN/2 The HIPERLAN/2 WLAN operates on the 5 GHz band. Its physical layer (PHY) is based on Orthogonal Frequency Division Multiplexing (OFDM). Seven transmission modes are defined, ranging from 6 Mbit/s to 54 Mbit/s. On top of the PHY layer, the DLC layer provides connection-oriented services between an Access Point (AP) and Mobile Terminals (MTs). The DLC layer includes the Medium Access Control (MAC) and the Error Control (EC) functions.  The MAC protocol of HIPERLAN/2 is based on a dynamic TDMA/TDD scheme with centralized control (performed by the AP). In order to perform the allocation of resources, the AP needs to know the state of its own buffers and of the buffers in the MTs. The MTs report their buffer states through Resource Request (RR) messages, either on the uplink phase or on the random access phase. Moreover, the MTs can negotiate with the AP for a periodic allocation of resources using the Fixed Capacity Agreement (FCA) procedure. The resource allocation information is conveyed by Resource Grant (RG) messages. The basic MAC frame format is displayed on Figure 1. The MAC frame duration is fixed (2 ms), but the duration of each phase depends on the demand. Uplink PhaseRandom AccessPhaseBroadcast Phase Downlink Phase FCH ACHRCHs BCH Figure 1: HIPERLAN/2 MAC frame structure.  The broadcast phase is composed by the Broadcast control CHannel (BCH), the Frame control CHannel (FCH) and the Access feedback CHannel (ACH). The BCH is used by the AP to broadcast basic cell information. The FCH uses the RG messages to provide an exact description of the allocation of resources on the downlink and uplink phases. The ACH provides feedback on the random access attempts made by the MTs on the previous frame. The downlink and uplink phases are composed of PDU trains, which consist of a sequence of transport channels. The Long transport CHannel (LCH) (54 bytes with 48 bytes of payload) is primarily used to carry data messages, while the Short transport CHannel (SCH) (9 bytes) conveys control messages, like RR and ARQ messages. The random access phase is composed of a number of Random access CHannel (RCH) slots. BCH, FCH, ACH and RCH PDUs are transmitted at the minimum rate (6 Mbit/s). The PHY mode used with LCH and SCH PDUs can vary. The main task of the Error Control (EC) function is to detect and recover from transmission errors not corrected by the inherent error correction mechanisms of the physical layer. The EC employs a Selective Repeat ARQ mechanism. On top of the DLC layer is the Convergence Layer (CL), which provides functions as segmentation and reassembly (SAR) and header translation to different core networks. There are currently two types of CLs defined: cell based [8], for use with ATM networks, and packet based [9], used with TCP/IP networks.  III. SIMULATION MODEL A detailed model comprising the MAC, EC and CL functions was developed, according with the standard specifications, using C++ language. These assumptions were made to reduce the complexity of the model: • The propagation delay is neglected, because its effects are irrelevant for the distances involved. • The incidence of bit errors is evaluated only on data messages. This assumption is reasonable since control messages are shorter and use a more robust PHY rate. A. Simulation Modules The simulation topology is composed by an AP module and a number of MT modules connected to a channel module. The traffic generated by the MTs is directed to the AP. Each MT handles one connection. A timestamp is associated to each packet when it’s generated. The packets are stored on a FIFO queue while they wait for their turn to be transmitted. The FIFO dimension used on each MT was 64 kbytes. The Convergence Layer (CL) adapts each packet to the payload of one or more data messages (LCH PDUs). A copy of each sent data message is kept on the MT until it receives the positive acknowledgement from the AP. The channel module performs tasks as the timely delivery of the messages to their destinations, the introduction of bit errors on the messages and the detection of collisions.  The data messages are checked for errors on arrival at the AP. If received correctly and in sequence, they are sent to the Convergence Layer (CL), where the original packet is restored and its delay is computed1 and collected. Erroneous                                                  1 For segmented packets, it’s necessary to wait for the last segment. messages force the scheduling of an ARQ message before being discarded. Out of sequence messages are stored until the correct arrival of its predecessor messages, when they are delivered to the CL. An ARQ message is also generated after a number of consecutive correct data messages, to allow the sender to remove the acknowledged messages from the buffer and advance the transmitter window. All ARQ messages are sent with the Cumulative Acknowledgement Indicator (CAI) bit set.  B. Scheduling Within the AP, the MAC scheduler is responsible for the allocation of resources for the transmission of data and control messages in the uplink and downlink phases, as well as the definition of the number of RCH slots. Several procedures were implemented in order to improve the delay performance for real-time connections: • On the reception of an errored message, the AP schedules an ARQ message on the immediately following MAC frame. • Together with the negative acknowledgment message, the AP grants extra resources for a fast retransmission of the associated errored data messages. • The MTs give priority of transmission to negative acknowledged messages over new messages. There are separated queues to handle pending ARQ messages, data retransmissions and RR requests for each traffic class. For each MAC frame, after the FCA allocation process, these queues are served in sequence (high priority queues first) until the resources are exhausted or all queues are empty. Leftover resources are used to enlarge the random access phase from its initial length (1 RCH slot). C. Simulation Parameters Table 1 shows some HIPERLAN/2 related parameter values used on the simulations (those that can assume more than one value). For the other fixed parameters, please refer to the standard specifications [2].  Table 1: HIPERLAN/2 parameters. LCH transmission rate 18 Mbit/s SCH transmission rate 6 Mbit/s Uplink / RCH guard time 2 µs Uplink / RCH preamble 16 µs Turn around time 6 µs Window size 512  The Access Point has been loaded with traffic generated by Mobile Terminals. Each MT generates 64 kbit/s, Constant Bit Rate (CBR) traffic, inside the ATM cell payloads, or Variable Bit Rate (VBR) traffic, inside the payload of the IP Packets. Table 2 presents the traffic parameters used on the simulation. Class 1 represents real-time ATM connections, launched by data acquisition and control applications with QoS requirements, while class 2 represents non-real-time IP traffic, carried out without QoS guaranty.   Table 2: Traffic characteristics. Class ID 1 2 Priority high low No. of MTs 30 0-50 Packet length (bytes) 53 1500 Rate (kbit/s) 70.67 2 300 Traffic type CBR Poisson Convergence Layer cell based  packet based  IV. SIMULATION RESULTS The histograms presented on this section were normalized by the number of samples to allow an easy evaluation of the percentage of samples associated with each cell. The cell width is 0.1 ms. Results are obtained from steady-state simulations. First results are relative to the system operation only with the CBR connections (30 MTs). The FCA procedure is used for resource reservation. For each connection, one LCH channel is allocated in every one out of three frames, performing a 6ms cycle (corresponding to the packet inter arrival time). In order to distribute the load, each frame handles 10 connections. All connections begin to generate traffic at the same time (t = 6 ms).  Figure 2: Delay distributions of 3 real-time connections.  Figure 2 shows the histogram of delay for 3 of the 30 connections, considering an error free channel. As the connection from the MT1 (RT1) is the first to be served, its delay is smaller than the others. The RT10 connection is the last one to be served on the same frame, while the RT30 connection is the last to be served on each cycle, so it suffers the longest delay3 on this case.  For each connection, almost all packets present a constant delay, but a little percentage of packets suffers a small increase of delay. This is caused by the periodic ARQ messages (ACK) sent by the AP4. A substantial part of the                                                  2 This cell rate corresponds to a payload rate of 64 kbit/s. 3 This delay can vary from near zero to 6 ms, depending on the traffic generation and transmission times. 4 The synchronization of the various CBR connections makes the effect exceptionally pronounced. delay comes from the SCHs allocated on the downlink phase; the other part is due to the additional RG messages on the FCH. Figure 3 presents results for the RT1 connection with channel errors (BER = 10-4). According to the procedures described in section IV.B, retransmissions occur on consecutive frames until the message is received correctly. The delay variation is approximately equal5 to the number of retransmissions multiplied by the frame duration (2 ms). The probability of a certain number of retransmissions depends on the Packet Error Rate (PER):  (1) The PER can be calculated from the bit error rate (BER) and the length (in bits) of the LCH PDU:  (2) For example, with BER = 10-4, the PER is 4.23x10-2, and the probability of 3 retransmissions (corresponding to delay variation of about 6 ms) is 7.24x10-5. Because out of sequence messages have to wait for the correct reception of previous messages before delivery, the real (and simulated) delay distribution differs slightly from the analytical results of equation 1.  Figure 3: Delay distribution of RT1 connection with BER 1E-4.   Figure 4: Delay distribution of RT1 connection with BER 1E-3.                                                  5 The exact value will depend on the position of the scheduled message on the MAC frame. ( ) (1 )rP r PER PER= −54 81 (1 ) xPER BER= − −Figure 4 shows the results with BER = 10-3. In this case, the number of retransmissions is significant because of the increased PER, with impact not only on delay, but also on the resource utilization. The next results are relative to the simulation of mixed traffic. Besides the 30 CBR terminals, a variable number of non-real time data terminals were added to the system. Figure 5 shows the throughput of each class of traffic and Figure 6 shows the delay of the RT1 connection, both as functions of the number of non-real-time connections. As expected, the throughput of the CBR connections remains the same even under high load conditions, since they have high priority. On the other side, the throughput of non-real-time connections reaches saturation with about 35 connections. From that point, their delay rises drastically, causing the overflow of the FIFO queues in the MTs.  Figure 5: Aggregate throughput for different traffic classes vs. the number of non-real-time connections.   Figure 6: Mean delay and standard deviation of RT1 connection vs. the number of non-real-time connections  The impact of the non-real-time traffic on the delay parameters of the CBR connections is small. At the beginning, there is a slightly increase on the delay as the load increases, due to the increase of the number of connections carried per MAC frame, which causes the enlargement of the FCH channel (the non-real-time traffic itself doesn’t have impact on the delay, since it is positioned after the CBR data on the MAC frame). As the load increases the delay slightly decreases. The reason is that, while the space available on the frames is all occupied, the average length of the PDU trains continues to increase, so the number of non-real-time connections served by MAC frame decreases.  V. CONCLUSIONS The presented results show that the non-real-time traffic load has little impact on the real-time traffic for the scenario proposed. Also, the delay in the presence of a moderate level of errors can be kept under control, if certain scheduling procedures are used. As the PER can be significantly reduced with a lower PHY rate [7], under poor channel conditions, the use of a more robust PHY mode for the retransmissions is worth considering. Future work includes the use of the simulator to evaluate the performance of the system in the presence of burst errors, and with other scheduling and resource reservation mechanisms, for example, the scheduling of RR messages in the uplink phase, for use with VBR traffic. A simulation model for the IEEE 802.11 was also developed. It will allow the performance comparison between the two standards.  VII. REFERENCES [1] J. E. Neves, “Modular Architecture for High Flexibility ATM Based Control System”, Asia-Pacific Conference on Communications, and Optoelectronics and Communications Conference APCC/OECC’99, Beijing, China, Oct. 1999. [2] ETSI TR 101 683 V1.1.1, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; System Overview, Feb. 2000. [3] ANSI/IEEE 802.11, Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 1999.  [4] ETSI TS 101 761-1 V1.2.1, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data Link Control (DLC) Layer; Part 1: Basic Data Transport Functions, Nov. 2000. [5] H. Li, G. Malmgren and M. Pauli, “Performance Comparison of the Radio Link Protocols of IEEE802.11a and HIPERLAN/2”, IEEE VTC2000, Sep. 2000. [6] A. Kadelka, A. Hettich and S. Dick, “Performance Evaluation of the MAC protocol of the ETSI BRAN HIPERLAN/2 standard”, European Wireless'99, pp. 157-162, Munich, Germany, Oct. 1999.  [7] A. Doufexi et al., “A Comparison of the HIPERLAN/2 and IEEE 802.11a Wireless LAN Standards”, IEEE Communications Magazine, pp. 172-180, May 2002. [8] ETSI TS 101 763-1 V1.1.1, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Cell based Convergence Layer; Part 1: Common Part, Apr. 2000. [9] ETSI TS 101 493-1 V1.1.1, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Packet based Convergence Layer; Part 1: Common Part, Apr. 2000. 

Performance simulation of HIPERLAN/2 with low debit traffic for real time data acquisition and control applications

http://repositorium.sdum.uminho.pt/bitstream/1822/1949/1/ConfTele%202003%20final.pdf

Performance simulation of HIPERLAN/2 with low debit traffic for real time data acquisition and control applications

Abstract

Similar works

Full text

Available Versions

Universidade do Minho: RepositoriUM