Felix Hupfeld, Michael Beigl

The challenges in telecommunication of the last decades were primarily to enable people to communicate over great distances independently of their location. As the prefix suggests, telecommunication is about remote communication. Telecommunication system abstract from the location of the communication partners.

The use of a telecommunication system arises from the need to communicate with somebody or something who or which is not physically present at the location of the caller. The communication partners (more precise the end-systems) are chosen by their identity, e.g. if you pick up your phone, you want to call a specific person whose identity is represented by her or his telephone number. The same applies to device telecommunication, here using the Internet. The first criterion for selecting the remote computer system is its identity represented by the IP address or the DNS name and then choosing the service. As a consequence parameters as the physical location of the partners are hidden from the user and from the end-system by the telecommunication system.

Local communication supports this by providing a basic communication that is easily understandable to the human and flexible in its use without administrative overhead. In local communication partners (e.g. computerized artifacts) are selected according to their spatial co-location and not based on their identity. This selection process does not require any user interaction or administration. Services or information, which are requested by one device, are retrieved through communication to devices nearby. In this form of communication access to and from devices outside the local environment is not supported.

The importance of the spatial relationship is obvious in human communication: If you want to talk to somebody, you stand in front of him. When you’re talking, you neither want to communicate with a person behind you nor with a person in another room. Furthermore, the identity of the person you are talking with is of less importance. Your scope of communication is the person next to you.

In spatially aware communication devices use location as their primary attribute for selecting potential communication partners. Devices describe a scope of interest in which they are willing to communicate depending on the current state of the application running on the device. By doing so the communication simulates the communication behavior of humans. Only communication from partners inside a scope is accepted. At the end of the paper we describe some example applications, that are build upon such communication paradigm.

Additionally, the reintroduction of the location in a telecommunication system requires a service rendered by a central server in current systems which introduces the problems of service discovery, configuration/administration and availability.

Using telecommunication systems for local communication introduces a large overhead. A genuine location-centric local communication system foregoes the problem of routing packets to mobile devices due to the fact that the message identifies the position of the targets. Thus no techniques such as mobile IP, stemming from implicated locality of the IP address system, need to be employed to be able to route the flow of information to a device in a constantly changing network topology. It does not depend on a central service to define the spatial communication scopes, which introduces the problems of service discovery, automatic configuration and availability.

The RAUM-concept describes the communication of devices according to their spatial relationship in the physical world. Devices define regions of interest in which they communicate (RAUMs). Such RAUMs describe a congruent geometric space in the physical world; the geometric space is defined as a envelop over all points defining the RAUM. Because the communication order in the RAUM-concept is bound to the physical location of the objects taking part in the communication, objects that are inside the space of interest are also inside the communication scope of the object defining the RAUM. Every device that is physically located inside the envelop of a RAUM (or more precisely: where the location is related to the set of points in the physical space) is then a member of the RAUM.

Fig. 1. Stack architecture of the RAUM system

The architecture of the RAUM system is layered and can be related to the one defined in the ISO/OSI model. The major functional operations for communication within the RAUM model are concentrated on layer 3, the RAUM-Layer.

The complete stack of the RAUM-System consists of 4 layers (see Fig. 1). The lowest layer is called "RAUM-Communication-Layer" and groups the physical and the DLL layer (ISO/OSI layers 1&2). The current definition of the RAUM-architecture does not specify this layer. Instead existing implementations of DLL and physical layer are used. The RAUM-Layer is responsible for the creation and dissolution of communication relationships, for device location and routing of packets. Communication relationships in the RAUM-system are created according to the definition of a spatial area, the RAUM. Note that these RAUMs are not restricted to the physical broadcast space of the medium.

The next layer, the RAUM Event-Layer, spans the layers 4 to 6 providing reliable communication and eventually offering abstract event communication services to the application, that resides at layer 7. The rest of this section will focus on the RAUM and RAUM-Event-Layer, but first the run of the RAUM-system is explained in more detail.

Fig. 2. Example of RAUM communication

The communication of the RAUM-system is datagram oriented. Applications running on the devices send datagram packets to every RAUM they belong to. At the application and RAUM Event-Layer these packets are called events. Figure 2 shows an example run: A doorplate defines a RAUM where it wants to receive events from. After definition it gets all events from the two cups (left) inside the RAUM. As one of the cups leaves the RAUM (right), only the remaining cup keeps sending events to the doorplate.

As it is not possible to technically prevent the doorplate from hearing also events from cup 2, the RAUM protocol has to shield the application from these unwanted events. Therefore every object keeps a list of RAUMs which he is belonging to, and a list of all RAUMs it has defined. According to this list the RAUM-Layer decides if a packet has to be ignored or to be processed.

To allow a flexible handling of events adopted to the application needs we had defined three kind of RAUMs:

• Listener-RAUMs: With this kind of RAUM only the object that has defined the RAUM receives all events from all objects inside the RAUM. In the above example the doorplate defines such a Listener-RAUM
• Speaker-RAUMs: If an object defines a Speaker-RAUM all objects inside the RAUM receive all events from the speaker (the defining object). An example of a Speaker-RAUM is a Location-Beacon that constantly sends its location into a certain area.
• Discussion-RAUM: In the Discussion-RAUM every object inside the RAUM receives every event from all objects in the RAUM. This kind of RAUM is needed to allow negotiation with devices in an unknown environment.

The purpose of the RAUM-Layer is to decide whether a received datagram is to be passed on for the user application or to be discarded, according to the RAUM model. As defined in the previous section, RAUM packets are accepted if the potential receiving device and the datagram packet itself are located inside the same RAUM. This is a purely geometric requirement.

