GB2438665A

GB2438665A - Reconfigurable mobile terminal decomposes protocols for generic data control processing

Info

Publication number: GB2438665A
Application number: GB0610853A
Authority: GB
Inventors: Nikolaos Georganopoulos; Konstantinos Boukis
Original assignee: Toshiba Research Europe Ltd
Current assignee: Toshiba Europe Ltd
Priority date: 2006-06-01
Filing date: 2006-06-01
Publication date: 2007-12-05
Anticipated expiration: 2026-06-01
Also published as: GB0610853D0; GB2438665B

Abstract

A flexible mobile terminal is designed to comprise reconfigurable modules, e.g. components 131-134 of the Generic Mobility Component (GMC) 130, which are implemented by one or more sets of communication protocols 152-1, 152-2, 152-3 to receive an incoming data control packet 120. A generic data control processing means is designed through decomposition of the protocols to be employed, e.g. identify similarities and differences in the protocols, and a model of computation for the generic data control processing means is defined. A dynamic reconfiguration procedure for reconfiguring the reconfigurable modules is specified and a specification for a Generic Component Manager 110 is defined. The mobile terminal designed by this method can modify at run-time the communication protocols it employs so that it is able to connect to more than one access network, and intelligently multi-home and perform load balancing of the various applications it supports.

Description

M&C Folio: GBP94920 1 2438665

A FRAMEWORK FOR A TERMINAL NETWORK PROTOCOL

RECONFIGURATION

The present invention relates to a method for specifying a terminal network protocol reconfiguration. In particular, it relates to a method for specifying a mobile terminal with reconfigurable modules implemented by communication protocols. It also relates to a mobile terminal specified in accordance with said method.

It is envisaged that in the future, communication systems, including wireless systems, will employ pure Internet Protocol (IP) as the solution for packet transport between nodes, with the mobile terminal normally being the last node or sink of the data flow. A mobile terminal could be equipped with one ore more wired network interfaces, thus enabling it to move and connect to different fixed networks. In a wireless communication scenario a mobile terminal with one or more wireless interfaces coimects to the fixed network, through one or more Access Points (AP) or Base Stations (BS).

In the Internet, different protocols are employed to solve issues like 1P mobility management, Quality of Service, security, routing. These solutions are proposed and standardised in the Internet Engineering Task Force (IETF). Fixed network protocol solutions are often adapted, or new protocols are designed to cater for the specific requirements of mobile terminals. As a result, a plethora of protocols is proposed to solve these problems, some for specific communication scenarios and applications and some for general cases.

In the case of mobility management, proposed protocols comprise Mobile IP Protocol (MIP) as described in: C. Perkins, "IP Mobility Support for lIPv4", IETF Request for Comments 3344, August 2002, and D. Johnson, C. Perkins, J. Arkko, "Mobility Support for IPv6", IETF Request for Comments 3775, June 2004.

Handover Aware Wireless Access Internet Infrastructure (HAWAII) has been described in: R. Ramjee, T. La Porta, S. Thuel, and K. Varadhan, "HAWAII: A domain-based approach for supporting mobility in wide-area wireless networks", in Proceedings of the International Conference on Networking Protocols (ICNP), 1999.

Regional Registrations (RR) are discussed in: E. Gusrafson, et al, "Mobile lPv4 Regional Registration", IETF, draft-ietf-mip4-reg-tunnel-01.txt (work in progress), November 2005, and J. Mailmen, C. Perkins, "Mobile IPv6 regional Registration", IETF, draft-malinen-rnobileip-regreg6-00.txt (expired), July 2000.

Hierarchical Mobile (HM1P) IPv6 is described in: H. Soliman, C. Castelluccia, El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", IETF, draft-ietf-mipshop-hmipv6-04.txt (work in progress), December 2005.

Cellular IP (CIP) is discussed in: Campbell, A., Gomez, J., Kim, S., Valko, A., and Wan, C., "Design, Implementation and Evaluation of Cellular IP", IEEE Personal Communications, June/July 2000, and Z. Shelby, D. Gatzounas, A. Campbell, C.-Y.

Wan, "Cellular lPv6", IETF, <draft-shelby-seamoby-celluiaripv6-00.txt> (expired), November 2000.

