D-07S-05 - Revision history

Nachtigall: /* Assumptions */

2007-07-28T08:57:39Z

Assumptions

← Older revision		Revision as of 08:57, 28 July 2007
Line 76:		Line 76:
	* all nodes have the exact time (needed anyway for sensors, via GPS)		* all nodes have the exact time (needed anyway for sensors, via GPS)
	* at least 3 (802.11b) orthogonal channels		* at least 3 (802.11b) orthogonal channels
			* knows its position via GPS (is this really always the case?)

	== Challenge ==		== Challenge ==

Nachtigall: +assumptions

2007-07-27T13:33:56Z

+assumptions

← Older revision		Revision as of 13:33, 27 July 2007
Line 71:		Line 71:

	== Assumptions ==		== Assumptions ==
			* all nodes are static, i.e. no mobility, but the addition and failure of nodes might occur

			* the network layout is setup for long term
			* all nodes have 2 wireless radios
			* all nodes have the exact time (needed anyway for sensors, via GPS)
			* at least 3 (802.11b) orthogonal channels

	== Challenge ==		== Challenge ==

Nachtigall: /* Ideas (brainstorming) */

2007-07-03T18:03:16Z

Ideas (brainstorming)

← Older revision		Revision as of 18:03, 3 July 2007
Line 83:		Line 83:
	* both radios are used for data and control (routing) messages, no need to reserve one radio for control messages only		* both radios are used for data and control (routing) messages, no need to reserve one radio for control messages only
	* admin might be allowed to set some of his radios to a fixed channel (because she has superior knowledge of the surrounding / due to some requirements (e.g. clients per dhcp on that channel))		* admin might be allowed to set some of his radios to a fixed channel (because she has superior knowledge of the surrounding / due to some requirements (e.g. clients per dhcp on that channel))
	* proactive protocols have a "world view" of the network. This is nice because routes to nodes do not have to be discovered on demand prior to sending data (which is slow). Also, a proactive routing protocol could also not only flood link state information but also other information every node with a certain hop distance (adjustable by TTL) should know. An approach could be to piggyback channel assignment information with the HELLO or TOPOLOGY CONTROL (link state) messages (e.g. by extending http://olsr.org). These information could be the ingredients to a distributed channel assign algorithm		* proactive protocols have a "world view" of the network (xxx: but only of the topology, which is dependend on the channel assignent, and not of the physical setup of nodes). This is nice because routes to nodes do not have to be discovered on demand prior to sending data (which is slow). Also, a proactive routing protocol could also not only flood link state information but also other information every node with a certain hop distance (adjustable by TTL) should know. An approach could be to piggyback channel assignment information with the HELLO or TOPOLOGY CONTROL (link state) messages (e.g. by extending http://olsr.org). These information could be the ingredients to a distributed channel assign algorithm
	* channel assigment algorithm takes into account joining/leaving/movement of nodes		* channel assigment algorithm takes into account joining/leaving/movement of nodes
	* require only system level software (user space should be fine), switching channels can be done every x secs using libiw/iwconfig/proprietary tool, no changes to 802.11 MAC		* require only system level software (user space should be fine), switching channels can be done every x secs using libiw/iwconfig/proprietary tool, no changes to 802.11 MAC

Nachtigall: /* Related work */

2007-07-03T17:58:11Z

Related work

← Older revision		Revision as of 17:58, 3 July 2007
Line 25:		Line 25:
	= Related work =		= Related work =

	In manage [http://www.citeulike.org/user/nachtigall my literature on citeulike]. So summeries and notes on referenced work can be found there.		I manage [http://www.citeulike.org/user/nachtigall my literature on citeulike]. So summeries and notes on referenced work can be found there.

	== Other solutions/approaches and their weaknesses (and strengths) ==		== Other solutions/approaches and their weaknesses (and strengths) ==
Line 55:		Line 55:
	==== Weaknesses ====		==== Weaknesses ====

	The problem is that we need to one dedicated control channel: We either waste capacity in case the data channels of the other radios are fully utilized (mainly if there are only a few additional data radios), or the dedicated control channel becomes the bottleneck (mainly if there are many additional radios on the node).		The problem is that we need to have one extra radio for a dedicated control channel: We either waste capacity in case the data channels of the other radios are fully utilized (mainly if there are only a few additional data radios), or the dedicated control channel becomes the bottleneck (mainly if there are many additional radios on the node).

	== Similar solutions/approaches and there weaknesses ==		== Similar solutions/approaches and there weaknesses ==

Nachtigall: /* Problem Statement */

2007-07-03T17:53:58Z

Problem Statement

← Older revision		Revision as of 17:53, 3 July 2007
Line 19:		Line 19:
	= Problem Statement =		= Problem Statement =

	802.11b offers three non-overlapping channels and 802.11a even twelve. However, ~~with~~ the 802.11 MAC layer ~~these~~ ~~are~~ ~~not~~ ~~utilisised~~. Rather, the wireless mesh network is usually on one common channel (or sometimes manually partioned into several channel collision domains). This only allows for one transmission whithin an interference range due to contention for the shared wireless channel. The interference range is about twice or three times as big as the communication range.		802.11b offers three non-overlapping channels and 802.11a even twelve. However, the 802.11 MAC layer does not utilisise them. Rather, the wireless mesh network is usually on one common channel (or sometimes ''manually'' partioned into several channel collision domains). This only allows for one transmission whithin an interference range due to contention for the shared wireless channel. The interference range is about twice or three times as big as the communication range.

⚫	The idea is to split the collision domain and therefore allow several simultanous transmissions in a neighbourhood by setting the multiple radios to different non-overlapping channels. Also by using two radios on one node we can receive and send data simultanously (xxx: Does this decrease latency / ~~and~~ break with "goodput is reduced by halve at each hop" rule of thumb, or doesn't it due to store-and-forward?) This should be done using commercial off-the-shelf hardware, where we do have no or a very limited access to the MAC layer.


		⚫	The idea is to split the collision domain and therefore allow several simultanous transmissions in a neighbourhood by setting the multiple radios to different non-overlapping channels. Also by using two radios on one node we can receive and send data simultanously (xxx: Does this decrease latency / Does this break with the "goodput is reduced by halve at each hop" rule of thumb, or doesn't it due to store-and-forward?) This should be done using commercial off-the-shelf hardware, where we do have no or a very limited access to the MAC layer.

	= Related work =		= Related work =

Nachtigall at 10:36, 2 July 2007

2007-07-02T10:36:15Z

← Older revision		Revision as of 10:36, 2 July 2007
Line 39:		Line 39:
	While this might be the best approach in theory my idea is to use cheap COTS hardware. These are equipped with the standard 802.11 MAC layer. The manufacturer usually does only allow some finegrained adjustments to MAC layer settings like RTS/CTS threshold. However, radical changes to the MAC are not allowed either due to FCC regulations or commercial reasons (closed source).		While this might be the best approach in theory my idea is to use cheap COTS hardware. These are equipped with the standard 802.11 MAC layer. The manufacturer usually does only allow some finegrained adjustments to MAC layer settings like RTS/CTS threshold. However, radical changes to the MAC are not allowed either due to FCC regulations or commercial reasons (closed source).

	Moreover most (xxx: which?) proposals of these multi-channel MAC layers operate on a packet-by-packet basis or do at least switch the channel very often. However, todays commodity 802.11 interfaces have a too long channel switching times to make this solution feasable (xxx: source?).		Moreover most (xxx: which?) proposals of these multi-channel MAC layers operate on a packet-by-packet basis or do at least switch the channel very often. However, todays commodity 802.11 interfaces have a too long channel switching times to make this solution feasable (xxx: source? http://www.citeulike.org/user/nachtigall/article/361101).

	=== Using directional antennas ===		=== Using directional antennas ===

	=== ===		=== Adjusting transmission power ===

			One can also change the transmission power at each node to control the connectivity between nodes (and therefore topology) as well as the interference range.


			''See [http://www.citeulike.org/user/nachtigall/tag/transmissionpower TransmissionPower tag] on citeulike''

	=== One common control channel ===		=== One common control channel ===
Line 94:		Line 99:
	* Distributed channel assignment algorithm		* Distributed channel assignment algorithm
	* based on a proactive routing protocol (allows world view, but maybe partly view is sufficient)		* based on a proactive routing protocol (allows world view, but maybe partly view is sufficient)
	* implementation and tests (e.g. compare to ~~homogeneours~~ and ~~random~~ channel assignment)		* implementation and tests (e.g. compare to homogeneous, random and identical channel assignment)

	== Project excecution plan ==		== Project excecution plan ==

Nachtigall at 09:25, 2 July 2007

2007-07-02T09:25:51Z

← Older revision		Revision as of 09:25, 2 July 2007
Line 19:		Line 19:
	= Problem Statement =		= Problem Statement =

	802.11b offers three non-overlapping channels and 802.11a even twelve. However, with the 802.11 MAC layer these are not utilisised. Rather, the wireless mesh network is usually on one common channel (or sometimes manually partioned into several channel collision domains). This only allows for one transmission whithin an interference range, ~~which~~ is about twice or three times as big as the communication range.		802.11b offers three non-overlapping channels and 802.11a even twelve. However, with the 802.11 MAC layer these are not utilisised. Rather, the wireless mesh network is usually on one common channel (or sometimes manually partioned into several channel collision domains). This only allows for one transmission whithin an interference range due to contention for the shared wireless channel. The interference range is about twice or three times as big as the communication range.

	The idea is to split the collision domain and therefore allow several simultanous transmissions in a neighbourhood by setting the multiple radios to different non-overlapping channels. Also by using two radios on one node we can receive and send data simultanously (xxx: Does this decrease latency / and break with "goodput is reduced by halve at each hop" rule of thumb, or doesn't it due to store-and-forward?) This should be done using commercial off-the-shelf hardware, where we do have no or a very limited access to the MAC layer.		The idea is to split the collision domain and therefore allow several simultanous transmissions in a neighbourhood by setting the multiple radios to different non-overlapping channels. Also by using two radios on one node we can receive and send data simultanously (xxx: Does this decrease latency / and break with "goodput is reduced by halve at each hop" rule of thumb, or doesn't it due to store-and-forward?) This should be done using commercial off-the-shelf hardware, where we do have no or a very limited access to the MAC layer.

Nachtigall: /* Related work */

2007-07-02T09:23:36Z

Related work

← Older revision		Revision as of 09:23, 2 July 2007
Line 26:		Line 26:

	= Related work =		= Related work =

			In manage [http://www.citeulike.org/user/nachtigall my literature on citeulike]. So summeries and notes on referenced work can be found there.

	== Other solutions/approaches and their weaknesses (and strengths) ==		== Other solutions/approaches and their weaknesses (and strengths) ==
Line 40:		Line 42:

	=== Using directional antennas ===		=== Using directional antennas ===

			=== ===

	=== One common control channel ===		=== One common control channel ===

Nachtigall: /* Ideas (brainstorming) */

2007-07-02T09:08:34Z

Ideas (brainstorming)

← Older revision		Revision as of 09:08, 2 July 2007
Line 72:		Line 72:
	== Ideas (brainstorming) ==		== Ideas (brainstorming) ==
	* other concepts do not consider the actual channel quality (e.g. the hyacinth project uses raw channel capacity divided by load and interference): we must have some measurements of the link quality amonst different channels (consider other interference in ISM band / using something like ETX?)		* other concepts do not consider the actual channel quality (e.g. the hyacinth project uses raw channel capacity divided by load and interference): we must have some measurements of the link quality amonst different channels (consider other interference in ISM band / using something like ETX?)
			* interference can be classified as inter-flow (within own path), intra-flow interference (other path) (after [http://www.citeulike.org/user/nachtigall/article/486139 Tang et al.]), but there is also interference from external sources (ISM)
	* do not require a fixed number (in other works often 2) of radios. Rather, also single radio nodes, i.e. utilise multiple radios (channels) whenever possible whithout requiring a node to have several radios		* do not require a fixed number (in other works often 2) of radios. Rather, also single radio nodes, i.e. utilise multiple radios (channels) whenever possible whithout requiring a node to have several radios
	* both radios are used for data and control (routing) messages, no need to reserve one radio for control messages only		* both radios are used for data and control (routing) messages, no need to reserve one radio for control messages only

Nachtigall: /* Ideas (brainstorming) */

2007-07-01T19:24:13Z

Ideas (brainstorming)

← Older revision		Revision as of 19:24, 1 July 2007
Line 74:		Line 74:
	* do not require a fixed number (in other works often 2) of radios. Rather, also single radio nodes, i.e. utilise multiple radios (channels) whenever possible whithout requiring a node to have several radios		* do not require a fixed number (in other works often 2) of radios. Rather, also single radio nodes, i.e. utilise multiple radios (channels) whenever possible whithout requiring a node to have several radios
	* both radios are used for data and control (routing) messages, no need to reserve one radio for control messages only		* both radios are used for data and control (routing) messages, no need to reserve one radio for control messages only
	* admin might be allowed to set some of his radios to a fixed channel (because she has superior knowledge of the surrounding / due to some requirements)		* admin might be allowed to set some of his radios to a fixed channel (because she has superior knowledge of the surrounding / due to some requirements (e.g. clients per dhcp on that channel))
	* proactive protocols have a "world view" of the network. This is nice because routes to nodes do not have to be discovered on demand prior to sending data (which is slow). Also, a proactive routing protocol could also not only flood link state information but also other information every node with a certain hop distance (adjustable by TTL) should know. An approach could be to piggyback channel assignment information with the HELLO or TOPOLOGY CONTROL (link state) messages (e.g. by extending http://olsr.org). These information could be the ingredients to a distributed channel assign algorithm		* proactive protocols have a "world view" of the network. This is nice because routes to nodes do not have to be discovered on demand prior to sending data (which is slow). Also, a proactive routing protocol could also not only flood link state information but also other information every node with a certain hop distance (adjustable by TTL) should know. An approach could be to piggyback channel assignment information with the HELLO or TOPOLOGY CONTROL (link state) messages (e.g. by extending http://olsr.org). These information could be the ingredients to a distributed channel assign algorithm
	* channel assigment algorithm takes into account joining/leaving/movement of nodes		* channel assigment algorithm takes into account joining/leaving/movement of nodes