Supported under the NSF Special Projects in Communication and Networking, Ohio State University researchers in both the wireless communications and networking areas are working toward achieving significant gains in wireless system performance by leveraging an existing and functioning wireless modem testbed. The narrow-band wireless modem testbed is expected to support both real-time (bus location tracking) and non-real-time (regular) data applications. The first step toward this objective is to design and implement an effective medium access control (MAC) protocol that coordinates the transmission activities on the forward and reverse channels.

In this paper, we document our design of such a MAC protocol, called OSU-MAC, subject to the physical layer characteristics and constraints. A number of techniques have been proposed to support QoS imposed by the real-time applications, to deal with the asymmetry on the forward and reverse channels and the half-duplex transmission constraint imposed by the physical layer, and to enhance the error control capability of OSU-MAC. We also present simulation results to demonstrate the key, functional characteristics of OSU-MAC.

Index Terms-- MAC, asymmetric wireless links, wireless WAN, temporal QoS, half-duplex transmission constraints, error control.

   
Introduction

Wireless communication has become an important technique for supporting emerging Personal Communications Service (PCS). In PCS, both traditional telephone service and other more advanced data applications, e.g., personal mail, bulk file transfer, audio/video, and periodic update of sensor information, are expected to be simultaneously supported. The latter applications, in particular, require different levels of temporal quality of service (QoS). An effective medium access control (MAC) protocol must be carefully designed for this purpose. In this paper, we document the design of a MAC protocol, called OSU-MAC, that supports both real-time and non-real-time applications on an OSU narrow-band wireless modem testbed, subject to its physical layer characteristics and constraints.

Supported under the NSF Special Projects in Communication and Networking, OSU researchers in both the wireless communication and networking areas are working toward achieving significant gains in wireless system performance. An existing and functioning wireless testbed is leveraged as the experimental system which forms the bedrock. The narrow-band wireless modem testbed is expected to support both real-time and non-real-time (regular) data applications, currently with the real-time bus location tracking via an on-board global positioning system (GPS) being the representative, real-time application and data applications such as e-mail, ftp, and telnet, being the other representative.

Our first step toward realizing the above objective is to design and implement an effective MAC protocol, OSU-MAC, that coordinates the transmission activities on the forward and reverse channels so as to support QoS imposed by both types of applications. In particular, we delegate to the base station the full responsibility of resource arbitration, channel access, and registration in each cell. As will be elaborated on in Section  3.1, this base- station-based scheduling approach enables provisioning of deterministic QoS for real-time applications, while maximizing the system utilization. To take the error characteristics of the physical layer into consideration, we encode both data packets and control fields in Reed-Solomon code [ 1, 2]. We also take into account of the half-duplex transmission constraint (i.e., a mobile subscriber cannot transmit and receive at the same time) imposed by the physical layer, and propose a two-control-field structure to fully utilize the limited bandwidth available on the reverse channel. The two-control-field structure, coupled with base-station-based scheduling, alleviates the asymmetry problem on the forward and reverse channels and ensures the data rate on the reverse channel commensurate with that on the forward channel. To make use of the unused bandwidth originally reserved for real-time traffic, we also propose a dynamic slot adjustment scheme. Finally, as a real-life MAC protocol currently being implemented on the OSU narrow- band wireless modem testbed, we insert, wherever advised by the wireless modem researcher, preambles, postambles, and guard times between packet slots or notification cycles for synchronization.

Several MAC protocols have been proposed in wireless networks, among which Packet Reservation Multiple Access (PRMA) [ 3], Dynamic TDMA (D-TDMA) [ 4], Dynamic Reservation Multiple Access (DRMA) [ 5], Resource Auction Multiple Access (RAMA) [ 6], Floor Acquisition Multiple Access (FAMA) [ 7], Remote-Queuing Multiple Access (RQMA) [ 8], and Multimedia Cable Network System (MCNS) [ 9] may have received the most attention. They have been designed either for voice/data traffic (PRMA, D-TDMA, DRMA, RAMA, and FAMA), for real-time/best-effort traffic on an abstract model (RQMA), or for cable modem users (MCNS). In comparison with the above research efforts, OSU-MAC is the first academic implementation workthat (i) takes into account of the physical layer characteristics and constraints on a specific environment in the design phase (rather than an abstract design), (ii) provides mechanisms for providing deterministic, temporal QoS for real-time applications, and (iii) is fault tolerant with both data slots and control fields protected by the (64,48) Reed-Solomon code.