BRAiN Candidate Mobility Protocol (BCMP) is described in: Costas Boukis, Nikos Georganopoulos, Hamid Aghvami, "A Hardware Implementation of BCMP Mobility Protocol for IPv6 Networks", GLOBECOM 2003, San Francisco.

Further protocol proposals exist for mobility management.

In the case of quality of service (QoS), proposed protocols include IntServ (J.

Wroclawski, "The Use of RSVP with IETF Integrated Services", IETF Request for Comments 2210, September 1997) and RSVP (R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)", IETF Request for Comments, September 1997), Mobile RSVP -MRS VP (A. Talukdar, B. Badrinath, and A. Acharya. "MRS VP: A Reservation Protocol for an Integrated Services Packet Network with Mobile Hosts", Wireless Networks, vol. 7, No. 1, 2001), DiffServ (S.

Blake, D. Black, M. Carison, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services DiffServ", IETF Request for Comments 2475, December 1998); Integrated Services over Specific Link Layers -ISSLL (Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Feistaine, "A Framework for Integrated Services Operation over Diffserv Networks", IETF Request for Comments 2998, November 2000), Mobile RSVP (W. Chen, L. Huang, "RSVP Mobility Support: A Signaling Protocol for Integrated Services Internet with Mobile Hosts", Proceedings of IEEE Conference on Computer Communications (INFOCOM), vol. 3, pages 1283-1292, 2000), HMRSVP (C.-C. Tseng, G.-C. Lee, R.-S. Liu, "HMRSVP: A Hierarchical Mobile RSVP Protocol," 21st International Conference on Distributed Computing Systems Workshops (JCDCSW 01), 2001). Further, numerous security and routing protocols have been proposed in the JETF, however listing all these protocols is beyond the scope of this document.

In C. Castelluccia, L. Bellier, "Toward a Unified Hierarchical Mobility Management Framework", IETF, draft-castelluccia-uhnim-framework-00.txt, (expired), June 1999, a framework is defined that uses MIP for inter-domain mobility but allows the deployment of any micromobility protocol, with the extension of fixed network functionalities to maintain bindings between the various protocol messages.

These communication protocols include procedures with various nodes in the network participating. The mobile terminal is one of the nodes involved in the various procedures comprised in a specific protocol. A mobile terminal thus performs specific tasks and goes through different states when operating a specific protocol. Furthermore, the mobile terminal differs from other network nodes involved in supporting a protocol in that it is the only one with limited resources, including processing, memory and battery life.

