Generic Architecture and Mechanisms for Protocol ... - Size

3 downloads 106241 Views 1007KB Size Report
(c) dynamic class loading and linking functionality .... The Specification class is a subclass of the Product ... readable formats (e.g., Adobe Acrobat) that cannot.
Mobile Networks and Applications (2006) 11: 917–934 DOI 10.1007/s11036-006-0058-x

Generic Architecture and Mechanisms for Protocol Reconfiguration Nancy Alonistioti & Eleni Patouni & Vangelis Gazis

# Springer Science + Business Media, LLC 2006

Abstract The next generation of wireless mobile communications termed beyond 3G (or 4G), will be based on a heterogeneous infrastructure that comprises different wireless networks in a complementary manner. Beyond 3G will introduce reconfiguration capabilities to flexibly and dynamically (i.e., during operation) adapt the wireless protocol stacks to better meet the ever-changing service requirements. For the dynamic reconfiguration of protocol stacks during runtime operation to become a practical capability of mobile communication systems, it is necessary to establish a software architecture that functionally supports reconfiguration. In the present paper, a generic architecture and respective mechanisms to achieve protocol stack and component based protocol layer reconfiguration are proposed. Keywords protocol component . binding . protocol stack . reconfiguration

1 Introduction Over the last decade, mobile communication technologies have spawned a wide gamut of wireless access technologies and systems; those include cellular wireless N. Alonistioti (*) : E. Patouni : V. Gazis Communication Networks Laboratory, Department of Informatics and Telecommunications, University of Athens, 157 84 Athens, Greece e-mail: [email protected] E. Patouni e-mail: [email protected] V. Gazis e-mail: [email protected]

systems (e.g., GPRS/EDGE/GERAN, UMTS, cdma2000), WLAN type systems (e.g., HIPERLAN/2, IEEE 802.11a/b/g, etc.) broadcast systems (e.g., DAB, DVB) and short range connectivity systems (e.g., Bluetooth). Given that future mobile devices will have to support multiple radio access standards and protocol stacks, reconfiguration has emerged as a key technological enabler for the convergence of heterogeneous systems, the support of multi-standard mobile systems and joint radio resource management across different spectrum bands. Audacious visions of reconfiguration [1] involve the dynamic modification of the protocol subsystem within operating network elements (e.g., mobile devices, base stations), which extends to the runtime incorporation of additional protocol stacks. Given the wide disparity in the technical characteristics of wireless equipment, evolution towards fully reconfigurable wireless systems will require a reconfiguration support framework, i.e., a common set of mechanisms which, support reconfiguration procedures on the network infrastructure, including the mobile devices themselves, in a manner that is transparent to their users. The focus of the present paper is on particular design considerations that are material to the facilitation of flexible protocol stack formations as well as on the introduction of a generic functional architecture that supports the dynamic synthesis of entire protocol layers through an assembly of elementary protocol components. The rest of the paper is organized as follows: The status of related industry activities and standardization bodies is presented in Section 2, followed by the design considerations of reconfigurable protocol stacks in Section 3. Section 4 introduces a generic logical architecture to support protocol stack reconfiguration and Section 5 introduces a generic object-oriented UML model for

918

Mobile Networks and Applications (2006) 11: 917–934

the description of reconfigurable protocol stacks. Section 6 presents a management and control architecture that enables reconfiguration of component-based protocol layers. Section 7 provides interface definitions for reconfigurable protocol components while Section 8 presents signalling sequences for protocol stack reconfiguration. Section 9 analyzes our experiences from a prototype and, finally, Section 10 concludes the paper and provides directions for future work.

from extreme vertical integration between software and hardware and lack of horizontal integration across different communication standards and protocol stacks. The desired protocol stack flexibility can be achieved by the following modular 1 design approaches [8]:

2 Previous and related work

&

&

2.1 Standardization activities in reconfigurable communication systems Several standards bodies and related organizations have developed activities relevant to the deployment of reconfiguration functionality in wireless networks and mobile devices. The industry-led OBSAI initiative has published the first specification release for internal base station interfaces, covering control, transport and base-band modules [2], while collaboration agreements to concerned standardization bodies (e.g., 3GPP) and industry fora (e.g., SDR Forum) are under way. The Common Public Radio Interface (CPRI) effort [3] is another industry cooperation working to publish a specification for the internal interfaces of radio base stations between the Radio Equipment (RE) and Radio Equipment Control (REC). Similar initiatives are pursued by proactive mobile network operators; for instance, NTT DoCoMo, the world_s largest wireless ISP, announced the introduction of a software renewal system that allows the users of i-modei cellular handsets to download software upgrades for their handset model while mobile [4]. SDR Forum has defined a Software Radio Architecture (SRA) [5] based upon a variant of the CORBA Component Model specification [6]. SRA specifies a framework for building, configuring, connecting and tearing down software radio applications in a device. The OMG Software-Based Communication (SBC) Domain Task Force has published a specification for a PlatformIndependent Model (PIM) and a Platform-Specific Model (PSM) for software radio components [7]. 2.2 Research activities in protocol stack reconfiguration The dynamic reconfiguration of a protocol stack imposes significant engineering challenges that cannot be efficiently addressed by the conventional Bsilo^ approach to protocol stack design. The latter suffers

&

Adaptive protocols, comprising two parts: a generic layer that implements protocol functions common to multiple protocols and a custom extension layer that implements additional protocol functions required to realize the functionality of a specific protocol. Composable protocols, where the overall protocol functionality is analyzed into elementary protocol functions, which are subsequently used as the building blocks for a customized protocol stack. Reconfigurable protocols, which exploit object-oriented design to define the software architecture of the protocol stack and support replacement of protocol (component) implementations during runtime.