The rest of the paper is organized as follows. In Section  2, we introduce the design objectives of, the types of applications to be supported on, and the system model used for, the OSU narrow-band wireless testbed. We also outline the physical layer characteristics and constraints of the wireless testbed. These characteristics and constraints are the major factors in directing the design of the proposed MAC protocol. In Section  3, we present OSU-MAC. In Section  4, we give a survey of existing MAC protocols for wireless local area networks. In Section  5, we evaluate OSU-MACin terms of throughput, packet delay, capability of providing temporal QoS, collision probability, and registration latency. We conclude the paper with Section  6.

   
The OSU Narrow-Band Wireless Testbed

   
Applications supported and design goals

Applications supported:

Design objectives:

• up to 8 active GPS users with 1 minute checking delay and 4 second access delay requirements, where the checking delay is the delay incurred when a non- active terminal becomes active, and the access delay is the time interval between the arrival of a packet at an active GPS user and its transmission.

  The 4 second access delay requirement is determined as follows: since a mobile unit moves at a speed no faster than 90 kilometers per hour and the allowable location error is within 100 meters, a GPS packet must be sent and received every hours, or 4 seconds. If a GPS packet is corrupted after being decoded, the corrupted packet will not be retransmitted.

• up to 64 active non-real-time users. No access delay requirement is imposed, but data packets need to be reliably transported.

By active users, we mean mobile subscribers which have registered with the base station and are actively transmitting/receiving data packets. The maximum time required to register with the base station is also a design parameter. In the current design, we require that 80% of the registration requests can be approved in two notification cycles, and 99% can be made in 10 cycles.

   
System model

The geographical area covered by a wireless network is divided into overlapping cells. Each cell is associated with a base station and can support a number of mobile subscribers. The base station is the central unit of the cell and is connected to one another to form a wired point-to-point backbone network. It also handles all the ongoing activities in the cell, and has the overall control of the system resources. Signals from the base station are broadcast to all mobile subscribers. Signals sent from mobile subscribers are, however, only received by the base station and not heard by other mobile subscribers. The base station receives data packets from all mobile subscribers and forwards them to their destinations.

Forward and reverse channels:

Information transported:

Physical characteristics of forward/reverse channels

Structure of pilot symbol frame:

   

Figure 1: Pilot symbol frame, P=pilot symbol, D=data symbol.

Each regular (non-real-time) data packet is 64 bytes (512 bits) long, 48 bytes (384 bits) of which are information bits. Since a PS frame contains 128 non-PS symbols (256 bits), each data packet is transmitted in two PS frames.

Error correction with Reed-Solomon code:

Insertion of preambles and guard times for synchronization:

Packet size:

Constraints imposed by physical layer characteristics:

Half duplex transmission constraint:

Asymmetry between the forward/reverse channels:

   
Proposed MAC Protocol - OSU-MAC

   
Base station-centric resource arbitration

A major feature of our proposed MAC protocol is that we delegate to the base station the full responsibility of resource arbitration, channel access, and registration in each cell. The reasons for this design are two-fold: first, as the base station in a cell usually has the overall control over all the system resources, it is reasonable to delegate the base station to arbitrate the assignment of data slots on both the forward and reverse channels. Second, because of the asymmetry between the forward and reserve channels, the MAC protocol should be so designed as to include as little control overhead on the reverse channel as possible. That is, the control information sent from mobile subscribers to the base station should be kept minimal. This leads to a base station-centric mechanism. The only control information sent uplink is the registration and slot reservation requests.

Specifically, the base station transports data packets as well as channel access information on the forward channel to mobile subscribers. Channel access information includes, among other things,

• the slot access schedule on the forward channel and on the reverse channel for the current notification cycle. In particular, the slot access schedule on the reverse channel is determined by the reservation requests received on the reverse channel in the previous notification cycle.
• acknowledgment for packets received by the base station on the reverse channel.
• information used to page inactive mobile subscribers.

Control fields:

   

Figure 2: The control fields on the forward channel.

