Couple of comments on 21-05-0671-00-0000-802.21-FrameFormat.doc
Hi all,
here are my comments on the document
21-05-0671-00-0000-802.21-FrameFormat.doc:
- I agree with Ulises that the length encoding is not clearly defined
over there. To explain it also an example proposal has already been
submitted by us too:
http://www.ieee802.org/21/doctree/2006-05_meeting_docs/21-06-0607-00-000
0-len-enc-eg.ppt
- From ulises document, section 2.2:
"....The length of the Value field (in octets) is then 128 plus the number represented by
the other appended Length field octets starting from the second. ..."
The present length encoding is taken (as far as I can remember) from the "definite form"
of ITU-T X.690 and is also used in 802.16. I advice to be standard confirm as defined in
ITU.
- My two cents to the MIHF header definition from this doc:
As far as I can remember, the reason to take Session ID and MIHF-ID into variable
part is: there are cases where we don't need them:
* initial communication doesn't need session ID but MIHF ID
* once communication 'pairing' is done, then there is no need of MIHF ID
but session ID.
So, if we keep them fixed in header, then we are having some overhead.
This might also
be valid for transaction ID. But the discussions have shown that in most cases
transaction ID enables faster and efficient communication. Thus, it has been finally
decided to take into fixed header.
Regards,
Kalyan
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl