GB2426666A - Method and apparatus for mobility management - Google Patents

Abstract

A mobile terminal comprises a plurality of configurable modules and a memory means operable to store at least a first template representing aspects of a communications protocol. A template interpreting module is operable to configure and control those of said configurable modules required in accordance with said at least first template. Consequently, in use one or more communication protocols are implemented by the configuration and control of said configurable modules in accordance with said at least first template.

Description

METHOD AND APPARATUS FOR MOBILITY MANAGEMENT The present invention relates to mobility management. In particular, it relates to the support of a plurality of mobility management protocols for roaming IP communications. On the Internet, the Internet Protocol (IP) address of a terminal has a hierarchical structure that reflects the topology of the Internet. The Internet can be thought of as an interconnection of many individual networks, and so for each network to communicate with another, the IP address has a network-level (or domain) address component assigned by a central network information centre. The remainder of the address then identifies sub-networks and eventually individual machines within a network. The IP address is assumed to be fixed, and is used during the routing of packets between a service provider and a user terminal. Therefore, if the terminal were to move to a new network during communications, its IP address would have to be changed to reflect its new position in the Internet topology and any packets currently in transit to the old address would be lost. In addition, the terminal's new location would have to be updated within the network in order for further packets to reach the new address. Mobile IP (MIP) is an Internet Engineering Task Force (IETF) communications protocol that is designed to solve this mobility problem by allowing mobile terminals to move from one network to another while maintaining their permanent (fixed) IP address. MIP provides mechanisms for forwarding packets to different domains when mobile terminals connect to the Internet via a network other than their original (home) network. As such, MIP provides a protocol for macro-mobility; that is, mobility between networks or domains. Thus, macro-mobility is also known as inter-domain mobility. MIP for versions 4 and 6 of the Internet protocol (MIPv4 and MIPv6) share the common idea of assigning each mobile terminal with a permanent home address on its home network, and a 'care-of address (CoA) that identifies the current location of the device with a visited network. Whenever the mobile terminal moves to a different network, it is assigned a new CoA. A mobility agent on the home network associates the permanent home address with each care-of address in turn. To achieve the association, the mobile terminal informs the home agent of each new care-of address using Internet Control Message Protocol (ICMP) messages. The home network is then able to forward data that was originally addressed to the mobile terminal's permanent home IP address, to the CoA on the visited network. However, it is left up to the visited network to then forward the data on to the mobile terminal itself. As a result, if the mobile terminal moves within a network, MIP does not provide a mobility solution. Mobility within a home or visited network is known as micro mobility or intra-domain mobility. In consequence, there is also a need to manage micro-mobility. A number of proposed solutions for micro-mobility exist, including Hierarchical MIPv6 (HMIP); Handover Aware Wireless Access Internet Infrastructure (HAWAII); Regional registration (RR) in MIPv4 and MIPv6; Cellular IP (CIP), and; The BRAIN candidate mobility management protocol (BCMP). These solutions roughly fall into two groups; one consisting of those that enhance existing MIP protocols, which includes HMIP, RRMIP and HAWAII, and the other which includes those that operate independently of MIP, such as CIP and BCMP. To date, no one protocol has been adopted as a standard method of micro-mobility management. If a network on the Internet can therefore opt for any one of these micro-mobility solutions, then it is necessary to provide compatibility between a roving terminal and the solution used within the visited network. However, with so many solutions available, providing compatibility with all available solutions could add a considerable computation and memory resource burden to a mobile terminal. Several solutions for supporting multiple micro-mobility protocols have been proposed in the art. Claude Castelluccia and Lubovic Bellier, 'Toward a Unified Hierarchical Mobility Management Framework', (soft published at http://comet.ctr.columbia.edu/micromobilitv/pub/draft-castelluccia-uhmm-frameworkOO.txt), propose a three-tier mobility management scheme, comprising a standardised access protocol, MIP for macro mobility, and domain-based choice of protocol for micro mobility. The primary aim of their mobility management framework is to provide an interface between the local micro-mobility scheme and the common macro-mobility scheme. To this end, a visited network contains a mobility support router that acts as a proxy for th( mobile terminal while it is within the network. The proxy communicates with the mobile terminal but then acts in accordance with the preferred micro-mobility scheme of the visited network. This enables a roving terminal to operate independently of the local network micro-mobility scheme, but requires the provision of a mobility support router in the network. Moreover, it requires mobility support routers in different parts o the network for different micro-mobility protocols used by different mobile terminals. Thus, a visiting mobile terminal is dependent upon the provision of a suitable mobility support router in order to operate successfully. If such a router does not exist then, unless the terminal and the visited network happen by chance to use the same protocols, the terminal will be unable to connect. A. Mihailovic et. al., in 'Experience of the BRAIN and MIND Projects in the Development of IP Mobility Solutions' (soft published at http://www.ctr.kcl.ac.uk/publications/papers/draft -mihailovic-brain-mind-00.txt), similarly proposes extending the functionality of the access network, providing separate components for functions such as address management, handover management and paging to enable flexible updating of new and existing protocols. However, a visiting mobile is again reliant upon the provision of a suitably configured access network. It would be desirable for a mobile terminal to use the native micro-mobility protocol of the visited network, so as to avoid reliance on supplementary mobility systems such as those described above. However, ideally such a facility should place the minimum demands on the system resources of the mobile device. One possible solution would be an enhanced registration scheme wherein, upon visiting a new network, the micro-mobility protocol used in that network would be downloaded to the mobile device as part of the registration process. However, this would add a significant delay to the registration process, and would be undesirable, for example, in packet speech applications such as voice over IP. It also assumes operating system compatibility, or that all devices can run protocols in a cross-platform language such as Java. Finally, it would require an alteration to current registration standards. Thus a means and method of providing compatibility between a roving terminal and a visited network is still desirable. In a first aspect of the present invention, a mobile terminal comprises a plurality of configurable modules and a memory means operable to store at least a first template, the template providing aspects of implementation for a mobility protocol. In addition, the mobile terminal comprises a template interpreting module that is operable to configure and control those of said configurable modules required in accordance with said at least first template, with the result that in use one or more mobility protocols are implemented by the configuration and control of said configurable modules in accordance with said at least first template. In a configuration of the above aspect, the or each template comprises a finite state machine operable to govern protocol behaviour. In a configuration of the above aspect, a template comprises data characterising one or more packets used in a mobility protocol. In a configuration of the above aspect, the configurable modules comprise a packet verification module, a movement detection module, a network configuration module, a timer module, and a control packet construction module. In a configuration of the above aspect, a template may characterise the behaviour of any one of the following mobility protocols; MIP, MIPv4, MIPv6, RRMIPv4, RRMIPv6, HMIPv6, HAWAII, CIP, CIPv4, CIPv6, and BCMP. In another aspect of the present invention, a method of communication comprises the steps of accessing at least a first protocol template, and composing a protocol implementation. The step of composing a protocol implementation in turn comprises the step of configuring and controlling a plurality of modules, each operable to implement generic functions related to one or more protocols, in accordance with said at least first protocol template. In another aspect of the present invention, a data carrier comprises code that when executed causes a computer to operate as a mobile terminal as described in a preceding aspect. In yet another aspect of the present invention, a data carrier comprises data that a computer or mobile terminal as described in preceding aspects is operable to interpret as directing the behaviour of a mobility protocol. Figure 1 is a schematic diagram of a mobile terminal in accordance with an embodiment of the present invention. Figure 2 is a schematic diagram of a generic component based unified mobility management system in accordance with an embodiment of the present invention. Figure 3 is a schematic diagram of a Mobile IP finite state machine. Figure 4 is a schematic diagram of a HAWAII finite state machine. Figure 5 is a schematic diagram of an RRMIPv4 finite state machine. Figure 6 is a schematic diagram of an RRMIPv6 finite state machine. Figure 7 is a schematic diagram of an HMIPv6 finite state machine. Figure 8 is a schematic diagram of a Cellular IP finite state machine. Figure 9 is a schematic diagram of a BCMP finite state machine. A terminal based protocol composition means and method are provided. In the following description, a number of specific details are presented, by way of example, in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to a person skilled in the art that these specific details need not be employed to practise the present invention. Referring to Figure 1, a mobile terminal 100 in accordance with an embodiment of the present invention is schematically illustrated. The mobile terminal 100 comprises a processor 124 operable to execute machine code instructions stored in a working memory 126 and/or retrievable from a mass storage device 122. By means of a generalpurpose bus 125, user operable input devices 130 are in communication with the processor 124. The user operable input devices 130 comprise, in this example, a keyboard and a touchpad, but could include a mouse or other pointing device, a contact sensitive surface on a display unit of the device, a writing tablet, speech recognition means, haptic input means, or any other means by which a user input action can be interpreted and converted into data signals. Audio/video output devices 132 are further connected to the general-purpose bus 125, for the output of information to a user. Audio/video output devices 132 include a visual display unit, and a speaker, but can also include any other device capable of presenting information to a user. A communications unit 150 is connected to the general-purpose bus 125, and further connected to an antenna 160. By means of the communications unit 150 and the antenna 160, the mobile terminal 100 is capable of establishing wireless communication with another device. The communications unit 150 is operable to convert data passed thereto on the bus 125 to an RF signal carrier in accordance with a communications protocol previously established for use by a system in which the mobile terminal 100 is appropriate for use. In the mobile terminal 100 of Figure 1, the working memory 126 stores user applications 128 which, when executed by the processor 124, cause the establishment of a user interface to enable communication of data to and from a user. The applications 128 thus establish general purpose or specific computer implemented utilities and facilities that might habitually be used by a user. In an embodiment of the present invention, the terminal 100 comprises a suite of components or modules that can be configured or adapted to achieve the operation of different macro and micro mobility components. In an embodiment of the present invention, an application 128 comprises these modules. By adapting one or more of these modules in response to the detected mobility scheme of a network, the terminal 100 can achieve transparent mobility management without recourse to automatic download of the protocols, or reliance on mobility support from the host network. Advantageously, such adaptation can limit the demands on the terminal's resources by identifying the similarities that exist between different protocols, and re-using code within the generic modules to configure for different protocols. In addition, some common functions are performed by every protocol; consequently when, for example, running micro and macro protocols simultaneously, redundancy can be reduced by a reuse of functionality for both protocols. This reduction in code and simplification of execution limit the computational overhead of supporting multiple mobility management protocols within the device. Referring now to Figure 2, in an embodiment of the present invention, the configurable modules, referred to collectively as a unified mobility management architecture (UMMA) 200 are arranged as follows. Mobility control packets 210 from the host IP network are passed to a packet verification module 220. The packet verification module parses the syntax of the packet to verify its compliance with established standards, and checks the packet fields for consistency. A wide variety of packet types are examined, such as router advertisements, registration replies and binding acknowledgements, for any protocol known by the packet verification module. Non-compliant packets are silently discarded. Compliant packets are then passed to a movement detection module 230. The movement detection module 230 examines incoming packets for evidence that the terminal 100 has moved to a new address. A number of strategies may be used to infer movement, and may be used singly or in conjunction. These include; comparing the network prefix on incoming router advertisement messages to the currently stored network prefix, and comparing the lifetime field on router advertisement messages with the actual interval between successive advertisements. Other methods by which to infer movement will be apparent to a person skilled in the art. The packets and any movement information are then passed to a control packet handler 240. The control packet handler 240 is responsible for interpreting the various protocols and responding appropriately according to the nature of the packet and known state of the terminal 100. The control packet handler 240 uses a finite state machine (FSM) representation of each protocol type, with each state machine including state descriptions and rules for transition from one state to another. The FSM thus provides a template for operation of the protocol, which the control packet handler is arranged to interpret. The control packet handler 240 is operable to load and use multiple finite state machines for different protocols. Where micro and macro mobility protocols co-exist in the control packet handler, the degree of functional overlap possible depends upon whether or not the micro mobility protocol is from the group that extends the macro mobility protocol, as noted previously. Where the micro-mobility protocol is an MIP extension to enable local registrations, a second FSM is not required, but only corresponding extensions to the MIP FSM, making protocol interaction straightforward. Where the micro-mobility protocol is independent of MIP, a second FSM is required, as is a local binding in the network, followed by an additional registration with MIP. Simultaneous operation of multiple FSMs is managed using a list maintained by the control packet handler 240. In this list, all mobility agents that the terminal 100 needs to register are stored. In addition to protocol specific information (such as packet specifications), the control packet handler 240 also stores the FSM that will manage each specific communication. The FSMs for MIP and various micro mobility protocols will be discussed in further detail in due course. A timer module 250 provides generic timer resources used by the various protocols run by the control packet handler 240. A network configuration module 260 similarly provides generic resources and functionality related to network configuration, such as routing table manipulation and acquisition of an IP address following movement of the terminal 100, so that IP connection can be resumed. The control packet handler 240 instructs the network configuration module 260 when a modification of network parameters is required, and the network configuration module 260 is operable to interact with the IP network to perform the updates. Finally, a control packet constructor 270 creates and outputs mobility control messages in accordance with the relevant protocol. The control packet handler 240 instructs the control packet constructor 270 when, for example, a handover occurs, or a registration request needs to be sent to the IP network. This arrangement of modules in the UMMA 200 provides a number of other advantages. Firstly, only one module, the control packet handler 240, is responsible for managing mobility. This is the case even when macro and micro mobility protocols are both in use, and so is economical in terms of system resources. Secondly, only running a single process to control two protocols advantageously avoids conflicts between protocols and their controlling processes when accessing terminal resources such as the network interface and routing tables in the network configuration module 260. Thirdly, the use of a single process means that no inter-process communication is necessary, so improving communication speed and security. Moreover, this architecture simplifies the addition of new protocols by defining them as new finite state machines within a generic system. The FSM for each new protocol comprises a set of rules that can be stored on a data structure. For different protocols the actions in a state vary, from the construction of a registration message, to installation of a default route on the routing table. A representation of the FSM as a file stored in the control packet handler 240 enables flexibility, as the acquisition of the appropriate file is enough to change the control packet handler's 240 operation and relevant actions. These actions are then performed by instructing the other modules as appropriate. In addition to the FSM for each micro-mobility management protocol, the appropriate packet specifications to enable verification, mobility detection and construction, and any other parametric information necessary for implementation of the micro-mobility management protocol are also stored. In one embodiment of the present invention, these are stored in association with their respective FSM. In an alternative embodiment, they are stored in a common library. Thus the full template for a given protocol comprises the operational template of the FSM plus the data template of the packet specifications and any parametric data. The finite state machines describing macro and micro mobility protocols for use with the above architecture will now be discussed in more detail. In the following descriptions, it will be understood that a transition by the control packet handler 240 or the terminal 100 to a particular state refers to the transition of an FSM hosted by the control packet handler 240 to that particular state. Mobile IP Figure 3 shows a finite state machine model of mobile IP (MIP) suitable for use by control packet handler 240 in an embodiment of the present invention. MIP comprises four states, labelled Idle, WaitA, WaitD and Bound. Transitions between these states are determined by sets of rules. The initial state is Idle, which denotes that the terminal 100 is located in its home network and thus it is not employing any Mobile IP specific feature. When the movement detection module 230 detects a handover, it notifies the control packet handler 240, which in turn notifies the network configuration module 260 to acquire a valid IP address for the current network. After the configuration of a valid care-of address, the Control Packet Constructor 270 is instructed to construct a Binding Update (BU) for MIPv6, (or a registration request for Mobile IPv4) and to transmit it to the Home Agent (HA). All the necessary information required to construct the packet is passed parametrically to the Control Packet Constructor 270. Finally, a timer in the timer module 250 is set to a protocol specific value in which a response from the HA must been received. After these actions are completed, a transition to the WaitA state occurs. The WaitA state, (standing for 'aWait Acknowledgment'), denotes the situation where a binding message has been transmitted to the HA but an acknowledgement message is pending. While in this state, if the previously set timer expires then the binding message is retransmitted and the terminal 100 remains in the WaitA state. Alternatively if a new handover occurs, then the terminal 100 remains in the WaitA state, but repeats the actions described for the Idle state when a movement had been detected, i.e. acquisition of an IP address, transmission of a BU and the setting of a timer. A binding acknowledgement (BA) with status field 141 denotes that some parameters of the BU message were miscalculated. In this case, the message is retransmitted with the fields corrected. The reception of a BA for MIPv6 (or a registration reply for MIPv4) with a status field that denotes a successful registration triggers the transition to the Bound state. For transition to the Bound state, the timer set previously for BU retransmissions is stopped, and additionally for Mobile IPv4 the network configuration module 260 is instructed to configure the routing table of the terminal 100. The Bound state represents the situation where the terminal 100 is currently successfully registered with the HA. From this state, two transitions are possible; either to the WaitA state or to the WaitD state. A transition to the WaitA state can occur either in the event of a handover or when a binding request message is received. In the event of a handover, the same actions as described previously for the WaitA and Idle states are repeated, and a transition to the WaitA state occurs. Transition to WaitD takes place when the terminal 100 returns to its home network. While transitioning to this state, again similar actions to those for a handover are repeated, but additionally the terminal must inform other nodes on the network of its return so they can update their IP to layer 2 address mappings. The WaitD state denotes the await deregistration acknowledgement state, as opposed to the registration acknowledgement of WaitA. The terminal's behaviour in the WaitD state is consequently similar to that in the WaitA state, except that when a valid BA is received, the terminal transits back to the Idle state instead of to the Bound state. As noted previously, the control packet handler 240 maintains a list storing the mobility agents that the terminal needs to register with. In the case of MIP, the mobile terminal 100 interacts simultaneously with a number of other nodes, including the home agent, correspondent nodes that attain sessions with the terminal 100, and finally home agents on the visited links that the mobile terminal 100 registers with for optimisation purposes. Consequently the control packet handler 240 must store state information for every binding individually and manage each binding independently of others that may be ongoing.

