Hello All,
As editors of the problem statement, use cases & requirements draft we are
attempting to prepare a completed draft which could be ready for working
group last call before IETF83. In the coming days we will post the
sections of the draft to the mailing list. Our request is that you review
these sections and reply to the email with any comments.
Below is the text for section on the rapid deployed network for emergency
scenario use case (new section numbering is NOT shown, all use cases will
be moved to section 4.2 Use cases in the next version). This text has been
marked up from version-02 as uploaded January 26, 2012 as follows:
* changed the terms "free" and "freed" as discussed on email reflector
Our goal is that any discussion on this text will conclude by February 10.
To be clear, approval of the document will go through the normal process
of last calls etc.. We are simply asking for your assistance in preparing
a complete & accurate document that could progress the work. So please
review the text and send your comments either directly to the editor or to
the mailing list.
Kind Regards,
Raj & Scott
4.7. Rapid deployed network for emergency scenario
Organizations involved in handling emergency operations often have a
fully owned and controlled infrastructure, with dedicated spectrum,
for day to day operation. However, lessons learned from recent
disasters show such infrastructures are often highly affected by the
disaster itself. To set up a replacement quickly, there is a need
for fast reallocation of spectrum, where in certain cases spectrum
can be <Delete>freed</Delete><Insert>cleared</Insert> for disaster
relief. To utilize <Delete>free</Delete><Insert>unused</Insert> or
<Delete>freed</Delete><Insert>cleared</Insert> spectrum
quickly and reliable, automation of allocation, assignment and
configuration is needed. A preferred option is make use of a robust
protocol, already adopted by radio manufacturers. This approach does
in no way imply such organizations for disaster relief must compete
on spectrum allocation with other white spaces users, but they can.
A typical network topology would include wireless access links to the
public Internet or private network, wireless ad hoc network radios
working independent of a fixed infrastructure and satellite links for
backup where lack of coverage, overload or outage of wireless access
links occur.
\|/
| ad hoc
|
|-|-------------|
| Master node | |------------|
\|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------|
---|------------/ | \ /
| Master node | | | (--/--)
| without | | ------( )
| backhaul link | | Wireless / Private \
----------------\ | Access ( net or )
\ | \ Internet )
\ \|/ | -------( /\
\ | ad hoc | | (------) \---------
\ | | / | Other |
\--|------------- /Satellite | nodes |
| Master node | / Link ----------
| with |/
| backhaul link |
-----------------
Figure 7: Rapid deployed network with partly connected nodes
In the ad hoc network, all nodes are master nodes in a way that they
allocate RF channels from the white space database. However, the
backhaul link may not be available to all nodes, such as depicted for
the left node in the figure. To handle RF channel allocation for
such nodes, a master node with a backhaul link relays or proxies the
database query for them. So master nodes without a backhaul link
follow the procedure as defined for clients. The ad hoc network
radios utilise the provided RF channels. Details on forming and
maintenance of the ad hoc network, including repair of segmented
networks caused by segments operating on different RF channels, is
out of scope of spectrum allocation.
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
