Multipacket Reception MAC Design in Heterogeneous Channels
3.3 Cooperative Multi-Group Priority Protocol
The flag-bit is the instrumental mechanism for facilitating the multi-group priority based user service in the MGP protocol. The central idea of the proposed CMGP scheme is to exploit the flag-bit message for distinguishing the direct links from the relay ones. By assigning different service priority to different types of links, the throughput degradation due to the packet relaying overheads can be limited, and an increase in the network-wide throughput can be achieved.
3.3.1 Operation of the Proposed CMGP Protocol
If user i is permitted to access the channel, as in the MGP scheme a flag-bit b is appended at i the tail of the packet upon transmission. The flag signature is ON (b = ) only if the second buffer i 1 is non-empty and contains a data packet also of user i. The flag signature is instead OFF (b = ) i 0 when either one of the following cases is true: i) the second buffer is empty, ii) the second buffer is nonempty but the packet therein is received from some other user j
( )
≠i . Upon successful packet reception, the CC decodes the flag-bit message and then schedules the user access according to the MGP protocol. If packet reception failure occurs at the CC and user k, who is not in the access setand has empty second buffer, successfully decodes the transmitted packet from user i, user k can serve as the relay in some upcoming channel access period1. If none of the users can serve as the relay, which happens when all other users’ buffers are non-empty or none of the users can successfully receive the packet, user i then re-transmits this packet during the next channel access.
We note the following key features regarding the proposed protocol:
1) The adoption of the flag-bit provides an in-built mechanism for the CC to dintinguish between the direct and relay-or-idle links for service scheduling. Users with flag-bits ON for direct data transmission will be arranged into either the ACTIVE or the PREM group, and thus enjoy potentially higher channel access priority. This prevents possibly frequent data relaying when collision occurs, thereby reducing the throughput penalty incurred by the packet relaying overheads.
2) Thanks to the PREM mechanism, users who are not permitted to access the channel over a time period longer than the threshold S will be granted with the highest service priority.
This can limit the service delay of the relay links, and can thus maintain the overall QoS requirement.
3) In the proposed protocol, each user takes his/her turn to access the channel according to the prescribed service priority. There is no need for active user identification, and the protocol complexity can be substantially reduced.
3.3.2 An Illustrative Example
This subsection uses an example to demonstrate the proposed CMGP protocol. We consider a network of M = users, and assume for simplicity that i) 4 n U =0
( )
2 attains the MPR channel capacity irrespective of the index set, and ii) the time slot threshold above which the STANDBY or
1 The newly generated packets of user k always enjoy the highest processing priority and, due to limited buffer size, may cause the dropping of the buffered packet from user i.
Fig. 3.2 An illustrative example.
ACTIVE users will be promoted into the PREM group is S =3. The traffic status of user i is summarized in a tag shown in Fig. 3.2 (a), in which the first field represents the user ID, second field is the counts of waiting slots, third and fifth fields represent the content of the two buffers, and forth field marks the status of the flag-bit. Fig. 3.2 (b) depicts the operation of the proposed protocol during three consecutive time slots, and is also explained in detail as below.
- At the end phase of slot t − : 1
The PREM group is empty; user 1 is in the ACTIVE group, users 2, 3, 4, are in the STANDBY group.
- At the start phase of slot t:
User 1 (with b = ) and user 2 (with 1 1 b = ) are allowed for channel access. 2 0 - At the end phase of slot t:
(i) The packet of user 1 is successfully received by CC; user 1 remains ACTIVE but the flag
is updated to b = since its second buffer is empty. 1 0
(ii) The packet of user 2 is not successfully received by CC; user 2 is put into the bottom of the STANDBY group.
(iii) User 3 successfully decodes the packet of user 2 and will serve as the relay.
- At the start phase of slot t +1:
User 1 (with b = ) and user 3 (with 1 0 b = ) are allowed for channel access. 3 0 - At the end phase of slot t +1:
(i) User 3 successfully relays the packet of user 2 to CC, and is then put to the STANDBY group since b = . 3 0
(ii) The CC fails to successfully receive the packet of user 1, and thus does not correctly decode the current bit message. User 1 remains ACTIVE since the latest flag message available to the CC is the previous setting b = . 1 1
(iii) User 2 successfully received the packet of user 1 and will serve as the relay.
(iv) User 4 (with b = ) has not been allowed to access the channel for more than 4 0 S =3 time slots, and is moved into the PREM group.
- At the start phase of slot t +2:
User 1 (with b = ) and user 4 access the channel. 1 0
3.3.3 Algorithm Summary
The proposed CMGP protocol is summarized as below.
CC-end:
I. Put all users into the PREM group.
II. Select first n U0
( )
users (by the order of PREM, ACTIVE, and then STANDBY group) to access the channel.a) If the packet of a certain user is received successfully, then put the user to the tail of the ACTIVE (if the flag-bit is on) or STANDBY group (if the flag-bit is off). And reset its
Fig. 3.3 Flow chart of user acting as a relay.
count of waiting slots to zero.
b) If, for a certain user, the buffer is empty (no packet sent) or there is a packet transmitted but not successfully received, and then put the user back to the tail of the STANDBY or ACTIVE group in which the user originally stayed. Reset its count of waiting slots to zero.
III. Increase waiting slots of all users by one.
IV. Move those users with waiting slots equal to S to the PREM group.
Fig. 3.4 Centrally controlled state transition diagram of an individual user.
V. Repeat steps II to IV.
User-end:
I. If the packet of user i is received successfully by some other user j, and then user j will store this packet if it has at least one buffer empty.
II. If an ACK for user i's packet is received by user j, then user j will remove user i's packet from his/her buffer.
The detail flow chart of client-end protocol is shown in Fig. 3.3, and the group transition diagram of users is shown in Fig. 3.4.