Establishing IP Network Support for a PAN-Based Virtual Device
Thanh V. Do, Paal E. Engelstad, and Tore E. Jønvik
{thanh-van.do, paal.engelstad, tore-erling.jonvik}@telenor.com
Telenor R&D, Snarøyveien 30, 1331 Fornebu, Norway
Abstract
The emergences of short-range wireless technologies, such
as Bluetooth, IEEE 802.11 WLAN and IEEE 802.15 WPAN,
lay the fundament for Machine-to-machine (M2M)
communications. People start already to envision a system
where devices collaborate and serve human beings. A first
step in this direction is the formation of a user’s Personal
Area Network (PAN). Due to the wide variety of current and
future radio technologies that can be used in such a
network, the future networking solution for Personal Area
Networks (PANs) should be IP-based, and thus radioagnostic. This paper describes how to form and establish an
IP-based PAN, starting in the bottom of the stack. Finally,
when IP-layer connectivity is established, the device may
establish higher layer connectivity. PAN middleware to
realize a Virtual Device is an example of this kind of higher
layer functionality. The Virtual Device carries higher layer
logics that are required for the PAN devices to collaborate
and fully serve the user’s needs.
Key Words: Personal Area Network, IP Networking, M2M,
Wireless Communication, Virtual Device
1. Introduction
The emergences of short-range wireless technologies, such
as Bluetooth, IEEE 802.11 WLAN and IEEE 802.15
WPAN, lay the fundament for Machine-to-machine (M2M)
communications [1, 2]. People start already to envision a
system where devices collaborate and serve the human
beings.
The Virtual Device concept [3, 4] was introduced to
contribute to the realization of this vision. It is a novel
concept that considers all the autonomous devices on the
user 's Personal Area Network (PAN) as virtually one big
device. The Virtual Device has multiple input and output
units and provides a coherent and surround interface to the
user. Devices can also be dynamically discovered and
enrolled in the Virtual Device.
In order to realize this compelling concept, and to enable
device-to-device collaboration, communication and
networking must be established. During operation, the
network must also adapt to and deal with the underlying
characteristics of a PAN, including the design limitations
related to power consumption, bandwidth constraints,
network dynamics and mobility, and diverse device
capabilities.
Due to the differing device capabilities, it becomes clear
that there is no radio technology that fits all. Traditionally,
PANs have often been thought of as realized by master-
slave-based (i.e. hierarchical) technologies, such as
Bluetooth technology. However, some devices would prefer
to use the higher bit rates provided by IEEE 802.11b,
802.11g or 802.15.3. Due to the high development rate of
new radio technologies, the PAN should be able to
accommodate all kinds of existing radio-technologies, and
let devices with different interfaces play together in the
same network.
To cope with this, we propose to seek an IP-based PAN
solution that is independent of underlying radio
technologies. The solution will be valid for most thinkable
link-layer technologies that might emerge in the future,
including those that are in the pipeline (e.g. 802.15.3a and
802.11n).
As newer radio technologies are introduced with shorter
radio ranges (to boost overall throughput and to minimize
power consumption), multi-hop communication might be
required to accommodate connectivity between all devices
within the Personal Operating Space (POS) where the PAN
shall be operational.
The fact that there might be different types of radio
technologies present in a PAN may also lead to multi-hop
communication. For example: for a device with one radio
technology (e.g. Bluetooth) to be able to communicate with
another device with another radio technology (e.g. 802.11b
WLAN), the communication must be routed via a third PAN
device that supports both technologies.
Multi-hop networking requires routing protocols and
forwarding functionality implemented on the participating
PAN devices.
In this paper, a model for establishment of an IP-based PAN
will be presented. The focus is on formation of a PAN that
has sufficient functionality to accommodate a Virtual
Device. How to deal with closed IP devices in this context is
a particular problem related to a Virtual Device [3, 4].
2. State of the Art
Despite recent progress, short-range wireless technologies
are still immature and not qualified for advanced personal
area network infrastructures. WLAN technology currently
does not cater for small devices like mobile phones,
headsets and microphones, while Bluetooth mainly serves as
cable replacement, enabling pairing between two devices.
Although the Bluetooth Piconet, consisting of one master
device and seven slaves, is defined together with the wider
reaching Scatternet, there is no specification that enables
competitive implementations. Bluetooth networking is
http://folk.uio.no/paalee/
limited and there is no official Bluetooth SIG strategy
addressing the issue.
Bluetooth devices are often shipped with a full
communication stack. However, in a IP-based multitechnology PAN, the Bluetooth-specific higher layers of the
stack are not useful for PAN networking beyond the direct
link between two devices.
Another alternative to building PAN functionality into the
link-layer is to build the PAN networking functionality on
top of IP, as proposed in this paper. This is similar to the
approach taken by the MANET working group of the IETF
[5]. The MANET WG works on mobile ad-hoc networking
with IP as a networking protocol, and where communication
often requires multiple IP hops. Their focus is mostly on the
routing aspects of communication. Some lessons might be
learnt from this work, however, a special PAN scenario calls
for a lot of additional networking capabilities not addressed
by this effort. Some of the required networking capabilities
will be outlined below.
3. Premises of IP-Based PANs
A particular difference between a MANET and a PAN is
that while MANETs assume 'symmetric' communication
between more or less equal routers, an outspoken premise of
a PAN is that devices can be highly heterogeneous. On a
MANET the routers are supposed to be equal in terms of
routing. This means that each device has at least a minimum
of capabilities e.g. processing, storage, communication, etc.
to support routing and forwarding of packets. A PAN, on
the other hand, must support devices with a wide range of
different networking capabilities and features.
To deal with heterogeneity of devices it would be beneficial
to group into different classes of devices with different
networking capabilities. As far as the IP-networking aspects
are concerned, it might be natural to distinguish between:
1.
2.
3.
”PAN-routers”: These are IP capable devices that
must participate in network management and operation.
This includes relaying (i.e. routing and forwarding) of
IP packets belonging to other communicating devices.
They might also be the source or destination of
communication and must thus also include all the
capabilities of a ”PAN-host”.
”PAN-hosts”: These are IP capable devices that
behave as source or destination of communications, but
do not participate in relaying (i.e. routing and
forwarding) of IP packets. Normally a “PAN-host”
cannot connect directly to another “PAN-host”, but
must connect to a ”PAN-router” to be able to
communicate.
”PAN-peripherals”: These are low capability devices,
such as microphones or headsets that do not run IP at
all. The peripheral do not participate as a stand-alone
”PAN-router” or host on the network, and can only
communicate on layer 2. It might be interconnected to
an IP capable device (”PAN-router” or ”PAN-host”),
which might make the services offered by the ”PANperipheral” available to other IP-enabled devices on the
http://www.unik.no/personer/paalee
network, e.g. by implementing some kind of proxy
functionality.
In a PAN that is centered round a user, it might make sense
also to define some Master Routers. These are high
capability IP-devices that might have additional networking
functionality beyond that of a regular ”PAN-router”. They
might for example monitor the state of the network and
control the functionality of routing on the network based on
this surveillance.
Another premise of a PAN - in contrary to the MANET
effort - is that the network is owned and controlled by one
user. One may therefore envision the PAN as a hierarchy of
heterogeneous devices with the user on top. Routing and
network management should be optimized to benefit the
user. Nodes that are close to the user, or that interact with
the user, might be more important in the network than other
nodes located farther from the user. These aspects are not
covered by the MANET effort, since a MANET is built on a
model of symmetric communication between equally
important devices.
4 Establishing the IP-Based PAN
4.1 Buttom-Up Network Establishment
PAN devices must be able to form the PAN network
dynamically. Since higher layer communication depends on
the services of lower layers, the network will normally be
established bottom-up: First, the physical and link layer
discovers the presence of a new neighboring device. When
the link layer is configured and operational, the node might
continue to configure the IP networking layer. Finally upper
layer parameters of IP-based middleware and applications
will finally be set.
The network formation procedure needs to accommodate
devices with diverse capabilities. A powerful model is to
introduce a step-wise process where the node upgrades
gradually:
1.
The PAN device first tries to enter the PAN as a ”PANperipheral”. The ”PAN-peripheral” must establish link
layer connectivity to a neighboring device.
2.
When link connectivity is established, the device might
continue to configure the IP networking layer and
upgrade its status to a ”PAN-host”.
3.
When IP connectivity is established, the device might
continue to configure the IP networking layer to
participate in Network operation and management,
including the PAN routing protocol, as a "PAN-router".
4.2 Device Discovery and Link Establishment
The network establishment process starts with two devices
that discover each other, possibly negotiate, pair with each
other and form the initial PAN network. Later, additional
devices may discover one of the devices in the network. A
newly arriving device will negotiate with the PAN device,
pair with it and thereby join the PAN network.
There are also a number of other scenarios that will not be
discussed further in this paper For example, two devices
belonging to different PANs may pair with each other in
order to merge the two PANs into one, or to allow for direct
communication between the two PANs.
If a device has a number of different interfaces, it will need
to establish link layer and IP layer connectivity of each of
them.
The radio technology dependent layer 1 and layer 2 have
normally a method to discover neighboring devices and
form the link. A sketch of some possible mechanisms might
be drawn based on knowledge of existing technologies, such
as IEEE 802.11 WLAN and Bluetooth.
A device with an 802.11 interface may passively scan for
beacon messages from surrounding nodes. It may also
actively send out probe requests and listen for
corresponding probe responses returned from surrounding
nodes. The actual algorithm for shifting between active and
passive scanning is vendor-specific and not part of the
802.11 specification [2].
If a device does not succeed in discovering a neighbor, it
might take initiative to be the first node of the PAN. It is
then free configure its link layer, IP layer and higher layer
functionality. It should configure itself as a ”PAN-router” so
that other nodes can easily connect to it as ”PAN-hosts”. As
far as the link-layer is concerned, it selects a BSSID at
random, assuming that the device uses 802.11 in ad-hoc
mode and will form an Independent Basic Service Set. It
starts sending out beacons that include the BSSID at regular
intervals, and waits for other PAN devices appearing in its
vicinity. The beacon might also carry a pre-configured SSID
identifying that the device belongs to a PAN of a specific
user.
A device with a Bluetooth interface, on the other hand, will
undergo the INQUIRY phase followed by the PAGING
phase, as specified in the Bluetooth baseband specification
[1]. The Inquiry process allows a master node to discover
and collect clock and address information about neighboring
devices. The page process uses this information to establish
a bi-directional frequency hopping communication channel.
The Logical Link Control and Adaptation Layer Protocol
(L2CAP) runs on top of this connection and provides
connection-oriented and connectionless data services to
upper layer protocols.
To accommodate IP communication, the Bluetooth Network
Encapsulation Protocol, BNEP, can run over L2CAP. It
emulates an Ethernet on a broadcast network segment,
hiding the underlying master-slave based piconet topology.
BNEP reuses the Ethernet packet format commonly used for
local area networking technology, and encapsulates IP
packets in BNEP headers.
The Bluetooth Service Discovery Protocol (SDP), which
runs on top of L2CAP, is a convenient protocol during link
establishment. SDP allows one device to discover
capabilities, services and configuration parameters of the
other device.
4.3 Authentication and Security
When the discovery process is complete, the paired devices
need to authenticate with each other, and ensure to which
extent the other device is authorized to participate in the
PAN.
Normally, authentication is undertaken at the link layer as
part of link establishment. For 802.11 types of technologies,
both WiFi Protected Access (WPA) and 802.11i
accommodate upper layer authentication (ULA) based on a
modified version of 802.1X and EAP [6, 7]. In a PAN
owned by one user, it might be sufficient with a scheme
based on pre-shared keys, however a certificate-based
scheme might be better and more secure, as it facilitates key
management.
ULA supplies the nodes with keying material so that the two
devices can form pair-wise session keys for privacy and
integrity in either direction. In addition, each device must
supply the other with its own group keys that it uses for
multicast and broadcast. To secure
multi-hop
communication and routing, additional IP layer mechanisms
might be needed.
Devices of an 802.11 IBSS need not associate before
communication. This paves the way for possible immediate
communication between all the different devices of the
same IBSS. However, the benefits of this are undermined by
the fact that devices need to share different pair-wise keys
and group keys of each neighboring device before
communication with it can take place. It might be possible
to use a common group key throughout the PAN to facilitate
immediate communication. This will be less secure,
however, and will require frequent coordinated updates of
the common group key.
Although authentication is normally implemented on the
link-layer, the PANA protocol is under development to
accommodate IP-layer authentication [8]. This can be useful
for radio technologies with limited authentication,
authorization and security features, such as Bluetooth.
4.4 Link-Layer Network Formation
Some radio technologies may have mechanisms for
formation of L2-specific networks. Bluetooth, for example,
aims at providing mechanisms for piconet and scatternet
formation. Although a device had better join the PAN as a
”PAN-host”, it is thinkable that it joins as part of a
scatternet. Some scatternet formation algorithms are
proposed in [9, 10].
4.5 Establishing IP-layer Connectivity
When the device has established link-layer connectivity to
the PAN, it might want to continue to establish IP layer
connectivity. It needs an IP address, and possibly other
configuration information.
The PAN devices might be manually configured with static
IP addresses. However, this puts more requirements on the
user. Manual configuration of devices might easily be an
unmanageable task, and the user may easily make damaging
mistakes.
Thus, the PAN device should instead auto-configure an IP
address. With IPv4, the simplest is to use stateful
autoconfiguration with DHCPv4. Other configuration
information, such as DNS, might also be provided by
DHCP.
As an alternative to using DHCP, the PAN device may use
stateless autoconfiguration of IPv4 Link Local Addresses as
described in [11] or IPv6 address stateless autoconfiguration
as described in [12]. In addition it may for example use linklocal multicast name resolution [13].
4.6 Accommodating Non-Configurable Closed IPDevices
4.6.1 Hiding PAN Complexity from ”PAN-hosts”
As explained in [3, 4], a Virtual Device should be able to
accommodate closed devices that are embedded and not
extensively configurable. A closed IP device is most
probably configured to operate as regular IP hosts on regular
access networks. It is therefore natural to deal with these
devices as "PAN hosts", since they have not enough
capabilities to tackle the more complex implementation of
”PAN-routers”.
Since ad hoc networks calls for special solutions to
networking mechanisms, such as autoconfiguration,
addressing, external access, name resolution, service
discovery and so forth, it is a good idea if the “PANrouters” hide this complexity from the ”PAN-hosts”.
4.6.2 Hiding Autoconfiguration and Addressing Complexity
As part of hiding complexity from possibly embedded
devices, each ”PAN-router” to which new PAN terminals
(i.e. prospective “PAN-hosts”) can connect to may
implement a lightweight DHCP server to lease out IP
addresses.
traffic is sent. Some of this traffic might be destined for
external networks outside the PAN, such as the Internet.
As described in [14-17], however, access to external
networks might require special handling, such as tunneling
or specific routing. This complexity is hidden from the
“PAN-hosts” by letting this functionality be handled by the
“PAN-router” alone. (Hence, it is the "PAN-router" that
encapsulates and decapsulates packets on behalf of the
interconnected "PAN-hosts" if tunneling is required.)
4.6.4 Hiding Name Resolution
Due to the dynamic use of IP-addresses, PAN devices
should be identified by their names, and a name is mapped
to an IP-address prior to communication. Much more than
addresses, names are easier for the user to configure,
manage and remember.
Since the size of higher layer name spaces, such as the name
space of DNS, is normally infinite, it is easy to assign
globally unique names to each PAN device of the PAN. The
use of globally unique names facilitates operation, because
it might not require mechanisms to detect duplicate naming.
Since the PAN may require special solutions to name
resolution as described in [18-20], the ”PAN-router” might
hide this complexity by operating as a DNS proxy for the
”PAN-hosts” connected directly to it.
The “PAN-hosts” would thus send all DNS request to the
“PAN-router”, which in turn would resolve the name on the
PAN or – if this is not successful - by means of DNS over
external IP networks. This solution is presented in [18].
For IPv4 it is probable that the user have only a limited
number of global IPv4 addresses at hand – if any – for the
PAN. Hence, to cope with this, the PAN is forced to use
private IP addresses and NATs.
4.6.5 Hiding Complexity Related to Service Discovery
A similar solution as for name resolution, might also apply
to service discovery. The IP-host would send a regular
service discovery message to the network. The PAN-router
would act as a proxy, and resolve the request on behalf of
the PAN-host on the network, using a service discovery
mechanism that is designed for ad hoc networks, such as
those studied in [21-23].
The ”PAN-router” may implement a NAT and lease out
private IP addresses for use of connected “PAN-hosts”. The
drawback of being such a ”PAN-host” is that the mobility of
the ”PAN-host” is limited, and it must autoconfigure a new
IP address when connecting to a new ”PAN-router”.
Some service discovery solutions would map service and
attributes to a name, as well as the protocols and port used
to initiate the service. In this case name resolution is
required in order to resolve the discovered name to an IP
address.
Alternatively, the “PAN-router” could autoconfigure an IP
address that is unique throughout the PAN on behalf of the
“IP-host” and lease this address out to the “IP-host” in the
DHCP response. The “PAN-router” would then have to send
routing messages on behalf of the “IP-host” throughout the
PAN, to ensure that the IP-address of the “IP-host” is
reachable by the rest of the network. However, many “IPhosts” might not be able to operate correctly when the
assigned IP-address is not under the prefix of the next hop
“PAN-router”.
4.7 Becoming a ”PAN-router”
A PAN device with sufficient capabilities might want to go
one step further than being a “PAN-host”, and configure
itself as a “PAN-router”.
4.6.3 Hiding complexity related to external access
If the "PAN host" is a closed device it expects that the nexthop ”PAN-router” operate as a default router, to which all
First the PAN device needs to discover (e.g. from the “PAN
router” to which it is currently connected) various network
configurations, such as the routing protocol currently being
used on the PAN.
The PAN device also needs an IP address for use as a
“PAN-router” on the ad hoc network. As pointed out above,
this often requires a separate address autoconfiguration
mechanism. Since existing “PAN routers” have good
insights into the addresses currently used on the network, it
might be a good idea to implement a proxy solution [24]. In
this case, the “PAN-router” to which the PAN device is
connected, autoconfigures an IP address on behalf of the
PAN device. The “PAN-router” may for example ensure
that a selected IP address is not currently present in its
routing table, to drastically reduce the chances of an
unsuccessful Duplicate Address Detection on the PAN. This
solution was also proposed in [24].
5. Conclusion
The PAN device is then ready to operate as a “PAN router”
and participate in the routing process, by receiving and
sending routing messages, and the routing table will be
gradually populated.
We propose a stepwise model where the PAN devices starts
establishing link layer connectivity as a “PAN-peripheral”.
If the capabilities of the device allow, the device continues
to establish IP layer connectivity as a “PAN-host”. To allow
for closed and embedded devices with an IP-stack, the
“PAN-host” only requires the same capabilities as a regular
IP-host on the Internet. If the PAN device has extended
capabilities and is configured for active PAN participation,
it may continue to configure itself also with more advanced
networking functionality, such as routing. It must also
implement mechanisms that hide the networking complexity
of PANs from directly connected “PAN-hosts”. Finally,
when IP-layer connectivity is established, the device may
establish higher layer connectivity. PAN middleware to
realize a virtual device serves as an example of this kind of
middleware.
With some routing protocols, the two “PAN routers” might
want to “bring up adjacencies” prior to this. This means that
the two nodes synchronize their routing tables before
regular routing messages are exchanged between the nodes.
This procedure makes also much sense in scenarios when
two “PAN-routers” of different disconnected parts of a
user’s PAN interconnect to merge the two disconnected
parts into one network. Network merging, however, is out of
scope of this paper.
4.8 Establishment of Higher Layer Functionality
After IP layer connectivity is established, nodes may
establish higher layer networking functionality. This might
also be a vital part of network establishment. It includes
functionality such as name resolution, service discovery,
event notifications, resource sharing, remote method
invocation (e.g. by means of XML Web services), service
initiation (e.g. by means of SIP) and so forth. Often various
applications have overlapping requirements in this process,
and it makes sense to implement such functionality in
middleware, i.e. independently of overlying applications.
Several papers have been published on the use of
middleware on ad hoc networks, such as PANs. In [3, 4], for
example, it is proposed to use special PAN-middleware in
order to implement a virtual device. Middleware functions
required to implement such middleware is also outlined in
this paper.
The work in [25] represents another example. This paper
presents an implementation where middleware is used to
realize event-based application layer device and resource
discovery. When a device enters the network, the underlying
event mechanism ensures that all other devices are made
aware of the new device and the resources that the new
device brings into the network. Devices are also informed
when other devices leave the network, or when the status or
attributes of available resources of a device changes.
The event mechanism is based on unsolicited
advertisements of events (i.e. a push-model), in contrast to
on-demand service discovery (i.e. a pull-model). While
there are several network layer protocols at hand for service
discovery, event-based resource discovery on the other hand
are more easily implemented at higher layers today.
This paper has argued that the future networking solution
for Personal Area Networks (PANs) should be IP-based, due
to the wide variety of current and future radio technologies
that can be used in such a network.
We have presented a model that groups devices in “PANperipherals”, “PAN-hosts” and “PAN-routers” and shown
how a PAN consisting of such devices can be formed.
References
[1] http://www.bluetooth.org/
[2] http://standards.ieee.org/getieee802/802.11.html
[3] Jønvik,T.E., Engelstad,P.E., Thanh,D.V., Dynamic PANBased Virtual Device, Proceedings of 2nd IASTED
International Conference on Communications, Internet and
Information Technology (CIIT'2003), 17-19 Nov 2003.
[4] Jønvik,T.E., Engelstad,P.E., Thanh,D.V., Building a Virutal
Device on Personal Area Network, Proceedings of 2003
International Conference on Software, Telecommunications
and Computer Networks (SoftCOM'2003), Dubrovnic
(Croatia) / Ancona, Venice (Italy), October 7-10, 2003.
[5] http://www.ietf.org/html.charters/manet-charter.html
[6] http://www.wi-fi.org/OpenSection/protected_access.asp
[7] http://standards.ieee.org/getieee802/802.1.html
[8] http://www.ietf.org/html.charters/pana-charter.html
[9] Engelstad,P.E., Jønvik,T.E, Thanh,D.V., Asynchronous
Formation of Non-Hierarchical Bluetooth Scatternets,
Proceedings
of
3G-Wireless
Conference
2003
(3GWireless'03), San Francisco, May 27-30, 2003
[10] Engelstad,P.E., Thanh,D.V., Jønvik, T.E. Formation of
Scatternets with Heterogeneous Bluetooth Devices,
Proceedings
of
3G-Wireless
Conference
2003
(3GWireless'03), San Francisco, May 27-30, 2003.
[11] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", draft-ietfzeroconf-ipv4-linklocal-15.txt, May 2004, Work in Progress.
[12] Thomson, S. and Narten, T., "IPv6 Stateless Address
Autoconfiguration", IETF RFC 2462, Desember 1998.
[13] Esibov, L., Aboba, B. and Thaler, D., "Linklocal Multicast
Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-33.txt,
July 2004, Work in Progress.
[14] Engelstad,P.E., Tønnesen, A., Hafslund, A., Egeland, G.,
Internet Connectivity for Multi-Homed Proactive Ad Hoc
Networks, Proceedings of IEEE International Conference on
Communication (ICC'2004), Paris, June 20-24, 2004.
[15] Engelstad,P.E., Egeland, G., Thanh, D.V., Investigating RaceConditions in Multi-homed On-Demand Ad Hoc Networks,
Proceedings of IEEE Wireless Networking and
Communication Conference (WCNC'2004), Atlanta, Georgia,
March 21-25, 2004.
[16] Engelstad,P.E. and Egeland, G., NAT-Based Internet
Connectivity for On-Demand Ad Hoc Networks, Proceedings
of Wireless On-Demand Ad Hoc Networks (WONS'2004),
Madonna di Campiglio, Italy, January 19-23, 2004. (Lecture
Notes on Computer Science LNCS2928, Springer 2004, pp.
342-356.)
[17] Engelstad,P.E., Egeland, G., Thanh, D.V., Analysis of NATBased Internet Connectivity for On-Demand Ad Hoc
Networks, Proceedings of Western Simulation Multiconferences, Symposium on Computer Networks and
Distributed Systems (CNDS'2004), San Diego, California,
January 18-22, 2004.
[18] Engelstad,P.E., Thanh,D.V., Jønvik,T.E., Name Resolution in
Mobile Ad-hoc Networks, Proceedings of 10th International
Conference on Telecommunication 2003 (ICT), Papete,
Tahiti, February 23-28, 2003.
[19] Engelstad, P.E., Geir Egeland, Rajeev Koodli and Charles E.
Perkins, Name Resolution in On-Demand MANETs and
External IP Networks, Internet-Draft, draft-engelstad-manetname-resolution-01.txt, IETF, January 2004, (Work In
Progress).
[20] Engelstad,P.E., Thanh,D.V.,Egeland,G., Name Resolution in
On-Demand MANETs and over External IP Networks,
Proceedings of IEEE International Conference on
Communication 2003 (ICC), Anchorage, Alaska, May 11-15,
2003.
[21] Engelstad et al., Service Discovery and Name Resolution
Architectures in On-Demand MANETs, Proceedings of 2003
Workshop on Mobile Wireless Networks (MWN),
Providence, Rhode Island, May 19-22, 2003.
[22] Koodli, R., and Perkins, C.E., "Service Discovery in On
Demand Ad Hoc Networks", IETF Internet draft, draftkoodli-manet-servicediscovery-00.txt, October 2002 (Work in
Progress).
[23] Zheng, Y. and Engelstad, P.E., “Evaluation of Service
Discovery Architectures for reactively routed MANETs”.
Submitted for review.
[24] Tønnesen, A., Hafslund, A., Engelstad, P.E., “IP Address
Autoconfiguration for Proactive Ad hoc Networks”,
Submitted for review).
[25] Engelstad et al., "Middleware Supporting Adaptive Services
in On-Demand Ad Hoc Networks", Proceedings of 9th
International Conference on Intelligence in service delivery
Networks (ICIN 2004), Bordeaux, France, October 18-21,
2004.