Hi Xavi,
Let me respond to the following first:
What if A resets? how you now at B that A has reset? do this require
a STATUS call from A to B when it join the network again?
That is one of options. Basically, it's up to an SF employed between
them. Here are other options in my mind:
(1) A
HI Yatch,
thanks for your comments. Could you please summarize how the timeout will
work in the 2 and 3 step transactions:
I see it in this way:
2-step
A sends to B an ADD, if A packet is lost, B will never realize and A will
timeout. Idem if B response fails ( A timeouts)
3-step
A sends to B an
Hi Qin,
I think nodeA=>nodeB request process includes two parts, one is Tx
from nodeA to nodeB, another part is for nodeB's MAC to process the
Request message. As you mentioned, failure of the first part can be
identified by mac-ack from nodeB, but not the second part. Right?
Yes, that's right
Hi Yasuyuki,
I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA
to nodeB, another part is for nodeB's MAC to process the Request message. As
you mentioned, failure of the first part can be identified by mac-ack from
nodeB, but not the second part. Right?
ThanksQin
Thanks, Qin.
(1) Timeout in nodeA can be triggered either by failure in
nodeA=>nodeB request process and by failure in nodeB=>nodeA response
process (i.e the process in above example). nodeA cannot tell exact
reason for a event of Timeout by itself. In another word, nodeA
cannot tell there is a
Hi Yasuyuki,
(1) Timeout in nodeA can be triggered either by failure in nodeA=>nodeB request
process and by failure in nodeB=>nodeA response process (i.e the process in
above example). nodeA cannot tell exact reason for a event of Timeout by
itself. In another word, nodeA cannot tell there is a
Hi Qin,
Hmm, in your example, node A can resolve the inconsistency without
using the generation counter by sending CLEAR to node B after the
timeout occurs. Node A could use STATUS or STATUS+LIST before sending
CLEAR in order to confirm inconsistency if the schedule generation
inconsistency detec
Hi Yasuyuki,
I'm not sure I fully understand you.
Let's assume node A wants to ADD cells with nodeB in 2-step transaction. After
nodeA sends ADD Request to nodeB, the Timeout of nodeA is set. nodeB receives
the ADD Request, adds the cells to its schedule and sends Response back to
nodeA at same
Hi Qin,
Thank you for replying to my long email!!
I put the two cases you provided below, in which schedule generation
inconsistency could occur:
(1) failure in communication because of PHY problems like bed channel
condition, collision
(2) failure in processing because of MAC problems suc
Hi Yasuyuki,
Regarding to the reasons of inconsistent allocation asked in your email, I
think, roughly speaking, they are (1) failure in communication because of PHY
problems like bed channel condition, collision, and (2) failure in processing
because of MAC problems such as buffer overflow.
Th
Xavi, Thomas, thank you for the responses!
I'm replying both of you in a single email to save bandwidth ;-)
Sorry for making this email so long... I put a shorter response first.
thomas> From an implementation point of view, cells that are in the
thomas> process of being reserved (i.e. 6P add r
I'd like to keep 6P simple, and just have a mechanism to detect
inconsistencies. I believe roll-back to a previous schedule generation adds
too much complexity. From an implementation point of view, cells that are
in the process of being reserved (i.e. 6P add request sent but no response
received y
Hi Yatch,
my 2 cents inline
> I've been thinking about how to handle inconsistencies. I know the
> current draft has an inconsistency detection mechanism with generation
> management; just wondering if there is another way or a supplemental
> mechanism to deal with such a situation.
>
> We decide
13 matches
Mail list logo
