GB2438664A

GB2438664A - Reconfigurable mobile terminal supporting multiple network addresses and interfaces

Info

Publication number: GB2438664A
Application number: GB0610848A
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: GB2438664B; GB0610848D0

Abstract

A flexible mobile terminal comprises 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. The data control packet 120 is arranged to correspond with the communication protocols 152-1, 152-2, 152-3 implemented in the reconfigurable modules 131-134, and information about relevant addresses and interfaces is stored in a dynamically extendable address database 190, e.g. an association of a permanent IP address to a network interface may be stored. The flexible reconfigurable mobile terminal is able to multihome with any combination of available IP addresses and network interfaces and transparently connect to different access networks. The mobile terminal can thus establish and maintain connections to different overlapping access networks and intelligently load balance its application data flows through those networks.

Description

1 2438664

METHOD TO SUPPORT MULTIPLE NETWORK ADDRESSES IN A FLEXIBLE

RECONFIGURABLE MOBILE TERMINAL

The present invention relates to a method to support multiple network addresses in a flexible reconfigurable mobile terminal. More particularly it relates to a method to support multiple network addresses in a flexible terminal enabled with a modular reconfigurable protocol stack.

It is envisaged that in the ftiture, communication systems, including wireless, 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 (MT) 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 MT with one or more wireless interfaces connects to the fixed network, through one or more Access Routers (ARs) equipped with an Access Point (AP) or Base Station (BS).

In the Internet, different protocols are employed to solve issues like IP 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 MTs. 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 addition, advances in software radio technologies will enable terminals to be equipped with reconfigurable RF front ends. This will enable a wireless MT to modify its wireless properties and connect to different Access Networks (AN).

Conventionally, a MT is characterised by a permanent network (IP) address, which traditionally is assigned to a physical network interface. Furthermore, a MT can only send and/or receive information with a relative source/destination address, same as its permanent address linked to its network interface. This permanent or home address is topologically significant and belongs, or is routable to the specific home network. When the MT leaves its home network, its permanent address loses its topological significance. In the visited network it acquires a temporary address which is routable to the current visited network. A macro mobility management protocol maintains a relation (binding) between the MT's permanent address and the locally acquired temporary address. In other words it handles mobility between Access Networks or Administrative Domains where the MT acquires a new temporary address. A micro mobility protocol handles mobility inside the same access network, i.e. handovers between access routers in that network, where the locally acquired temporary IP address does not change. Macro and micro mobility protocols occasionally need to cooperate regarding acquiring a temporary IP address which both can use.

In co-pending patent application GB0606003.2 a terminal architecture to support a reconfigurable modular mobility protocol stack was designed. The protocol decomposition of the framework was applied to the family of mobility management protocols and a Generic Mobility Component (GMC) has been developed, which is included in co-pending patent application GBO5 10738.8. This GMC enables a flexible and reconfigurable MT operation, in the presence of multiple access networks with support for different mobility management protocols.

The mobile terminal described in co-pending patent application GB0606003.2 assumes the traditional MT concept with a single permanent IP address assigned to a single physical network interface. Recently it has been envisaged that a MT can have multiple permanent IP addresses associated with one or more physical network interfaces.

Furthermore these permanent IP addresses could belong to the same (e.g. different IP addresses for use with different applications) or different Home Networks (e.g. a permanent IP address at the work network and a permanent IP address at the home network). In that case, the MT is referred to as multihomed and may desire to establish multiple connections to the same or different access network, (R. Bradden, "Requirements for Internet hosts -Communication Layers", IETF, RFC 1122, October 1989). The mode of operation that is assumed is the one that allows the MT with multiple permanent IP addresses to send IP packets through a network interface different from the one that corresponds to the source IP address of the packet. This is also called a "weak end system" (see: R. Bradden, "Requirements for Internet hosts -Communication Layers", supra).