To allow such a test, every packet sent must be mapable to a geometric position and every device has to know its own position in space and be aware of the defined RAUMs it is located in. Our devices have a built-in facility to detect their geometric location via a location system (e.g. our IR-Beacons), so they know their location and can tag broadcasted datagram packets with their current position. Device position information is handled by a subsystem called the Locator service whose instances communicate with the RAUM Location Protocol (RLP).

The RAUMs themselves are named and defined geometrically by a sets of points. Currently, unions of spherical and cubic shapes are possible. The RAUMs are either stationary or moving with the device that is defining that RAUM. The interface to layer 3 provides upper layers with functions to open and close RAUMs. New or updated RAUM control information is broadcasted to all other devices via the RAUM Information Protocol (RIP). RAUM management is done by a subsystem called the RAUM service. Data is exchanged via the RAUM Data Protocol (RDP).

If devices use different media for communication or the broadcast area of the medium does not allow direct communication between devices coupling of network segments is needed. This coupling enables for example a PDA with infrared communication to interact with an ordinary network printer or an application running on a desktop computer.

Every medium with its limitations forms something like a logical Local Area Network (LAN). This is not exactly the original LAN concept, but every range-limited medium can be thought of as a network in a local area. For example, the infrared (IR) communication in a room form a LAN, as all IR transmitter-equipped devices in the room can communicate, but no information reaches other rooms. Low power radio frequency (RF) transmission and especially cable networks like Ethernet are other examples. Each LAN covers a specific geometric area, for example the room the wireless transceiver is in or the spots where devices are connected to the Ethernet. The regions covered by these LANs can overlap, and thus a certain area in a room can be supplied by several media (Figure 4).

To allow the inter-medium communication mentioned above, these LANs have to be coupled with devices connected to some type of infrastructure giving them access to the other LANs. This coupling is similar to inter-LAN communication in telecommunication systems. Because there is no explicit addressing in RAUM communication location information of the communication packets is used for routing. The location information paired with the RAUM definition results in an addressing concept where the location is congruent to the address in local communication and which can be used for routing decisions. Such a router caches all communicated RAUM definitions of adjoining LANs. Furthermore the component knows the physical dimension of theses LANs, too. Using this information and the fact that RAUMs are geometrical objects it can be decided which packets from one network interface should be forwarded on the other. RAUM packets are of interest to a LAN if the described RAUM intersects with the area the LAN covers, so they must be forwarded in this case. Packets must be forwarded into a LAN when any of the devices there should receive it, for example when a RAUM covers the geometrical areas of both LANs. So the communication stack has to check all RAUMs in this LAN to see whether the packet is inside. Position information of a distinct device is needed in a LAN when a packet from it has to be routed. Therefore location information has to be associated with every packet send.

The doorplate application defines a RAUM with the same shape as the room it is related to. In our set-up the plate is mounted next to the door and waits for context information emitted in events by MediaCups. These events get packed into RAUM datagrams and sent out via the infrared link. Every other infrared device within range, i.e. every other device in this LAN, receives the packets. The router device, which has a transceiver in every LAN, receives them, checks for the extension of the defined RAUMs and routes them to the appropriate LANs, here the Ethernet. The communication stack of the doorplate application receives them and puts them into the recognized "world", a storage space where the RAUM Event-Layer puts all information of interest into. Events of interest are expressed with the receive operator. The doorplate is able to track the presence of MediaCups in the room this way, and thus can infer from this context to an ongoing meeting.

Writing an application using the spatial awareness feature based on local context can be done easily in a natural way, because the communication stack holds all important information for it. When setting up this application using the RAUM system, the doorplates define a RAUM with the same spatial dimensions as the conference room they are monitoring. The cups in turn are set up to emit their data as messages sent to this RAUM. With this simple setup, using just one RAUM per conference room, it is possible to implement this application; the pseudo code of the smart doorplate is shown below:

 4.2 Communication with peripheral devices

A common scenario in local communication is the wireless connection between an appliance and a peripheral device. For example, a digital photo camera has to communicate with a printer or a storage medium on user’s request, input devices as a mouse or a keyboard have to be bound to a computer. We built a wireless computer keyboard (AwareKeyboard) which can be used to input text on Palm Pilots. The connection between the keyboard and the Palm Pilot is location sensitive: if you put the Palm Pilot next to the keyboard, you can use it to enter text.

The Palm Pilot defines a RAUM of circular shape around his current location and filters for keyboard event messages. On keypress, the keyboard puts an event in the RAUM system, which, when the Palm Pilot is near enough and thus the keyboard is inside its RAUM, is received by the Palm Pilot:

We introduced the term local communication, contrasted it to telecommunication and showed that location-based communication is more suitable to human needs and to local communication topics. Such location-based communication is best suited for interactive rooms where a multitude of computerized artifacts are communicating with each other to carry out tasks mostly without direct user interaction.

The presented RAUM system is an example of such a location-based communication system. The architecture of the RAUM system is layered and can be related to the one defined in the ISO/OSI model. The major functional operations for communication within the RAUM model are concentrated on layer 3, the RAUM-Layer. In this layer delivery and reception of packets according to spatial areas (RAUMs) and routing of packets is handled.

Our current setup shows the advantage of using location-based communication for local applications. Further work will investigate how location-based and telecommunication can be assembled to provide the appropriate communication basis for different application tasks. Also the routing algorithm will be extended to allow for more flexible routing and load balancing. Work on the RAUM architecture will research on the lifetime of events in RAUM-communication and on supporting applications with a rule-based language to describe situation-reaction pairs.