Conduits+ [9] is a black-box framework for network protocol software whose design factors out common structure and behaviour from the protocol specific parts in reusable software components which, can be combined into different protocol implementations without requiring any source code modifications. By considering an entire protocol layer as a component, DiPS/CuPS supports the dynamic adaptation of protocol stacks, in order to come up to the applications requirements or the network optimization issues [10, 11]. In summary, Conduits+ is classified as composable protocol approach while CuPS/DiPS fall in the reconfigurable protocol category. In the X-kernel [12] runtime framework, microprotocol objects form the functionality of the protocol when assembled, according to a graph definition. The Cactus and Appia system extended this concept, proposing a hierarchical composition mechanism for composite protocols based on QoS requirements [13, 14]. In addition, Ensemble is a group communications system which supports the communication between the protocol modules using the linear stacking composition mechanism; however it allows direct communication only between adjacent protocol components [14]. The component concept is also applied in the THINK–FRACTAL frameworks. FRACTAL introduces a generic recursive component model which allows sharing of sub-components between

1 For the rest of the paper the focus is on protocol stack reconfiguration, hence the terms Bprotocol^ and Bcomponent^ are used interchangeably.

Mobile Networks and Applications (2006) 11: 917–934

components [15]. However, this model cannot be easily applied to protocol layers, since it requires suspension of communication links and empty status at the time of replacement. THINK is another component-based framework that targets on building flexible operating system kernels [16]. All these approaches prescribe a particular software architecture style for protocol stack software but reveal little or nothing of their design blueprints, particularly those pertaining to protocol stack reconfiguration (e.g., what functionality supports export/ import of protocol state). In addition, most of the aforementioned frameworks bear a serious disadvantage: the correctness of composition cannot be completely assured and formally verified. In summary, although previous research efforts have provided valuable insight into the intricacies of protocol stack reconfiguration, there are still important architectural aspects of protocol stack reconfiguration that remain unclear—in particular, what is required at the design level for protocol stack reconfiguration to be possible.

3 Design considerations for protocol stack reconfiguration A set of protocol stacks realizes a specific (possibly multi-standard) mode of communication that may be assumed by wireless devices at any time instance (e.g., a mobile device that supports simultaneous UMTS and WLAN operation modes in a 3GPP Rel. 6 cellular mobile network). Reconfiguration implies a certain degree of exchange functionality at particular reference points within the protocol stack, namely: &

&

A (virtual) reference point that exists between an implicit abstract specification of the affected protocol_s functionality and all of its available implementations. This reference point is involved in reconfigurations that simply change one implementation of a particular protocol for another. An actual reference point that exists at the boundaries of adjacent protocol instances. This reference point is involved in reconfigurations that modify the protocol graph (i.e., the particular stratification of protocols) of the communication subsystem.

919

&

Exchanging different protocol stratifications (i.e., manipulating protocol stack graphs) within the communication subsystem.

For instance, reconfiguration of a link layer protocol may entail substituting a single link layer protocol for another but may also involve an entire protocol stack as the substitute (e.g., using a GPRS protocol stack as a link layer protocol in the TCP/IP protocol suite).

4 Generic architecture for component-based protocol reconfiguration The replacement of protocol functionality, specified in protocol components, should guarantee that the new component will be configured in a proper way to achieve seamless replacement [17]. To support the dynamic unanticipated reconfiguration of the protocol subsystem in near-seamless manner that does not disrupt continuity of operation, several functional capacities must be orchestrated carefully: (a) download and installation functionality to dynamically acquire and install the desired software packages in the target device, (b) discovery and decision support functionality to filter infeasible reconfiguration options (e.g., due to resource limitations, etc.), (c) dynamic class loading and linking functionality offered by the protocol execution environment to include unanticipated code into the protocol subsystem, and, (d) control and management functionality over the dynamic assembly of elementary functional components into integral protocol layers. Therefore, it is necessary to introduce mechanisms which monitor and control the protocol reconfigura-

Consequently, protocol reconfiguration within and across the boundaries of communication standards requires two types of exchange functionality (see Fig. 1): &

Exchanging different implementations of a particular protocol (i.e., swapping protocol implementations).

Figure 1 Reconfiguration reference points in the context of a protocol stack

920

Mobile Networks and Applications (2006) 11: 917–934

tion process. Our design approach lies in the introduction of the following layers: &

&

A layer of semantic information regarding the attributes of each individual protocol component and composition information concerning particular protocol layers or even the entire protocol stack—in short, metadata to support decision making in the context of protocol reconfiguration. A management layer that undertakes initiation, control and supervision of the protocol reconfiguration process occurring within a particular protocol layer.

These key artifacts form the cornerstone of a generic functional architecture that supports protocol stack reconfiguration in mobile communication systems. Figure 2 illustrates this architecture with its constituent elements. The key design elements shown in Fig. 2 are: &

&

&

&

&

&

&

The Download Module (DWM) which undertakes the downloading of (software) protocol components to the reconfigurable system and supports multiple concurrent downloads. Each downloading procedure starts by asserting the authenticity of the concerned component_s source and completes with integrity checks (e.g., signature validation) on the downloaded data. The Installation Module (IM) which deals with the integration of downloaded protocol software in the protocol stack execution environment. The Decision Module (DM) which is responsible for the selection of the most suitable protocol stacks to use in a given situation. This module also undertakes the decision for the downloading of new protocol components or protocols. The Query Manager (QM) which caters for the retrieval of protocol stack metadata, the navigation in the metadata knowledge base and the discovery of protocol stack combinations with particular properties or matching a given predicate (e.g., which installation requirements do not exceed a particular limit, e.g., in terms of memory size and total installation time). The Profile Repository (PR) which provides a backend persistence service for reconfiguration metadata (e.g., descriptions of protocol stacks and communication standards) expressed in the aforementioned reconfiguration vocabulary. The Protocol Stack Configuration Control Module (CCM_PS) API, which provides the interfaces for the negotiations and interactions during the protocol reconfiguration procedure. The Protocol Stack Configuration Control Module (CCM_PS) that is responsible for the overall control