• GPS schedule: gives the user IDs of (up to) 8 GPS users which are scheduled to use the 8 GPS slots on the reverse channel. This field is bits.
• Reverse schedule: is used by the base station to announce the slot schedule in response to the reservation requests received on the reverse channel, either explicitlyor implicitly ² , in the previous notification cycle. It gives the user IDs of (up to) Mdata users scheduled to use the data slots on the reverse channel. In our current design ³ M=9, and hence this field is bits.
• Forward schedule: is used to inform mobile subscribers to which subscriber data slots on the forward channel will be transmitted. It gives the user IDs of mobile subscribers which should receive data on the Ndata slots on the forward channel. In our current design ⁴ N=37, and hence this field is bits.
• Reverse ACKs: are used to acknowledge receipt of data packets on the reverse channel in the previous notification cycle or to notify a mobile subscriber (whose registration request is approved) of its (EIN, user ID) pair. This field is bits.
• Paging:is used to page and locate inactive mobile subscribers. To support paging of up to 18 users, this field contains bits.

Slot reservation and scheduling:

To allow mobile subscribers with regular, non-real-time data to gain access to the reverse channel, one or more data slots on the reverse channel are designated as contentionslots in each notification cycle, where a contention slot is simply a data slot notassigned to any mobile subscribers on the reverse channel. There are three possible means to reserve data slots on the reverse channel:

1.

sep 0.0in 0.0in

2.

A mobile subscriber may explicitly send a reservation request packet, specifying the number of data slots desired, on one of the contention slots.

3.

When a mobile subscriber transmits its data packets in the data slots assigned to it in a notification cycle, it may set a reservation field in the header of the data packet to implicitly indicate that it would like to request more data slots in the next notification cycle.

4.

A mobile subscriber may send its data packet in one of the contention slots and compete with the other mobile subscribers with data or reservation packets on a contention basis. If multiple mobile subscribers attempt to transmit their data/reservation packets in the same slot, collision occurs. (The base station has to explicitly acknowledge on the forward channel receipt of data packets on the reverse channel as a result of these potential collisions in contention slots.)

When collision occurs, mobile subscribers back off with a random period of time before their subsequent attempts. (To increase the probability of successful reservation, mobile subscribers that transmit data packets without reservation are required to back off with a longer time period.) Also, if collisions occur multiple times in a notification cycle or across multiple notification cycles, the base station may designate more than one data slots as contention slots (i.e., leave them unassigned) in the next cycle. On the other hand, if multiple contention slots have been left unused in the current cycle, the base station may decrease the number of contention slots in the next cycle.

The base station notifies a mobile subscriber that makes a reservation request or transmits its data in a contention slot of whether or not the request/data has been received by indicating in the ith reverse ACKsfield the user ID of the subscriber whose request/data has been received. Note that the fact that a reservation request is received does not imply the request will be honored. A mobile subscriber has to look into the reserve schedulefield to find out whether or not it is assigned data slots.

After the base station ``collects'' all the requests in the current notification cycle, it uses a specific scheduling algorithm (in our current design, the round robin algorithm) to determine the slot schedule on the reverse channel, subject to the half-duplex transmission constraints. The resulting slot schedule is then announced in the reverse schedulecontrol field in the next notification cycle. Mobile subscribers will then transmit their data accordingly.

   
Registration of mobile subscribers

A mobile subscriber registers itself with the base station (also) through the use of contention slots. A mobile subscriber that newly enters the cell first listens to the forward channel to synchronize itself on the reverse channel and to find out the positions of contention slots. Then it transmits its registration request in one of the contention slots. The registration request packet may compete with other registration/reservation/data packets. If a collision results, the mobile subscriber with the registration request persistsin the next notification cycle until it succeeds in one notification cycle or fails after a pre-determined number of attempts. Note that we give the priority of using contention slots to mobile subscribers which intend to register themselves with the base station, as other mobile subscribers with reservation/data packets will back off in the case of collision.

If a registration request made in the ith contention slot is successfully received by the base station, it will be passed to the registration handling module for approval. If the registration request is approved, the base station will notify the requesting subscriber by returning the (EIN, user ID) pair in the ith reverse ACKsfield.

   
Structure of notification cycle on the reverse channel

   