Further information on mobility can be found in: McCaim, S. Groting, W. Pandolfi, A. Hepworth, E., "Next generation multimode terminals", lEE 3G Mobile Communication Technologies, 2004; Jun Liu, Kazaura, K., Matsumoto, M., "A low latency inter-system handover scheme for multiple interfaces terminal", Proceedings of the IEEE 6th Circuits and Systems Symposium on Emerging Technologies: Frontiers of Mobile and Wireless Communication, Volume 2, 2004; Haijie Huang; Jianfei Cai; Kassler, A.J.; Chengpeng Fu, "Load-sharing in wireless multi-homed systems", IEEE ICC 2005, May 2005; Chebrolu, K., Rao, R., "Communication using multiple wireless interfaces" IEEE Wireless Communications and Networking Conference, 2002; and Matsuoka, H., Yoshimura, M., Ohya, T., "A robust method for soft IP handover", IEEE Internet Computing, IEEE, Volume 7, Issue 2, 2003; lera, A., Marano, S., Molinaro, A., "Supporting mobility in broadband wireless networks", IEEE Vehicular Technology Conference, 1998.

Moreover the MT is able to accept packets that are destined to an address which is different from the one specifically assigned to the physical interface used. This multihomed model breaks the link between a permanent IP address and a network interface, resulting in a MT with multiple permanent IP addresses which can be used on any of its present network interfaces. All these features are enabled through manipulation of the routing table and binding interface addresses to network interfaces.

The routing table in the MT includes a set of rules that determine which interface outgoing packets are sent to. By manipulating these rules, arrangement of what information with which source address is sent through which interface to which next hop router, is controlled. In the GMC model the routing table consistency is controlled by the Network Configuration component.

Routing table management will enable the MT to operate intelligently and distribute different application data flows (load balancing) over different access networks, with different characteristics like wireless bit rates, supported mobility management protocols, etc. Load balancing is achieved for both incoming and outgoing traffic.

Outgoing traffic is assigned to the interfaces by manipulation of the routing Table. On the other hand, incoming traffic will arrive to the interface to which the relevant permanent IP address has been assigned. This IP address is further used to perform a mobility registration for the MT. As a result incoming traffic will be destined to the temporary address acquired and used for the mobility registration.

In that case, the MT must be able to transparently support multiple IP address over one or more network interfaces. The same mobility protocol will be required to handle multiple events and messages for different data flows. Further it is envisaged in more advanced scenarios that other network protocols like QoS or routing could be supported for different data streams, over one or more interfaces.

In conventional implementations where every protocol runs independently in a different system process, the same protocol functions will have to be run for the different IP addresses. Common terminal resources are accessed by different processes, with information exchange between them achieved through signalling. This however leads to a complicated MT design and can have a negative effect on performance and synchronization. The limitation of the current GMC design in co-pending patent application 0606003.2 is that only one IP address and network interface are considered.

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

A first aspect of the invention provides a method of communication comprising the steps of: processing an incoming data control packet by means of data control packet processing means; storing one or more sets of communications protocols for use in a plurality of reconfigurable modules; configuring and controlling 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, and; obtaining said incoming data control packet and arranging said incoming data control packet such that in use said incoming data control packet corresponds with said communications protocols implemented in said reconfigurable modules; and storing information about relevant addresses and interfaces in a dynamically extendable address database.

The method preferably further comprises the step of keeping a record in the address database of which permanent IP address is currently assigned to which interface.

The method preferably further comprises the step of, when in a visiting network, also keeping a record of the currently used temporary address linked to the relevant permanent IP address and interface.

The method may further comprise the step of externally controlling and setting the address database field of permanent IP address and network interface.

The method may further comprise the step of controlling the address database fields in order to achieve multihoming and/or load balancing.

The method may further comprise the step of filling in the remaining fields by the GMC when a mobility event has occurred while a mobility protocol is loaded and operating.

The method may further comprise the step of using all address database fields by the components of the GMC in order to perform protocol operations.

The method may further comprise the step of processing all incoming events according to the network interface the address identifier is associated with.

The method may further comprise the steps of: retrieving the relevant database entry and permanent IP address; using the entire database by the GMC to operate according to the protocol.

The method may further comprise the step of modifying the reconfigurable elements (RE) to access the relevant database entry.

The reconfigurable elements may comprise Packet Verification, Movement Detection, Handler and Packet Constructor.

The method may further comprise the step of using the address database to store multiple instances of the same protocol which is used for different IP addresses.

The method may further comprise the step of determining, by the network configuration component, which routes in the table are to be modified, based on network interface information and permanent IP address.

The method may further comprise the step of controlling by said data control packet means a protocol database comprising a plurality of protocol records, such that said plurality of reconfigurable modules corresponds with the plurality of protocol records.