&

&

of the protocol stack reconfiguration. This module interacts with the CBCM modules within each layer so as to initiate and synchronize the process of protocol component reconfiguration. The Component Metadata Parser (CMP) which is responsible for parsing and interpreting protocol component metadata and providing information support to control and management tasks concerned with protocol bindings. The Component Binding Control Module (CBCM) that undertakes the establishment of binding and replacement of protocol components belonging to a single protocol layer in the protocol stack (each CBCM controls a specific protocol layer).

The aforementioned modules of the proposed architecture interact, according to three distinct phases, to achieve the discovery of all feasible protocol stacks, the download and installation of the associated software packages and libraries, and, the dynamic binding of the protocol components forming each affected protocol layer. Figure 3 depicts the associated signalling sequence. Considering that, from a design viewpoint, the download and installation functionality is independent to protocol stack formation and synthesis, the remaining sections focus on the latter topics (i.e., the first and last of the phases illustrated in Fig. 3).

5 Modeling reconfigurable protocol stacks In order to identify and deploy the alternative protocol stacks, the CCM_PS has to determine the feasible configuration based on metadata information that are provided by the configuration profiles on the PR, and following relevant triggers by the DM. In our metadata design (Fig. 3), the goal is to provide a minimal set of information classes and associations (i.e., an information model [18]) for the dynamic synthesis of the protocol stack based on service requirements and protocol interdependencies as well as relevant meta-information on protocol layer behaviour (e.g., QoS requirements). To this end, the major classes in our model inherit from the abstract root class Product, which represents objects that can be identified through a (textual) name. Each Product instance bears also a single (URI-convertible) URL attribute that identifies it as an RDF resource [19]—though it may not be accessible over the Web. Based on the aforementioned analysis, Fig. 4 depicts the proposed object-oriented UML model for reconfigurable protocol stack modelling The Service class refines the Product class to represent a precisely defined functionality which is

Mobile Networks and Applications (2006) 11: 917–934

921

Figure 2 The generic functional architecture for protocol stack reconfiguration with a 3GPP Release 6 UMTS/ WLAN protocol stack as example

associated to a textual description. In practice, the Service class provides a placeholder for a service definition and the respective textual descriptor, which may also bear formal semantics (e.g., OMG Interface Definition Language (IDL), W3C Web Services Description Language (WSDL)). Regarding our design objective, it is not particularly important that a unique format is agreed upon and used for the service

descriptor_s notation, since adaptation mechanisms can be used to identify the appropriate handler for each available format. However, it is utterly important each service is unambiguously identified by its descriptor. Subsequent sections elaborate on this overlooked but quite important issue. The Specification class is a subclass of the Product class with additional attributes (author, version,

922

release, description and summary) that models an established specification of protocol functionality (e.g., the specification of a mobility protocol_s functionality). It provides an abstraction for protocol specifications developed and published by authoritative bodies (e.g., the UMTS protocol specifications developed and published by the 3GPP). Currently, such specifications are recorded in various humanreadable formats (e.g., Adobe Acrobat) that cannot be unambiguously interpreted by a computational agent and, therefore, do not support automation of processing. This limitation effectively rules out the possibility of having those specifications interpreted and exploited in the context of protocol stack reconfigurations. Implementation is a subclass of Product that refers to the real-life software artifact that implements some functionality that is associated to multiple specifications. An Implementation may also be used to represent some utility functionality unrelated to a specification (e.g., cryptographic functionality). Considering that software implementations are developed in various combinations of programming language and runtime platform (e.g., C, C++) and that may also be deployed in different containers (e.g., Java archive, Microsoft CAB), the proper modelling of implementations must support the use of different deployment artifacts. This packaging disparFigure 3 Constituent phases of protocol stack reconfiguration

Mobile Networks and Applications (2006) 11: 917–934

ity is facilitated by the Deployment Artifact class and its subclasses that capture and express deploymentrelated concerns that pertain to the download and subsequent installation of protocol software in a reconfigurable communication device (Fig. 4). 5.1 Metadata associations for protocol stack synthesis Broadly speaking, a particular specification may depend on the availability of multiple services and may also render multiple services. Similarly, a particular implementation, in addition to the services that its associated specifications (Fig. 4) collectively require and provide, may also depend on the availability of additional services so as to function properly and realize additional services. Because these concerns apply to Specification and Implementation instances alike, they are accommodated through a pair of associations named requirement and realization that hold between the Service class and the Product class, the latter being the closest common superclass of Specification and Implementation. Regarding the relation between Specification and Implementation classes, we observe that it is not mandatory for an Implementation instance to be associated to a Specification instance; for it might be implementation of utility functionality not subject to standardization yet required by another implementation. Hence, the

Mobile Networks and Applications (2006) 11: 917–934