Figure 3: Two formats of the notification cycle on the reverse channel.

The structure of the notification cycle on the reverse channel is shown in Fig.  3. Depending on the number of active GPS subscribers, the system can choose one of the two possible formats. If there are more than three active GPS subscribers, the system uses the first format. In this format, 8 GPS slots are scheduled first, followed by 8 data slots. The second format is used when the number of active GPS subscribers is less than or equal to 3. In this case, five unused GPS slots are combined to form a data slot (to be used by data users). The notification cycle begins with 3 GPS slots, followed by 9 data slots and a guard time of 0.03375 second.

Since the base station knows how many active GPS subscribers are in the system, it is the base station's responsibility to choose and announce which format to use. The announcement is made implicitly through the number of GPS subscribers in the control fields. If the number is greater than 3, then the base station and all mobile subscribers will use format 1, otherwise, they use format 2. By “using a format,” we mean the mobile subscribers will synchronize themselves to the beginning of each notification cycle and access the reverse channel according to the time given in Table 2.

Dynamic GPS slot adjustment on the reverse channel:

A more sophisticate approach is to dynamically adjust GPS slots to consolidate allocated GPS slots and then combine unused GPS slots into data slots. If there are more than three GPS users, the system uses format 1. When GPS users leave, GPS slots are re-assigned to existing GPS users and unused GPS slots converted into a data slot, subject to the real-time requirements of existing GPS users. If more GPS users register later, this data slot can be split into five GPS slots again. The real-time requirements of existing GPS users are ensured through the following rules of slot re-assignment:

sep 0.0in 0.0in

(R1)

The GPS slots in a cycle are allocated in order.

(R2)

When a GPS user is admitted into the system, it is allocated the first unused GPS slot.

(R3)

When a GPS user assigned GPS slot ileaves the system, the GPS user that uses GPS slot j> i(if any) is re-assigned slot i.

Note that with (R3), when a GPS user is re-assigned a slot, it is ensured to has an slot access interval that is less than 4 seconds in the current notification cycle and hence the real-time requirement is fulfilled. Also, with these rules, allocated GPS slots are consolidated at the beginning of each notification cycle, and unused GPS slots can be converted into a data slot.

The number of regular data slots on the reverse channel:

Guard time:

   
Structure of notification cycle on the forward channel

The notification cycle on the forward channel begins with a preamble of 300 symbols. The preamble is then followed by control fields and data slots.

Two control fields to deal with the half-duplex transmission constraint:

As an alternative to deal with the half-duplex transmission constraint, we insert two sets of control fields, with the second one exclusively used by mobile subscribers scheduled to transmit during the time interval when the first control fields are transmitted. In other words, the bandwidth utilization on the reverse channel is improved at the expense of introducing a second set of control fields on the forward channel (which has comparatively more abundant bandwidth).

   

Figure 4: The structure of notification cycles on the forward and reverse channels.

Problem 1: Where to place the second set of control fields?

One intuitive approach would be to evenly divide data slots into two groups and arrange the preamble, control fields, and data slots in each notification cycle as follows:

4in space1.xfig.eps

The problem with the above arrangement is that the base station cannot use the first half of data slots on the forward channel to send data to the mobile subscribers that listen to the second set of control fields. This is because these subscribers will not know their schedule until they listen to the second set of control fields. Similarly, the reverse data slots that are ahead (in time) of the second set of control fields cannot be assigned to these mobile subscribers either. To deal with this problem, we propose to place the second set of control fields as closely as to the beginning of each notification cycle. As shown in Fig.  4, the notification cycle is structured as the preamble (of size 300 symbols) followed by the first set of control fields (2 RS codewords), one data slot (1 RS codeword), another preamble (of size 150 symbols), the second set of control fields (2 RS codewords), and the rest of data slots. With this configuration, in the worst case (which occurs when the base station only has packets destined for the data user which is scheduled to transmit in the data slot), only one data slot on the forward channel cannot be used.

The reason for not concatenating the two sets of control fields back to back is to ensure that the data user scheduled to transmit in the last reverse data slot completes its uplink transmission and has sufficient times to switch from the transmit function to the receive function.

Problem 2: How does a mobile subscriber know which control fields it should listen to?