Currently, mobile terminal protocol functionalities are implemented in software and embedded in the system's network protocol stack. This can be implemented in different ways: 1. Partly into the terminal's kernel (Operating System) (e.g. the Mobile IPv6 KAME implementation: www.kame.net) 2. Complete protocol modules (kernel modules) that are loaded in the system memory (e.g. the Linux IPv6 kernel module implementation: Linux lPv6 How-To, http://tldp.org/HO WTO/Linux+IPv6-HO WTO/systemcheck-kernel.html) 3. User space programs that are executed on demand (e.g. MiND BCMPv6 micro mobility management protocol implementation (Costas Boukis, et a!., "A Hardware Implementation of BCMP Mobility Protocol for IPv6 Networks", (supra)) In any case, protocol functions have access to terminal resources like network interfaces, routing tables, etc. In addition, advances in software radio technologies will enable terminals to be equipped with reconfigurable RF front ends. This will enable a wireless mobile tenninal to modify its wireless properties and connect to different Access Networks (AN). Further, the existence of one or more interface, wired and/or wireless, will enable the mobile terminal to connect to more than one access network. These enables the mobile terminal to multihome to networks with different application support characteristics and perform intelligent load balancing for different types of applications.

It is likely that different access networks will support different networks, which will require the terminal to be able to securely support concurrent multiple protocols.

Currently, protocol design especially in the mobile terminal, where all protocols put functionality, is orthogonal and simplistic. Most designs consider only single stand-alone protocols and assume exclusive control of terminal resources.

Furthermore, regarding protocol implementation as mentioned above, there are three ways of loading specific protocol functionalities, as complete protocol blocks in the terminal. Consequently, to change the terminal's protocol operation, either the system kernel has to be modified to include the new protocol code, and the kernel recompiled and reboot, or the whole kernel module has to be unloaded and replaced with the new protocol precompiled module, or the user space program will be terminated and a new one executed. A limitation of the kernel approach is that there is no on-the-fly protocol reconfiguration. Limitation of all approaches is that there is no inherent simultaneous protocol operation, since common terminal resources need to be accessed from all the protocols. This has implications on performance, security and terminal resource utilisation.

Specific network protocols are designed to address relevant problems (mobility, Q0S, security, routing) which apply to a specific communication scenario, involving a set number of nodes and functionalities and in most cases specific applications. Thus, tailor made protocols are often evaluated in these specific scenarios and found to outperform other proposals. This leads to prolonged efforts to design and standardise the super protocol, capable to address most cases, or design and standardisation of narrow scope protocols, applicable to limited circumstances. Those efforts are likely to lead to an infinite loop.

In E. Patouni, N. Alonistioti, P. Magdalinos, "A Framework for Protocol Reconfiguration", In Proceedings of the 7th IFIP International Conference on Mobile and Wireless Communications Networks (MWCN 2005), Marrakech, Morocco, September 2005, a framework is proposed for composing individual network protocols as part of the system kernel.

Other proposals have been made for reconfiguration and composition of individual protocol in various systems: Norman C. Hutchinson and Larry L.Peterson, "The x-kernel: An architecture for implementing network protocols", IEEE Transactions on Software Engineering, 17(1): 64-76, January 1991; Sergio Mena, Xavier Cuvellier, Christophe Gregoire, Andre Schiper, "Appia vs. Cactus: Comparing Protocol Composition Frameworks", 22nd International Symposium on Reliable Distributed Systems (SRDS'03), Florence, Italy, October 2003; Magesh Kannan, Ed Komp, Gary Minden, Joseph Evans, "Design and Implementation of Composite Protocols", Technical Report ITTCFY2003-TR-l9740-05, Feb 2003; E. Bruneton, T. Coupaye, and J.B. Stefani, "Recursive and Dynamic Software Composition with Sharing", Seventh International Workshop on Component-Oriented Programming (WCOPO2), Monday, June 10, 2002 -At ECOOP 2002, Malaga, Spain (June 10-14, 2002); Jean-Philippe Fassino, Jean-Bernard Stefani, Julia Lawall and Gilles Muller, "THINK: A Software Framework for Component-based Operating System Kernels", In Proceedings of the USENIX Annual Technical Conference, 2002; N. Janssens, S. Michiels and P. Verbaeten, "DiPS/CuPS: a Framework for Runtime Customizable Protocol Stacks", CW Technical Report 328, Dept. of Comp. Science, K.U.Leuven. November 2001; S. Michiels, T. Mahieu, F. Matthijs and P. Verbaeten, "Dynamic Protocol Stack Composition: Protocol independent Addressing", In 4th ECOOP Workshop on Object-Orientation and Operating Systems (ECOOP000SWS' 2001), June 2001; G. Minden, E. Komp, S. Ganje, M. Kaiman, S. Subramaniam, S. Tan, S. Vallabhaneni, J.Evans, "Composite Protocols for Innovative Active Services", DARPA Active Networks Conference and Exposition (DANCE'02), San Francisco, CA, May 2002; Moessner, K.; Vahid, S.; Tafazolli, R, "Terminal reconfigurability-the OPTiMA framework", 3G Mobile Communication Technologies, 2001.

In EP0767564, a network interface device is disclosed which can communicate with other devices via a local area network (LAN) by using various protocols and frame types, and which can be remotely configured to use different protocols and frame types.

In WO985 7508 an extended mobility is proposed for a DECT system, based on Mobile P. In US2004190477 a dynamically reconfigurable dynamic wireless network for connecting a local area network LAN) to wireless mobile stations is described.

In WO2004049745 a structure of a mobile terminal for different communication systems is disclosed, containing a number of exchangeable receive modules which are coupled with higher layers via a convergence layer.

Consequently, it is desirable to develop a method that overcomes the limitations imposed by individual protocols. It would further be desirable to develop a method that can overcome the inflexibility of conventional component protocol operation.

Accordingly, aspects of the present invention seek to mitigate, alleviate or eliminate the above-mentioned problem.

In a first aspect of the present invention, a method of defining the design specifications for a mobile terminal comprising a data contiol packet processing means operable to process an incoming data control packet, said data control packet processing means further comprising a plurality of functional modules and a plurality of reconfigurable modules; a memory means operable to store one or more sets of communications protocols for use in said plurality of reconfigurable modules; and a control means operable to configure and control said data control packet processing means such that in use said plurality of reconfigurable modules are implemented by means of said communications protocols to receive said incoming data control packet, comprises the steps of: designing a generic data control packet processing means through protocol decomposition of the protocols to be employed; defining a model of computation for the generic data control packet processing means; specifying a dynamic reconfiguration procedure for reconfiguring the reconfigurable modules; and defining a specification of

the generic component manager specification.

In a first configuration of the above aspect, the step of designing the generic component further comprises: identifying similarities and differences in the protocols through detailed protocol decomposition; and developing a unified generic component.

In another configuration of the above aspect the step of identifying similarities and differences in the protocols through detailed protocol decomposition further comprises dismantling the protocols of interest in individual orthogonal components.

In a further configuration of the above aspect, the step of designing a unified generic component further comprises the step of, once the commonalities and differences among the target protocols are identified, developing a generic component that will reconfigure only by acquiring the parts that the protocols differ.

In yet another configuration of the above aspect the step of defining the model of computation further comprises identifying the requirements of component interaction; and selecting the most appropriate model of computation from a group of predetermined models of computation.

In one more configuration of the above aspect the step of identifying the requirements of component interaction further comprises one or more of the following: identifying the number of processes which are needed; identifying whether asynchronous messages can be supported; identifying the number of common resoursces accessible by the components; identifying whether operation is data or event driven.

In another configuration of the above aspect the group of predetermined models of computation comprises a component interaction (CI) model of computation.

In yet a further configuration of the above aspect the group of predetermined models of computation comprises one or more models of computation which have been adapted for the specific generic component derived for a protocol family.

In another configuration of the above aspect the step of specifying a dynamic reconfiguration procedure further comprises a platform specific method for loading and unloading at run-time the various reconfigurable modules; a method for the Generic Component to access at run-time the relevant protocol modules; specifying the changes to terminal's operating system (kernel) to support the generic component.

In one more configuration of the above aspect the various reconfigurable modules for loading and downloading at run-time include the generic component module itself and the supported protocol component modules.

In a further configuration of the above aspect the platform specific method for loading and unloading at run-time is the Dynamic Linking facility available in many operating system platforms.

In yet another configuration of the above aspect the programming language specific definition of Reconfigurable Elements can be dynamically adjusted to point to the appropriate protocol module.

In a further configuration of the above aspect, in the case of programming languages like C, the reconfigurable elements are pointers to functions In one more configuration of the above aspect, in the case of object oriented classes, the reconfigurable elements are overridden methods of parent/child classes In another configuration of the above aspect the step of specifying the changes to terminal's operating system further comprises intercepting relevant protocol messages, and overriding of default functions not needed by all relevant protocols.

In a further configuration of the above aspect the Generic Component Manager is a terminal module responsible for controlling the flexible reconfigurable process.

In yet another configuration of the above aspect the step of specifying the generic component manager further comprises: identifying when a new protocol is to be installed in the system; attaining the appropriate software modules necessary to construct the protocol according to the employed Generic Component; installing said software modules in the system architecture with preferred dynamic loading/unloading utility; adjusting the Reconfigurable Elements so as to deploy the relevant modules.

In another aspect of the present invention, a computer program comprises data processing device program code means adapted to perform the method of the first aspect when said program is run on a data processing device.

In a further aspect of the present invention, a computer-readable medium comprises computer-executable instructions for defining the design specifications for a mobile terminal in accordance with the first aspect.

In one more aspect of the present invention, a mobile terminal comprises a data control packet processing means operable to process an incoming data control packet, said data control packet processing means further comprising a plurality of functional modules and a plurality of reconfigurable modules; a memory means operable to store one or more sets of communications protocols for use in said plurality of reconfigurable modules; and a control means operable to configure and control said data control packet processing means such that in use said plurality of reconfigurable modules are implemented by means of said communications protocols to receive said incoming data control packet, the mobile terminal being specified according to the method according to the first aspect of the invention.

According to the present invention, a framework is proposed that may be applied to network protocol families and may lead to a flexible modular component protocol operation, enabling the mobile terminal to connect to different access networks, support multiple protocols, while optirnising its performance.

This framework has already been applied to the family of mobility management protocols and a Generic Mobility Component (GMC) has been developed and including in co-pending patent application GBO5 10738.8. This GMC enables a flexible and reconfigurable mobile terminal operation, in the presence of multiple access networks with support for different mobility management protocols.

These and other aspects of the invention will now be further described, by way of example only, with reference to the accompanying figure in which Fig. 1 shows an embodiment of a reconfigurable component architecture according to the present invention.

Referring now to Fig. 1, in an embodiment of the present invention, the modules, referred to collectively as a reconfigurable protocol architecture 100, are described as follows.

The reconfigurable protocol architecture comprises kernel 160, a system memory 150, and a reconfiguration framework 105. This framework 105 in turn comprises a Generic Component Manager 110 which controls the Generic Components 130 of the mobile terminal, in the form of a number of individual Components 131, 132, 133, 134. Each of these components has a reconfigurable element (RE) which maybe adapted as needed according to the protocol which is being run.

The Generic Component Manager (GCM) 110 is a terminal module responsible for controlling the flexible reconfigurable process. Input events are passed from Input 162 to the GCM 110 which identifies whether a related protocol is currently supported (loaded) by a Generic Component 131, 132, 133, 134. If a protocol is currently installed, the event is then pushed to the Generic Component 130 for processing. if the protocol is not installed, but the protocol modules 152-1, 152-2, 152-3 are stored in the system memory 150 of the mobile terminal, it loads the modules and modifies the Generic Component's 130 individual components 131, 132, 133, 134 to deploy the newly installed protocol modules. If the relevant modules are not stored in the mobile terminal, it may initiate a new procedure to acquire the module from external entities.

This procedure, however, is not specified here in detail.

The Generic Components 131, 132, 133, 134 behave according to the protocol currently installed in the respective reconfigurable modules (RE).

Protocols define functionalities of the Generic Components 131, 132, 133, 134.

Various protocols can be used, according to the type of access network or mode of operation used by the mobile terminal. The internal behaviour of theses abstractions can vary from one protocol to another. The Generic Components operate according to the intrinsic characteristics of the protocols, and thus these components need to be reconfigured when the mobile terminal changes from one protocol to another. As a result, Generic Components 131, 132, 133, 134 each comprise respective reconfigurable elements (RE), to enable them to dynamically change to different protocol modules.

The reconfigurable elements are stored and can be accessed in system memory 150, in which a plurality of reconfigurable elements 152-1, 152-2, 152-3 are stored. Once a set of protocol modules is loaded in the memory and the mobile terminal needs to reconfigure to a new protocol, then the new protocol modules are loaded and the reconfigurable elements are changes to point to that new part of the memory.

According to the present invention flexible, reconfigurable terminal operation for a specific network protocol family may be achieved through the application of the following mechanism. In more detail, the framework consists of a set of distinct procedures; each one has a specific task and relevant benefits: 1. At first, a Generic Component (GC) design is obtained through protocol decomposition: Such a component is feasible since protocols that tackle the same problem bear similarities. These similarities and differences are identified through detailed protocol decomposition and on this basis a unified generic component can be developed. Network protocols belonging to the same family focus on similar problems, bear similarities in their algorithms and usually the deviations among them are in intrinsic characteristics. In order to define such an entity the protocols of interest are dismantled into individual orthogonal components, i.e. into smaller abstractions or functional entities independent of each other and responsible for accomplishing a well defined task. More analytically, every protocol is designed for tackling a specific problem and usually the algorithm that is implemented constitutes of smaller independent tasks. Amongst these tasks will be accessing and modifying terminal resources, like interface IP addresses and routing tables, so relevant modules will be specified. Thus if the commonalities and differences among the target protocols are identified then the development of a generic component that will reconfigure by only acquiring the parts in which the protocols differ is feasible. The Generic Component will thus consist of a set of protocol modules that will cooperate and collectively operate according to the specifications of the desired protocols.

2. Model of Computation definition: The Generic Component consists of a selection of module components that interact. The rules of information exchange between the components are termed in programming terms as Model of Computation (MoC). It is the conceptual framework that enables a larger design that is constituted by smaller components. Numerous MoCs exist and the appropriate one has to be chosen depending on the kind of problem that is being addressed. The requirements of the component interaction are identified, including the number of processes that are needed, whether asynchronous messages can be supported, the number of common resources accessible by the components, whether operation is data or event driven. Following that the most appropriate MoC is chosen which can then be further modified to exactly fit the operation of the designed Generic Component. Further and in the case of network protocol families Component Interaction (CI) MoC (David Clark, "Structuring of systems using upcalls", ACM Symposium on Operating System Principles, December 1985) is recommended for use in this proposal. CI is a push-pull model which is specifically designed for network protocols and specifies data being pushed or pulled between components. In both cases communication is data driven. Various other MoCs exist that can be adapted for the specific Generic Component derived for a protocol family and the choice is done at design time.

3. Dynamic reconfiguration procedure specification: This procedure specifies the way the dynamic reconfiguration will be supported and can be further split in three discrete operations: A platform specific method for loading and unloading at run-time the various reconfigurable modules (including the Generic Component module itself and the supported protocol component modules). Such a method may be the Dynamic Linking facility available in many operating system platforms, like Windows and Linux.

A method for the Generic Component to access at run-time the relevant protocol modules (programming language specific definition of Reconfigurable Elements that can dynamically be adjusted to point to the appropriate protocol module).

Reconfigurable Elements could be pointers to functions in the case of programming languages like C, or overridden methods of parent/child classes in the case of object oriented classes.

Specification of changes to terminal's operating system (kernel) to support the generic component. This will include interception of relevant protocol messages, and overriding of default functions not needed by all relevant protocols.

4. Generic Component Manager (GCM) specification: The GCM is a terminal module responsible for controlling the flexible reconfigurable process. This is a common module related to controlling a reconfiguration process and the tasks that it should include are: Identify when a new protocol is to be installed in the system.

Attain the appropriate software modules necessary to construct the protocol according to the employed Generic Component.

Install them in the system architecture with preferred dynamic loading/unloading utility.

Adjust the Reconfigurable Elements so as to deploy the relevant modules. The described protocol reconfiguration framework leads to the

high-level design of a reconfigurable network protocol architecture including the Generic Component and the Generic Component Manager. All the stimuli that are processed from the implemented protocols must be passed to the architecture. There is a plethora of stimuli including, specific protocol messages originating from the kernel, time driven events originating internally from the Generic Component, and possibly events originating from other parts of the terminal, like the link and physical layer.

An embodiment of a reconfigurable Generic Component architecture according to the present invention can be seen in Figure 1. The Generic Component Manager checks whether reconfiguration is required and configures the Generic Component appropriately. The resulting design can be implemented in numerous marmers varying from user-space process to a thread in the operating system. There is no restriction to the implementation mechanism.

According to the present invention a method for terminal network protocol reconfiguration is proposed to achieve and support flexible reconfigurable modular network protocol operation. The proposed method can be applied to any IP protocol families for which a Generic Component can be derived. Relevant protocol decomposition will identify procedures that appear common or even identical to more than one protocol. The Generic Component as a result distinguishes and groups the various operations performed by a specific protocol. Common pararneterized protocol components are derived and protocol reconfiguration can be achieved by simply changing or tweaking the components that are different. Further, common function libraries can be derived and these functions can be used and shared when implementing different protocols.

Following the framework guidelines a terminal architecture can be designed to support the flexible operation. With the Model of Computation definition, data exchange between module components will be specified in order to construct a large protocol through the use of smaller components. The MoC specifies the number of processes created for the various protocol modules, the behaviour of the modules input queues where data is placed and then retrieved to be processed and whether the operation of the Generic Component is data, time or event driven. As a result, for specific Generic Components the relevant MoC ensures that data exchange between modules is fast, efficient and secure.

Dynamic reconfiguration procedure specification ensures that the requirements of the mobile terminal platform can be satisfied. Firstly, it specifies the dynamic linking capabilities that are needed from the mobile terminal platform, e.g. whether a linker and or a compiler are needed.

Regarding small programs, which are implemented in a single file, the compiler reads the source code and builds the executable file; however as the size of the programs increases and the source code is scattered in numerous files, the compiler builds intermediate object files which then links in order to obtain a single executable. Usually this linking is performed before the execution of the program; however it is possible to add an object file afterwards with Dynamic Linking. Given that a protocol is implemented according to the Generic Component derived from the decomposition, and every component is implemented as a separate object file, it is possible to be integrated into the system with Dynamic Linking.

Furthermore, the reconfiguration procedure specifies the way to modify the Generic Component in order to include the installed protocol modules. This is achieved by specifying in the Generic Component's design of individual reconfigurable component an entity called Reconfigurable Element, which is adjusted dynamically to the appropriate protocol. Reconfigurable Elements are implementation specific and depend on the programming tecimiques principles of the underlying programming language.

For object oriented languages a Reconfigurable Element is a method of a parent class which is overridden from child classes in order to perform the protocol specific operations. For function oriented languages like C a Reconfigurable Element can be implemented as a pointer to a function, ergo it can be set to point to the appropriate protocol component.

Finally, the reconfiguration procedure specifies the changes that need to be performed to the mobile terminal's kernel in order to accommodate the presence of the Generic Component in the system. This includes protocol messages that need to be passed to the Generic Component, other input stimuli that can modify the operation of the Generic Component and needs to be passed to it, standard kernel functions that need to be disabled since they are overridden by the operation of the Generic Component.

Through the Generic Component Manager smooth operation of the Generic Component is ensured. The Generic Component Manager will be responsible for deciding when a reconfiguration event will occur and what module modifications and reconfigurations are needed. It makes sure that relevant protocol modules are present in the system, by modifying current modules, or by acquiring relevant binaries, or source code and compiling it. Further, it controls the Reconfiguration Elements and modifies the Generic Component at run time to invoke the new protocol modules. The operation of the Generic Component Manager assumes the presence and collaboration with other entities outside the mobile terminal, but this is outside the scope of this document, which only specifies the role of the Generic Component Manager inside the terminal.

According to the present invention a framework is proposed for designing a flexible reconfigurable terminal architecture that supports a modular network protocol operation.

The main benefit of the method according to the present invention is that the mobile terminal is no longer tied to a single mode of operation and thus cormection to access networks that only support the specific protocol the mobile terminal runs. Network protocols can be changed at run time, and the mobile tenninal can thus change its operation to suit specific applications and available access networks.

The present invention relates to a method for specifying a terminal network protocol reconfiguration in the design of a Generic Component for a specific protocol family.

The benefits of the generic component design include: Reduced size of needed software since derived common protocol components and functions don't change.

Faster multiple downloads of smaller files (one per component).

Multiple protocols implemented through a single programming entity.

No redundant operations (same one program instance used by many protocols).

Facilitate protocol update, development or enhancement which can occur by modifying components or functions.

The Generic Component reduces the resources required for multiple protocol support, since one system process can support multiple protocols, one ore more at the same time.

The existence of a suitable MoC for the designed Generic Component ensures that component interaction is fast, efficient and reliable. The reconfiguration procedure specification ensures that all the requirements for system dynamic operation are defined.

The Generic Component Manager ensures that the reconfiguration process is smooth and centrally controlled in the mobile terminal. Consequently it is not possible for entities outside of the architecture to modify the Reconfigurable Elements which could lead to terminal operation instability. Overall, the benefit of the derived framework is that all the procedures needed to support a flexible protocol reconfiguration are clearly covered and the complete set of requirements for the mobile terminal design and the capabilities of the mobile terminal platform are defined. As a result a high level architecture for the mobile terminal is produced, serving a guideline for a relevant mobile terminal implementation.

As an example, the method according to the present invention can be employed to design a mobile terminal that can support multiple mobility management protocols and connection to different access networks. The framework is applied to the mobility management protocol family and a Generic Mobility Component (GMC) is derived.

Following the framework guidelines, a terminal is designed that may attach to access networki and may download and run Mobility Protocol 1. The mobile terminal may then move to a different access network2 that may employ a different Mobility Protocol 2,may perform securely the required reconfiguration at run time and the new protocol may be transparently run.

Although the examples described in the present invention refer to]IPv6, it is evident to the person skilled in the art that the present invention may equally well be employed under other Internet protocols, e.g. lPv4. Moreover, other suitable communications protocols may also be employed.