case of an Implementation instance unassociated to a Specification instance is considered valid. In the typical case, however, the association between a Specification and an Implementation is expressed through the realizationCertificate and requirementCertificate (multilateral) associations. The former signifies that the Implementation instance realizes the behavior of the set of Specifications, while the latter marks the dependence of the Specification instance upon a set of Specification instances. In practice, this seemingly loose modelling approach ensures that design concerns and development choices pertaining to Implementation instances are in no way limited by the need to establish an association to a Specification instance and that the set of options available for implementing a particular protocol remains open. Thus, a particular protocol implementation can be represented in various ways, from a single instance of the Implementation class associated to the respective Specification instance to an arbitrary large set of Implementation instances, all but one of which provide utility functionality to another and exactly one of which is associated to the respective Specification instance. Implementation instances associated to a Specification instance will Figure 4 The UML model for capturing the options pertaining to reconfigurable protocol stacks

923

be identified as such through the realizationCertificate association, while those without such an association will not. 5.2 Metadata encoding for protocol stack synthesis To support wide circulation even across administrative domains and to ease automation, reconfiguration metadata should be represented in a platform-independent format that guarantees interoperability. Two W3C standards, XML [20] and RDF [19] are considered as prime candidates for this task. In general, XML is easier to learn and manipulate, while RDF offers greater capabilities for expressing semantically rich information. However, only RDF is capable of unambiguous representation, because there is a unique explicit interpretation of any RDF data, based on the RDF Model Theory [21]. Consequently, a certain piece of information has exactly one RDF representation, while in XML many different representations with the same underlying meaning are possible [22]. Given that the protocol stack subsystem is an essential element of communication devices and that even the slightest misinterpretation of reconfiguration metadata about a protocol stack would inevitably lead to

924

erroneous manipulations, we chose to represent all reconfiguration metadata for protocol stack synthesis in RDF. A vocabulary named FRCM_ that extends the standard RDF vocabulary is used for the RDF representation. The FRCM_ vocabulary is defined in an RDF Schema (RDFS) document which, in turn, is derived from an isomorphic mapping [23] of the UML model, thus preserving the structural definitions (i.e., the classes and associations) in the latter. Figure 5 presents a simplified form of the RDF graph for protocol stack metadata pertaining to the UMTS Packet Switched (PS) domain protocol stacks. We should note that the list of identified services is tentative; an alternative (e.g., more detailed) identification (and naming) of Service entities is not precluded by the UML model or its RDF representation.

6 Management and control of component-based protocol layer reconfigurations In this section, the main aspects of the layer responsible for the management, control and supervision of the reconfiguration process within a protocol layer are presented. It is assumed that each protocol layer_s functionality may be split in individual components, each undertaking a specific part of the whole protocol layer_s functionality. Each component is associated with relevant metadata, comprising meta-information

Figure 5 A simplified RDF graph for the UMTS/WLAN protocol stack of the SGSN element of 3GPP cellular mobile networks

Mobile Networks and Applications (2006) 11: 917–934

necessary for the identification of binding requirements. This management layer undertakes the establishment and monitoring of the following procedures: & &

The dynamic binding of the protocol components. The dynamic replacement of protocol functionality specified and implemented in protocol components, thus guaranteeing that the new component will be configured in a proper way to achieve seamless replacement [17].

As far as the interaction between adjacent protocol layers is concerned, we adopt the standard assumption that it is realized via Service Access Points (SAP). As shown in Fig. 6, the Component Binding Control Module (CBCM) is responsible for dynamically establishing a particular composition of protocol components. In addition, the CBCM has the overall control of the process of the dynamic replacement of protocol components. The CBCM performs the aforementioned functions by parsing and reasoning about the component_s metadata. To this end, each component_s metadata includes information that enables the CBCM to perform its tasks. In particular, the components metadata include all the necessary information that will allow the CBCM to identify the binding between the components, verify the correctness of the proposed binding and perform this binding (i.e., realize the communication between the protocol components that should be bound together).

Mobile Networks and Applications (2006) 11: 917–934

925

In our architecture, the metadata include the following information: & & &

A unique identifier (i.e., the name of the component). The version and type of the component. The component_s composition information.

The first two fields enable the identification of the protocol component, while the last field indicates which components can be combined with the subject component in a protocol composition. Because this information concerns the deployment of a component_s implementation in particular runtime environment, they form part of a subclass of the DeploymentArtifact class described previously.2 Collectively, the unique identifier and version attributes enable the identification of each protocol component. In addition, the versioning information allows the identification of incompatible components (i.e., components that should not be bound together). Each component_s composition information indicates which components are composed with the specified component. That is expressed through two array structures: &

An array for the input components (the components that send data to the specified component).

&

An array for the output components (the components that receive data from the specified component).

Based on the input and output components arrays, the CBCM identifies the components that should be bound to the specified component. All of the metadata information about a protocol component_s composition is represented in an appropriate XML profile, like the one shown in Table 1. The process of identifying the bindings of a specified protocol component is illustrated with an example. For example, let_s assume that componentA_s metadata include the following input and output arrays: inputArray = [componentB], outputArray = [componentC]. The CBCM should first check the input array for the componentA (this array includes componentB); then it should verify the composition between componentA and componentB by checking that the output array in the componentB metadata includes componentA. Thereafter, the CBCM should check the output array in the componentA metadata and verify the composition between componentA and componentC in the same way.

2 This approach accommodates the case of multiple implementations of a particular component, each intended for deployment to a different runtime environment.

Figure 6 A reconfigurable protocol stack exploiting the protocol component and component binding concepts

7 Defining reconfigurable protocol components The basic step for enabling the reconfigurability concept within the protocol layers is the definition of the protocol component. The latter should be done taking into account that the defined protocol components should realize the functionality of the specified protocol when they are integrated. In addition, it should be possible to compose a specified protocol by using combinations of different protocol components; however, the specified protocol functionality should remain the same. 7.1 Interface specification The fulfilment of the above requirements raised the need for the definition of a generic reconfigurable component interface (ReconfigurableComponentInterface) that incorporates all the necessary functions for the realization of the protocol reconfiguration