All mobile hosts need to listen to the control fields in order to synchronize with the base station and to receive channel access schedule. With the two control field design, some users will transmit at the same time of the control fields. How does they know which control field they should listen to? In order to solve this problem, we shift the cycle on the reverse channel seconds later than that on the forward channel (Fig.  4), where

The extra 0.02 seconds makes it possible for the GPS users to transmit right after they learn their schedules on the forward channel.

After the shift, the only slot on the reverse channel that overlaps the first control fields in the next notification cycle is the last data slot. The user which is scheduled to transmit in this slot should listen to the second set of control fields. All the other users should listen to the first set of control fields. In summary, mobile subscribers use the following rules to decide which set of control fields it should listen to:

sep 0.0in 0.0in

• When a mobile subscriber first enters the system, it listens to the first control fields.
• If a mobile subscriber is assigned to transmit in the last reverse data slot, it listens to the second set of control fields; otherwise, it listens to the first set of control fields.

Note that the base station must not assign the first slot on the forward channel to the user which listens to the second set of control fields.

Problem 3: Is there any difference between the first and the second set of control fields?

The only difference between the two sets of control fields is that the second set of control fields has to acknowledge the activity that occurs on the reverse channel when the first set of control fields is transmitted. Specifically,

sep 0.0in 0.0in

• If the last data slot on the reverse channel was used to send a data packet, the second set of control fields acknowledges its reception (in the reverse ACKs field).
• If the last data slot on the reverse channel was used by a new mobile subscriber for registration, the second set of control fields announces whether or not the reservation succeeds.

Also, the base station can schedule forward data slots that were announced idle in the first set of control fields to the user assigned the last data slot on the reverse channel, based on whether or not the user requests for more data slots in the packet header of its packet (transmitted in the last slot). However, the base station cannotmake any change in the reverse schedule.

The number of data slots per cycle on the forward channel:

   
Scheduling constraints and algorithm

As mentioned in Section  3.1, we delegate to the base station the full responsibility of (i) generating slot schedules on both the forward and reverse channels and (ii) handling registration requests in each cell. After introducing the notification cycle structure on both the forward and reverse channels, we are now in a position to delve into the details of how data slots are scheduled on both channels. Since the reverse channel has limited bandwidth than the forward channel, the base station schedules slots on the reverse channel and then assign slots on the forward channel, the latter subject to the half-duplex-transmission and two-control-fields constraints.

Generation of slot schedules for data/GPS applications:

After the reverse slots are scheduled, the data slots on the forward channel are allocated in a similar way, but subject to the following constraints:

sep 0.0in 0.0in

(i)

a mobile subscriber cannot be scheduled to transmit on the reverse channel and to receive on the forward channel at the same time;

(ii)

a mobile subscriber cannot be scheduled to transmit on the reverse channel 20 ms before and after it is scheduled to receive on the forward channel; and

(iii)

a mobile subscriber cannot be scheduled to receive on the forward channel 20 ms before and after it is scheduled to transmit on the reverse channel.

Registration and reservation window and backoff algorithm:

In order to reduce the registration latency (defined as the time interval between the time when a registration is first made and the time it is finally received by the base station), the base station monitors the collision rate in the contention slots. If the rate exceeds some pre-determined threshold, the base station dynamically allocates a few more contention slots in the subsequent notification cycles, and vice versa.

   
Survey on Existing MAC Protocols

PRMA:

   

Figure 5: Frame structures for the PRMA and D-TDMA protocols.

D-TDMA:

RAMA:

   

Figure 6: The frame structure in RAMA.

DRMA and FAMA:

All the above wireless MAC protocols are tailored to meet the specific requirement of supporting only voice and data users, and do not address the need for supporting other aspects of QoS. In particular, they provide no temporal QoS required by bus location tracking applications. Recently, several other MAC protocols have been proposed that address the QoS issues in wireless LANs, which we summarize below.

RQMA:

   

Figure 7: The frame structure in RQMA