HAWAII Figure 4 shows a finite state machine model of HAWAII suitable for use by control packet handler 240 in an embodiment of the present invention. HAWAII also comprises the four states Idle, WaitA, WaitD and Bound. Transitions between these states are determined by sets of rules. Again, Idle is the initial state that denotes no mobile management protocol functionality has yet commenced. While in this state, two transitions to the state WaitA are possible, depending on whether an intra- or an inter-domain handover occurs. An intra-domain handover corresponds to the power up registration required by the protocol, where the terminal 100 is urged to register even though it is located at its home domain. A care-of address of the access router is employed for the construction of the registration message. In the case of an inter-domain handover, the terminal 100 acquires a co-located care-of address and transmits a registration request message to its home agent. As in Mobile IP, the WaitA state represents the situation wherein the terminal is awaiting acknowledgement. The deviation from the equivalent state in MIP is that receipt of a registration reply message can cause different actions depending on the cause of the initial transition to WaitA. If the transition to WaitA was due to an intra-domain handover, then a registration reply message will trigger a routing table configuration and a transition to the Bound state. On the other hand, if the terminal 100 is in state WaitA owing to an inter-domain handover, then a registration reply message will additionally trigger the establishment of a tunnel interface. A similar dependency occurs when an intra-domain handover on a foreign network takes place while the terminal 100 is in the WaitA state. If transition to WaitA was due to an inter-domain move, then the new movement is also treated as inter-domain, because the original registration with the home agent is not yet completed. However, if the initial transition to WaitA occurred due to an intra-domain handover, then the new migration is treated as intra-domain. To differentiate these situations, the event that caused transition to WaitA must be stored. This is a significant difference from the memory-less state machine of Mobile IP. Other aspects of inter- and inter-domain moves do not require knowledge of the transition method. Thus during an inter-domain move, for example, the control packet handler 240 instructs the network configuration module 260 to acquire a co-located care-of address, and instructs the control packet constructor 270 to transmit a registration reply to the home agent, while remaining in state WaitA. Similarly, during an intra-domain move, the control packet handler 240 instructs the network configuration module 260 to acquire a care-of address from the base station and instructs the control packet constructor 270 to send a registration reply, while still remaining on WaitA. Finally, an inter-domain migration to the terminal's home domain will trigger the transmission of deregistration message, and a transition to WaitD. Finally, the Bound state again represents a terminal's successful registration. While in this state, an intra domain move on the home network will trigger the acquisition of a care-of address, and transmission of a registration message, and upon completion a transition to the WaitA state occurs. An identical transition occurs during an intra domain handover on a foreign network, but without the acquisition of a care-of address. Inter domain handoffs are similar to intra domain handovers, except that a co-located care-of address is obtained. Finally, an inter domain handover to the home domain will cause the transmission of a deregistration message and a transition to the WaitD state. Regional Registration for MIPv4 Figure 5 shows a finite state machine model of RRMIPv4 suitable for use by control packet handler 240 in an embodiment of the present invention. RRMIPv4 again also comprises the four states Idle, WaitA, WaitD and Bound. Transitions between these states are determined by sets of rules. The initial Idle state denotes no ongoing protocol functionality as before. From this state only an inter domain handover is possible, which triggers a home registration. During the home registration the control packet handler 240 instructs the control packet constructor 270 to construct and send a registration request message using the gateway foreign agent (GFA) address as a care-of address, and then transits to the WaitA state. Two alternatives are possible for transmitting the packet, either through the foreign agent (FA) or directly to the GFA. In the latter scenario the terminal must insert a Hierarchical FA extension. As with the preceding schemes, the WaitA state represents the anticipation of the registration reply message. While in this state, transitions to all three other states are possible. An inter domain handover will again trigger a home registration as described before and the FSM remains in the WaitA state. Similarly an intra domain handover will trigger a regional registration while remaining in the WaitA state. The regional registration requests have similar syntax as the original MIP messages, and only vary in the value of some fields. For home registrations, the terminal 100 has the option to either acquire a co-located care-of address and append the Hierarchical FA extension, or use an FA care-of address, and send the message through that foreign agent. An inter domain handoff to the home network is handled as in MIP, i.e. a registration request message is sent to the HA so as to cease the MIP processing for the terminal 100, and a transition to the WaitD state occurs. The last possible transition from the WaitA state is to the Bound state, upon reception of a registration reply or a regional registration reply message. The specific action taken depends on whether the terminal acquires a co-located care-of address or not. In the former situation, the installation of a tunnel interface is required. Once successfully registered and in the Bound state, an inter domain handover will trigger a home registration and a transition back to the WaitA state. Similarly an intra domain handover will cause a regional registration and a transition to the WaitA state. Finally, an inter domain handover to the home network will initiate the deregistration process and a transition to the WaitD state. In the WaitD state, receipt of a valid BA will cause the control packet handler 240 to transit back to the Idle state. Regional Registration for MIPv6 Figure 6 shows a finite state machine model of RRMIPv6 suitable for use by control packet handler 240 in an embodiment of the present invention. RRMIPv6 was designed to simplify mobility management, and as a result only three states; Idle, WaitA and Bound. Transitions between these states are determined by sets of rules. As for original MIP, the initial state is Idle and the only transition from that state is due to an inter domain handover. Upon inter domain handover the control packet handler 240 instructs the network configuration module 260 to acquire a regional CoA and a collocated CoA, and instructs the control packet constructor 270 to construct a regional BU. The control packet handler 240 also sets the appropriate timers 250 required for retransmissions. Consequently the terminal transits to the WaitA state and anticipates a binding acknowledgement. While in the WaitA state, subsequent inter domain handovers prompt the repetition of the above actions for the Idle state, and the machine remains in the WaitA state. Intra domain handovers cause the acquisition of a new collocated CoA and transmission of a regional BU, if the terminal is already registered with the visited domain. Finally, if a BA is received then a transition to the Bound state occurs and the network layer is configured appropriately, i.e. routing table manipulation and installation of a tunnel interface by the network configuration module 260. In the Bound state, inter or intra domain handovers trigger a home registration, followed by a transition to the WaitA state. For inter domain handovers, a regional CoA is required, while for intra domain handovers a Previous Access Router Extension is required on the BU. In either case, however, a collocated CoA must be obtained. From either the WaitA or Bound state, an inter domain handover to the home network causes no action, and a transition by the control packet handler 240 to the Idle state. In this case, the MIP finite state machine can be triggered to deregister the node. Hierarchical Mobile IPv6 Figure 7 shows a finite state machine model of HMIPv6 suitable for use by control packet handler 240 in an embodiment of the present invention. As with RRMIPv6 above, the simplified mobility management of MIPv6 means that there are only the three states Idle, WaitA and Bound. Transitions between these states are determined by sets of rules. The initial state of the FSM is the Idle state. In this state, when an inter domain handover occurs, the control packet handler 240 co-ordinates the acquisition of regional care-of address (RcoA), a local care-of address (LcoA) and instructs the control packet constructor 270 to send a local BU to the mobility anchor point (MAP). Having accomplished these tasks it transits to the WaitA state. In the event that multiple MAPs operate on the network, preferably the terminal registers with the most distant one. In the WaitA state, the reception of a successful binding acknowledgement will cause the control packet handler 240 to transit to the Bound state and initiate a Mobile IPv6 registration. If an On-link Care-of address Test option is present on the binding acknowledgement then the control packet handler 240 instructs the control packet constructor 270 to send a BA back to the MAP. While in the WaitA state, a subsequent inter or intra domain move will cause the acquisition of care-of addresses, transmission of a BU and no state transition. Finally, if while in the WaitA state an inter domain move at the home network occurs, then the state machine transits to the Idle state. In the Bound state, an inter domain handoff will trigger the acquisition of an RCoA, an LCoA and transmission of a BU, together with a transition to the WaitA state. Similar actions occur for an intra domain handover, except that an RCoA is not required. Similarly for WaitA, a return in the home domain will cause a transition to the Idle state. Cellular IP Figure 8 shows a finite state machine model of Cellular IP (CIP) suitable for use by control packet handler 240 in an embodiment of the present invention. CIP belongs to the group of solutions independent of MIP. In consequence it uses a different set of states; Idle, Active and Inactive. As before, transitions between these states are determined by sets of rules. The initial Idle state denotes that no CIP specific action is currently performed, or that the terminal is not located in a CIP network. While in the Idle state the only possible event is the entrance in a CIP access network, which will trigger a registration function. Initially, the closest access router is selected as the default route for all data packets sent in future by the terminal 100. In addition, a route update message is constructed by control packet constructor 270 and sent to the Cellular IP Gateway. A MIP registration is initiated in the case where the terminal enters a foreign domain. For CIPv4, the Gateway IP address is employed as the care-of address, whereas in CIPv6 a care-of address is constructed with stateless autoconfiguration using the CIP Gateway's subnet. By contrast, if the terminal 100 is located in its home domain, an MIP registration is not required. Having accomplished these actions, the control packet handler 240 transits to the Active state. While in the Active state, the control packet handler 240 instructs the network configuration module 260 to manipulate the routing table and send a route update packet after every handover to an access router within the same CIP domain. Handover to different domains also initiates MIP registration. A route update packet is also sent if a data packet has not been generated from the terminal 100 within the system specified time route update time. This is to ensure that entries in the route cache do not expire. The control packet handler 240 remains in the Active state for as long as it sends or receives data IP packets. If no packet is received for a fixed time period, denoted also as active state timeout, then a transition to the Inactive state takes place. In the Inactive state, the terminal does not have to send an update packet after every move. However, a packet is required every time a move to a different paging area takes place or after the lapse of the system specific time paging update time. If an IP data packet is received, then a transition to the Active state occurs followed by the transmission of a route update packet. As in the previous case, inter domain handovers also trigger MIP registrations. In either Active or Inactive states, if the terminal 100 is to depart from the network, then a paging teardown message is transmitted followed by a transition by the control packet handler 240 to the Idle state. It is the control packet handler 240 that decides the kind of handover performed. The difference between a hard and semi-soft handover is that in the former, the terminal 100 immediately configures its routing table and wireless interface to the new base station's characteristics, whereas in the latter a time period elapses before those configurations take effect. BRAIN Candidate Mobility Management Protocol Figure 8 shows a finite state machine model of BRAIN suitable for use by control packet handler 240 in an embodiment of the present invention. BRAIN also belongs to the group of solutions independent of MIP, and so uses a proprietary set of five states; Idle, WaitL, WaitH, WaitP and Bound. Again, transitions between these states are determined by sets of rules. The Idle state denotes that the terminal is not registered yet with a BCMP access network. When the presence of a BCMP access network is sensed, a Login Request message is sent, and a transition to the WaitL state (await login acknowledgement) takes place. While in the WaitL state, subsequent movements trigger the transmission of another Initial Login message in a manner similar to that of the WaitA state in other schemes. Similarly, if an acknowledgement is not received within a specified time period then a retransmission occurs. If on the other hand a Login Reply message is received, then the control packet handler 240 configures its interface and routing table and transits to the Bound state. In the Bound state, a transition to the WaitH state (await handover acknowledgement) occurs after the migration to another subnet within the same domain, accompanied by the transmission of a Handover message. If the terminal 100 is to perform a planned handover instead, then a transition to the WaitP state (await handover preparation acknowledgement) takes place followed by the transmission of a Handover Preparation message. Inter domain handovers will cause registration with the new domain, and thus a Login Request message is sent and the control packet handler 240 transits to the WaitL state. Finally, if the terminal 100 is to depart from the network, a Logout message is sent and the control packet handler 240 returns to the Idle state. The WaitH state represents the anticipation of a Handover Acknowledgement message. Subsequent movements from this state are handled according to the type of handover. Intra domain handovers cause the retransmission of a Handover message and no transition to another state. Inter domain handovers will initiate a registration and a transition to the WaitL state. Finally, if a valid Handover Acknowledgement is received, then the control packet handler 240 instructs the network configuration module 260 to configure the routing table. The control packet handler 240 then transits to the Bound state. The WaitP state denotes the expectation of a Handover Preparation Acknowledgement message. A successful reception of an acknowledgement, or an intra domain move, will cause the transmission of a Handover message and a transition to the WaitH state. If the planned handover does not complete successfully then a transition to the Bound state occurs. Finally, inter domain moves cause initiation of a registration and a transition to the WaitL state. For any of the above mobility solutions, in an embodiment of the present invention the control packet handler in operation may, if necessary, link module binaries at run time using techniques known in the art; for example Windows dynamic link libraries, or the FreeBSD dynamic kernel loader, depending on the operating system of the device. Similarly, the control packet handler may load one or more FSMs with any attendant data characterising packet types or other system features relevant to a given mobility solution. Consequently, the application modules and the data representations of each mobility solution may be stored on data carriers either separately or in combination. It will be appreciated that therefore in embodiments of the present invention, the modules of the UMMA 200 and the data representations of the protocols may be located either within the mobile terminal 100, or within communications unit 150, or distributed between the two, in any suitable manner. For example, communications unit 150 may be a PCMCIA card comprising a factory set of FSMs in read-only memory. In a converse example, the communication unit 150 may hold the UMMA 200 in firmware whilst the host terminal 100 holds the FSMs in working memory 126, or bulk storage 122. Thus the present invention may be implemented in any suitable manner to provide suitable apparatus or operation; in particular, a UMMA may consist of a single discrete entity, a single discrete entity such as a PCMCIA card added to a conventional host device such as a laptop, multiple entities added to a conventional host device, or may be formed by adapting existing parts of a conventional host device, such as by software reconfiguration, e.g. using a software plug-in. Alternatively, a combination of additional and adapted entities may be envisaged. For example, the configurable modules of the UMMA may operate on the host device, whilst FSMs are stored on a PCMCIA card. Thus adapting existing parts of a conventional host device may comprise for example reprogramming of one or more processors therein.As such the required adaptation may be implemented in the form of a computer program product comprising processor-implementable instructions stored on a storage medium, such as a floppy disk, hard disk, PROM, RAM or any combination of these or other storage media or signals. It will be clear to a person skilled in the art that an FSM may be downloaded from a network access point if necessary. Whilst this may cause an initial delay, the new FSM (and ancillary information such as packet descriptions) may then be stored locally for subsequent use. It will be clear to a person skilled in the art that if, at some future date, a single micromobility protocol becomes standard, that the method and means of the present invention may still be used in conjunction with a template corresponding that standardised micromobility protocol. If said protocol is an extension of MIP, this may comprise a single augmented MIP FSM. If said protocol is independent of MIP, then this template may co-exist with an MIP template, or other future macro-mobility protocol equivalent. A method of communication is also provided, comprising the steps of obtaining at least a first protocol template, and composing a protocol implementation. The step of composing a protocol implementation in turn comprises the step of configuring and controlling a plurality of modules that implement generic functions related to one or more protocols, in accordance with said at least first protocol template.