926 Table 1 Metadata profile for a single-input singleoutput protocol component

Mobile Networks and Applications (2006) 11: 917–934

XML profile Version 1 Test Protocol ComponentA protocol.test.components.TestCompA Version 1 Test Protocol ComponentB protocol.test.components.TestCompB Version 1 Test Protocol ComponentC protocol.test.components.TestCompC

mechanisms (Fig. 7). In particular, three main categories of protocol reconfiguration aspects are addressed: (a) The necessary functionality to support the dynamic binding of the protocol components. This functionality is realized through the setMyOutputQueues() and setMyInputQueues() pair of methods. These methods are used during the composition of the protocol components. (b) The functionality for the interactions between the protocol components. This functionality is realized by the writeMessage() and readMessage() methods. These methods support the message exchange between the protocol components, which is realized by the input and output queues of the protocol components. (c) The functionality for the realization of seamless reconfiguration during the dynamic replacement of protocol components. The seamless reconfiguration process is achieved with the preservation of state information within each protocol component. In particular, this information describes the state of the protocol component at the time of its dynamic replacement. This state information is then applied in the new protocol component, so as to support operation continuity (of this particular protocol component but also of the aggregate protocol). 7.2 Interface implementation Regarding the implementation issues of the reconfigurable component, a generic reconfigurable compo-

nent interface (ReconfigurableComponentInterface) was defined and the ReconfigurableComponent, which realizes this interface, was introduced. The implementation of each distinct protocol component is realized as a subclass of the ReconfigurableComponent class (Fig. 7). This design provides a generic programming construct for the development of protocol components, including any extensions in protocol functionality. Every protocol component since it is implemented as a subclass of the ReconfigurableComponent, incorporates the necessary functionality which enables the aspects of identified protocol reconfiguration. Finally, the function method allows for the functionality specific to each particular protocol component, i.e., it is intended to be overloaded by protocol component implementations. This design approach enables the decomposition of the protocol layers in different combinations of protocol components, through suitable implementations (i.e., subclasses of the Reconfigurable Component). 8 Protocol layer reconfiguration using protocol components Up to this point, the architecture and mechanisms that enable the establishment of the protocol reconfiguration process were analyzed. In this section, the interactions between the CBCM and the protocol components during the process of their dynamic binding and replacement are presented. Regarding the dynamic binding of protocol components, the CBCM identifies which components must be

Mobile Networks and Applications (2006) 11: 917–934

composed with a particular component based on each component_s metadata information. Once the CBCM identifies that a set of protocol components should be composed together into a protocol layer, it undertakes the necessary signalling to realize that composition; the latter is implemented with the use of First-In FirstOut (FIFO) queues. In particular, the CBCM creates a FIFO queue for each pair of components that should communicate with each other. Thereafter it passes the queue identifier to both of the components. The sending component inserts its packets in the FIFO queue and the receiving component extracts them. Supposing that a protocol component communicates with N components, then this component will realize this communication with the use of N FIFO queues the CBCM creates. These N components, when composed, create a directed graph; each edge of this graph is implemented with a FIFO queue. Furthermore, the queue handlers corresponding to the FIFO queues are stored in a two dimensional array in order to enable their retrieval when necessary.

Figure 7 Protocol component definition (interface and implementation)

927

At this point a reconfiguration scenario which requires the downloading of a new protocol composed of two components, componentA and componentB, will be described. Once the metadata associated to these components have been retrieved and parsed and the associated software packages downloaded (Fig. 3), the CBCM is triggered to realize the process of the protocol component binding (Fig. 8). Initially, the CBCM retrieves the components metadata by using the interface of the Query CBCM, the latter being an RDQL [24] facility for querying reconfiguration metadata (see Section 5) and discovering the feasible protocol stack combinations. Next, the CBCM validates the composition of the two components. Supposing that the composition realizes a directional communication between the componentA and componentB (componentA sends data to componentB), then the CBCM should create only one FIFO queue. Thereafter it passes the queue handler to both the protocol components. To the next step, some aspects related to the dynamic replacement of a protocol component with

928

Mobile Networks and Applications (2006) 11: 917–934

another are clarified. In particular, emphasis is given on the clarification of the different scenarios during dynamic protocol replacement regarding the components with which the old and the new component communicate with. In particular, the following cases are distinguished:

should be downloaded and installed so as to enable the binding of the specified protocol.

& &

The new protocol component communicates with the same protocol components the old component does. The new protocol component communicates with different components from the old protocol component. This means that the new protocol component communicates with some protocol components the old one did not communicate with. Two sub-cases are distinguished: (a) These protocol components exist in the system_s protocol library (i.e., the specified protocol components have been downloaded and installed previously). In this case, the CBCM follows the same steps with the case of the dynamic binding of the protocol components. (b) These protocol components do not exist in the system. In this case, these protocol components

Figure 8 Sequence diagram illustrating the composition process of two protocol components

