Subject: [manet] Advanced signal processing within SIFS interval in IEEE 802.11 wireless networks

From: Debarshi Sanyal <[email-masked]>
Date: Thu, 21 May 2015 11:47:21 +0530

Hi,

In the IEEE 802.11 standard, SIFS time is defined as

aSIFSTime is:  aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay +
aRxTxTurnaroundTime

The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g.
Usually aMACProcessingDelay is very small so that the 10 us limit for SIFS
can be obeyed.

Now if the MAC frame is, say, encoded with Reed-Solomon code, is it
possible to decode it, process it (say, perform a XOR on the bits using a
predefined sequence) to generate a response and encode the response back
with Reed-Solomon code within aMACProcessingDelay?

Can anyone kindly provide some pointers in this direction - like is it
possible for very small (how small?) MAC frames or is it not possible at
all using current technology?
We may use FPGA to implement RS code encoder and decoder.

Thanks for your time.

Regards,
Debarshi Kumar Sanyal
KIIT University, Bhubaneswar, India

---

From: Frank Fitzek <[email-masked]>
Date: Thu, 21 May 2015 08:46:29 +0200

Dear all,

according to our measurements this should be possible. There are two 
ways to look at it:

- The standard Block Codes, RS codes, etc: They will work on a 
predefined set of packets/symbols and do the whole encoding in one push, 
so packets will be available at the time you need them in the encoded form

- Network Codes: They are different and allow for recoding on the fly, 
so encoding takes place per node on a certain time instant, but even 
here our experience is that the recoding will be fast enough. If it is a 
simple XOR for sure no problem, but also higher finite field 
calculations should work

Does it help?

FF

Am 21.05.2015 um 08:17 schrieb Debarshi Sanyal:
> aSIFSTime is:aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay 
> +aRxTxTurnaroundTime
>
>
> Usually aMACProcessingDelay is very small so that the 10 us limit for 
> SIFS can be obeyed.
>
> possible to decode it, process it (say, perform a XOR on the bits 
> using a predefined sequence) to generate a response and encode the 
> response back with Reed-Solomon code within aMACProcessingDelay?
>
> possible for very small (how small?) MAC frames or is it not possible 
> at all using current technology?
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

-- 
Frank Fitzek
Professor
Chair of Communication Networks
Institute of Communication Technology
TU Dresden

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net
skype:	fitzek

5G Lab Germany Coordinator 5Glab.de

---

From: Debarshi Sanyal <[email-masked]>
Date: Thu, 21 May 2015 12:49:40 +0530

Hi Frank,

Thanks for the response.

We are currently analyzing the case of RS-coded packets (not network
coding). In fact MAC packets for a specific function will be RS-coded.

Can you kindly point to any real measurements that specify the time for
encoding and decoding RS codes for various numbers of information and
parity bits? Especially for total size of encoded packet WITHIN 32 bytes.

The available literature mainly deals with RS(255,x) codes.

Regards,
Debarshi Kumar Sanyal

On 21 May 2015 at 12:16, Frank Fitzek <[email-masked]> wrote:

>  Dear all,
>
> according to our measurements this should be possible. There are two ways
> to look at it:
>
> - The standard Block Codes, RS codes, etc: They will work on a predefined
> set of packets/symbols and do the whole encoding in one push, so packets
> will be available at the time you need them in the encoded form
>
> - Network Codes: They are different and allow for recoding on the fly, so
> encoding takes place per node on a certain time instant, but even here our
> experience is that the recoding will be fast enough. If it is a simple XOR
> for sure no problem, but also higher finite field calculations should work
>
> Does it help?
>
> FF
>
>
> manet mailing [email-masked]://www.ietf.org/mailman/listinfo/manet
>
>
> --
> Frank Fitzek
> Professor