Claims (16)

CLAIMS:

1. A mobile terminal comprising; a plurality of configurable modules; a memory means operable to store a template representing aspects of a communications protocol, and; a template interpreting module operable to configure and control those of said configurable modules required in accordance with said template, such that in use one or more communication protocols are implemented by the configuration and control of said configurable modules in accordance with said template.

2. A mobile terminal according to claim 1 wherein the memory means is operable to store a plurality of templates.

3. A mobile terminal according to claim 1 or claim 2 wherein the template interpreting module is operable to configure and control those of said configurable modules required in accordance with two or more templates.

4. A mobile terminal according to any one of the preceding claims wherein a template comprises a finite state machine model of a communications protocol.

5. A mobile terminal according to any one of the preceding claims wherein a stored template comprises data characterising one or more types of packet used by a communications protocol.

6. A mobile terminal in accordance with any one of the preceding claims wherein the plurality of configurable modules comprises any or all of: i. a packet verification module; ii. a movement detection module; iii. a network configuration module; iv. a timer module, and; v. a control packet construction module.

7. A mobile terminal in accordance with claim 6, wherein the packet verification module parses the syntax of incoming packets to verify their compliance with one or more protocols.

8. A mobile terminal in accordance with claim 6, wherein the movement detection module examines incoming packets for indications that the mobile terminal has moved to a new access point.