No doubt many other effective alternatives will occur to the skilled person. It will be understood that the invention is not limited to the described embodiments and encompasses modifications apparent to those skilled in the art lying within the spirit and scope of the claims appended hereto.

Claims

CLAIMS

1. A method of defining the design specifications for a mobile terminal comprising a data control packet processing means operable to process an incoming data control packet, said data control packet processing means further comprising a plurality of functional modules and a plurality of reconfigurable modules; a memory means operable to store one or more sets of communications protocols for use in said plurality of reconfigurable modules; and a control means operable to configure and control said data control packet processing means such that in use said plurality of reconfigurable modules are implemented by means of said communications protocols to receive said incoming data control packet, the method comprising the steps of: designing a generic data control packet processing means through decomposition of the protocols to be employed; defining a model of computation for the generic data control packet processing means; specifying a dynamic reconfiguration procedure for reconfiguring the reconfigurable modules; defining a specification of the Generic Component Manager.

2. The method of claim 1, wherein the step of designing the generic component further comprises: identifying similarities and differences in the protocols through detailed protocol decomposition; and thereafter developing a unified generic component.

3. The method according to claim 3, wherein the step of identifying similarities and differences in the protocols through detailed protocol decomposition further comprises: dismantling the protocols of interest in individual orthogonal components.