A second aspect of the invention provides 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; 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; an input terminal operable to receive said incoming data control packet, said input terminal further comprising a queuing means such that in use said incoming data control packet corresponds with said communications protocols implemented in said reconfigurable modules; and a dynamically extendable address database capable of storing information about relevant addresses and interfaces; an address identifier means operable to relate said incoming control data packet with address data in the address database.

The control means may further comprises a protocol database comprising a plurality of protocol records which is controlled by said data control packet means such that in use said plurality of reconfigurable modules corresponds with the plurality of protocol records.

The mobile terminal may be operable to execute the method of the first aspect of the invention.

A further aspect of the invention provides a mobile terminal operable to execute the method of the first aspect of the invention.

The inventive method here allows to enhance the MT operation to support a single protocol for multiple IP addresses and network interfaces, together with protocol reconfiguration as with the original design. Use of this method in the context of the flexible reconfigurable terminal protocol stack leads to transparent and secure single protocol operation with multiple IP address (multihoming) over one or more network physical interfaces.

The skilled person will recognize that the above-described methods may be implemented using and/or embodied in processor control code. Thus in a further aspect the invention provides such code, for example on a carrier medium such as a disk, CD-or DVD-ROM, programmed memory such as read-only memory (Firmware) or on a data carrier such as an optical or electrical signal carrier. Embodiments of the invention may be implemented on a DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). Thus the code may comprise conventional program code, or micro-code, or, for example, code for setting up or controlling an ASIC or FPGA. In some embodiments the code may comprise code for a hardware description language such as Verilog (Trade Mark), VHDL (Very high speed integrated circuit Hardware Description Language), or SystemC. As the skilled person will appreciate, processor control code for embodiments of the invention may be distributed between a plurality of coupled components in communication with one another.

These and other aspects of the invention will now be further described, by way of example only, with reference to the accompanying figures in which Figure 1 shows a flexible reconfigurable mobility protocol architecture to support multiple addresses.

Figure 2 depicts an embodiment of a structure of an address database.

Figure 3 shows a flexible reconfigurable mobility protocol architecture to support multiple protocols.

Figure 4 depicts a structure of an extended address database.

According to the invention the terminal flexible, reconfigurable network protocol stack is enhanced with a method to support multiple IP address and network interfaces and thus multihoming and intelligent load balancing through possibly different access networks.

The GMC also described in co-pending patent application GB0606002.8 is employed as the basis of supporting this feature. The Generic Mobility Component (GMC) behaves according to the protocol currently installed. Initially the message is passed to the packet verification component so as to verify the packet's consistency and to discard bogus messages. Valid protocol messages are then passed to the movement detection component for identification of MT network movements and then the packet is pushed to a handler for processing. The behaviour of the handler varies from one protocol to another and also from one input message to another. This component is responsible for initiating the appropriate procedures in the event of MT registration, MT handover, or simple reception of acknowledgement messages. The handler is responsible for identifying when a network related reconfiguration is required. Thus it instructs the network configuration component to perform the desired operation according to the

specifications of the mobility protocol.

In the GMC a single process is responsible for managing the mobility protocol. To further enable the MT to support multiple IP address and possibly multiple network interfaces, the design needs to be enhanced by enhancing the intelligence of the Generic Mobility Component Manager and the design of the GMC: Multiple IP addresses may be flexibly supported, by adding a dynamically extendable Address Database that stores information about the relevant addresses and interfaces. The Address Database keeps a record of which permanent IP address is currently assigned to which interface. If the MT is in a visiting network it also keeps a record of the currently used temporary address linked to the relevant permanent IP address and interface, the addresses of its current and previous access routers through which it is connected and the current state of the Handler according to which the protocol is operating for the specific IP address. The Address Database fields of permanent IP address and network interface are externally controlled and set, to achieve multihoming and intelligent load balancing. The other fields are filled in by the GMC when a mobility event has occurred and a mobility protocol is loaded and operating.

All these fields are needed and employed by the various components of the GMC to perform the correct protocol operations including Routing Table manipulation.

An Address Identifier is introduced that process all incoming events according to the network interface it is associated with it. The Database entry with the correct interface and permanent IP address is retrieved and the whole Database entry is then used by the GMC to operate according to the protocol.

