DTN Research at TZI
Wireless access technologies are key to providing Internet and VPN connectivity to mobile users. Today, we can observe two approaches towards mobile network access: 1) Cellular (phone) networks strive for enabling ubiquitous - permanent - connectivity by building up an extensive infrastructure of base stations. Those permanets are usually run by mobile phone operators; they are expensive to build and maintain, but they support continuous network access (at lower bit rates) and do not require users nor applications to adapt significantly to the mobile environment. 2) Wireless LANs, in contrast, provide only hot spots of network access thus yielding irregular - intermittent - connectivity. Those nearlynets are often provided as part of a service arrangement (in hotels, airports, cafés etc.) and run by individuals, companies or by mobile network operators (e.g. ISPs). They are rather simple and inexpensive to operate, however with only local geographic coverage - even if many WLAN access points cooperate to extend a network's reach, e.g. on a university campus or in a city center. As a consequence, users have to adapt, e.g. by not moving out of a hot spot area. In addition, applications can be adapted to support offline operation. One important class of mobile users are those traveling by car: they currently have to rely on cellular access technology, which is expensive, bandwidth constrained, and still not ubiquitous. Rather than attempting to provide truly ubiquitous network coverage using GSM or UMTS possibly in cooperation with other networks, our approach is to accept the intermittent nature of connectivity on the road. Therefore, we focus on providing powerful network access where it is available by means of WLAN hot spots along the road as a cost-effective alternative. In our Drive-thru Internet project, we have proven that WLAN technology is suitable to build connectivity islands for wide area networks with intermittent connectivity supporting mobile users in cars. In such a network, the hot spots are located in irregular distances along the road, most likely provided by single or groups of access points at gas stations, restaurants, or in rest areas, with no (or limited cellular) connectivity in-between. The Drive-thru Internet project focuses on providing useful Internet services in environments with intermittent connectivity. While the approach we have taken in the Drive-thru Internet project is quite similar to the FleetNet project in some architectural aspects, we explicitly consider instantaneous and incremental deployability as well as current practices for setting up hot spots.In particular, we do not assume mobile IP, and we also do not assume cars capable of packet forwarding. Similarly to FleetNet, we use an intermediary (a Drive-thru proxy) situated in a corporate or other home network or run by a third party to act as rendezvous point for all (Internet) communications. Mobility management takes place only at the application layer: the mobile node is responsible for re-establishing connectivity in each cloud with the Drive-Thru proxy. The latter acts as a fixed point for efficient communication setup: it fetches and buffers content from the Internet on behalf of the mobile node and forwards this data whenever the mobile node is reachable. Apparently, this architecture deviates from the well-established end-to-end paradigm that the Internet and most Internet protocols are based on. http://www.drive-thru-internet.org/ for detailed information and a complete list of papers
Future heterogeneous wireless networks will encompass different link layer technologies and allow selecting the most appropriate network depending on different criteria. To support mobile nodes in the selection process, network information services are developed that provide the mobile node with sufficient information about its network neighborhood, typically focusing on the optimization of handover processes. With Network Service Maps we take a more general approach towards network information services, which is needed to support mobile communications in the existing environments of WLAN hotspots and wide area mobile communications networks. Service Maps are a mobile data management approach allowing a mobile user to obtain a detailed view of available networks and the services they offer depending on the user context such as geographic position, mobility paths, and application requirements. Based on our experiences with networking in highly mobile scenarios from which we have derived a set of requirements for a general information service we have developed a system design and data model that also accounts for business and (incremental) deployment considerations. Network Service Maps are the foundation for an approach we call Scheduled Disconnection-Tolerant Networking for mobile communications, because service maps enable a mobile node to anticipate connection losses, future contacts etc., and thus help to predict connectivity conditions, e.g., for scheduling application and system behavior, for optimizing handover etc.
Measuring real-world protocol and application behavior in DTN scenarios can be a resource-consuming task (as our activities in the Drive-thru Internet project have shown). For example, measuring the performance of DTN-enhanced mobile ad-hoc networks for applications such as sensor networks can likely involve more than 100 mobile nodes each of which running a non-trivial DTN implementation. Unfortunately, simulation is rarely useful for developing and assessing the performance of typical DTN setups, as the complex protocol behavior of real-world applications, bundle routers etc., cannot be re-produced accurately in a simulation environment. What is needed, is a testbed environment, that allows researchers to develop and assess protocol behavior of complete stacks, such as production TCP stacks, MANET routing sub-systems, DTN bundle router functionality and real-world user applications such as web browsers and e-mail agents under controlled, reproducible network conditions. We have developed the Kasuari emulation framework for these kinds of scenarios and have used it for a range of non-trivial measurements. The Kasuari framework is mainly intended to help with (IP) protocol development and testing. One of its features is the possibility to run unmodified real-world networked applications on a virtual host under simulated network conditions. The framework is based on Xen 3.0, and comes with scripts to run the virtual machines, a pre-configured filesystem image (with DTN and AODV implementations), a copy-on-write driver and a few other tools. It can be used for testing almost any kernel module or networked application that runs on Linux, and it allows to simulate complex and realistic (wireless) networks using a slightly adopted version of the ns2 network simulator.
For scalable and robust communication in Delay-Tolerant Networking scenarios, we have developed Uni-DTN, a DTN convergence layer protocol for unidirectional transports. The protocol is based on FLUTE (File Delivery over Unidirectional Transport). DTN (Delay Tolerant Networking) is an end-to-end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. The DTN architecture is specified in [RFC4838]. Unidirectional transport refers to communication over networks without any return channel. Unidirectional communication is relevant to many DTN communications scenarios such as satellite-based communications or terrestrial broadcast communications, i.e., environments that are typically classified as challenged networks. In unidirectional networks, reliability and flow control cannot be achieved by return-channel-based mechanisms. It should be noted that this applies to both unicast and multicast networks. Reliable multicast transport protocols often apply techniques such as forward error correction (FEC) and periodic retransmissions to increase reliability without receiver-feedback. For receiver-based rate- control, mechanisms such as layered coding may be applied, where receivers can select an appropriate aggregate reception rate by receiving on a (sub) set of channels. In networks that support appropriate multicast routing and signaling this can also be applied to achieve congestion control.
https://prj.tzi.org/cgi-bin/trac.cgi/wiki/Uni-DTN
I have developed Ruby bindings (dtn-ruby) for DTN2's application library. dtn-ruby comes with some Ruby classes that provide some abstraction over the direct bindings to the DTN2 client lib functions. There is a class called DtnClient, and instances of this class represent connections to the DTN bundle router. See the sample application dtncat in the apps directory of the dtn-ruby SVN module. The following sample code (taken from dtncat) illustrates basic receiving in blocking mode:
client = DtnClient.new("dtn://host1/dtncat")
if client.ok? && (client.register()==0)
puts("Registration successful.")
spec = BundleSpec.new(client.eid)
payload = BundleMemPayload.new
else
puts(client.strerror(client.status))
exit(-1)
end
if localEid
if (client.recv(spec,Dtn::DTN_PAYLOAD_MEM, payload, -1) < 0)
puts("error no bundle received.\n")
puts(client.strerror(client.status))
else
bytes=payload.getBufLen
print(bytes)
puts(" bytes received.\n")
puts(payload.getBuf.slice(0,bytes-1))
puts("--")
end
client.unregister
client.close
puts("done.")
exit(0)
end
dtn-ruby can be downloaded from https://prj.tzi.org/cgi-bin/trac.cgi/wiki/Dtn-ruby.
The DETOUR project is a two-years practical students' computer science project at Universität Bremen. The general topic is application development for future mobile communications with a focus on disruption-/delay tolerance. One of the thrusts of the project is the notion of employing emerging community WLAN effort such as FON, sofanet etc. as an cost-effective communication infrastructure in order to develop innovative services for mobile users. Enabling technologies such as DTN and Network Service Maps are applied to different challenging scenarios such as mobile WLAN usage in vehicular environments. |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||