4. The method according to any of the preceding claims, wherein the step of designing a unified generic component further comprises the step of, once the commonalities and differences among the target protocols are identified, developing a generic component that will reconfigure only by acquiring the parts that the protocols differ.

5. The method according to any of the preceding claims, wherein the step of defining the model of computation further comprises: identifying the requirements of component interaction; and thereafter selecting the most appropriate model of computation from a group of predetermined models of computation.

6. The method according to claim 5, wherein the step of identifying the requirements of component interaction further comprises one or more of the following: identifying the number of processes which are needed; identifying whether asynchronous messages can be supported; identifying the number of common resoursces accessible by the components; identifying whether operation is data or event driven.

7. The method according to claim 5 or 6, wherein the group of predetermined models of computation comprises a component interaction (CI) model of computation.

8. The method according to any on of claims 5 to 7, wherein the group of predetermined models of computation comprises one or more models of computation which have been adapted for the specific generic component derived for a protocol family.

9. The method according to any one of the preceding claims, wherein the step of specifying a dynamic reconfiguration procedure further comprises: a platform specific method for loading and unloading at run-time the various reconfigurable modules a method for the Generic Component to access at run-time the relevant protocol modules.

specifying the changes to terminal's operating system (kernel) to support the generic component.

10. The method of claim 9, wherein the various reconfigurable modules for loading and downloading at run-time include the generic component module itself and the supported protocol component modules.

