additional bits, where
In order to get to the expression
The most important implication from the previous discussion is: any flexibility in the allocation of the communication resources corresponds to additional signaling information or metadata that needs to be communicated between the base station and the devices. Thus the flexibility can offer better use of resources, but then the overall correct operation of the protocols becomes more vulnerable to the loss or errors in the metadata.
In order to make the most of the flexibility offered by the additional signaling bits, Basil should somehow know what is the most appropriate way to allocate the slots to the users in a given frame. For example, in an ideal case, Basil should allocate two slots to Xia only if he is certain that both slots will be filled with data to/from Xia. This is not a problem for downlink traffic from Basil to Xia, as Basil precisely knows how much data there is to send to Xia and can allocate the appropriate number of slots. More precisely, the data that can be allocated in this way should have arrived to the transmit queue of Basil before the header of the actual frame has started, such that the allocation can be announced in the header.
However, making the right allocation is not that simple in the case of uplink transmission. Unless the packets of Xia arrive in a perfectly predictable way, Basil cannot always know a priori how much data Xia has to send during the upcoming uplink frame and therefore Basil has either to guess it or learn it. Consider the case in which Basil allocates two slots to Xia in the uplink frame. Then the frame header sent by Basil can be understood as a polling or an invitation to Xia to send. If Xia has only one packet to send, then the second allocated slot remains empty. Intuitively, polling should use cautious allocation of resources and minimize the number of empty responses. However, if this allocation is overly cautious, then the devices end up being inhibited in sending all their data. This can be based on a knowledge or prediction about the current demand for uplink traffic across the population of terminals that have active connections to Basil.
But, how is this knowledge obtained by Basil? Going back to the analogy with speech, one can think of a conference scenario, in which the chairman (Basil) gives word to the individuals from the audience (devices or terminals). The first difference with the TDMA communication scenario from above is that whenever an individual speaks, not only the chairman but all the people in the audience receive the data. On the contrary, in our setting a mobile device does not communicate directly with another device. Furthermore, there is another difference with the TDMA operation described previously, which is essential for protocol operation. This is the way in which the individuals signal to the chairman whether they have an “uplink traffic”, which can be done by raising a hand or pressing a button. As already mentioned several times, a raised hand or a pressed button represent an additional communication channel. So, we stick to the dark room analogy and ask: how can we imitate the raising of a hand in a dark room in which the only way to communicate is to speak? This question leads to the idea of reservation packets.
1.4.3 Short Control Packets and the Idea of Reservation
Instead of directly allocating an uplink slot to send data, each device is given the opportunity to send a short control packet, termed a reservation packet, which is used to inform Basil how many slots for sending data it will need in the TDMA frame. We need to make a distinction between reservation and data packets. The reservation packet should only carry a few bits in order to indicate how many data slots in the frame it can use. For example, if the TDMA frame has a fixed number of
Figure 1.8(a) describes a possible way to use reservation packets. Basil sends the frame header H to indicate that it allows uplink reservation transmissions to start. This is followed by