The GMC reconfigurable components (Packet Verification, Movement Detection, Handler and Packet Constructor), are modified to access the relevant Database entry to retrieve or update relevant entries. In the original single address/interface case this information was constant and was kept inside the GMC. Only one protocol instance could occur and this information was always the same. Now, multiple instances of the same protocol can occur for different IP addresses and this information can change at any given time.

In the original design the Network Configuration component was only handling a single interface and all incoming or outgoing traffic was handled by that interface.

Since multiple interfaces can now be present the component is enhanced to check network interface information and permanent IP address to decide what routes in the

table to modify.

An enhanced flexible architecture according is depicted in Figure 1, showing an embodiment of the present invention, in which the modules, referred to collectively as a reconfigurable mobility protocol architecture 100 are described as follows.

A Generic Mobility Component Manager (GMCM) 110 is a terminal module responsible for controlling the flexible reconfigurable process. Input events 120 are passed to the Generic Mobility Component Manager 110 which identifies whether a related mobility protocol is currently supported (loaded) by a Generic Mobility Component (GMC) 130. If a mobility protocol is currently installed, the event is then pushed to the GMC 130 for processing. If the protocol is not installed, but the protocol modules are stored in the MT, it loads the modules through instructing the Dynamic Loader 112, and modifies the GMC's individual components to deploy the newly installed protocol modules. The operation of the GMC's individual components is described in the following paragraph. If the relevant protocol modules are not stored in the MT, it initiates a new procedure to acquire the modules from external entities. This procedure is not specified here as it is a different work area.

The Generic Mobility Component (GMC) 130 behaves according to the protocol currently installed. Initially the message is passed to the packet verification component 131 so as to verify the packet's consistency and to discard bogus messages. Valid protocol messages are then passed to the movement detection component 132 for identification of MT network movements and then the packet is pushed to a handler 133 for processing. The behaviour of the handler 133 varies from one protocol to another and also from one input message to another. This component 133 is responsible for initiating the appropriate procedures in the event of MT registration, MT handover, or simple reception of acknowledgement messages. The handler 133 is responsible for identifying when a network related reconfiguration is required. Thus it instructs the network configuration component 136 to perform the desired operation according to the

specifications of the mobility protocol.

Additionally the handler sets timers 135 and is also responsible for initiating procedures that are triggered from the timers 135. Mobility protocols define functionalities that are triggered from the timers 135 and aim to enhance protocol reliability. One such example is the retransmission of handover messages if an acknowledgement is not received within a specified time period. In the GMC 130 the timer 135 is responsible for generating these events. The handler 133 sets the timer 135 after the transmission of the protocol control message and the timer 135 on its behalf notifies the handler 133 when the time period from the transmission of the message has elapsed. The handler 133 then passes information to the packet constructor, who generates the relevant protocol message to be transmitted.

Various mobility protocols can be modelled with the above abstractions, independent from the type of mobility which they address. The internal behaviour of the abstractions can either vary significantly or not vary at all from one protocol to another.

In the latter case, the behaviour of the network configuration 136 together with the timer components is specific to the underlying Operating System and thus in the specific design those components do not need to be modified. On the other hand, the remaining components operate according to the intrinsic characteristic of the mobility protocols and thus those components need to be replaced when the terminal reconfigures from one mobility protocol to another. As a result, packet verification 131, movement detection 132, handler 133 and packet construction 134 components include a Reconfigurable Element (RE), to enable them to dynamically change to different protocol modules. On the other hand network configuration 136 and the timers 135 are common and fixed in the GMC 130, so do not need to include REs.

The architecture of the described embodiment consists of a selection of module components that interact. These components include the components of the GMC 130 as described above and a Generic Mobility Component Manager (GMCM) 110.

Following the design framework the most appropriate Model of Computation (MoC) is chosen and adapted to exactly fit the operation requirements of the GMC 130. In the case of mobility protocol family Component Interaction (CI) (see David Clark, "Structuring of systems using upcalls", ACM Symposium on Operating System Principles, December 1985) MoC is used. CI is a model which is specifically designed for network protocols and specifies data being pushed or pulled between components.

