Reverse Traffic Channel MAC of 1xEV-DO Revision A Description

Reverse Traffic Channel MAC of 1xEV-DO Revision A Description

Last updated: July 25, 2008

This section is only applicable to the lab application.

The Subtype 3 Reverse Traffic Channel MAC Protocol is for 1xEV-DO Revision A Subtype 2 Physical Layer. It provides the procedures and messages required for an Access Terminal (AT) to transmit, and for Access Network (AN) to receive the Reverse Traffic Channel. This protocol supports intra-access terminal Quality of Service (QoS) for multiple concurrent active MAC flows at the AT. Rate control is accomplished via per active MAC flow Traffic-to-Pilot power ratio (T2P) control. The Subtype 3 Reverse Traffic Channel MAC protocol provides per active MAC flow QoS. This is achieved by distributed rate selection (at the AT) and centralized (scheduled) resource allocation (by the AN).

1xEV-DO RevA supports reverse traffic data rates ranging from 4.8 kbps to 1.8432 Mbps (See R-Data Pkt Size for details). The data rate is a function of payload size and latency target, where latency target is the number of transmission subpacket required to achieve the desired packet error rate (PER), and can be 1, 2, 3 or 4 subpackets. Latency target is controlled by varying the traffic channel power ratio above pilot power (TxT2P) of each subpacket for a given payload size. Note that shorter latency target packets require larger Eb/No for the same throughput. The RTCMAC function can be described in simple terms: at each subframe where a new physical packet allocation is possible, the RTCMAC chooses a payload size and TxT2P profile and designates which application bits are to be placed in the packet. But in reality, many factors will affect the system performance such as network stability, flow QoS constraints, resource allocation fairness and efficiency interact across the network. So the system uses RTCMAC Closed-Loop Rate Control method to control the physical layer resources.

RTCMAC Closed-Loop Rate Control

The process is inllustrated in the figure above. The Rise-over-Thermal (RoT) at a sector is defined as the ratio of total received power to thermal noise power. This quantity is readily measurable an self-calibration, and provides an estimate of the interference seen by each AT. The RoT also has a direct relation to sector stability, for it is an indication of the degree to which received power will react to changes in loading. For these reasons the RoT is used as the load metric. To control RoT, each flow's contribution to it need to be measured. Each AT physical layer packet consists of data from one or more AT flow, the average TxT2P transmitted by an AT contributes directly to average RoT of the sector, so the MAC-Layer variable T2PInflow defined as the resource level in the network that is currently assigned to the flow is introduced. Effectively T2PInflow is a measure of RoT consumption in units of pilot power.

The Reverse Activity Bit (RAB) is the control bit in each sector, it indicates if the AN is busy. Sector load is estimated by filtering the RAB over a time interval, yielding a load estimate referred to as Filtered RAB (FRAB). The T2PUp and T2PDown functions may be a function of FRAB. In each slot the filtered RoT value is compared with an RoT threshold. If it is larger than the threshold, RAB is set to busy, otherwise RAB is not busy. Each flow in the network receives RAB from a set of sectors, generally those receiving significant power from the AT and interprets the resulting signal as busy if any of the controlling sectors is busy. Each flow increases its T2PInflow level by its T2PUp value when its sectors are all not busy and decreases it by its T2PDown value otherwise. Hence, when a sector is busy associated flow ramp down their T2PInflow levels, which subsequently convert to less TxT2P transmission, thereby lowering sector RoT. The converse occurs when a sector is not busy.

The T2PInflow is the mean transmission resource available to a flow, and is set via ramping function interaction with RAB. The bucket mechanism is introduced to convert T2PInflow resource into flow packet transmission. Each flow maintains a bucket for storing unused T2P resource, up to some maximum level. As flow data arrives, bucket resource is used to allocate packets, subject to a maximum bucket withdrawal rate based on peak-to-average access control. In this way average resource usage is bounded by T2PInflow, but locally bursty allocations can be made for data sources that benefit from them. Peak-to-average control, referred to as BucketFactor, restricts how bursty the AN received power can be from each flow. RoT stability is affected by both pilot power control imperfection and RTCMAC allocation burstiness.

So 1xEV-DO RevA RTCMAC provides fully centralized control of network resource allocation for arbitrary configuration of network flows, achieved through support of robust and efficient QoS functionality. Once at flow connection the AN and AT will negotiate many attributes to control the physical layer resource. The users should configure the following parameters as the QoS requirements:

Related Topics


GPIB Commands: CALL:MS