Re: Wireless Channel error model

[Karunaharan Ratnam <karu@ece.neu.edu>]

Javier,

I guess I didn't make my point very clear. Even though errors are inserted
on both up-link and down-link, they are inserted independantly of each
other. As the code from ns-lan.tcl you quoted below says, there are two
instances of ErrorModel/.. is installed one for uplink other for downlink.

For example, if we use,
	set e1 [new ErrorModel/MultiState/TwoStateMarkov $rate  $trans $unit]
	set e2 [new ErrorModel/MultiState/TwoStateMarkov $rate $trans $unit]

and let the two states be 'good' and 'fade', then, when $e1 is in 'good'
state, it is possible that $e2 may be in 'fade' state. 

The problem is we cannot install $e1 on both links.

Isn't it correct?

Karu.

> 
> Hi Karunaharan, below is the definition of create-error in ns-lan.tcl. At
> the end of the procedure the error is 'inserted' in both downlink, uplink:
> 
> 		$self install-error $src $dst $e1
>                 $self install-error $dst $src $e2
>  
> Unless you change this, the error will be for up/down link. You can of
> course use only uplink or downlink if you want, but as you said this is
> not a good model for wireless. The other choice in ns-lan.tcl is when you
> do not include the source and destination pair, in this case the error
> model is inserted in the "channel" of the lan, which means it will create
> errors for any transmission on the lan no matter from which mobile is
> comming from.
> 
> You can post this if you want...
> 
> LanLink instproc create-error { src dstlist emname rate unit {trans ""}} {
>         if { $trans == "" } {
>                 set trans [list 0.5 0.5]
>         }
>  
>         # default is exponential errmodel
>         if { $emname == "uniform" } {
>                 set e1 [new ErrorModel/Uniform $rate $unit] 
>                 set e2 [new ErrorModel/Uniform $rate $unit] 
>         } elseif { $emname == "2state" } {
>                 set e1 [new ErrorModel/MultiState/TwoStateMarkov $rate
> $trans \
>                                 $unit]
>                 set e2 [new ErrorModel/MultiState/TwoStateMarkov $rate
> $trans \
>                                 $unit]
>         } else {
>                 set e1 [new ErrorModel/Expo $rate $unit]
>                 set e2 [new ErrorModel/Expo $rate $unit]
>         }       
>  
>         foreach dst $dstlist {
>                 $self install-error $src $dst $e1
>                 $self install-error $dst $src $e2
>         }
> }
> 
> 
> 
> --Javier
> -----------------------------------------
> COMET Group
> Columbia University, New York. 	
>  
> On Sun, 9 Aug 1998, Karunaharan Ratnam wrote:
> 
> > > 
> > > 
> > > i do not think this is correct, i believe the error model 'injects' errors
> > > in the LAN base on packets, bytes or bytes, independent if it is downlink
> > > or uplink, you should check the code for that.
> > > 
> > > --Javier
> > > -----------------------------------------
> > > COMET Group
> > > Columbia University, New York. 	
> > 
> > 
> > Javier:
> > 
> > I agree. But, the LAN is made up of point-to-multipoint links, and the
> > ErrorModel is installed seperately for downlink and uplink (see ns-lan.tcl).
> > Hence, the error injection is independant.
> > 
> > Karu.
> > 
> > PS: Is it okay if I post this reponse to ns mailing list?
> > 
> > >>On Sat, 8 Aug 1998, Karunaharan Ratnam wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Question on error model (particularly for wireless channels).
> > > > 
> > > > Looking at the ns-lan.tcl, the ErrorModel is installed independantly
> > > > for forward link and reverse link.
> > > > In other words, when the ErrorModel uses Expo or TwoStateMarkov,
> > > > forward link can be in 
> > > > burst error state (fading) but the reverse link may not be experiencing
> > > > any fading, and transmitting error free.
> > > > 
> > > > Is it a correct model for wireless channel.
> > > > 
> > > > The links cannot be totally independant because,
> > > > * Fadding affects on both links are almost same (even if different
> > > > bands were used they are in similar spectrum).  
> > > > 
> > > > The links may not be totally dependant because,
> > > > * Radio at the hub (base station) may control power differently
> > > >   to handle the fading than the customer radio.
> > > > 
> > > > I'd like to see response on this (especially from radio engineers).
> > > > 
> > > > Karu.
> > > > 
> > > 
> > > 
> > 
> > 
> 
>