The most desirable feature of RQMA [ 8] is that it takes into consideration of the error characteristic of the wireless channel, and establishes a prioria real-time retransmissionsession to retransmit time-critical data packets upon error detection in the normal transmission phase. To support temporal QoS, mobile hosts are required to calculate packet deadlines by themselves. This may not be desirable due to the following two reasons: (i) mobile hosts are usually small and inexpensive devices and may not possess much power to perform deadline calculation; (ii) since the base station usually generates the slot schedule based on packet deadlines, a malicious mobile host may use more resources than its fair share by specifying tighter deadlines for its packets.

MCNS MAC:

There are many features in common between the MCNS MAC protocol and the proposed MAC protocol. For example, as we use user ID to identify mobile subscribers in a cell, MCNS uses the Service ID to provide both device identification and class-of-service management to the cable modems (which are equivalent to mobile subscribers in wireless networks). Similar to our proposed MAC protocol, cable modems in MCNS request bandwidth for data transmission and the cable modem termination system (CMTS) broadcast to every cable modem the slot allocation schedule.

In spite of all the above research efforts, we believe our proposed MAC protocol is the first that (i) takes into account of the physical layer characteristics (e.g., Reed Solomon code encoding for error control, preambles/postambles for synchronization, dynamic slot adjustment to alleviate asymmetry on the forward/reverse channels) and constraints (e.g., the two-control-field structure to deal with the half-duplex transmission constraint), (ii) provide a mechanism for deterministically ensuring temporal QoS (e.g., the 4-second access delay requirement for up to 8 GPS mobile subscribers), and (iii) is being implemented on a narrow-band wireless modem testbed.

   
Performance Evaluation

We have implemented OSU-MAC in a Java-based simulation environment, called JavaSim[ 10], and conducted a simulation study to validate the proposed design. We do not include a simulation comparison to the other existing protocols (summarized in Section  4) because all the protocols have been designed with different objectives under different environments: OSU-MAC has been designed for both bus tracking applications and regular data applications on a specific testbed, while other protocols were designed either for voice/data users (PRMA, D-TDMA, RAMA, DRMA, FAMA), for real-time/best-effort traffic on an abstract model (RQMA), or for cable modem users (MCNS). A comparison among them would not be fair.

The simulation scenario is as follows: there are up to 8 buses within the cell covered by a base station. Each bus carries a GPS unit that transmits GPS packets periodically to report its location. Also, mobile subscribers in the cell may send/receive short e-mails on the reverse/forward channel. For the purpose of evaluating the MAC performance, we assume the e-mail messages are generated at a mobile subscriber according to a Poisson process with mean interarrival time T. Two types of packets are used in the simulation: packets of fixed length L=120 bytes and variable-length packets whose length is drawn from a uniform distribution between 40 and 500 bytes. When the number of GPS users is less than or equal to (greater than) 3, each notification cycle on the reverse channel has d=9 (d=8) data slots, among which the first is a contention slot for registration and reservation.

Given that there are mmobile data subscribers in the cell, the loadindex of the reverse channel is defined as

The simulation runs are designed to evaluate the system performance under light, medium and heavy loads, with the value of varying from 0.3, 0.5, 0.8, 0.9, 1.0 to 1.1, the number of GPS users varying from 1 to 8, and the number of data users varying from 5 to 14. Given different combinations of traffic conditions, the interarrival time Tis calculated as

Utilization on the reverse channel:

   

Figure 8: Performance evaluation with respect to link utilization and packet delay.

Packet delay:

Control overhead:

   

Figure 9: Control overhead as a function of load.

   

Figure 10: Performance evaluation with respect to the probability of collision in contention slots and the reservation latency.

Fairness:

   

Figure 11: Fairness

   

Figure 12: Performance improvement resulted from using two control fields and dynamic slot adjustment.

Performance improvement due to the two-control-fields design and dynamic slot adjustment:

Fig.  12 (b) depicts the average number of data slots that have been used in the case that the number of GPS users is 1 and 4, respectively. Recall that when there are 3 or less GPS users, 5 GPS slots will be converted to an additional data slot. Hence, Fig.  12 (b) shows how effective the dynamic slot re-adjustment approach helps in utilizing bandwidth originally allocated to unused GPS slots. The effect of dynamic slot re-adjustment is not significant when the load is light, but as much as 15% more bandwidth can be utilized with slot re-adjustment.

   
Conclusion