9. A mobile terminal in accordance with claim 6, wherein the timer module implements timers under instruction from the template interpreting module.

10. A mobile terminal in accordance with claim 6, wherein the control packet construction module assembles packets upon request from the template interpreting module.

11. A mobile terminal in accordance with any of the preceding claims wherein a template encapsulates aspects characterising any one of the following protocols: i. MIP; ii. MIPv4; iii. MIPv6; iv. RRMIPv4; v. RRMIPv6; vi. H-MIPv6; vii. HAWAII; viii. CIP; ix. CIPv4; x. CIPv6, and; xi. BCMP, all acronyms as defined herein.

12. A method of communication comprising the steps of obtaining a protocol template, and; composing a protocol implementation, wherein composition in turn comprises the step of configuring and controlling a plurality of modules operable to implement generic functions related to one or more protocols, in accordance with said protocol template.

13. A method of communication according to claim 12 wherein the step of obtaining a protocol template is achieved by any one of: i. recalling said template from a memory means, and; ii. downloading said template from an access point.

14. A data carrier comprising computer readable instructions that, when loaded into a computer, cause the computer to operate as a mobile terminal according to any one of claims 1 to 11.

15. A data carrier comprising computer readable instructions that, when loaded into a computer, cause the computer to operate as any or all of i. a packet verification module; ii. a movement detection module; iii. a template interpretation module; iv. a network configuration module; v. a timer module, and; vi. a control packet construction module.

16. A data carrier comprising computer readable instructions characterising a mobility protocol that, when accessed by a computer operating a template interpretation module that is in turn operable to configure and control a plurality of modules that implement generic functions related to one or more protocols, cause the computer to implement said mobility protocol.