Thanks, Tengfei.
I understand that adaptation to traffic doesn't work for Rx
managed cells. So, as you suggested, the parent node should
trigger 6P ADD/DELETE/RELOCATE to one of its children, probably
using 3-step transaction. That would affect description on usage
of AutoUpCell and AutoDownCell.
Thanks, Diego!
I think, if SeqNum=0 has the special meaning, 6P would need to pass a received
SeqNum to a corresponding SF... But, my understandings is that, SeqNum is
maintained only by 6P and not revealed to SFs... An alternative way to tell
a power-cycle event to the peer would have been
Yacht,
Let me chime in a little bit. Responses below.
Regards,
Diego
El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka
escribió:
> Hi Xavi,
>
> > What is the issue you see with this?
>
> At least, there is an inconsistency in RFC8480. Here is another example:
>
>
Hi Xavi,
> What is the issue you see with this?
At least, there is an inconsistency in RFC8480. Here is another example:
https://tools.ietf.org/html/rfc8480#section-3.2.2
rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a given
rfc8480> transaction MUST share the same
Hi Yatch,
thanks for your response. see inline my comments.
Missatge de Yasuyuki Tanaka del dia dt., 23
d’abr. 2019 a les 10:49:
> Hi Xavi,
>
> Thank you for your reply.
>
> On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
> > When node B power cycles loses the last seen seqNum. Its stored
