Possibly you could find in NS3 as per my information its not available in Castalia. But I agree it will generate huge overheads for a single channel.
Rahul, could you suggest that the same mechanism could be used for IEEE 802.15.6 as per our draft https://datatracker.ietf.org/doc/draft-sajjad-6lo-wban/? It will be good to adopt a similar mechanism. We are trying to finalize our draft and possibly I will upload a revised version next week. Tell me your thougts on it. Regards Sajjad On Tue, Oct 9, 2018 at 10:14 PM Rahul Jadhav <[email protected]> wrote: > We havent tried RTS/CTS .. i thought 802.15.4 does not support RTS/CTS > because of high overhead. > Anyways i tried checking if ns3 (which is what we use in backend) supports > it and i could not find any support. > I checked Castalia and that too does not seem to support RTS/CTS. > > Having said that, ns3 does implement carrier sensing which is also what we > use. > > Best, > Rahul > > > On Tue, 9 Oct 2018 at 16:21, sajjad akbar <[email protected]> wrote: > >> Hi Rahul, >> >> That's an interesting solution and useful as you packet delivery is >> improved. Other than pacing, did you try RTS/CTS as usually simulators have >> this option for IEEE 802.15.4 based node for channel access/attempt? I am >> not sure either it create more delay for your case. >> >> Regards >> Sajjad >> >> On Mon, Oct 8, 2018 at 11:27 PM Rahul Jadhav <[email protected]> >> wrote: >> >>> Hello Sajjad, >>> >>> The packet loss rates due to channel were "relatively" same >>> with/without fragment forwarding. The channel attempt rate was the primary >>> problem. To verify this Carsten/Pascal suggested to try pacing with >>> fragment forwarding. After we tried pacing at the sender side, it resulted >>> in much improved packet delivery, which also signals that channel attempt >>> was the primary problem. Please note we used 802.15.4 in single channel >>> CSMA/CA mode. >>> >>> Regards, >>> Rahul >>> >>> On Mon, 8 Oct 2018 at 17:00, sajjad akbar <[email protected]> wrote: >>> >>>> Hello Rahul, >>>> >>>> Looks interesting. Could you elaborate the reason of failure? is it >>>> only due to channel attempt? Did you observe packet loss? I did not get >>>> chance to read your previous discussions, may be you already discussed >>>> this. >>>> >>>> Regards >>>> Sajjad >>>> >>>> On Mon, Oct 8, 2018 at 10:17 PM Rahul Jadhav <[email protected]> >>>> wrote: >>>> >>>>> <sending to 6lo, lwig WGs because both have relevant drafts> >>>>> >>>>> >>>>> >>>>> Hello All, >>>>> >>>>> >>>>> We tried experimenting with the virtual reassembly buffer and fragment >>>>> forwarding drafts. >>>>> >>>>> One fundamental characteristic that has major implications on fragment >>>>> forwarding performance is its behavior with realistic 802.15.4 RF >>>>> (especially when a train of fragments are simultaneously received and >>>>> transmitted). This is something which was not evaluated in any other >>>>> experiment. >>>>> >>>>> >>>>> >>>>> You ll find the details of the implementation, test setup details and >>>>> performance result here: >>>>> >>>>> >>>>> https://github.com/nyrahul/ietf-data/blob/rst/6lo-fragfwd-perf-report.rst >>>>> >>>>> >>>>> >>>>> Results are quite interesting: Simultaneous send/recv of fragments >>>>> with fragment forwarding has major implications on PDR/Latency. >>>>> >>>>> >>>>> >>>>> Feedback most welcome. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Rahul >>>>> _______________________________________________ >>>>> 6lo mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6lo >>>>> >>>>
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
