OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
OZ1KPM > DAMA     10.08.96 16:45l 350 Lines 17948 Bytes #-10143 (0) @ EU
BID : 14421-OZ1KPM
Read: DJ4XR DJ4RX GUEST
Subj: DAMA - A New method of handling packe
Path: DB0AAB<DB0SL<DB0RGB<DB0ABH<DB0SRS<DB0SIF<DB0NHM<DB0JES<DB0TUD<DB0NDR<
      DB0HES<OZ7BOX<OZ2BOF<OZ9PAC<OZ4PAC<OZ4BBS<OZ4BOX<OZ3BOS<OZ7PAC<OZ3BUL<
      OZ3BOD
Sent: 960810/0937Z @:OZ3BOD.HGR.SJL.DNK.EU $:14421-OZ1KPM [Helsing›r] JO66GA
From: OZ1KPM@OZ3BOD.HGR.SJL.DNK.EU
To  : DAMA@EU

R.960810/0933Z @:OZ1KPM.HGR.SJL.DNK.EU #:14421 [Helsing›r]


            DAMA - A NEW METHOD OF HANDLING PACKETS ?
            ==========================================

by Detlef J. SCHMIDT, DK4EG   Steinbrecherstr. 22    D-38106 BRAUNSCHWEIG

                        NORD><LINK e.V.
                        c/o Peter G}lzow, DB2OS
                        Allensteiner Str. 5
                        D-30880 LAATZEN
                        Germany

              Translation : Mark Bitterlich, WA3JPY
              Reprint     : Pierre Cornelis, ON7PC

Lately it seems we are hearing more and more stories about hams who are
having trouble using their local node or digipeater. It seems that the user
has no trouble hearing the digi, but the digi doesn't seem to hear the user
at all. The symptoms almost match those where the receiver at the digi site
is either dead or close to it. While that kind of failure is always a
possibility, it is not the subject of this article.

The condition that this paper will talk about is one where the above
symptoms do actually occur, but not from any lack of receiver sensivity.
Instead it is due to the digi's receiver hearing too many signals all at
once and the remote user pretty much gets lost in the "noise".

The reason for this becomes obvious when we consider that while all the
users may hear the digi/node just fine, they in many cases don't hear each
other. Thus in some cases, more than one station will transmit at the same
time causing packet collisions. This situation is referred to as "a hidden
station" problem, and for remotely located users access to his or her
favorite digipeater become difficult to impossible during rush hour
periods.

This is not a new problem, and in fact there are other services
experiencing the same difficulties. A real world example is ships on the
open sea trying to gain access to a communication satellite.

Several different experiments have been made to overcome this dilemma on
amateur packet radio. One possible solution that is being pursued is
through the use of full duplex digipeaters (BTMA), however there are
several disadvantages to this approach. In a full duplex the hardware
expense will normally be much higher and the system will occupy two
frequencies but will only realize the maximum throughput of one. A better
approach might be to increase the throughput by reducing the collisions on
a single channel system rather than spreading the load onto two channels.
It would be ideal if we could incorporate a system that did this with
something so minor as software change (such as replacing the EPROM in a
TNC) or by changing some operational parameters.

One of the methods used that attempts to solve the hidden station problem
while still using a single frequency is called DAMA (Demand Assigned
Multiple Access). A description of this method follows.

In a connection oriented protocol environment, an end user will try to
connect to the master (satellite) by means of a slotted ALOHA method
(channel access without any coordination). Collisions might occur during
this phase but they are tolerable since they are relatively rare. Once a
connect request is recognized by the master, the connecting stations
identification is added to the polling list and from this point on the
master controls all connected stations. Permission to send data is granted
by means of polls which might be included in ACK packets or even in
transferred data frames.  so in this case a user will only be allowed to
transmit after receiving "permission" in the form of a poll sent from the
master station. Once permission is granted several frames might be
transmitted in a block. However, if the user does not respond within a
given time frame (say around 1/2 second) then the master assumes that the
poll got clobbered or the user never received it for some reason. The
master then passes permission to to transmit to all other active stations
and when completed comes back to the first user and gives him another
chance.