In both cases communication is data driven. Input messages are pushed to the Generic Mobility Component Manager 110. Message processing occurs in the Generic Mobility Component Manager 110 according to the procedures described later. The message is then pushed to the GMC 130 for processing. Inside the GMC 130, messages are pushed to the internal components according to the procedure described above.

However, a more thorough insight about the handler-timer interaction raises a significant issue in the system design. Although no message is passed from handler 133 to the timer 135, the timer 135 generates events (notifications) that must be passed back to the handler 133 for processing. Since these events are time varied and can happen in the future, there is a chance that a reconfiguration procedure might have happened and the GMC 130 components have changed to an entirely different protocol. This would result in system instability and erroneous operation since the wrong handler protocol component would be notified. Similarly there are other system events, generated randomly, and not network layer3 events, which need to be passed to protocol modules to enhance protocol performance. For example, link Iayer-2 changes (channel, network id), can be passed to the movement detection 132 component to instruct the handler 133 to initiate a handover. It has to be ensured that such events are passed to the correct module component and the GMC 130 is not in the process of reconfiguring to a new protocol operation.

The resulting protocol component design and Address Database can be implemented in numerous maimers and platforms. The enhanced design is also backward compatible and can still support single protocol over a single interface. An implementation of the described design has been realised as a proof of concept and for performance evaluation.

An example of the employed Database can be seen in Figure 2. The Address Database fields of permanent IP address and network interface are externally controlled and set, to achieve multihoming and intelligent load balancing. The other fields are filled in by the GMC when a mobility event has occurred and a mobility protocol is loaded and operating. Al! these fields are needed and employed by the various components of the GMC to perform the correct protocol operations including Routing Table manipulation.

Furthermore, the need might arise for the terminal architecture to flexibly handle more than one protocol for different IP addresses or interfaces. In the attached annex, which is another patent application being filed today simultaneously with the present application, a method is described to support concurrent multiple protocol operation for a single address and network interface. Micro and macro mobility protocols can then interoperate and combined support mobility of the terminal. In the likely scenario that multiple concurrent protocol operation for multiple IP address over multiple interfaces is desired, it is possible to include the method in this design to achieve that.

The resulting terminal design can be seen in Fig. 3. The functionalities of the Protocol Database and enhanced Event Identifier will be exactly the same as the one described in the annex. The difference in this scenario would be the structure of the Address Database which will be extended to include multiple protocol specific information that are related to a specific address and or interface.

The manner in which dynamic reconfiguration is performed in the system will now be described with reference to Fig. 3. This is implementation related and so does not have a major effect on the architecture design. A platform specific method for loading and unloading at run-time the various reconfigurable modules is provided. These include the GMC 330 and Generic Mobility Component Manager 320 which are represented as kernel modules inFig. 3, and the various supported protocols 352-1, 352-2, 352-3 loaded in the system memory (as are the kernel modules as well). An example of such a method is the Dynamic Linking facility available in all operating system platforms, including Windows and Linux. This requires that platform specific binaries are available in the terminal and loaded in the memory. Furthermore these modules need to be compliant to the GMC 330 specifications and ensure interoperability between the components. This again is implementation specific and thus is resolved at realisation time.

As shown in Fig. 3, the event identifier will process all incoming data control packets and determine which mobility protocol, stored in the protocol database, it relates to and needs to be passed on for processing. By adjusting the REs it ensures that the correct protocol modules will be employed in the GMC. The address identifier will then process the incoming data control packet and decide which one of the addresses this relates to and retrieve the relevant information from the address database. This information is then passed to the modules in the GMC for processing.

Essentially, the protocol modules are generic, blank, and all the needed address/interface specific information is stored in the address database. Hence in order to run the same protocol for different address/interface, it only needs to be loaded once, and pass to it every time the relevant information.

In the common case that micro and macro mobility protocols need to operate for a specific address and interface the Address Database could be extended as shown in Fig. 4. Information related for micro and macro mobility protocols is stored in the database, including which protocol it is and its handler state, together with more detailed protocol specific information. The flags entry in the database control the interoperation between the protocols, e.g. whether a dedicated micro mobility session is needed, or to bind protocol sessions to the same temporary acquired address.

We have described the details of the enhancements needed for a flexible reconfigurable terminal to support multiple network IP address to be handled by the same mobility protocol. This enables the terminal with a single system process, to transparently handle multiple address registrations to the same or different access networks. This MT multihoming feature can then be employed to perform load balancing for different application data flows.

