Hello Erico, Generally speaking, the packet flow is: when a packet is sent by the particular node from the network layer (down direction), it is first received by the 802_11::recv. In the 802_11::recv, the direction of the particular packet is checked, if it is down direction, the 802_11::send is called. If the packet is up direction (means that the packet is received from the phy layer), several conditions are checked including the including the state of the channel and incoming power.
Note that 802_11::recv (packet direction up) is called by all the nodes [i.e. packet is received by all the nodes] that are within the carrier sensing range i.e. approx. 2 times the transmission range and then in the packet, the error() bit is marked as 1 for those nodes that are outside the transmission range of the node and has some errors or noise. [In previous versions of ns2, the ch->error() bit is marked at the mac layer, but now it is moved to physical layer ]. See ch->error(). Note that the ch->error() is used to include the noise, bit erros: see wireless-phy.cc file, WirelessPhy::sendUp(Packet *p) function. Moreover, in the same file, you can see the modulation, FECs etc Regards Mubashir Husain Rehmani Lip6/UPMC, Paris, France On 22 February 2011 19:09, Érico Porto <ericoporto2...@gmail.com> wrote: > I understood these parameters, but the problem is, when a msg is sent, and > we have a packet, the 802_11::recv will be called by which nodes? > > And why the wireless channel nodes in range when a msg is sent get delay > time increased by a factor distance/speed of light, and why this happens > inside a square? > > Also I'm not seeing any reference to noise, so it seems that it is not even > a AWGN channel. > > Érico V. Porto > > > > On Tue, Feb 22, 2011 at 2:39 PM, Mubashir Rehmani <mshrehm...@gmail.com>wrote: > >> Please look at this also written by Kimaya on ns2 old mailing list: >> >> RXThresh_ is the reception threshold. If the received signal strength is >> greater than this threshold, the packet can be successfully received. >> >> >> >> CSThresh_ is the carrier sensing threshold. If received signal strength is >> >> greater than this threshold, the packet transmission can be >> sensed. However, the packet cannot be decoded unless signal strength is >> >> >> >> greater than RXThresh_. >> >> CPThresh_ refers to the capture phenomenon. If two packets are received >> >> simultaneously, i.e. they collide, it is still possible to receive the >> 'stronger' packet if its signal strength is CPThresh_ times the other >> >> >> >> packet. For example, if CPThresh_ is 10.0, the stronger packet in a >> >> collision can be decoded if its signal strength is at least 10.0 times >> that of the other packet; otherwise, both packets are lost in the >> collision. >> >> >> >> Hope that helps. >> >> Kimaya >> >> >> >> On 22 February 2011 18:33, Mubashir Rehmani <mshrehm...@gmail.com> wrote: >> >>> Hello Erico, >>> >>> Here are some dicussions regarding RXThresh_ that may help you >>> http://overegoz.tistory.com/668 >>> >>> http://www.lastking.net/54?TSSESSIONlastkingnet=5ec6c07a691774bd721516037eafa42b >>> http://mailman.isi.edu/pipermail/ns-users/2004-July/043516.html >>> http://mailman.isi.edu/pipermail/ns-users/2006-March/054712.html >>> >>> Best Regards >>> Mubashir Husain Rehmani >>> >>> >>> On 22 February 2011 18:17, Érico Porto <ericoporto2...@gmail.com> wrote: >>> >>>> >>>> Has anyone understood how this works? I found 158 matches to calls of >>>> Mac802_11::recv,. >>>> >>>> Any help appreciated. >>>> >>>> Érico V. Porto >>>> >>>> >>>> On Mon, Feb 21, 2011 at 2:38 PM, Érico Porto <ericoporto2...@gmail.com >>>> >wrote: >>>> >>>> > I was looking at the mac802_11.cc implementation, and looking at the >>>> > following function: >>>> > >>>> > Mac802_11::recv >>>> > >>>> > It seems that it also has another type of decision clause: >>>> > >>>> > if(pktRx_->txinfo_.RxPr / p->txinfo_.RxPr >= p->txinfo_.CPThresh) { >>>> > capture(p); >>>> > } else { >>>> > collision(p); >>>> > } >>>> > >>>> > From this code I think a package can interfere with another in a one >>>> on one >>>> > way, so multiple packages don't sum their energy to create a noisy >>>> > environment. >>>> > >>>> > Also, if one package Receive power is CPThresh times bigget the >>>> another, >>>> > than it is received, otherwise, it as marked as colision and >>>> discarded. >>>> > >>>> > Érico V. Porto >>>> > >>>> > >>>> > >>>> > On Mon, Feb 21, 2011 at 2:05 PM, Érico Porto < >>>> ericoporto2...@gmail.com>wrote: >>>> > >>>> >> Hello everyone, >>>> >> >>>> >> I was looking at how the NS-2 implements the interference that a noda >>>> has >>>> >> over the other... So I map this functions: >>>> >> >>>> >> (phy.cc) Phy::recv -> >>>> >> (wireless-phy.cc) WirelessPhy::sendDown(packet *p) -> >>>> >> (channel.cc) WirelessChannel::Recvd(packet *p) -> >>>> >> WirelessChannel::SendUp(packet* P, Phy * tifp) -> >>>> >> getAffectedNodes(mtnode, distCST_ + 5, &numAffectedNodes) -> >>>> >> distCST_ = wifp->getDist( wifp ->getPowerMonitorTresh(), >>>> wifp->getPt(), >>>> >> wifp->getAntennaRxGain(), wifp->getAntennaTxGain(), highestZ, >>>> highestZ, >>>> >> wifp->getL() ) >>>> >> >>>> >> The getDist function implementation depends on what model is being >>>> used: >>>> >> >>>> >> (propagation.cc) [freespace/friss] lambda/(4pi) * sqrt(Pt Gt Gr / Pr >>>> L) >>>> >> (tworayground.cc) {tworayground] hr/ht sqrt(Pt Gt Gr / Pr) >>>> >> >>>> >> Also I was reading this : >>>> >> http://www.cs.binghamton.edu/~kliu/research/ns2code/note.pdf ; and >>>> >> looking at that and at the code, it became strange that, looking at >>>> the >>>> >> code, a node affects the nodes in a SQUARE centered in the one which >>>> is >>>> >> sending, with a distance from the getDist plus 5. >>>> >> >>>> >> I may be wrong, but a Node was suposed to interfere with another, >>>> with a >>>> >> bigger distance than just the Friss model distance - something like >>>> twice >>>> >> that distance... ???? >>>> >> >>>> >> Érico V. Porto >>>> >> >>>> > >>>> > >>>> >>> >>> >>> >>> -- >>> Mubashir Husain Rehmani >>> >>> >>> >> >> >> -- >> Mubashir Husain Rehmani >> >> >> > -- Mubashir Husain Rehmani