On the other hand, if the user (slave) actually receives the poll and
replies with sent I frames, the master will not acknowledge them until the
next time around after serving all the other active stations. If when
polled by the master, the user responds with an empty frame (Receive
Ready/Final), then the master will reduce the user in polling priority and
will skip him on the next time around.

As the activity on the frequency increases, the polling priority of
inactive users might be further decreased, but when these stations respond
with an I-frame they will again regain their original priority.

If you understand the description just given, you might think that you are
reading about AX.25 level 2 protocol and this is why DAMA has a chance of
working over amateur packet radio. AX.25 L2 provides all the protocol
elements that are needed to implement DAMA and no new syntax is required.
Most of the new functions required could be obtained simply by patching
existing operational parameters while the rest could be achieved by making
some minor changes to the TNC's firmware.

So how do we actually go about incorporating DAMA using AX.25 protocol ?

Due to the fact that there are no new syntax elements required, the
following description will only use standard AX.25 terms. Since CSMA
(Carrier Sense Multiple Access) as well as DAMA is used, please interpret
all future references DAMA as CSMA-DAMA. The term "poll" used throughout
this text in no way refers to the poll bit  in the control field of packet
frames and this bit remains unchanged to ensure compatibility. The
different phases of the protocol will be described separately below.

Connect Establish :
-------------------

When a node attempts to connect to a user, the node adds the users ID to
it's polling list and begins to send SABMs to that station. If after a
certain amount of tries no UA is received, the user is assumed to be
inoperable and is removed from the polling list.

When a new user starts a connect sequence to the node, he begins by sending
SABMs to the master in a simple CSMA manner duplicating the existing method
used today. Collisions are possible during this phase, so it might be
necessary to repeat the SABMs several times until the node replies with a
UA. Once the node recognizes the users connection attempt, the users ID is
added to the polling list in a fashion very similar to the one used by
TheNet nodes (TheNet userlist) and the node (master) is now in control of
the uplink users station. After the user sends SABMs and the node replies
with a UA, the user replies with an RR0 to signal to the node that it had a
successful reception of UA.

Idle state :
------------

As long as no information transfer occurs between user and node, (idles)
then the node sends its polls as an RR with the corresponding count. If the
response by the user is just an RR#, then the time until the next poll to
the user will be lengthened to avoid unnecessary channel load. The exact
amount of time added is determined by the total channel activity.

If information transfer by other users on the node is high (as determined
by the number of I-frames being sent) then the amount of time  added before
the next poll occurs to an inactive station is longer than in cases where
there is only very little  channel activity. Thus when the frequency is
basically clear, the waiting times are reduced to a minimum so that no
decrease in channel throughput takes place. This is the principle of the
self-alignment mechanism of DAMA, where a channel is always regulated to
insure its maximum possible throughput.

If the node ever fails to receive an RR from the user (due to a collision
of the nodes poll or the users RR response) then the node will proceed on
to the other stations on its polling list. The node will come back and try
this station again after all the other users on its list have been
serviced. If after a certain number of transmitted polls this station still
has not answered, then it is considered to be unavailable by the node and
is dropped completely from the list. This is analogous to those "keep-alive
polls" that we have today.

Data transfer : Node --> User :
-------------------------------

There is no difference between regular CSMA and DAMA in this case. Because
it is always up to the master (node) to act first, it could send one or
more I-frames or a poll to the user. The user will acknowledge I-frames
immediately with an RR#, but could also send its own I-frames with the
corresponding count (having to correct the count on the sent I-frame serves
the same purpose as an ACK with AX.25). The meaning of the Poll/Final bit
remains unchanged.

Data transfer : User --> Node :
-------------------------------