At this point, the necessary signalling for the replacement of a protocol component will be presented (Fig. 8). In this scenario, the dynamic replacement of componentA with componentC is considered. In addition, it is assumed that componentC exists in the system_s protocol library and that componentC is bound to the same components that componentA does. At first, the CBCM retrieves the metadata for the new component (componentC) and checks which components it is composed with. In replacing a particular protocol component, the CBCM should guarantee the correct initialization of the new protocol component. This is achieved by pausing the function of the old protocol component and retrieving its state information. The latter is subsequently applied in the new protocol component before starting its function, thus ensuring that overall protocol function remains intact. Finally, the CBCM establishes the composition between the componentC and the components it communicates with by passing to it the proper queue identifiers (that correspond to the components it

Mobile Networks and Applications (2006) 11: 917–934

929

Figure 9 A sequence diagram illustrating the process of replacing componentA with componentC

communicates with). These queue identifiers are the same queue identifiers with the old component; they are just retrieved from the structure they are stored. In case that the new component communicates with more components than the old one, the CBCM should not only retrieve the queue handlers that correspond to the components the old component communicates with, but it should also create the necessary queue handlers that correspond to the other components the new component communicates with. Finally, we should note that the FIFO queues function as buffers during the dynamic replacement of a component with new one, since the other components that communicate with replaceable component place their packets in these queues. The latter are being processed by the new component after the finalization of the reconfiguration process (Fig. 9).

9 Performance evaluation The strict performance requirements in protocol stack subsystems form a major issue for communication devices. To this end, in conventional protocol software development practices, the protocol stack subsystem is designed monolithically and in a platform-dependent manner so as to make the most efficient use of the available platform API (e.g., operating system kernel calls). This approach yields a highly optimized implementation which, however, is rigidly integrated together and ir-

revocably tied to the programming facilities offered by the operating system. The introduction of dynamic reconfiguration capabilities in the protocol stack subsystem increases its flexibility but—inevitably—incurs a performance penalty.3 To investigate the performance impact of our protocol binding design in our developed prototype, we undertake performance evaluation studies focusing on the following factors: &

&

Delay overhead induced by the component based implementation of the protocol functionality and respective operation with respect to the interaction between adjacent protocol components (e.g., in terms of additional communication delay between protocol components) Time required for a protocol reconfiguration to take place

To investigate the performance impact of protocol reconfiguration on our prototype and provide answers to these questions, extensive trials were conducted. 9.1 The trial case study: FTP Targeted to trial the presented semantic-based component-based protocol binding and reconfiguration mechanisms, a modular protocol implementation was

3 Let us not forget that, from an engineering perspective, flexibility and performance are inversely proportionate variables—ceteris paribus of course.

930

Mobile Networks and Applications (2006) 11: 917–934

Figure 10 Setup of the performance evaluation system

required. To this end, a proof-of-concept prototype was developed by refactoring an open source implementation of the FTP protocol to produce a component-based implementation. The modified FTP version comprises the following components: &

&

A component responsible for establishing the initial FTP connection and updating the respective connection state information. This component also processes user requests and handles the process of uploading a file to the FTP server. This is illustrated as the FConnection & Upload_ component in Fig. 10. A component that handles the process of downloading a single file from the FTP server. This is illustrated as the FDownload_ and FDownloadAlso_ components in Fig. 10.

To support the runtime reconfiguration of the FTP protocol_s composition, communication between these FTP components is realized through the protocol binding mechanism described in previous sections. The communication pattern between the FTP components is unidirectional; the first FTP component informs the second FTP component about a particular file download request along with its associated parameters (e.g., directory on FTP server, transfer mode, etc.) which are used by the latter FTP component in establishing and progressing the file download session.

9.2 Setup and instrumentation details In this trial setup, the Java VM was the one bundled with the Sun Java Development Kit (JDK) 1.4.2 Standard Edition (SE). To assess the delay incurred by reconfiguration, we considered the case of replacing one of the FTP protocol components during runtime, i.e., while FTP operations are in progress, with an updated FTP component of similar basic functionality, supporting enhanced features (the FDownload Component_ is replaced with the FDownloadAlso_ component). The delay associated to the reconfiguration of the FTP protocol was defined as the time interval from the time instance the existing FTP protocol component is being signalled to stop its operation until the time instance the replacing FTP protocol component is being signalled to start its operation (i.e., the interval during which the FTP protocol is not progressed computationally). That time interval includes the following operations: &

Disconnection of the existing FTP protocol component (i.e., breaking the protocol binding, idle time waiting for the component to be in a safe state to be replaced)

&

Instantiation of the new FTP protocol component

Mobile Networks and Applications (2006) 11: 917–934

&

931

Connection of the new FTP protocol component (i.e., establishing the protocol binding, initialization of the component via state transfer mechanisms)

9.3 Analysis of performance results about the protocol binding mechanism To quantify the delay factor associated to the protocol component binding mechanism, we measured and compared the time lapse from the time instance a user request for a file download is received to the time instance the file download commences for our modular FTP prototype and its original (monolithic) counterpart. The relative percentage (%) of these delay values over 100 samples was calculated. The mean value of this percentage was 4.72%. Thus, the component binding mechanism introduces 4.72% delay to the component based protocol operation compared to the monolithic protocol operation. For the record, the minimum percentage was 1.10% and the maximum percentage was 11.08%. Figure 11 illustrates the percentage differential for these delay measurements. Obviously, the introduction of the protocol binding mechanism incurs only minimal delay on the operation of the FTP protocol (as a composition of protocol components). 9.4 Analysis of performance results about protocol reconfiguration In order to check the feasibility aspects of the proposed mechanisms for protocol reconfiguration, the reconfiguration delay as defined in the previous section was measured as well as the time that is necessary for the Download component to reach a safe state for replacement. In addition, the time difference between the abovementioned delay values was calculated. Figure 12 illustrates the respective delay value measurements for a set of 93 samples, whereas Table 2 presents statistics of the collected performance data for protocol reconfiguration. As the data of Table 2 reveal, the average total reconfiguration delay and the time required by the component to reach a safe state are 2,761 and 2,403 ms, respectively. In particular, this idle time until the process of reconfiguration may be initiated takes 87% of the total reconfiguration time, whereas the delay introduced by the proposed framework is only 358 ms. Specifically, for the current proofof-concept prototype it should be noted that the time that is necessary for the Download component to reach a safe state for replacement varies, since once

