Middleware allows the development of transparent distributed network applications while providing mechanisms that enhance application response at run-time. In particular, varying requirements (often stated as quality of service parameters) have lead to the specification of RT-CORBA [M1], real-time Java [M2][M3] and distributed real-time Java [M4]. These promise to simplify the development of distributed application with complex QoS requirements, such as stringent latency, jitter and dependability needs. On the other hand, standard middleware infrastructures such as CORBA [M5], COM+ [M6] [M7], and MOM [M8] were conceived for static distributed systems and require considerable resources at run-time. (A number of related systems were built using CORBA, such as a distributed robotic system [M9] and a distributed supervisory control scheme for control devices [M10].) Thus, they are not well suited for highly mobile environments, where resource and power constraints, as well as security issues (authentication, authorization and communication secrecy or integrity) pervade the application. Furthermore, the specification and enforcement of QoS present interesting challenges in mobile environments, due to their lack of support for continuous flow of information over error-prone channels and the notion of an on-going communication activity with an associated QoS. Meta-programming techniques are becoming a popular way to enable distributed real-time systems that are adaptable, flexible, configurable, predictable [M11][M12] and composable [M13]. We used a meta-programming architecture based on a two-level reflective middleware model [M14] to develop a QoS-enabled reflective middleware framework, called CompOSE|Q [M15] and we propose to follow the same model in order to design an adaptive robotic middleware framework (ARM) capable to provide an adaptive communication environment, and mechanisms to handle location and power awareness required by DRSs. Since robots use captured video to add visuomotor coordination to their behavior, video transmission becomes a critical issue in the design of the overall architecture. In such a sense, video transmission has an important impact on the required QoS. That is, video transmission needs a continuous circuit-switch like connection requiring certain QoS guarantees such as fast, predictable and loss-free forwarding of data packages. However, robot's mobility may create situations where QoS for video transmission cannot be provided, due to handovers between access routers or network gateways, or frequent notifications that may overload the network resources and/or QoS renegotiation. As a result, QoS and mobility mechanisms should be aware of each other. Thus, the ARM should be able to follow the robot's movement fast enough to minimize the QoS disruption caused to the video transmission. In order to do that, the ARM must track the robot's location and provide coordination between the handover management and the QoS broker. In our prototype, each robot tracks its location using a GPS (Global Positioning System), which is used to trigger the handover management initiation. Assuming that all handovers are planned, the handover initiation determines the type of handover required and sends the corresponding signal message to the QoS broker, which will react to it preparing advance resource reservations along the new route using MRSVP (mobile RSVP). Also, we define three types of handover depending on if the network layer is involved in the handover:

1. Intra-access router provides handover between 2 cells that correspond to the same access router.
2. Inter-access router provides handover between 2 cells that correspond to different access routers that belong to the same LAN.
3. Inter-access network provides handover between 2 cells located in different LANs.

Another aspect of the design is how to keep the mobile robot software up to date. In order to achieve this, we define a mobile API for mobile aware software and provide a dynamic reconfiguration module that keeps track of dependence management and automatically updates software components with minimum disruption and a profile module that gathers specific information in order to (1) specify and manage software updates (what, when and how to change), possibly including installation and uninstallation of services and (2) preservation of application and service properties (safety and liveness) that guarantee system consistency and correctness. On the other side, the ARM components should be aware of the underlying access network characteristics and their core protocols in order to access their resources efficiently and transparently. Hence, the ARM should provide an interface that allows unified access to the (heterogeneous) underlying networks. We propose to follow the UMTS adaptation layer specification, taking advantage of the fact that UMTS represents a transition bridge between the 2^nd and 3^rd generation of mobile services and, initially use GPRS (general packet radio service) as the underlying telecommunication system. GPRS introduces packet-oriented traffic in GSM (global system for mobile communications) and its connectionless network service is suitable for applications based on the Internet protocol IP. Furthermore, GPRS offers a way to specify a QoS profile, which can be tailored to enforce QoS constraints. For example, the ARM can enforce high service precendence, 2^nd reliability class and 1^st delay class for video trasmission, which will enable the use of UDP as a transport protocol, avoiding flow control and the complexities of the current designs of TCP for mobile environments.

---