AirTube for Android

AirTube - service oriented mesh network solution for Android applications

AirTube is a platform which realizes an "Internet of Services" - simply and flexibly. The number of WiFi enabled appliances, which can be connected to smartphones, are becoming endless. "Connecting services" is getting more important than "connecting devices" for the network of these WiFi enabled appliances and smartphones. AirTube is an Open Source library, which is built to "connect services" on Android devices and other Java platforms.

Technically, AirTube is a networking library for Android providing Service Discovery, Publish/Subscribe Asynchronous Messaging, and Application Layer Mesh Networking functionality. AirTube network requires no server. With its simple and easy to use API, AirTube shortens the development cycle of network applications for mobile devices. For example, applications to share multimedia content, such as camera, microphone, speaker, or sensors among multiple Android devices, can be developed in a very short time frame.

AirTube is free and licensed under the LGPL v3.

If you are designing or developing an Android based network product or system, AirTube is for you!

AirTube network: Peer to peer service connection for local network and also for remote network over the Internet

One of the most commonly used "service discovery" protocols today is Apples "Bonjour" or more technically "DNS-SD over multicast DNS". Another one is Qualcomm's AllJoyn. AirTube, by targeting Android, provides application developers and product designers with an optimal service oriented solution for mobile devices. It has mesh networking capability built in, which realizes the unique features described below.

We have built AirTube from our more than 10 years of experience and effort in the mesh technology field. With the flexibility of the AirTube mesh, you can expand your service over the network in various forms.

Download

  • AirTube source code: GitHub
  • Developer documentation: GitHub

 

 Technical Overview

What is AirTube

AirTube is a networking library especially designed for service oriented solutions. It can run on any Java platform, but is optimized especially for the Android platform while maintaining the same programming interface for both. On Android, AirTube is implemented as an Android service (not to be confused with a service in AirTube) which can be used by several Activities at the same time thru Androids "Binder" IPC. This is shown below. 

Key Features:

  • Distributed peer-to-peer overlay mesh network independent of IP addresses
  • Distributed service discovery by "name" and JSON description
  • Asynchronous message-oriented networking optimized for multimedia data
  • Efficient and small library (~250KB) for Android and any Java platform

By combining these features into a small and dedicated library, AirTube frees application developers from networking details like topologies, IP addresses and port numbers, and simply lets them discover "services" and receive data from it.

The core of AirTube is the unique implementation of a hybrid application layer mesh routing protocol offering a lot of flexibility in network topologies.  Additionally, the integration of service discovery and asynchronous messaging makes it very easy to discover and connect to "services", be it local, remote or anywhere in the global AirTube mesh "cloud".  More details are described below.

 

How AirTube works

Service Discovery

AirTube takes a service-oriented view and its service discovery helps applications to find all available instances of services on demand. Every device in an AirTube network can announce one or more services which are identified by an "AirTubeID". The AirTubeID is composed of "Device ID" and an integer value, which is dynamically assigned when the service is registered with AirTube. This is equivalent to the combination of IP address and port in a IP network. Below shows a screenshot of the AirTubeMonitor and, for example, 3/15086... is the AirTubeID for the "test" service.

 

The SERVICES panel shows the list of available services in this AirTube network.In this example, there are 5 services on remote peers:

  • video: AirTubeID[11/c04a..] provides this service, ToS is VIDEO
  • audio: AirTubeID[3/1508..] provides this service, ToS is VOICE
  • test: AirTubeID[5/5e53..] provides this service, ToS is NORMAL
  • video: AirtubeID[2/5e53..] provides this service, ToS is VIDEO
  • cv/people-count: AirTubeID[1/5e53..] provides this service, ToS is NORMAL

 

As this example shows, a single Android device can provide multiple services and there can be more than one service providers for the same service name. For example, the "cv/people-count" service provides a "computer vision" service which is counting the number of people by our CV algorithm and sends the result (the number of people detected) to the clients. Each client has its own threshold to start subscribing the video service from this service peer. 

Clients interested in a certain service can search for a "service name" and will be notified of any service which is available with that name. In the screenshot, there exist five services which are represented as "video", "audio", "test",  "video" and "cv/people-count" respectively.  Service can further be described by a service-specific JSON string (e.g:  { "codec": "h264", "width": 640, "height": 480 }) and the service can choose a particular transmission type and its type of service (ToS/QoS). These service descriptions are spread thru the mesh network. Services themselves don't need to manage clients' state, they just publish their data and AirTube takes care of distributing the data. All data transmission and service subscription is done efficiently and asynchronously on a message (packet) basis using the Java NIO framework.