As part of the ongoing NSF Special Project, we have designed and implemented a MAC protocol, OSU-MAC, that coordinates the transmission activities on the forward and reverse channels so as to support both the real-time bus location tracking application and the regular data applications, on an OSU narrow-band wireless modem testbed. There are several unique features of OSU-MAC: first, we delegate to the base station the full responsibility of resource arbitration, channel access, and registration in each cell. This base- station-based scheduling approach enables provisioning of deterministic QoS for real-time applications, effective supports of slot reservation and mobile registration, while maximizing the system utilization. Second, we take into account of the error characteristics of the physical layer. For example, we consider the half-duplex transmission constraint and propose a two-control-field structure to fully utilize the limited bandwidth available on the reverse channel. The two-control-field structure, coupled with base-station-based scheduling, alleviates the asymmetry problem on the forward and reverse channels and ensures the data rate on the reverse channel commensurate with that on the forward channel. Third, to make use of the unused bandwidth originally reserved for real-time traffic, we also propose a dynamic slot adjustment scheme. Finally, as a real MAC protocol currently being implemented on the OSU narrow- band wireless modem testbed, we insert, wherever needed as advised by the wireless modem researcher, preambles, postambles, and guard times between packet slots or notification cycles for synchronization.

We are currently implementing OSU-MAC on the MS-Windows operating system and will develop a real-time bus tracking application and an email delivery system. Due to the limited bandwidth available on the reverse channel, it is not appropriate to built the entire TCP/IP protocol stack on this system, and hence we are building the two applications directly on the data link layer (which includes the MAC layer). The MAC layer interfaces with the physical layer which is implemented on a DSP board connected with the PC through a RS-232 link.

Bibliography

1

R. E. Blahut, Theory and practice of error control codes.
Addison-Wesley, Reading, MA, 1983.

2

A. J. McAuley, ``Reliable broadband communication using a burst erasure correcting code,'' in Proc. of ACM SIGCOMM, pp. 297-306, September 1990.

3

S. Nanda, D. Goodman, and U. Timor, ``Performance of PRMA: A Packet Voice Protocol for Cellular Systems,'' IEEE Trans. Veh. Techn., vol. 40, pp. 584-598, 1991.

4

N. Wilson, R. Ganesh, K. Joseph, and D. Raychaudhuri, ``Packet CDMA Versus Dynamic TDMA for Multiple Access in An Integrated Voice/Data PCN,'' IEEE JSAC, vol. 11, pp. 870-884, 1993.

5

X. Qiu and V. O. Li, ``Dynamic Reservation Multiple Access (DRMA): A New Multiple Access Scheme for Personal Communication System (PCS),'' Wireless Networks, vol. 2, pp. 117-128, 1996.

6

N. Amitay, ``Distributed Switching and Control with Fast Resource Assignment/Handoff for Personal Communications Systems,'' IEEE JSAC, vol. 11, pp. 842-849, 1993.

7

C.L.Fullmer and J.Garcia-Luna-Aceves, ``Floor Acquisition Multiple Access (FAMA) for Packet-Radio Networks,'' in Proceedings of ACM SIGCOMM '95, 1995.

8

N. R. Figueira and J. Pasquale, ``Remote-Queueing Multiple Access (RQMA): Providing Quality of Service for Wireless Communications,'' in Proc. IEEE INFOCOM'98, IEEE Computer Society, April 1998.

9

CableLabs, ``Data Over Cable Service Interface Specification.'' http://www.cablemodem.com/public/pubtech.html, April 1998.

10

H.-Y. Tyan, B. Wang, Y. Ye, L. Su, W. Lin, and C.-J. Hou, ``NetSim ^Q : a java-integrated network simulation tool for qos control in high speed networks.'' http://eewww.eng.wustl.edu/drcl/grants/middleware97/netsimQ.html., 1999.

11

R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling,.
Wiley-Interscience, New York, NY, May 1991.
Winner of 1991 Best Advanced How-To Book, Systems awardfrom the Computer Press Association.

Footnotes

... ¹

The work reported in this paper was supported in part by NSF under Grant No. ANI989018. Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the funding agency.

... implicitly ²

To be discussed below.

... design ³

The reason why M=9 will be given in Section  3.3.

... design ⁴

The reason why N=37 will be given below.