Figure 11 The delay percentage differential between the component-based FTP case and its monolithic counterpart

the Download component has initiated the process of software transfer to the system, it should finalize the file downloading before it can be replaced. The above condition justifies the reason why the idle time takes 87% of the total reconfiguration time. Therefore, it is clear that the total reconfiguration delay depends mostly on the time required for a component to complete its operation so that it can be transparently replaced preserving the system reliability. Moreover, it is apparent that the proposed framework is applicable in lower layer protocols since the mean value of the reconfiguration delay posed by the proposed mechanisms is only 358 ms. From a viewpoint concerned with the development of a reconfigurable protocol stack, this is clearly a positive outcome. 9.5 Relation to other protocol functions occurring in the reconfigurable device As already described in previous sections, the dynamic reconfiguration of the protocol stack may affect only a subset of its protocol layers (e.g., the lower protocol layers such as the radio link layer). The black-box paradigm under which protocol layers operate requires that higher protocol layers are impervious to the processes occurring within lower protocol layers. In wireless communications where protocol layers activate and monitor the lapse of multiple timer functions (e.g., timers related to mobility and/or session management), it is highly desirable that the reconfiguration of a protocol layer occurs within a finite time budget that does unnecessarily trigger a timer lapse function at a higher protocol layer. We include these aspects in our evaluation by considering a scenario where the protocol layers specific to the underlying radio technology are modified by a reconfiguration procedure in a GPRS/UMTS mobile setting. We checked our performance figures against the timer values employed

932

Mobile Networks and Applications (2006) 11: 917–934

Figure 12 Delay introduced by the reconfiguration of the composite FTP protocol (for a set of 140 samples)

by the GPRS and UMTS mobility management protocols [25], more specifically the timers that trigger the Routing Area Update (RAU) procedure, i.e., the most frequently occurring mobility management procedure in GPRS/UMTS. We were gratified to find that the delay attributed to protocol stack reconfiguration does not exceed the time budget defined by these timers. Thus, our component binding framework can support the reconfiguration of specific GPRS/UMTS protocol layers fast enough to avoid causing unnecessary mobility management signalling between the mobile terminal and the core GPRS/UMTS network. This also means that end-to-end GPRS Tunnelling Protocol (GTP) sessions are not disrupted, thus leading to a seamless experience at and above the end-to-end IP level. Table 2 Statistics of the delay measurements accumulated in our trial experiments Average t (ms) Median (ms) Standard deviation V (ms) Percentage of samples tD 'jtD  tj > V (%)

10 Conclusions and future work Reconfigurability is seen as one of the strong candidate concepts for the support of the convergence of heterogeneous systems, the evolution and migration of future communication systems, and the introduction of substantial flexibility in mobile systems. Furthermore, reconfigurability provides the ground for the development of yet more advanced concepts like cognitive and autonomic communications [26]. In order to meet these expectations, a major issue is to establish a framework for enabling reconfiguration in all protocol layers, as well as plug-and-play solutions for protocol stack formation and activation. In this paper a generic architecture targeting to cover this Total reconfiguration delay

Time required for the component to reach a safe state for replacement

Time difference

2,761 2,608 1,532 18.28

2,403 2,141 1,486 24.73

358 477 134 1.08

Mobile Networks and Applications (2006) 11: 917–934

important issue of protocol reconfiguration has been presented and analyzed. In addition, generic mechanisms for protocol stack and protocol component synthesis have been designed, implemented and illustrated. Finally, performance issues have been studied and key performance metrics of protocol reconfiguration have been evaluated and discussed. Based on the quantitative and qualitative design considerations set for the protocol reconfiguration attributes, as well as the discussion on limitations of other related frameworks, the proposed generic architecture satisfies many requirements related to flexibility, delay overhead, generic protocol component design, as well as plug and play capabilities. The elaboration of the presented framework to meet the functional requirements of cognitive reconfigurable communication systems will be one of our next research targets.