Different from the conventional approach, AirTube service discovery is designed to work especially for services on mobile devices, where services are likely to have a dynamic and adhoc nature. In the AirTube implementation, we strategically focused on the integration of mesh routing and service discovery, to solve this issue.

Next, we describe different network topologies where this flexible service oriented network solution can work.

AirTube Topology

AirTube creates a peer-to-peer network in (1) a single LAN, (2) over local Layer 3 (IP) network and (3) over the Internet without a server device. To realize this, AirTube provides an "overlay" mesh network feature on the application layer ("OSI Layer 7").

One of the core AirTube technologies is "overly mesh network" which connects the AT nodes across routers by exploring the best route to reach each destination AT node. AirTube implements its own hybrid routing protocol on Layer 7, which combines an improved distance-vector (DV) protocol with an on-demand (OD) routing protocol.

The next image shows a simple topology composed of a single LAN network. A blue box indicates "AirTube running on Android" and a light blue box indicates "AirTube running on non-Android platform". All AirTube (AT) nodes are direct neighbours to each other and multihop relaying is not necessary in this simple case.

 Note: Case 3, adhoc mode, refer to our work on 802.11 IBSS mode on Android here

The next image shows a topology example over a routed local L3 network. Case 1: AT nodes are connected either by using "ProxyAT" or by an AT enabled router. "ProxyAT" is an AT node connected to remote ATs over "TCP tunnel": packets are delivered between ProxyAT and its connecting remote AT nodes through the tunnel. In general, a ProxyAT node runs on stable equipment with JVM platform, for instance a PC. An AT enabled router can be built on an embedded PC or open architecture router such as OpenWRT.

airtube-topology-02 

The next image shows the AirTube peer-to-peer network over the Internet. "ProxyAT" functionality is also used in this case and it is located at a certain location in the public cloud. Case 1 shows how ProxyAT works to connect two remote AirTube networks. As soon as one AT node in each network has a tunnel to the ProxyAT node, all other AT nodes in the same network are automatically connected to the remote nodes by the mesh technology. How they can reach each other is shown by the red arrows.

AT nodes connected over 3G/LTE network can also join the AirTube peer-to-peer network via a ProxyAT node. Once it gets connected to the ProxyAT node, it is connected to all AT nodes reachable by the ProxyAT node instantaneously.

In case 2, two ProxyAT nodes are connected. This configuration can be useful for administrative flexibility, for providing better throughput, load balancing, and for higher reliability as each ProxyAT can be used as a fallback for the other. 

airtube-topology-03

 Finally, the following AirTube Monitor GUI screeshots show the state of multihop connections.

  • Peer list: This AT node has 6 remote nodes (peers), 4 of them are "neighbours" direclty connected. 88 is reached via 77 (2 hops). 15086 is reached via 77 and 88 (3 hops).
  • Traceroute: Showing that 88 is now reachable via 77.

 

Publish/Subscribe

Services in the AirTube network follow the "publish/subscribe" paradigm. Any participant in the network can announce "services" which are found by "name" (String) and are further described by service-specific JSON. Once a service has been found, clients can subscribe to the service in order to receive the service data (e.g. video stream) or to send data to the service.

To make the data sending and receiving simple and efficient for its users, AirTube provides an asynchronous message-oriented networking abstraction. Services can simply specify the type of data transmission they want (e.g. UDP, TCP or Broadcast) and then simply pass data packets to AirTube, which will transport them over the best path to the destination.

 

What is the benefit of AirTube

For Android based network product designers

AirTube, with its embedded mesh capability gives freedom for product designers to deal with various network topologies. AirTubes flexibility can integrate any pre-existing or sponateously formed network topology into its "overlay mesh" network, be it local Ad-hoc (IBSS mode) Wi-Fi networks, Access Points, Ethernet, 3G/LTE mobile data connections or public servers. There is no limit for service expansion, by adding needed services, whatever sensor data or video data integration, from anywhere in the world, or locally without any server, you can do as you wish.

In addition to topology freedom, AirTubes architecture, optimized for a mobile environment, will give product designers freedom in "connecting services". Service can be anywhere, service can "come and go" at any time and services don't need to care about clients status. So product designers can design coordination among services flexibly. In contrast to "cloud" services which always require Internet connectivity and big servers somewhere on Internet, AirTube forms its own "cloud" which can exist only locally, while also offering the possiblity to interconnect over the Internet.

For Android based network application developers

By combining flexible service discovery with an overlay peer-to-peer mesh networking protocol and asynchronous message-oriented networking AirTube frees application developers from worrying about underlying networking technologies. Services and clients can simply specify the type of data transmission they want (e.g. UDP, TCP or Broadcast) and then pass data packets to AirTube, which will transport them over the best path to the destination.

