[Ns-developers] Mac layer 802.11n

[Mirko Banchi]

Mathieu Lacage ha scritto:
> On Wed, 2009-01-07 at 12:25 +0100, Mirko Banchi wrote:
> 
>> Use of A-MSDU or A-MPDU should be chosen according to type of traffic.
>> The idea is to implement the possibility of choose first, second or
>> both.
> 
> Ok. Is it the responsability of the MAC layer to choose whether to use
> A-MPDUs or is the PHY layer expected to be able to make its own choices
> on its own without interference from the MAC ?

How and when aggregation (both) is an user's choice. User will be able
to select two algorithms that have the job of perform aggregations.
A-MDSU and A-MPDU are independent each other.

>> 1)I agree with you about EdcaTxopN class. Maybe the better way to
>> reuse
>> also DcfManager to implement Edca mechanism is write an interface
>> DcaTxop and inherit from it.
> 
> You don't need anything special to reuse DcfManager: You should be able
> to instance one DcfManager, 4 DcfState, 4 EdcaTxop and associate each
> DcfState to one EdcaTxop.

Yes!I was in confusion beetween the two names DcfState and DcaTxop :)
>> 2)About BlockAck, you suggest to move storage of packets for which an
>> ack hasn't been received yet in DcaTxop and i agree with you.
> 
> I think that it should be the EdcaTxop class which should be responsible
> for keeping a copy of each outgoing packet to perform a retransmission
> if needed. I merely suggested that the MacLow be responsible for sending
> a block of packets all in one go. I would expect the MacLow to forget
> about each packet as soon as it is sent on the medium, regardless of
> whether the packet is acked later or not.
> 
>>> a) change the signature of MacLowTransmissionListener::GotAck to
>> include
>>> the sequence number of the packet we got an ack for:
>>>  virtual void GotAck (double snr, WifiMode txMode, uint16_t seq) =
>> 0;
>>> This method will be invoked by the MacLow class to notify the
>> EdcaTxop
>>> class of each packet whose bit is set in a received BlockAck.
>> Changing the signature of
>>
>> virtual void MacLowTransmissionListener::GotAck(double snr, WifiMode
>> txMode, uint16_t seq) = 0;
>>
>> involves calling it for every corretly received packet that is
>> acknowledged with the BlockAck frame. Maybe is better a function like
>> this?
>>
>> virtual void MacLowTrasmissionListener::GotBlockAck(double snr,
>> WifiMode
>> txMode, uint16_t *p) = 0;
>>
>> where p array contains sequence numbers indicated in the blockack
>> bitmap.
> 
> Yes, you could do something like this but the one I suggested:
>   - allows you to not have to deal with an array of uint16_t (hence, not
> have to allocate/deallocate it)
>   - allows you to not pass around a pointer
> 
> I think that both options have probably about the same performance cost
> (in one case, you have to do a dynamic allocation and perform a single
> function call, in the other case, you don't have to do dynamic
> allocation and you perform multiple function calls) but the one I
> suggested seems more simple.
> 
>>> b) add MacLowTransmissionListener::MissedAck to notify a listener
>> that a
>>> specific packet has been missed.
>>>  virtual void MissedAck (uint16_t seq) = 0;
>> If we implement the function above there isn't need to add thid
>> method.
> 
> It seems easier for EdcaTxop to have this method too because it saves
> EdcaTxop from having to infer which packets must be retransmitted to
> prepare the retransmission.
> 
>>> add MacLowTransmissionParameters::AddPacket and m_packets:
>>> void AddPacket (Ptr<const Packet> packet,
>>>                 const WifiMacHeader *hdr);
>>> std::list<std::pair<Ptr<const Packet>, WifiMacHeader> > m_packets;
>> Sorry but i have some problems here :( How is used m_packets? When is
>> AddPacket called ?
> 
> Sample code:
> 
> EdcaTxop::Send (void)
> {
>   MacLowTransmissionParameters params;
>   params.[...]
>   params.AddPacket (p1, h1);
>   params.AddPacket (p2, h2);
>   m_low->StartTransmission (params, m_listener);
> }
> 
> MacLowTransmissionParameters contains all the parameters to apply to a
> set of packets to transmit. This, of course, will work only if all
> packets share the same tx parameters. Will it be the case for you ?

Yes...it's perfect. Also with m_packets we'll be able to keep track of
all packets which are acknowledged with block ack.

> Finally, I wanted to point out that if you really care about merging
> your work in ns-3 itself, it is very important to proceed in small steps
> and not try to merge/implement all features at once: I would suggest
> that you first define a couple of clear milestones with subsets of the
> full functionality and that we try to merge each of these incrementally.

At the moment we are working on MSDU aggregation. When this feature will
be operative i'll ask you or Tom, if will be possible, for a
mercurial repository on your server. Just then we would try to merge.

Regards,

Mirko

-- 
Mirko Banchi

e-mail:    mk.banchi at gmail.com
e-mail:    mk.banchi at virgilio.it
id-jabber: mk.banchi at jabber.org
id-msn:    mb11684 at hotmail.com

PGP key fingerprint:

308F BFB1 4E67 2522 C88E
DC69 7631 52ED 32A5 6456

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3410 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090110/ccb8d07d/smime.bin