A proposal for packet radio conferencing by John Unruh, NY9R Before Christmas, Phil Karn, KA9Q, posted a "challenge" for someone to study the problem of conferencing by packet radio. While thinking about the problem, I talked to several packet radio experimenters about the problems. It seems that the essence of the problem is that in a single frequency conferencing system, each station with a message contends for access to the conferencing "bridge". Once the bridge hears an error free packet from some station, it acknowledges the packet and then sends the packet to every station that is "connected" (in the AX.25 sense) to the bridge. Each station that receives the packet must acknowledge it to the bridge. Thus, the channel is used to receive the initial packet from the sending station, then to send it to each of the other stations on the conference, and to acknowledge each transmission. Depending on the maximum number of outstanding packets at each station, the acknowledgement timeouts, and the number of stations, this can lead to heavy channel loadings and low throughput due to many collisions. My proposal is to use the broadcast nature of radio by abandoning AX.25 connected mode and switching to a broadcast protocol for conferencing. The most likely implementation for this would be to build a protocol on top of disconnected mode AX.25 level 2 (UI frames) or on top of UDP (using a broadcast address). I am proposing a "token passing" protocol with centralized control. The conference bridge explicitly gives each station in the conference permission to transmit. Once the permission is received, the station will transmit to the conference bridge using CSMA channel access. If the frequency were clear of other traffic, the station could just blast away. Since I am assuming that several conferences (and other communications) may be on the same frequency simultaneously, so CSMA is necessary. The conference station that was given permission to transmit by the bridge must either transmit a packet for the conference or transmit a packet indicating that there is not any data for the conference. When the permission to send is transmitted, the conference bridge sets a timer. In a simple implementation, this timer might have a fixed value. Performance would probably be improved if the length of the timer were somewhat longer than an estimate of the round trip delay based on recent transmissions. If the station that received permission does not reply before the timer expires, permission is sent again. If the station does not reply the second time, it is bypassed. After bypassing a station several times because of timeouts, the bridge will assume that the node has left the conference and will no longer give it permission to transmit. Upon receiving the transmission from the station that had permission to transmit, the bridge will store the packet, insert a conference sequence number, and retransmit it. When the station that originated the packet hears the bridge repeat it, it assumes that the bridge received the packet correctly (this is an echo acknowledgement). Note that the bridge must use the CSMA channel access protocol to avoid colliding with other traffic on the - 2 - frequency. The repeated packet from the bridge contains not just the data for the conference, but the permission for the next station in the conference to transmit. If the station that just transmitted sent an empty packet (no data) or did not respond, the bridge will send a packet with only a permission for the next station to send. When the next station receives permission to send, it will send data (or a no data response) just like the preceding station if it has received all the packets correctly since its last transmission. If it didn't receive a packet in the sequence, it will send a message indicating which packets it did not receive correctly (this number is bounded by the number of possible transmissions between the times this station is serviced). The bridge will then retransmit the first missing packet and give permission to transmit to the station that reported missing packets. When that station no longer reports missing packets, it will have a chance to transmit its data. Even though one node reported a missing packet, every node receives the retransmitted packets from the bridge, and, if received correctly, will not ask for a retransmission during that stations turn to transmit. Once the bridge returns to the originator of a packet, the stored version can be discarded since, if the originator has not received the packet correctly, it will retransmit it on its turn rather than ask the bridge for a retransmission. This method was chosen because when a node does not hear its own packet retransmitted, it may be because the bridge did not hear the packet at all. Since each packet will contain both a sequence number from the originator and a conference sequence number from the bridge, if the originator just failed to hear its own packet repeated and retransmits it, the other nodes will know it is a duplicate that should be discarded when it is repeated by the conference bridge. When a station wishes to leave the conference, it sends a finish message on its turn. From time to time, the conference bridge gives transmit permission to "any node wishing to join the conference". Any station that wants to enter the conference then contends for the frequency using CSMA. Any station that is heard correctly by the bridge is admitted to the conference, and the bridge sends it permission to transmit next. This permission is the acknowledgement to the joining request. When a conference is not is progress, the bridge will be silent. If a station wishes to start a conference, it will first listen for bridge transmissions. If it cannot hear the bridge, it will then send a start conference message. If the bridge is on the air but the node wishes to start a different conference on the same bridge, it will wail until the bridge asks for new nodes that wish to join the conference. It will then send a request to start a new conference. When the last station leaves a conference, the bridge will consider the conference ended and cease transmissions for that conference. - 3 - The exact form of addressing depends on the underlying protocol. The addressing idea, however, remains constant. Any packet from a node to the bridge has a source address of the node and a destination address of the bridge with a conference number appended. The conference number is used to assure that multiple conferences on the same frequency that might be using the same bridge are kept separate. Packets from the bridge to a node are sent with the bridge address as a source and the destination address is a broadcast address with the conference number appended. Appending the conference number might consist of putting something into address fields in the underlying protocol (such as a SSID in AX.25 or a port number in UDP), or it might consist of fields in the conferencing protocol structure. Since the conference bridge polls each station for transmissions, it has the opportunity to construct a transmission schedule for the conference. Round robin is both a simple and fair schedule for a conference. Unfortunately, in a polling system under the assumption that most of the time most stations will have nothing to transmit, I would recommend a system that would give more transmission opportunities to those stations that have had transmissions in the recent past. A reasonable heuristic might be to keep a list of those stations that have had transmissions with data in the last four visits and a list of all the other stations. The stations that have had recent transmissions would be polled twice as often as those that had not. This assumes that some stations are actively involved in an exchange at the time, and that others are either listening or preparing responses. A second scheduling issue involves providing a place in the schedule for additional stations that wished to join the conference. As a starting point, I would recommend once on each time around the conference. For a small conference, this would not add much delay, and it would provide a limiting effect on the number of participants in a large conference. Due to buffering limitations in the conference bridge and channel loading limits, the bridge might stop asking for stations to join the conference when large conferences are in progress. When I mention using the CSMA channel access protocol, I actually mean that a station should listen before transmitting, and back off if necessary. If a node in the conference hears the bridge go to the next station while waiting for an opportunity to transmit, it should refrain from transmitting since that would only cause collisions. This protocol is intended to improve channel usage by limiting collisions and by recognizing that the conference bridge must transmit after each packet it receives. Therefore, a protocol for conferencing should attempt to prevent stations from colliding with the bridge. Finally, it attempts to minimize transmissions by using the broadcast nature of packet radio to have the bridge retransmit each packet only once, by using echo acknowledgements, and by having each station listen to retransmissions to get any packets that it missed. In many ways, this protocol has the conference bridge taking the place of a net control operator on a - 4 - typical 2 meter net. John Unruh, NY9R att!ihlpf!jdu