Since most of the complicated things are solved inside AirTube, its API is quite simple and easy to use.

A service simply registers a certain ServiceDescription ("name" and the data transmission type) with AirTube and gets assigned its unique AirTubeID. It can then send "ServiceData" and AirTube takes care of where to distribute this data to. A client on the other hand, does not announce, but search for a certain service by "name" and will be notified of any matching service. It can then subscribe to one or more of them and receive its data.

 

What Thinktube can do

Our expertise is with wireless networks, including mesh protocols, architecture design and implementation in the embedded Linux field. We believe AirTube will bring great benefit to your Android network product development. According to your request, we hope to provide services, including technology transfer, consulting and implementation support, applying AirTube technology.

Contact: airtube@thinktube.com

AirTube for Android (tkaiso)

  • What is AirTube

AirTube is an easy to use networking library for Android and Java creating a distributed peer-to-peer overlay mesh network with service discovery and asynchronous message-oriented end-to-end connectivity. By combining these three main features into a small and dedicated library, AirTube frees application developers from worrying about networking details like topologies, IP addresses and port numbers, and simply lets them discover "services" and receive data from it, be it local, remote or anywhere in the global AirTube overlay mesh "cloud".

Allthough AirTube is a generic networking library for Java, it is optimized for Android mobile devices and the transmission of real-time multimedia data like streaming audio and video.

AirTube is an Open Souce project and licensed under the LGPL.

  •  How AirTube works
    • AirTube Topology

AirTube creates a peer-to-peer network in a single lan, over local L3 network and also over Internet even without a servier device. To realize a peer to peer network over L3 network (including over Internet), AirTube provides overlay mesh network functionality on "OSI Layer 7". 

Next slide shows simple topology composed of a single LAN network. As descibeed before, AirTube can run not only on Android devices but also simple Java platform including a PC. Here in this document, AD stands for "AirTueb running on Android" and AJ stands for "AirTube running on Non-Android platform".  we call this latter case also "AirTube on Pure Java".  Case 3 in this slide shows the topology built on IEEE 802.11 IBSS network, which is standard functionality defined in 802.11, but most of the commercial Android devices fail to implement it. But we, thinktube, also worked for this ........ (not yet completed )  please refer http://www.thinktube.com/tech/android/wifi-ibss 

 Next slide shows the topology over local L3 network. One of the core AirTube technologies is "overly mesh network" which connect the AirTube network in a LAN and explore the best route to reach the AitrTube destination node. AirTube implements it's own flavor of the advanced distance-vector (DV)  combined with on-demand(OD) routing protocol invented by Thinktube. After detecting its neighbourhood in its L2 network, AirTube node distributes the information about the shortest paths to all participants of the network across multiple LAN segement. Each member of this multi-hop network will route data on behalf of other devices following the best path to the destination: Local data will be routed locally while at the same time global connectivity is possible.

I need to descibe "solution1" and "solution2".  in below, AG is wrong, I must replace it with AJ node = local relaying AT node (not need to have global IP address)

 

 Next slide shows the topology of AirTube Peer to peer network over Internet. To realise this, we need an AirTube relay node with a global IP address. we call this "AG" node in this slide. At least one AirTube node in a local network must have the global IP address of the AG node so that service information packets and user application data might be routed thrugh the AG node to reach remote AirTube network.

In addtion to Airtube Nodes in local networks, AirTube node connected over 3G/LTE network can also join this Airtube network by assiging the proxy(relay) node address explicitly. please see case1 below.  Case2 shows more advanced topology in which multiple AG nodes are conneted in Internet cloud. this configuration brings the benefits of more flexible administration and also redundancy increasing the reliability.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

following panel shows AirTube Monitor daemon screen on each Android device.

    • Airtube Monitor daemon panel on an Android device

      remote peer node list

          traceroute utility  

      Left panel: PEERS

      This peer has 6 remote  peers, 4 of them are Neighbours direclty connected to this peer and 88 is a 2 hop peer reached via 77. 15086 is a 3 hop peer reached via 77->88.   

      Left panel: TRACEROUTE

      This peer can reach peer 88 via 77

       

    • Service discovery

Every device in an AirTube network can announce one or more services which are identified by an "AirTubeID". AirTubeID is composed of "Device ID" and an integer value, which is dynamically assigned when the service is registered to the AirTube. This is equivalent to the combination of IP address and port as in layer 3 network.  In the following screen shot, 3/15086... is the AirTubeID for the "test" service.  