Acknowledgments This work has been partially performed in the framework of the EU-funded project E2R (http://e2r.motlabs. com/). The authors would like to acknowledge the contributions of their colleagues from E2R consortium. Part of the work presented herein, in particular the generic metadata model for reconfigurable protocol stacks, was done in the context of an internal research project undertaken by the Department of Informatics and Telecommunications (http://www.di.uoa.gr/).

References 1. Dillinger M, Madami K, Alonistioti N (2003) Software defined radio—architectures, systems and functions. Wiley series in Software Radio, Wiley, New York (ISBN 0-47085164-3) 2. Open Base Station Architecture Initiative, http://www.obsai.org/ 3. Common Public Radio Interface, http://www.cpri.info/ 4. NTT DoCoMo press release (2003, October 10) http:// www.nttdocomo.com/presscenter/index.html 5. Bickle J (2000, December 11) Software radio architecture (SRA) overview. OMG TC, Orlando, Florida 6. OMG CORBA Components, version 3.0, June (2002), http:// www.omg.org/ 7. OMG Software-Based Communication (SBC) Domain Task Force, http://sbc.omg.org/ 8. Tuttlebee W (2002) Software defined radio—enabling technologies. Wiley series in Software Radio, Wiley, New York (ISBN 0-470-84318-7) 9. Hermann H, Johnson R, Engel R A framework for network protocol software. Proceedings OOPSLA _95, ACM SIGPLAN Notices 10. Janssens N, Michiels S, Verbaeten P (2001, November) DiPS/CuPS: a framework for runtime customizable protocol stacks. Technical report, DistriNet, K.U. Leuven 11. Michiels S, Mahieu T, Matthijs F, Verbaeten P (2001, June) Dynamic protocol stack composition: protocol independent addressing. In 4th ECOOP Workshop on Object-Orientation and Operating Systems (ECOOPOOOSWS 2001)

933 12. Hutchinson NC, Peterson LL (1991, January) The x-kernel: an architecture for implementing network protocols. IEEE Trans Softw Eng 17(1):64–76 13. Mena S, Cuvellier X, Gregoire C, Schiper A (2003, October) Appia vs. Cactus: comparing protocol composition frameworks. 22nd International Symposium on Reliable Distributed Systems (SRDS_03), Florence, Italy 14. Kannan M, Komp E, Minden G, Evans J (2003, February) Design and implementation of composite protocols. Technical Report ITTC-FY2003-TR-19740-05 15. Bruneton E, Coupaye T, Stefani JB (2002, June 10-14) Recursive and dynamic software composition with sharing. Seventh international workshop on component-oriented programming (WCOP02), Monday, June 10, 2002—At ECOOP 2002, Malaga, Spain 16. Fassino JP, Stefani JB, Lawall J, Muller G (2002) THINK: a software framework for component-based operating system kernels. In Proceedings of the USENIX Annual Technical Conference 17. Minden G, Komp E, Ganje S, Kannan M, Subramaniam S, Tan S, Vallabhaneni S, Evans J (2002, May) Composite protocols for innovative active services. DARPA Active Networks Conference and Exposition (DANCE_02), San Francisco, California 18. Pras A, Schoenwaelder J. On the difference between information models and Data Models. RFC 3444, http:// www.ietf.org/ 19. RDF: Resource Description Framework home page, see http://www.w3.org/RDF/ 20. XML: Extensible Markup Language home page, see http:// www.w3.org/XML/ 21. Hayes P. RDF Semantics, see http://www.w3.org/TR/rdf-mt/ 22. Berners Lee T. Why RDF model is different from the XML model, W3C discussion note, see http://www.w3.org/Design Issues/RDF-XML.html 23. Chang W A discussion of the relationship between RDFSchema and UML, W3C discussion note, see http://www. w3.org/TR/1998/NOTE-rdf-uml-19980804 24. RDQL—A query language for RDF, W3C submission, http://www.w3.org/Submission/RDQL/ 25. 3GPP TS 24.008 V7.3.0, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3, http://www.3gpp.org/ 26. Patouni E, Alonistioti N (2006, June 26-29) A framework for the deployment of self-managing and self-configuring components in autonomic environments. In the Proceedings of the International IEEE WoWMoM Workshop on Autonomic Communications and Computing (ACC 06), Niagara-Falls/ Buffalo-NY Dr. Nancy Alonistioti has a B.Sc. degree and a Ph.D. degree in Informatics and Telecommunications (University of Athens). She had been working for 7 years at the Institute of Informatics and Telecommunications of NCSR BDemokritos^ in the areas of protocol and service design and test, mobile systems (UMTS), open architectures, and software defined radio systems and networks. She specializes in reconfigurable mobile systems and networks for beyond 3G and adaptable services, pervasive computing and context awareness. Moreover, she has wide experience in formal specification and testing of communication protocols and services, design of object oriented, mobile applications. She has participated in several national and European projects (CTS, SS#7, ACTS RAINBOW,

934 EURESCOM etc.), and was Technical manager of the ISTMOBIVAS and IST-ANWIRE projects, which had a focus on reconfigurable mobile systems, networks an respective service provision. She is now member of the PMT and WP Leader of the FP6 IST-E2R project on reconfigurability and she also participates as University of Athens technical manager in the ISTLIAISON project focusing on Location based services in working environments. She is co-editor and author in BSoftware defined radio, Architectures, Systems and Functions,^ published by John Wiley in May 2003. She is TPC member in many conferences in the area of mobile communications and mobile applications for systems and networks beyond 3G. She has over 55 publications in the area of mobile communications and reconfigurable systems and networks.

Ms. Eleni Patouni received the B.Sc. degree from the Department of Informatics and Telecommunications at the University of Athens in 2003 and the M.Sc. (signal processing for telecommunications and multimedia) with honours (ranked first in her class) from the same department in 2005. Since October 2004, she has been a member of the Communication Networks Laboratory (CNL) and has been participating in the IST Integrated Project E2R

Mobile Networks and Applications (2006) 11: 917–934 on beyond 3G reconfigurable mobile systems. Her main research interests include mobile network protocols, component-based models for protocol stacks, reconfigurable protocols for beyond 3G heterogeneous mobile communication networks, and autonomic communication systems. Since July 2006, she is pursuing her Ph.D. in the above thematic areas.

Vangelis Gazis received his B.Sc. and M.Sc. (Communication Networking) degrees from the Department of Informatics & Telecommunications at the University of Athens, Greece in 1995, and 1998, respectively, and his M.B.A. from the Athens University of Economics and Business in 2001. From 1996 until now, he has been with the research staff of the Communication Networks Laboratory (CNL) at the Dept. of Informatics & Telecommunications. He has participated in national and European research projects (MOBIVAS, ANWIRE) of the IST framework programme. He specializes in reconfigurable mobile systems and protocol stacks for beyond 3G mobile networks, ontology languages, reflective and component middleware, adaptable services and open API frameworks for telecommunications. He is currently pursuing his Ph.D. in the Department of Informatics and Telecommunications.