11. The method of claim 9 or 10, wherein the platform specific method for loading and unloading at run-time is the Dynamic Linking facility available in many operating system platforms.

12. The method of any of claims 9 to 11, wherein the programming language specific definition of Reconfigurable Elements can be dynamically adjusted to point to the appropriate protocol module.

13. The method of claim 12, wherein, in the case of programming languages like C, the reconfigurable elements are pointers to functions 14. The method of claim 12, wherein, in the case of object oriented classes, the reconfigurable elements are overridden methods of parent/child classes 15. The method of any of claims 9 to 14, wherein the step of specifying the changes to terminal's operating system further comprises intercepting relevant protocol messages, and overriding of default functions not needed by all relevant protocols.

16. The method according to any of the preceding claims, wherein the Generic Component Manager is a terminal module responsible for controlling the flexible reconfigurable process.

17. The method according to any of the preceding claims, wherein the step of specifying the generic component manager further comprises: identifying when a new protocol is to be installed in the system attaimng the appropriate software modules necessary to construct the protocol according to the employed Generic Component installing said software modules in the system architecture with preferred dynamic loading/unloading utility adjusting the Reconfigurable modules so as to deploy the relevant modules 18. A computer program comprising data processing device program code means adapted to perform the method of any of claims 1 to 17 when said program is run on a data processing device.

19. A computer-readable medium comprising computer-executable instructions for defining the design specifications for a mobile terminal in accordance with any one of claims 1 to 17.

20. A mobile terminal comprising a data control packet processing means operable to process an incoming data control packet, said data control packet processing means further comprising a plurality of functional modules and a plurality of reconfigurable modules; a memory means operable to store one or more sets of communications protocols for use in said plurality of reconfigurable modules; and a control means operable to configure and control said data control packet processing means such that in use said plurality of reconfigurable modules are implemented by means of said communications protocols to receive said incoming data control packet, the mobile tenninal being specified according to the method according to any one of claims 1 -17.