Clients interested in a certain service can search for a "service name" and will be notified of any service which is available with that name. In the screenshot, there exist five services which are represented as "video", "audio", "test" and "cv/people-count" respectively.  Service can further be described by a service-specific JSON string (e.g:  { "codec": "h264", "width": 640, "height": 480 }) and the service can choose a particular transmission type and its type of service (ToS/QoS). Services descriptions are spread thru the network. Services themselves don't need to manage clients' state, they just publish their data and AirTube takes care of distribution the data to all clients. All data transmission and service subscription is done efficiently and asynchronously and on a message (packet) basis using the Java NIO framework.

Left panel : SERVICES

SERVICES panes shows the lisy of available services in this AirTube network.

In this example, there are 5 services now on remote peers

  • video : AirTubeID[11/c04a..] provides this service, ToS is VIDEO
  • audio : AirTubeID[3/1508..] provides this service, ToS is VOICE
  • test   : AirTubeID[5/5e53..] provides this service, ToS is NORMAL
  • video : AirtubeID[2/5e53..] provides this service, ToS is VIDEO
  • cv/people-count : AirTubeID[1/5e53..] provides this service, ToS is NORMAL

 

As this example shows, single Android device can provide multiple services and there can be more than one service providers for the same sevice name.

"cv/people-count" services provides "computer vision" service which is counting the number of people by our developing CV algorithm and sends the result (people number) to the clients.  Each client has its own threhold to start subscribing the video service from this service peer. 

 

 

     

      • Publish/Subscribe

    Services in the AirTube network follow the "publish/subscribe" paradigm, and any participant in the network can announce "services" which are found by "name" (String) and are further described by service-specific JSON. Once a service has been found, clients can subscribe to the service in order to receive the service data (e.g. video stream) or to send data to the service.

    To make the data sending and receiving simple and efficient for its users, AirTube provides an asynchronous message-oriented networking abstraction. Services and clients can simply specify the type of data transmission they want (e.g. UDP, TCP or Broadcast) and then simply pass data packets to AirTube, which will transport them over the best path to the destination.

     

     

     

     

     

                   AirTube Network         Features              
     airtube-concept-2
    • Service Discovery
    • Piblish/Subscribe Messaging
    • Overlay Mesh Networking

     

    • Comparison to "Bonjour" or "DNS-SD"

    One of the most commonly used "service discovery" protocols is Apples "Bonjour" or more technically "DNS-SD" over multicast DNS. While it can be useful to find and announce services in a local network, and it can help assign local IP addresses automatically, it leaves many problems unsolved. Application developers still have to manage and assign port numbers to its services and then implement the whole IP socket communication themselves. A typical DNS-SD program has to:

    1) Assign IP addresses, possibly with the help of DNS-SD "Zeroconf"
    2) Assign a port number to the "service"
    3) Write a UDP or TCP server to listen on the service port
    4) Use DNS-SD to announce the "service" like "myService.tcp.local"
    5) Use DNS-SD to resolve the service "myService" to an IP address and port
    6) Open a UDP or TCP connection to that IP address and port
    7) Define the application protocol on that connection

    In comparison with AirTube you just have to:

    1) Register a service "name" with AirTube
    2) Look up the service "name" on the client and subscribe to it
    3) Define the application protocol on that "service"

    In AirTube that service can even change IP addresses, or move location, and still maintain the data connection to the client which subscribed before.

    • Download the code and other technical documents

    https://github.com/thinktube-kobe/airtube

     

     

     

     

    RMRカスタムアプリケーション搭載

     ○ RMR9000 アプリケーション開発SDKを使ったカスタム機能開発

    alt


    災害時ネットワーク

     ○ 災害時向け無線メッシュネットワーク活用について

    alt

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    地方公共団体のためのBCP策定のガイドライン(総務省 ICT-BCP初動版 導入ガイド)の中でも「特に、通信手段の洗い出しにおいては一つの通信手段だけではなく、複数の通信手段を挙げておくことが望ましい。」と通信のバックアップを準備することの重要性がうたわれています。

    災害時用ネットワークシステムの予算が限られている場合も、平常時有効利用可能な 無線メッシュ通信ノード(可搬型無線メッシュノード 活用例 ) を準備することで、災害時のバックアップ通信網としての利用が可能になります。

    総務省でまとめられた 「災害に強い情報通信ネットワーク 導入ガイドライン」(ガイドラインはこちら) で災害時ネットワークの課題解決のひとつの方策として挙げられている 「車が拠点を繋ぐ仕組み」 に、可搬型無線メッシュノード の利用が可能です。

    鉄道関連工事遠隔監視の事例

    工事現場監視システム
    線路工事監視システム
    線路脇50mおきに無線メッシュルーターを設置し、夜間に行われる鉄道工事の映像を遠隔監視する実証実験。


    More Articles...

    1. 製品情報