As mentioned before, the node will send polls to all users that are
uplinked to it and the user will not respond until it receives this poll or
an I-frame from the node. It may be wise to point out that when a user is
polled he must always come back with some kind of response, even if it is
an RNR#. If the node fails to hear any kind of response from the user then
it assumes something went wrong (such as a collision) and moves on to the
next user on its polling list.

This method of always waiting for a poll before transmitting is the central
aspect used to avoid collisions in a situation where hidden stations exist.
This is in contrast to the usual CSMA method where several stations can
actually transmit at the same time. Additionally the problem of deadtime
collisions is resolved. Deadtime refers to the period from when the TNC
realizes the channel is free and starts transmitting, to when he has been
on the air long enough for other TNCs to recognize his carrier. This is
really not a rare case, as exemplified by the case where two or more TNCs
are waiting for a digipeaters carrier to vanish so that they can leap on
the frequency. Using DAMA the node will not acknowledge received frames the
instant it hears them. Instead it will first service all other uplinked
stations and then come back with an RR# to the sending stations I-frames
along with a poll to that station. This poll basically says "Have you got
any else for me ?".

Disconnecting :
---------------

If the master intends to cut the connection, it will send the usual
DISC-frame to the user. The user will then promptly respond with the
UA-frame (final bit set). If the node fails to receive the UA and again
sends a DISC-frame, the user will respond with a DM-frame. This is
identical to the actual CSMA version.

When the user wants to disconnect from the node, he will wait to send his
DISC-frame until polled by the master. AT this point it makes no major
difference whether the node responds to the user right away with a UA or
goes through another polling cycle to do so, however an immediate UA is
preferred.

UI-frames :
-----------

In CSMA as well as in a DAMA environment, the UI-frames are treated in a
special way. I.E. These frames are used to carry some information besides
the regular protocol traffic. Normally UI-frames are never sent from a user
to a node, and it is not good headwork to make a habit of making UI-frame
direct QSOs on the input frequency of a node. However, in contrast to a
duplex system, it is possible to actually do this. So although the rare
UI-frames will reduce the throughput to the CSMA value, it will not drop
the much lower ALOHA value that would occur with a duplex digi having a QSO
on its input frequency. UI-frames originated by the node are no problem
since all stations receive these frames.

Other protocol elements :
-------------------------

So we have gone from the beginning to the end in describing a complete DAMA
session. We have not translated each and every AX.25 element into one that
has a special significance to DAMA. This is not required since many of them
will keep their initial meaning. DM, RNR, REJ, etc will all be used as they
were before. The only deviation from the pure CSMA version is in the fact
that the users will only be allowed to transmit these frames after
receiving permission from the master (node) in the form of a poll. The node
will only transmit these frames after all other users on its list are
served by completion of one polling cycle.

Compatibility of DAMA and CSMA :
--------------------------------

One advantage of the DAMA method is that it does not require everybody to
change everything all at once. However as additional users convert their
TNCs to work with DAMA the more pronounced will become the increase of
throughput. Even stations that are waiting to switch over could help to
increase the areas throughput by changing a few operational parameters. For
example the delay between the reception of a frame and the TNCs response
(sometimes called T2 or DWAIT) should be reduced to a value under 1 second.
In addition the time interval from when an I-frame is sent to when the TNC
sends an RR# to ask for a pending ACK, should be set to a value that is
clearly higher than the time between two polls of the master (usually more
than 30 seconds at 1200 Bd).

To fully benefit from DAMA both the node and the user must work together in
the master/slave relationship. Assuming that the users TNC is capable of
both the normal and the DAMA mode, there still remains the problem of how
to tell the user to "turn DAMA mode on". There are several ways that this
could be done:
1. Automatic detection of the protocol version by means of the protocol
identifier byte or reserved SSID-octet-bits of the node (preferred
version).
2. Implementation of a channel specific parameter which controls the
protocol version.
3. Implementation of a new UPLINK command besides the current CONNECT
command.
4. Implement a further protocol element such as a SABM-frame (similar to
X.25) so that at connect time the node could alert the user to the
increased features.