By employing the Address Database 180, all the relevant information associated with a permanent IP address is stored in the Generic Mobility Component Manager. This information is retrieved based on incoming events and then passed to the GMC components protocol components to perform the relevant processing. The Database information can be flexibly handled to intelligently perform load balancing, by assigning different IP addresses to different network interfaces that connect to different access network with different characteristics (bit rate, range, application support, etc.) The database can also be dynamically extended to add and remove permanent IP address and/or interfaces and modified to change the assignment of an address to an interface.

By including the Address Identifier processing of events according to the relevant interface and corresponding IP address information is enabled, thus ensuring the correct information of the database is retrieved and passed to the GMC.

By making the GMC components generic, taking all needed information as parameters, we enable support of multiple addresses, i.e. multiple protocol instances, with only one system process and the same protocol modules loaded in the memory.

By enhancing the operation of the Network Configuration module, to modify terminal resources based on interface and IP address information, we ensure that the correct changes are made and prevent erroneous terminal operation.

By including the method for concurrent multiple protocol support the design is enabled to operate multiple protocols for multiple IP addresses, over multiple interfaces. This is achieved by enhancing the Address Database to include more protocol specific information.

According to the present invention, the design of a flexible reconfigurable terminal mobility protocol component has been enhanced to support multiple IP address over one or multiple network interfaces.

The main benefit of the present invention is that a single system process is still responsible for operating multiple protocol instances. Protocol modules need only be loaded once in the memory and used for all different protocol instances. This can lead to reduced terminal resources like processing power and system memory being used.

Further Inter Process Communication can be avoided, increasing security of operation.

A single process is responsible in the GMC 130 for managing mobility protocol, which facilitates information exchange and synchronicity issues. To further enable the MT to support multiple protocol cooperation, the design is enhanced by enhancing the intelligence of the Generic Mobility Component Manager: Multiple protocols are flexibly supported, by adding a dynamic Protocol Database (DB) 180 that stores the location 182-1, 182-2, 182-3 of the various protocol modules 152-1, 152-2, 152-3 in the memory 150. A single RE is maintained in the GMC components and is again controlled by the Event Identifier 114 in the Generic Mobility Component Manager.

The Event Identifier in the original single protocol support case only processed new incoming events to initiate a reconfiguration event and call the Dynamic Loader to load the new protocol modules. In order to support multiple protocols the Event Identifier 114 is further enhanced to process all incoming events and adjust the elements to the related part of the Protocol database 180 according to the relevant protocol the event is associated with.

This GMC model with the incorporated Reconfigurable Elements, is maintained, with the protocol components being made generic accepting relevant information from the Database as parameters. The main added enhancements are included in the Generic Mobility Component Manager.

It flexibly enables multihoming and facilitates load balancing to be performed. Load balancing algorithms only need to decide which interface to be used by which application and then assign in the database the IP address the application will use to the relevant interface. As a result, by manipulating the Address Database the incoming and outgoing traffic can be distributed to the network interfaces.

By including the Protocol and Address Database total flexibility of the terminal design is achieved, since it can handle any number of mobility protocols, for any number of IP address for any number of network interfaces. Moreover this may be achieved with only one system process running and with protocol related modules loaded in the memory only once, i.e. minimising the needed terminal resources for such a complex and multidimensional terminal operation.

Further, backward compatibility with the single address, protocol and interface support is maintained and there is no performance overhead degradation.

Overall, the benefit of the present invention is that secure, efficient, fast and smooth reconfiguration process, to support concurrent multiple IP addresses and interfaces may be, achieved. By including the additional method, multiple protocol operation may be combined as well, resulting in an ultra flexible design.

The main benefit of the present invention resides in the fact that, no matter how many protocols or addresses/interfaces are used, there is only one single process, i.e. one GMC configuration operating at any one time, supported by the databases. This leads to increased security, and speed of operation while reducing the terminal resources used.

The enhanced design of the mobile permits a flexible reconfigurable terminal to be implemented. The designed terminal may support multiple IP address assigned over multiple interfaces.

