Lr-wpan - Revision history

Tommaso: /* History */

2015-01-05T14:54:45Z

History

← Older revision		Revision as of 14:54, 5 January 2015
Line 12:		Line 12:
	Some initial 802.15.4 models were contributed by Boeing in the 2011 timeframe, and maintained at http://code.nsnam.org/tomh/ns-3-lr-wpan/. This repository is now considered obsolete, replaced by the 'lr-wpan' module that is now in ns-3 as of ns-3.20 release.		Some initial 802.15.4 models were contributed by Boeing in the 2011 timeframe, and maintained at http://code.nsnam.org/tomh/ns-3-lr-wpan/. This repository is now considered obsolete, replaced by the 'lr-wpan' module that is now in ns-3 as of ns-3.20 release.

	In ns-3.19 release, a [http://www.nsnam.org/doxygen/group__sixlowpan.html 6LoWPAN model] was included, but the 6LoWPAN model precedes the 802.15.4 model. As a consequence, the 6LoWPAN examples are based on wired (csma) NetDevices.		In ns-3.19 release, a [http://www.nsnam.org/doxygen/group__sixlowpan.html 6LoWPAN model] was included, but the 6LoWPAN model precedes the 802.15.4 model. As a consequence, the 6LoWPAN examples are based on wired (csma) NetDevices. The model, of course, is perfectly working over the lr-wpan model.

	= Current status and next steps =		= Current status and next steps =

Tommaso: /* 6LoWPAN */

2015-01-05T14:52:18Z

6LoWPAN

← Older revision		Revision as of 14:52, 5 January 2015
Line 54:		Line 54:
	= 6LoWPAN =		= 6LoWPAN =

	The 6LoWPAN module has been merged with ns-3-dev and ~~will be~~ available in ns-3.19. The current implementation is based on RFCs 4944 and 6282.		The 6LoWPAN module has been merged with ns-3-dev and is available from ns-3.19. The current implementation is based on RFCs 4944 and 6282.
	The module does not implement all the 6LoWPAN features (in particular BC0, MESH and HC2 are not implemented). Moreover stateful compression is not yet supported (as it requires 6LoWPAN-ND).		The module does not implement all the 6LoWPAN features (in particular BC0, MESH and HC2 are not implemented). Moreover stateful compression is not yet supported (as it requires 6LoWPAN-ND).

	Interested users should read the Doxygen and ns-3 manual for a full description of the module functionalities and limitations.		Interested users should read the Doxygen and ns-3 manual for a full description of the module functionalities and limitations.


	The "Neighbor Discovery Optimization for Low Power and Lossy Networks", also called 6LoWPAN-ND (RFC 6775) is '''strongly''' being considered for implementation. It could be extremely useful to study WSN bootstrap operations and proper RPL neighbor discovery under limited (i.e., non-multicast capable) assumptions.		The "Neighbor Discovery Optimization for Low Power and Lossy Networks", also called 6LoWPAN-ND (RFC 6775) is '''strongly''' being considered for implementation. It could be extremely useful to study WSN bootstrap operations and proper RPL neighbor discovery under limited (i.e., non-multicast capable) assumptions.

Tomh: /* Current status and next steps */

2014-05-01T04:50:20Z

Current status and next steps

← Older revision		Revision as of 04:50, 1 May 2014
Line 16:		Line 16:
	= Current status and next steps =		= Current status and next steps =

	~~A set of developers plans to contribute initial~~ 802.15.4 support ~~for~~ ns-3.20~~. This group plans to work on the ns-developers mailing list and propose a mergeable subset of full 802.15.4 support~~. Full 802.15.4 support is expected to require a few release cycles.		Initial 802.15.4 support will be included in ns-3.20. Full 802.15.4 support is expected to require a few release cycles.

	== Goals for ns-3.20 ==		== Goals for ns-3.20 ==

	* <strike>Support for 6LoWPAN over 802.15.4 model</strike> (done)		* <strike>Support for 6LoWPAN over 802.15.4 model</strike> (done)
	* Define clearly what features are modeled and validated, and which are for further study.		* <strike>Define clearly what features are modeled and validated, and which are for further study.</strike>

	== Goals for post-3.20 ==		== Goals for post-3.20 ==
Line 27:		Line 27:
	* Align with 802.15.4-2011 version of the standard		* Align with 802.15.4-2011 version of the standard

	Other goals are ~~TBD~~ and will later be listed here.		Other goals are to be determined and will later be listed here.

	== ~~Initial patch for review~~ ==		== Previous list of issues with 802.15.4 model ==

	~~Sascha Alexandar Jopen and Margherita Filippetti have proposed recent patches to the base Boeing patch, and Sascha~~ has ~~merged much of them to a single patch~~ for ~~review. This is being reviewed until mid-February,~~ at ~~which time it will be merged to~~ http://code.nsnam.org/~~lr-wpan~~/ns-3-lr-wpan/~~, and the remaining workplan for ns-3.20 will be decided~~.		Some initial code has been available for some time now at http://code.nsnam.org/tomh/ns-3-lr-wpan/.

	~~The code review is listed here: https://codereview.appspot.com/59240044/~~		Some missing features have been identified by others:

	~~== Old list of issues with 802.15.4 model ==~~

	~~Some initial code has been available at http://code.nsnam.org/tomh/ns-3-lr-wpan/.~~

	Some missing features have been identified:
	* Extended adresses		* Extended adresses
	* Expose all MAC and PHY variables as ns-3 attributes.		* Expose all MAC and PHY variables as ns-3 attributes.

Tomh: /* History */

2014-05-01T04:48:52Z

History

← Older revision		Revision as of 04:48, 1 May 2014
Line 10:		Line 10:
	* more description of the ns-2 implementation is [http://www.ee.washington.edu/research/funlab/802_15_4/ here]		* more description of the ns-2 implementation is [http://www.ee.washington.edu/research/funlab/802_15_4/ here]

	Some initial 802.15.4 models were contributed by Boeing in the 2011 timeframe, and maintained at http://code.nsnam.org/tomh/ns-3-lr-wpan/. This repository is now considered obsolete, replaced by ~~http://code.nsnam.org/~~lr-wpan/ns-3~~-lr-wpan/.~~		Some initial 802.15.4 models were contributed by Boeing in the 2011 timeframe, and maintained at http://code.nsnam.org/tomh/ns-3-lr-wpan/. This repository is now considered obsolete, replaced by the 'lr-wpan' module that is now in ns-3 as of ns-3.20 release.

	~~Please see [http://code.nsnam.org/tomh/~~ns-3~~-lr-wpan/file/735b14afde8e/lr-wpan-documentation.pdf Sphinx documentation] for a description of what is already done in this repository. This repository is only the starting point for a full 802.15~~.~~4 model~~.

	In ns-3.19 release, a [http://www.nsnam.org/doxygen/group__sixlowpan.html 6LoWPAN model] was included, but the 6LoWPAN model precedes the 802.15.4 model. As a consequence, the 6LoWPAN examples are based on wired (csma) NetDevices.		In ns-3.19 release, a [http://www.nsnam.org/doxygen/group__sixlowpan.html 6LoWPAN model] was included, but the 6LoWPAN model precedes the 802.15.4 model. As a consequence, the 6LoWPAN examples are based on wired (csma) NetDevices.

Jopen: /* Old list of issues with 802.15.4 model */

2014-04-29T08:09:53Z

Old list of issues with 802.15.4 model

← Older revision		Revision as of 08:09, 29 April 2014
Line 44:		Line 44:
	* Extended adresses		* Extended adresses
	* Expose all MAC and PHY variables as ns-3 attributes.		* Expose all MAC and PHY variables as ns-3 attributes.
			* Implement Interframe Spacing (IFS) in the MAC.
			* Do we need PacketBursts in LrWpanSpectrumSignalParameters? Maybe a Packet would be sufficient.
	* <strike>Calculate and check FCS if global attribute ChecksumEnable is set.</strike>		* <strike>Calculate and check FCS if global attribute ChecksumEnable is set.</strike>
	* <strike>Class WpanAddress is not used, remove? Or use it instead of Mac16Address/Mac64Address.</strike> (WpanAddress Removed)		* <strike>Class WpanAddress is not used, remove? Or use it instead of Mac16Address/Mac64Address.</strike> (WpanAddress Removed)

Jopen: Mark some 802.15.4 work items as done.

2014-04-23T12:38:35Z

Mark some 802.15.4 work items as done.

Tommaso at 12:23, 17 March 2014

2014-03-17T12:23:10Z

← Older revision		Revision as of 12:23, 17 March 2014
Line 23:		Line 23:

	* <strike>Support for 6LoWPAN over 802.15.4 model</strike> (done)		* <strike>Support for 6LoWPAN over 802.15.4 model</strike> (done)
			* Define clearly what features are modeled and validated, and which are for further study.

			== Goals for post-3.20 ==

	* Align with 802.15.4-2011 version of the standard		* Align with 802.15.4-2011 version of the standard
	* Define clearly what features are modeled and validated, and which are for further study.

	Other goals are TBD and will later be listed here.		Other goals are TBD and will later be listed here.

Tommaso: /* History */

2014-03-17T12:21:37Z

History

← Older revision		Revision as of 12:21, 17 March 2014
Line 14:		Line 14:
	Please see [http://code.nsnam.org/tomh/ns-3-lr-wpan/file/735b14afde8e/lr-wpan-documentation.pdf Sphinx documentation] for a description of what is already done in this repository. This repository is only the starting point for a full 802.15.4 model.		Please see [http://code.nsnam.org/tomh/ns-3-lr-wpan/file/735b14afde8e/lr-wpan-documentation.pdf Sphinx documentation] for a description of what is already done in this repository. This repository is only the starting point for a full 802.15.4 model.

	In ns-3.19 release, a [http://www.nsnam.org/doxygen/group__sixlowpan.html 6LoWPAN model] was included, but the 6LoWPAN model precedes the 802.15.4 model, ~~and hence can only run over~~ wired ~~links~~.		In ns-3.19 release, a [http://www.nsnam.org/doxygen/group__sixlowpan.html 6LoWPAN model] was included, but the 6LoWPAN model precedes the 802.15.4 model. As a consequence, the 6LoWPAN examples are based on wired (csma) NetDevices.

	= Current status and next steps =		= Current status and next steps =

Tommaso: /* Old list of issues with 802.15.4 model */

2014-03-17T11:37:05Z

Old list of issues with 802.15.4 model

← Older revision		Revision as of 11:37, 17 March 2014
Line 46:		Line 46:
	* NetDevice: 6LoWPAN: Do you need the MTU, which MTU should we export? The maximum, i.e. without security, only 16bit addresses and with only the destination address and pan id, or source and destination addresses with pan id compression?		* NetDevice: 6LoWPAN: Do you need the MTU, which MTU should we export? The maximum, i.e. without security, only 16bit addresses and with only the destination address and pan id, or source and destination addresses with pan id compression?
	** This is dependent on the PAN. Once a node is associated, those params are known.		** This is dependent on the PAN. Once a node is associated, those params are known.
	* <strike>NetDevice: NeedsArp: Only true for 6LoWPAN?</strike> (No. ARP is needed by 802.15.4. Eventually it's ~~elided~~ by higher layer protocols (e.g., 6LoWPAN-ND)		* <strike>NetDevice: NeedsArp: Only true for 6LoWPAN?</strike> (No. ARP is needed by 802.15.4. Eventually it's suppressed by higher layer protocols (e.g., 6LoWPAN-ND)
	* <strike>Helper for assigning MacAddresses and configuring the lr-wpan stack.</strike> (Done)		* <strike>Helper for assigning MacAddresses and configuring the lr-wpan stack.</strike> (Done)
	* LrWpanSpectrumValueHelper: Make noise factor accessible through the ns-3 attribute system		* LrWpanSpectrumValueHelper: Make noise factor accessible through the ns-3 attribute system

Tommaso: /* Old list of issues with 802.15.4 model */

2014-03-17T11:36:34Z

Old list of issues with 802.15.4 model

← Older revision		Revision as of 11:36, 17 March 2014
Line 46:		Line 46:
	* NetDevice: 6LoWPAN: Do you need the MTU, which MTU should we export? The maximum, i.e. without security, only 16bit addresses and with only the destination address and pan id, or source and destination addresses with pan id compression?		* NetDevice: 6LoWPAN: Do you need the MTU, which MTU should we export? The maximum, i.e. without security, only 16bit addresses and with only the destination address and pan id, or source and destination addresses with pan id compression?
	** This is dependent on the PAN. Once a node is associated, those params are known.		** This is dependent on the PAN. Once a node is associated, those params are known.
	* NetDevice: NeedsArp: Only true for 6LoWPAN?		* <strike>NetDevice: NeedsArp: Only true for 6LoWPAN?</strike> (No. ARP is needed by 802.15.4. Eventually it's elided by higher layer protocols (e.g., 6LoWPAN-ND)
	* <strike>Helper for assigning MacAddresses and configuring the lr-wpan stack.</strike> (Done)		* <strike>Helper for assigning MacAddresses and configuring the lr-wpan stack.</strike> (Done)
	* LrWpanSpectrumValueHelper: Make noise factor accessible through the ns-3 attribute system		* LrWpanSpectrumValueHelper: Make noise factor accessible through the ns-3 attribute system

← Older revision		Revision as of 12:38, 23 April 2014
Line 44:		Line 44:
	* Extended adresses		* Extended adresses
	* Expose all MAC and PHY variables as ns-3 attributes.		* Expose all MAC and PHY variables as ns-3 attributes.
	* Calculate and check FCS if global attribute ChecksumEnable is set.		* <strike>Calculate and check FCS if global attribute ChecksumEnable is set.</strike>
	* <strike>Class WpanAddress is not used, remove? Or use it instead of Mac16Address/Mac64Address.</strike> (WpanAddress Removed)		* <strike>Class WpanAddress is not used, remove? Or use it instead of Mac16Address/Mac64Address.</strike> (WpanAddress Removed)
	* NetDevice: LinkUp, LinkDown, remove? Or enable/disable transceiver.		* NetDevice: LinkUp, LinkDown, remove? Or enable/disable transceiver.
Line 52:		Line 52:
	* <strike>Helper for assigning MacAddresses and configuring the lr-wpan stack.</strike> (Done)		* <strike>Helper for assigning MacAddresses and configuring the lr-wpan stack.</strike> (Done)
	* LrWpanSpectrumValueHelper: Make noise factor accessible through the ns-3 attribute system		* LrWpanSpectrumValueHelper: Make noise factor accessible through the ns-3 attribute system
	* LrWpanSpectrumValueHelper: Make all functions static?		* <strike>LrWpanSpectrumValueHelper: Make all functions static?</strike>
	* PHY: More sophisticated handling of interference, i.e. handle it at all		* <strike>PHY: More sophisticated handling of interference, i.e. handle it at all</strike>
	* PHY: Tracing should be reviewed, especially RxBegin, RxEnd, RxDrop		* PHY: Tracing should be reviewed, especially RxBegin, RxEnd, RxDrop
	* PHY: Do we really need m_rxTotalNum, or can we derive the information from m_rxTotalPsd?		* <strike>PHY: Do we really need m_rxTotalNum, or can we derive the information from m_rxTotalPsd?</strike>
	* Coordinator, GTS, CAP		* Coordinator, GTS, CAP