In case #1 of the above it would be sufficient to tell the user to switch
DAMA mode only once, at connect time. This state would then remain in
effect until disconnect. However since there is no PID  field in
SABM-frames this information has to be carried in some other way, such as
utilizing the dormant bit 5 of the master's SSID address field. It is
proposed that DAMA test versions set this bit to 0 to convey the necessary
information to the users TNC.

Conclusion :
------------

The existing AX.25 version was established in 1982 when packet radio was
not widespread as it is today. Most stations in the beginning were pretty
much equal and there was no distinction made between DTE and DCE functions.
However with the implementation of wide area networks not all stations are
performing the same function. In fact today the network nodes are acting in
DCE function considering their control and information exchanging aspects.
These functions will be better served with the implementation of DAMA.

The methods discussed in this article could increase the throughput on an
AX.25 channel tremendously. One advantage is the avoidance of system
breakdown which occurs with channel overload. Using DAMA, the throughput
will increase continuously up to its maximum. There is no foldback effect
like that which occurs using CSMA where at a special limit (above ca 60%)
the throughput is actually reduced.

There is also a strong "social" aspect of DAMA wherein even the weak
stations can work through the node reliably without being overpowered by
stations close to the node.

It is possible to make direct connections with other HAMs on the uplink
frequency unlike that of a duplex system. In addition the users TNCs still
retain the digipeater capability inherent in our present simplex system.
All protocol elements keep their original meaning which allows both
versions to be utilized on the same frequency, yet throughput increases as
more and more users switch over to the new method.

 Literatur

 Fox,T.        AX.25 Level 2 protocol specifications    AMRAD

 Kauffels,F.J. Lokale Netze                             R.M}ller Verlag

 Mahle,C.      Satellite Scenarios and Technology       IEEE J. on selected
 Hyde,G        for the 1990's                           Areas in communication
 Inukai,Th.                                             May '87

 Schmidt,D.J.  DAMA, ein neues Verfahren f}r            cq-DL, 4/89
               Packed-Radio?

 Schmidt,D.J.  Synchrone DF]-Protokolle mit 6809-Micro- TU-Script BS '81
               Computern in heterogenen Sternnetzen

 Tanenbaum,A.  Computer Networks                        Prentice Hall Verlag

-------------------------------------------------------- July 24, 1992 ---

Note by DB2OS: The full DAMA protocoll is implemented in the latest
               version of TheNetNode (TheNet for PC) as a DAMA MASTER
               and TheFirmware (WA8DED Hostmode for TNC2) as a DAMA
               SLAVE by NORD><LINK. DAMA is also supported by TFPCX, a
               resident AX.25 software TNC for the PC (only external
               Modem required, no TNC) and by TFKISS (former TFPCR).
               TFKISS emulates a TNC with TheFirmware and any TNC
               can be used if it can be switched into KISS-Mode!!!
               DIGICOM and BAYCOM Software also now supports DAMA.
               DAMA is now used on several german TNN digipeaters and 
               the results are of great promise. 
----------------------------------------------------------------------------

Marcus Busch (DL1EKC)
Volksgartenstrasse 194                       * CW forever *
D-41065 Moenchengladbach
Universitaet Duesseldorf

=====================================================================73=====


Vy 73 de OZ1KPM Kenneth                    

     OZ1KPM @ OZ3BOD.HGR.SJL.DNK.EU           
     InterNet: E-mail khp@it.dtu.dk    WWW: http://www.it.dtu.dk/~khp
     Sysop: OZ3BOD BBS Helsing›r JO66GA, OZ7DIG NODE Helsing›r JO66HB

/ACK


Read previous mail | Read next mail


 18.05.2024 19:09:06lGo back Go up