An example of the use is a MT with two interfaces, one supporting WLAN IEEE 802.11 b and one supporting WLAN IEEE 802.11g. The MT is assigned two permanent IP address from its home network. One IP is used for normal data communications (web browsing, e-mail etc.) and one is used for high rate multimedia applications. The MT is then found under the coverage of two visiting Ans, one supporting basic 802.11 b and one supporting high rate 802.11g. By detecting that the MT loads MIPv6 component in the memory, assigns the first IP to its 802.11 b interface and the other one to its 802.11 g interface. Then, by operating MIPv6 on both its interfaces, acquires two temporary addresses from the visiting access networks and registers them with its home network.

It can then transparently start accessing the internet on the 802.11 b access network and set up a video conference on the 802.1 ig access network. Subsequent movements to other access networks are flexible handled by modifying on the fly the information in the Database.

By including the multiple protocol support function the present invention may be implemented, e.g. with MIPv6 and HMIP (Hierarchical Mobile IP) v6 running on one network interface connected to one access network and BCMP (BRAIN Candidate Mobility Protocol) v6 running on the second interface and connected to a different access network.

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. IPv4. 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 communication comprising the steps of: processing an incoming data control packet by means of data control packet processing means; storing one or more sets of communications protocols for use in a plurality of reconfigurable modules; configuring and controlling 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, and; obtaining said incoming data control packet and arranging said incoming data control packet such that in use said incoming data control packet corresponds with said communications protocols implemented in said reconfigurable modules; and storing information about relevant addresses and interfaces in a dynamically extendable address database.

2. The method according to claim 1, further comprising the step of keeping a record in the address database of which permanent IP address is currently assigned to which interface.

3. The method according to claim 2, further comprising the step of, when in a visiting network, also keeping a record of the currently used temporary address linked to the relevant permanent IP address and interface.

4. The method according to any of the preceding claims, further comprising the step of externally controlling and setting the address database field of permanent IP address and network interface.

5. The method according to claim 4, further comprising the step of controlling the address database fields in order to achieve multihoming and/or load balancing.

6. The method according to any one of claims 4 or 5, further comprising the step of filling in the remaining fields by the GMC when a mobility event has occurred while a mobility protocol is loaded and operating.

7. The method according to any one of claims 4 to 6, further comprising the step of using all address database fields by the components of the GMC in order to perform protocol operations.

8. The method according to any one of the preceding claims, further comprising the step of processing all incoming events according to the network interface the address identifier is associated with.

9. The method according to any one of the preceding claims, further comprising the steps of: retrieving the relevant database entry and permanent IP address; using the entire database by the GMC to operate according to the protocol.

10. The method according to any one of the preceding claims, further comprising the step of modifying the reconfigurable elements (RE) to access the relevant database entry.

11. The method according to claim 10, wherein the reconfigurable elements comprise Packet Verification, Movement Detection, Handler and Packet Constructor.

12. The method according to any of the preceding claims further comprising the step of using the address database to store multiple instances of the same protocol which is used for different IP addresses.

13. The method according to any of the preceding claims, further comprising the step of determining, by the network configuration component, which routes in the table are to be modified, based on network interface information and permanent IP address.

14. The method according to any of the preceding claims, further comprising the step of controlling by said data control packet means a protocol database comprising a plurality of protocol records, such that said plurality of reconfigurable modules corresponds with the plurality of protocol records.

15. 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; 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; an input terminal operable to receive said incoming data control packet, said input terminal further comprising a queuing means such that in use said incoming data control packet corresponds with said communications protocols implemented in said reconfigurable modules; and a dynamically extendable address database capable of storing information about relevant addresses and interfaces; an address identifier means operable to relate said incoming control data packet with address data in the address database.

16. The mobile terminal according to claim 15, wherein said control means further comprises a protocol database comprising a plurality of protocol records which is controlled by said data control packet means such that in use said plurality of reconfigurable modules corresponds with the plurality of protocol records.

17. The mobile terminal according to any of claims 15 or 16, operable to execute the method of any of claims 1 to 14.

18. A mobile terminal operable to execute the method of any of claims ito 14.

19. A computer program comprising data processing device program code means adapted to perform the method of any of claims 1 to 14 when said program is run on a data processing device.

20. A computer-readable medium comprising data processing means-executable instructions for performing the method of any of claims 1 to 14 when said instructions are executed on a data processing device.