GB2445586A - Method of deploying software modules to a configurable terminal in which the suitability of the module is assessed before full deployment. - Google Patents

Abstract

Disclosed is a method of deploying a software module in a configurable terminal, such as a computer or mobile phone. The method has the steps of providing a software module to the configurable terminal, assessing the software module in the terminal before deployment or installation, if the assessment is found to be satisfactory, the module is deployed. The assessment may involve analysing a network description of the module with respect to set criteria. The terminal may receive or generate the network description of the module as part of the assessment. The analyses may include invariant analysis, load analysis, state-space exploration, delay analysis or checking the syntax and the criteria may include safety, liveness, reachability boundedness and delay times. The results of the assessment may be shared with other terminals and compared with the results from the other terminals. The module may be a communications protocol or enhancement.

Description

On-line Verification of Protocols and Protocol Enhancements The present

invention relates to a configurable terminal and a method of deploying software modules in a configurable terminal.

The concept of enabling terminal devices to apply protocol enhancements, or even entirely new replacement protocols, allows devices to tailor their performance for the application requirements and operating constraints at any given time.

Many of the ideas in this area come from reconfigurable terminal research such as software defined radio (SDR) (L. Elicegtii, G. Vardoulias, G. Clemo, D Thomas, D. Grandblaise, R. J. Haines, et al.: "White paper -Dynamic Spectrum Allocation: a Stake for Re-configurable Terminals", ITU-T Detailed Considerations on spectrum implications of ongoing development of IMT-2000 and systems beyond, Vol. Annex 4, 2001; T. Farnham, G. Clemo, R. J. Haines, E. Seidel, A. Benamar, S. Billington, et al.: "IST-TRUST a perspective on the reconfiguration of future mobile terminals using software download", The 11th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, 2000, Vol. 2, pp. 1054-1059, 2000; T. Farnham, G. Clemo, R. J. Haines, E. Seidel, A. Benamar, S. Billington, et al.: "Reconfiguration of Future Mobile Terminals using Software Download", 1ST Mobile Communications Summit, 2000). Other concepts originate from cognitive radio (Walko, J.: "Cognitive Radio", lEE Review, 5 1(5), pp. 34 -37, 2005). Both technologies rely on the ability to "plug and play" alternative modules (both physical layer definitions and higher-layer protocols) in order to reconfigure a terminal device to the requirements and capabilities of alternative communications systems.

Whilst SDR proposals tend to assume the download of pre-defined modules, cognitive radio assumes more dynamic and intelligent approaches where modules and behaviours can be generated or optimised dynamically and as needed. The capability to reconfigure a terminal to use a temporarily available spectral resource is set to become increasingly valuable as regulators around the world seek to improve the utilization of the radio spectrum.

The process of deploying a protocol enhancement or a more comprehensive reconfiguration oblige the device to engage in interactions with management functions in the available networks to select a specific configuration, as well as various distributed algorithms and protocols that it must use once a configuration has been activated. These interactions, algorithms and protocols can be considered to be "computing programs" in the most general sense: i.e. collections of communicating activities executed by computer processors. This multiplicity, and the dislocations of time and space due to the distribution of the components, make the behaviour of the overall system difficult to describe and impossible to test, due to the enormous number of possible paths. While methodologies exist for generating tests, such as Testing and Test Control Notation (TTCN) exhaustive testing of protocols has never been an effective process, and, with the number of protocols and protocol optimisations increasing to realize pervasive communications from the personal to the cellular domain, the probability of achieving significant path coverage for any scenarios is very low. In the case of a fully intelligent and adaptable Cognitive Radio that is able to deploy a very specific protocol on an ad hoc basis, there may not even be the opportunity to perform such testing.

Whereas JP 63286947 describes an automatic verification system for protocols, it is restricted to state-space exploration and is merely targeting the question of whether a particular undesirable state is reachable or not.

"Brute force" testing of modules is inefficient, ineffective and patently unsuitable for the more dynamic reconfiguration environments. What is needed is the ability to verify and validate key properties of modules in a reliable and efficient manner. It is therefore an object of the present invention to obviate at least some of the above disadvantages and to provide an improved method for deploying software modules in a configurable terminal.

According to a first aspect of the present invention, a method of deploying a software module in a configurable terminal comprises providing at least one software module to said configurable terminal, assessing said at least one software module in said configurable terminal prior to deployment, determining in said configurable terminal whether the assessment of said at least one software module is satisfactory; and upon satisfactory assessment of said at least one software module, deploying said software module in said configurable terminal.

The step of assessing said software module may further compnse analysing the network description of said software module with respect to at least one criterion.

The step of assessing said software module may further comprises determining a degree of conformance for said software module with respect to the at least one criterion.

The step of analysing the network description of said software module may further comprise at least one of invariant analysis, load analysis, or state-space exploration.

The at least one criterion may be selected from the group comprising safety, liveness, reachability and boundedness.

The step of providing said at least one software module to said terminal may further comprise receiving at least a network description of said at least one software module from a source external to said terminal, or generating at least a network description of said at least one software module internally within said terminal.

The step of providing said software module to said terminal may further comprise providing said network description of the software module in the Petri-net form.

The step of verifying said software module may further comprise checking the syntax of the software module andlor the network description.

The step of verifying said software module may further comprise reducing the network description of said software module prior to its analysis.

After verification, the verification results for said software module may be shared with other terminals.

After verification, the verification results for said software module may be compared with those of other terminals.

A plurality of software modules may be provided, the plurality of software modules being assessed individually, and after satisfactory assessment, selecting the software module for deployment which best meets the selected criterion or criteria In one configuration of the above aspect, the terminal may be a telecommunications terminal, preferably a mobile telephone.

In another configuration of the above aspect, the terminal may be a personal computer.

In a configuration of the above aspect, the software module may be a communications protocol module or protocol enhancement module.

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

According to another aspect of the present invention, a computer-readable medium comprises computer-executable instructions to configure a configurable terminal to operate in accordance with the method according to the first aspect of the invention.

According to a further aspect of the present invention, a configurable terminal comprises means for providing at least one software module to said configurable terminal, means for assessing said at least one software module in said configurable terminal prior to deployment; means for determining in said configurable terminal whether the assessment of said at least one software module is satisfactory; arid means for deploying one of said at least one software modules in said configurable terminal upon satisfactory assessment of said at least one software module,.

In a configuration of the above aspect, the configurable terminal may further comprise means for operating in accordance with the method according to the first aspect of the invention.

In one configuration of the above aspect, the terminal may be a telecommunications terminal, preferably a mobile telephone.

In another configuration of the above aspect, the terminal may be a personal computer.

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: Fig. 1 illustrates a fundamental network component in Petri-net format.

Fig. 2 is a flow chart illustrating the steps of a method according to present invention.

Fig. 3 is a block diagram illustrating a detail of step 110.

Fig. 4 is a block diagram illustrating a detail of step 120.

Fig. 5 is a block diagram illustrating in detail the steps of a method according to present invention.

Fig. 6 is a Petri-net diagram of an unreduced network.

Fig. 7 is a Petri-net diagram of a reduced network.

Fig 8 is a flow chart showing the steps of the T-invariant delay verification Fig. 9 is a flow chart showing an example protocol module in Petri-net format.

Fig 10 is a flow chart illustrating key path I of the example protocol module.

Fig. 11 is a flow chart illustrating key path 2 of the example protocol module.

Fig. 12 is a flow chart illustrating an example protocol module after reduction.

Fig. 13 is a representation of a MAC queuing system.

Fig. 14 is a flow chart illustrating the verification rake of step 128 Fig. 15 is a listing of program code for generation a reachability graph for state-space exploration.

Formal mathematical methods, also known as formal description techniques (FDTs), take the logically and mathematically sound basis of aspects of discrete mathematics (logic, set-theory, graph-theory, matrices) and apply them to the specification and verification of computing programs. Formal methods allow a rigorous proof to be made of various "correctness" properties of the program under consideration. In the case of protocols, properties of particular interest include the classic design error of deadlock and whether the number of resources consumed is finite and bounded.

A wide range of formal methods exists, offering a variety of capabilities and approaches. There are perhaps as many formal methodologies as there are programming languages, although, unlike the case of progranirning languages, there is no short-list of clear winners or popular favourites. The different formalisms can be categorized in a number of ways, including the style of the syntax-from textual, algebraic expressions to graphical representations-and the degree to which the formalism suits the description of static or dynamic problem domains.

Petri-nets (C.A. Petri: "Kommunikation mit Automaten" -English translation: Technical Report RADC-TR-65-377 -PhD Thesis, University of Bonn; Engi.: Vol. 1, Suppl. 1, Applied Data Research, Princeton, N.J., incorporated herein by reference)) and the variety of extensions and specialized dialects descended from them (M. Ajmone Marsan and (3. Cluola: "On Petri Nets with Deterministic and Exponential Transition Firing Times", 7th European Workshop on Application and Theory of Petri Nets, Oxford, England, 1986; reprinted in: Advances on Petri Nets 87, Lecture Notes in Computer Science 266, pp 132-145, Springer-Verlag, 1987, incorporated herein by reference; R. Valk: "Petri Nets as Token Objects -An Introduction of Elementary Object Nets," Lecture Notes in Computer Science 19th 1.nternational Conference on the Application and Theory of Petri Nets (ICATPN 98), Lisbon, Portugal, 1998, incorporated herein by reference; 0. Kummer: "Introduction to Petri Nets and Reference Nets," Soziomk Aktucll, vol. 1, pp. 1-9, 2001; S. Gilmore, J. Hillston, L. Kioul, and M. Ribaudo: "PEPA nets: A structured performance modelling formalism, " Computer Performance Evaluation, Modelling Techniques and Tools, 12th International Conference, TOOLS 2002, pp. 111-130, 2002, incorporated herein by reference) offer a formalism that combines a graphical representation that can be readily grasped and used with a strong mathematical foundation to permit automated proof-checking The graphical form comprises a small number of components that are soon learned, yet offers a very rich and expressive vocabulary. The underlying (matrix-based) mathematical representation allows automated exhaustive state-space exploration as well as rigorous expression and analysis of critical properties of the net in question (Singh, G. and Sanimeta, M., On the construction of multiphase communication protocols, in International Conference on Network Protocols, Boston, Massachusetts, 1994, IEEE, pp. 151-158, incorporated herein by reference).

Petri-nets have been an active research area for over forty years. The fundamental Petri-net formalism, as defined by Prof. Carl Adam Petn's thesis of 1962 (cf. C.A. Petn, supra), aimed to provide a means of describing a system in such a way that its inherent parallelism, asvnchrony, and indeterminism was apparent. As illustrated in Fig. I, in its graphical form (a bi-partite multigraph), a Petri-net comprises places 1 (represented graphically as circles,), transitions 2 (rectangles) and arcs 3 (the lines between them) joining the places and transitions. An arc 3 can only join a place 1 to a transition 2, or vice versa-an arc cannot connect a place 1 to a place 1, for example. Arcs 3 can be weighted, which is a shorthand notation for multiple parallel arcs.

The final component is the token 4 (typically represented as dots or a pair of square brackets as in the representation in Fig. I), whieh are distributed across the places in the net. The distribution of tokens at any point in time is termed the marking. The presence of tokens at a place is typically interpreted as the availability of a resource. If tokens are present at all of the places connected to a transition (allowing for weighted arcs), then the transition may fire and deposit tokens in the output places. The initial marking of places with tokens determines the initial conditions of the net. Concerning the inherent properties mentioned above, it is often the case that multiple transitions may be enabled.

In Petri's original formalism, there are no rules about the order of firing, so the net moves from marking to marking, representing processing steps that may be proceeding in parallel and asynchronously, with many possible sequences partly capturing the non-deterministic progress. The other aspect of non-determinism is termed "conflict", meaning that choosing one transition may prevent the firing of others that were previously enabled. This seemingly simple behaviour is representative of the most basic building blocks of communicating processes, and models of complex systems can be constructed relatively quickly.

Algebraically, the basic Petri-net can be described as a 4-tuple, comprising P, the (finite) set of places, T the (finite) set of transitions (these two sets being distinct), the incidence function A and the initial marking M0. These tuple elements can be most conveniently represented in matrix form, with P, T and M0 being vectors. The incidence function A represents the weights of the arcs between transitions and places (the weights are negative if a transition removes tokens from a place; positive if it adds tokens to a place). Specifically, element a1 of the matrix A defines the weight of the arc from transition ito placej (if the weight is negative, it defines the weight of the arc to transition i from placej). Hence, a Petri-net PN (P, T, A, M0), where: P=[pi,p2,...,p] T=[t1,t2,t} ATxP-[...-3,-2,-l,O,1,2,3,...] Mo=P-[O,l,2,3,...] PnT= ; PUT!= The aforementioned incidence matrix A represents, row by row, the token movements associated with each firing, assuming it is enabled. Combining this matnx with the marking vector of the net prior to the transition firing (Mk.I) gives the marking of the net after the transition has fired (Mk). This can be expressed as Murata' s state equation (T. Murata, Petri Nets: Properties, Analysis and Applications," Proceedings of the IEEE, vol. 77, issue 4, pp. 541 -580, 1989, incorporated herein by reference): Mk =M1 +(ATUk)T (1) Where Uk is the control vector identifring the transition about to fire at step k and T is the matrix-transpose operator.

A variety of extensions to basic Petri-nets introduce additional capabilities, including tokens as typed objects (as coloured nets: K. Jensen: "Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use", vol. 1 (Basic Concepts): Springer-Verlag GmbH, 1997, incorporated herein by reference), tokens as other nets (R. Valk, supra) to allow refinement via a hierarchical and modular net structure, and transitions capable of invoking external actions (0. Kummer, supra). Higher order Petri-net formalisms such as Stochastic Petri-nets (S. Donatelli, M. Ribaudo, and J. Hiliston: "A comparison of performance evaluation process algebra and generalized stochastic Petri nets", Proceedings of the Sixth International Workshop on Petri Nets and Performance Models, pp. 158-168, 1995, incorporated herein by reference; A. Heindi and R. German: "Performance modeling of IEEE 802.11 wireless LANs with stochastic Petri nets", in Performance Evaluation, vol. 44: Elsevier Science B.V., 2001, pp. 139-164, incorporated herein by reference) and PEPA-nets (Gilmore et al., supra) introduce further functionality to support analysis of nets (or their component tokens in the case of PEPA-nets) as Markov-models. Higher order Petri-nets have been successfully applied to a number of areas, including modeling aspects of the IEEE8O2.11 Distributed Coordination Function (DCF) (Heindl and German, supra), and the benefits of 1IEEE8O2. lie-style Quality of Service (QoS) prioritisation in high-reliability medical environments (F. B. Sloane and V. Gehiot: "Ensuring Patient Safety by using Colored Petri Net Simulation in the Design of Heterogeneous, Multi-Vendor, Jntegrated, Life-Critical Wireless (802.x) Patient Care Device Networks", IEEE-EMBS 2005. 27th Annual International Conference of the Engineenng in Medicine and Biology Society, 2005, incorporated herein by reference).

The first problem that becomes apparent when performing formal validation of any form is that of state-space explosion-beyond the most trivial of nets the number of combinations soon becomes unmanageable. However, there are techniques available to mitigate this, not least of which being the hierarchical structure facilitated by Reference-nets. Additionally, there is a well-defined set of mathematically proven reduction rules to collapse complex Pen-i-nets down to more manageable sizes, through the elimination of self-loops and the fusion of places and transitions (T. Murata, supra). Table I lists the full set of Petri-net reduction rules.

Rule Abbr. Description

Fusion of Series Places FSP Two places linked by a single transition can be _________________________ ______ collapsed into a single place.

Fusion of Series FST Two transitions linked by a single place can be Transitions ______ collapsed in a single transition Fusion of Parallel Places FPP Two places with common source and destination transitions and equivalent arcs can _________________________ ______ be replaced by a single place Fusion of Parallel FPT Two transitions with common source and Transitions destination places and equivalent arcs can be ________________________ _______ replaced by a single transition.

Elimination of Self-loop ESP A self-loop place, one with the same source Places and destination transition and no other arcs, can be removed.

Elimination of Self-loop EST A self-loop transition, one with the same Transitions source and destination place and no other arcs, can be removed.

Table 1: Reduction Rules for Petri-nets Properties of Petri-nets can be verified through a number of means. Two properties of considerable interest are those of safeness (the idea that "nothing bad happens", see Hailpern, B.T. and Owicki, S.S.: "Modular Verification of Computer Communication Protocols", IEEE Transactions on Communications, 3 1(1), pp. 56 -68, incorporated herein by reference) and liveness ("eventually something good happens"). In particular, a Petri-net is defined as "safe" if no more than one token can accumulate in any given place (there is also a weaker definition of safe, where no more than k tokens will ever accumulate), and defined as "live" if there is no possibility of deadlock in the net. By deadlock, we mean that markings exist from which no sequence of transition firings can be found to all other markings, so liveness is a very strong property. it does not exclude other possible starvations, such as livelock, which arise due to conflicts and the possibility that some transitions are never chosen to fire.

The most straightforward and easily-automated means of evaluating these and many other conditions is the generation of labelled directed graphs known as reachability graphs: from the initial marking of the net, all possible transitions are fired.

Graphically, the reachability graph comprises nodes labelled with the corresponding marking, linked with arcs labelled with the transition moving from one marking to the next. This state-space exploration can be achieved through repeated elementary matrix manipulation operations using Murata's state equation (1). Clearly, such a brute-force approach is susceptible to state-space explosion, with the reachability space exponentially related to the size of the net and its connectivity. Nonetheless, provithng the size of the net can be kept under control, it is an intuitive and reliable means for evaluating behavioural properties It is conceptually simple and therefore relatively easy to automate.

More mathematical-based analysis of the structural properties of nets can be conducted without requiring brute-force computation. The key structural properties of a net can be expressed through invariants. These are statements about places or transitions that (as the name implies) are true throughout the operation of the net. Invariant analysis, as with the automated state-space exploration, exploits the matrix form of the Petn-net and the representation of net firings as vector-additions of the appropriate row of the incidence matrix and a given marking vector. There are two invariants commonly used in the literature to investigate properties of nets: place invariants (S-invariants) and transition invariants (T-invariants), referring to constant properties associated with places and transitions respectively.

A place-invariant defines an immutable statement regarding some or all of the places in a net, i.e. a weighting factor such that the vector product of that weighting factor and any given marking is constant. Typically this would be that the number of tokens in a group of places never exceeds a certain value, equal to that at the initial marking. One well-cited example is proving that a number of places (i.e. resources) are mutually exclusive; if the place-invariant for those places can be proven to sum to one (i.e. one token), then clearly the token can be in one place only, and must be mutually exclusive.

An S-invariant is an integer solution to: Ay=O (2) where A is the incidence matrix, y the vector solution and 0 an appropriately sized zero-matrix. Related to S-invariants are the "supports" of the invariant. In the case of S-invariants, the support is effectively the firing sequence (albeit without any ordering or notion of time-it simply records the number of times each transition has to fire) associated with the place-invariant. The support of an invariant, is the set of places corresponding to non-zero entries in an invariant x = 0. The support is a minimal support if no proper non-empty subset of the support is also a support. If there's a minimal support, there's a corresponding minimal invariant. The set of all minimal-support-invanants can serve as a generator of invariants, i.e. any invariant is a linear combination of minimal-support-invariants. From these minimal support invariants an upper bound on the number of tokens in any place can be calculated according to the following equation: M(p) = min[(M Ty1)/(y1 (p))j (3) Where M(p) is the upper bound on the marking of place p, y, the minimal support and (p) is the vector identifier for the place p. Transition invariants are, in many ways, the complement of place invariants. Intuitively, a transition invariant defines a sequence of firings in the net that forms a cyclic sequence; most commonly in the literature the sequence of firings to get all the way back to the initial marking M0 (and therefore known as a neutral sequence as it has no overall effect on marking). Mathematically, a T-invariant is an integer solution to: ATx=0 (4) where AT is the transposed incidence matrix, x the vector solution and 0 an appropriately sized zero-matrix. As with S-invariants, T-invariants have "supports", which, in this case, are firing-count vectors. Transition invariants can be used to determine the liveness and fairness of a net, that the net eventually achieves some particular procedure or sequence of transitions and, most importantly, form a necessary condition for the net to be bounded and live (if the net can get back to somewhere, then it cannot be deadlocked).

To surnmarise, given a particular net of interest, techniques including state-space exploration and invariant analysis can be applied to determine flmdamental properties such as safety and liveness.

With reference to Fig. 2, a flow chart illustrates the steps of a method of deploying a software module in a configurable terminal in accordance with the present invention.

Initially, at least one software module is provided in a first step 110 to said configurable terminal, in a further step 120 the at least one software module is assessed in said configurable terminal prior to deployment. In another step 130 it is determined in said configurable terminal whether the assessment of said at least one software module is satisfactory. After satisfactory assessment of said at least one software module, in step one of said at least one software modules is deployed in said configurable terminal.

The terminal may preferably be a telecommunications terminal or a personal computer.

The software module may be a communications protocol or enhancement The method according to the present invention begins by obtaining a candidate protocollprotocol enhancement module. As shown in Fig. 3, the step 110 of providing said software module to said terminal may comprise obtaining said software module and a network description thereof from a source external to said terminal; or generating said software module and a network description thereof internally within said terminal.

This can be achieved through the download in step 111 of a protocol module definition which could be in a format such as the Petri-net Markup Language (PNML), an XML-like markup language for describing Petri-nets. Alternatively, the module could be generated locally in step 112 by means such as the optimisation or reconfiguration of existing modules (e.g. altering the inter-frame spacing between frames to cover longer ranges), or techniques such as genetic programming (T. Lewis, N. Fanning, and 0.

Clemo: Enhancing IEEE8O2.1l DCF using Genetic Programming," IEEE VTC 06 Spring, Melbourne, Australia, 2006, incorporated herein by reference).

Still referring to Fig. 3, step 110 of providing said at least one software module to said terminal may comprise receiving at least a network description of said at least one software module from a source external to said terminal (step Ill); or generating at least a network description of said at least one software module internally within said terminal (step 112) With reference to Fig. 9, which shows a flow chart representing an example protocol module in Petri-net format, one embodiment may relate to e.g. a reprogrammable cellular telephone, typically comprising a primarycommunication mechanism (3G, GSM, etc.), and optionally one or more secondary communications mechanisms (Bluetooth, 1JWB, WiBree, WLAN, also wired USB connections) and peripheral connections (typically a removable non-volatile memory chip such as a plug-in SD Card" or Memory Stick'). However, due to the continuing convergence of computing and communications, it will be appreciated that there is no longer a clear distinction between a cellular "smart" telephone and a FDA with communications capabilities and/or a laptop computer. Such devices have common traits of mobility, wre1ess networking, battery power and high processing capabilities and memory capacity.

Protocol download may be achieved through one of three means. The first option is the provision of a protocol module directly by the network operator as an over-the-air (OTA) download from the network operators servers as described, for example, in ("System re-configuration and over-the-air download functions of the software radio prototype supporting PHS and wireless LAN", Shiba, H.; Shono, T.; Uehara, K.; Umehira, M.; Vehicular Technology Conference, 2002. Proceedings. VTC 2002-Fall.

2002 IEEE 56th Volume 3, 24-28 Sept. 2002, pp. 1627-1631, Vol. 3, incorporated herein by reference). The second possibility is through an operator independent download where a standard data connection is set up by the device over the primary communication path to the internet, and a connection made to a File Transfer Protocol (FTP) server to download a protocol module directly (transfer over a secondary communication medium such as Bluetooth or UV.rB would fall under this category).

The third option is the provision of a protocol module through an intermediate medium, such as a plug-in SD CardTM or Memory StickTM.

The protocol module arrives in a temporary storage area once it has been fully downloaded (acknowledged, and subjected to checksum verification to ensure that the module has been downloaded in a complete and correct state, un-corrupted by noise or errors) over the air interface or across the ancillary interface from the penpheral plug-in memory cards. The module is then uncompressed if necessary (cf. contemporary compression programs such as WinZip or WinRAR) into the temporary area of memory. The module is now ready for the verification and checking stages.

The protocol module for the purposes of this invention is envisioned as either an executable Petri-net representation or an executable module with an accompanying Petn-net description. Since the latter model places a burden of trust on the link between the module and its Petri-net description, the former model may be preferred. Extended PNML is a good contender for a Petri-net representation for this purpose.

Again referring to Fig. 3, an alternative approach to downloading a pre-prepared protocol incorporated within this invention is to modify, adapt or generate a protocol independently, locally on the device, as indicated by step 112. One approach for achieving this may be genetic programming, where atomic actions described within the vocabulary of a protocol's behaviour are randomly assembled, divided, spliced and evolved in a manner representative of random genetic mutation. Each generation of genetic mutation is evaluated according to a fitness function, with the "fittest" mutations surviving, in a Darwinian process. This approach is show-cased as a means of evolving and improving an aspect of the [EEE8O2. 11 WLAN protocol (T. Lewis, N. Fanning, G. Clemo, supra).

A related approach is to perform simple modifications to a pre-defined protocol. An example of this is taking the defined 802.11 protocol and adjusting the timing parameters. In the case of 802.11, operation is governed by two fundamental PHY-specific values, the Short Inter-frame Space (SIFS) and the Slot time. The SIFS is comprised of the time taken to transit the radio receiver, the time taken to transit the physical layer baseband processing, the time taken to transit the MAC, and the time taken for the radio transceiver to switch ("turnaround") from "receive" to "transmit" modes of operation. The Slot time is comprised of the radio transceiver turnaround time and the MAC transit time again, plus the time taken for the clear-channel assessment mechanism to assess the medium (to determine whether it is clear or occupied) and the time taken for a signal to propagate from a transmitter to a receiver. This last term is crucial in this example: considering a deployment using 802.11 at an extreme range, then even if the transmit power is increased to combat the effects of path-loss over that distance, this propagation time component will now be incorrect and the WLAN will experience significant collisions and errors. Therefore, the protocol generation module modifies the existing protocol defmition to increase the Slot time component.

This modified protocol is then analysed with the following stages to determine if the modifications result in a working protocol, and whether the application requirements will then be met. If the application requirements are not met, then the protocol generator can increase the slot time by a different amount and try again, in an iterative process.

Another example would be a WLAN system where a reconfiguration management process identifies that the WLAN is poorly utilised because there are, say, only two devices in the BSS and they're just shuttling video traffic between each other (so all of the contention mechanisms and back-offs are just wasted overhead). In this case, the protocol could be modified to reduce the back-off contention window to a minimal amount (e.g. 0 slots if the two applications are known to be taking turns to transmit) - (see T. Lewis, N. Fanning, G. Clemo, supra) -and to scale back the DIFS (usually comprising SI1FS-time + 2 x Slot-time) to a much smaller value.

Preferably, the at least one software module is provided to said terminal in the form of a network description of the software module in the Petri-net form.

The step 120 of assessing the at least one software module may further comprise checking (step 121) the syntax of the software module andlor the network description.

Elementary syntax checking of the module definition may be performed e.g. to discard badly formed definitions.

Petri-nets have a well-defined syntax, as discussed above. Syntactic parsing is well known to those skilled in the art, as it is a fundamental part of compiler design. Typical approaches use parse-trees to break down objects expressed in the particular formal

--

grammar; any objects that cannot be broken down according to the rules of the formal grammar (typically expressed in terms of rules in a form such as that available in Backus-Naur form (BNF)) are deemed to be syntactically incorrect and are rejected.

The syntax checking module parses the Petri-net, and, if the module indicates success, then we can be sure that standard rules of a Petri-net (e.g. places are connected to transitions by arcs, and vice versa, but places cannot be connected to places and transitions cannot be connected to transitions) apply. Additionally, in the case of executable higher-order Pefri-nets (such as Reference-nets), the inscription language is in Java, so the Java language elements can be parsed by a standard Java grammar parser too.

Assessment step 120 may further comprise reducing the network description of said software module, as shown in Fig. 5. Net reduction is applied in step 1 24 according to the rules described in Table 1 to reduce the potential state space of the net.

Table I lists the standard rules for net reduction. The net may be further parsed for places and transitions where these rules can be applied without adversely affecting the operation of the net (typically achieved by replicating the inscriptions associated with a place or transition that has been removed in the resulting coalesced place/transition). As with any optimisation technique, this must be approached conservatively, as over-optimisation soon affects function (a classic example being an apocryphal optimisation pass on an encrypted bus device where the optimiser spotted that on one end of a signal line the signals were encrypted, and at the other end they were decrypted, therefore the two modules served no purpose and it optimised them out...).

Referring to Fig. 6, the sequence of Petri-net diagrams shows the progressive application of the FSP, FST, FPP, FPT, ESP and EST rules respectively.

These reduction rules are applied in order, working down from the top to the bottom of the original Petri-net (on the left). Having made one pass, the rules can continue to be applied, ultimately arriving at the Petri-net shown in Figure 7.

The step 120 of assessing said software module may further comprise analysing the network description of said software module with respect to at least one criterion.

Preferably qualified verification 128 is performed m step 128, details of which are given below. As a result of this process, a degree of conformance in the venfication process is then obtained with respect to the at least one criterion. Preferably the network description of said software module is analysed in accordance with, for example, invariant analysis; load analysis; and/or state-space exploration. Safety, liveness, reachability and boundedness are examples of suitable criteria for the analysis.

The qualified verification process 128 gives a qualitative indication as to the degree of confidence in the module given the amount of verification performed. Referring to Fig. 14, this is achieved firstly by determining the available resources 301 for this verification activity -this may be in terms of the time available to perform the verification (example: if an urgent reconfiguration is required, as a result of an impending loss of service, for example), processing or memory capabilities of the device (some verification approaches could be too time-consuming to perform), or some similar constraint. Each verification activity 302 has an associated cost, which can be compared 303 with the available resources 301 to determine whether the activity can be performed. At the end of the analysis phase, the test results may be combined using a weighted sum approach 304, producing the estimation of the confidence in the module.

This summation may be supported using fuzzy logic approaches, where each verification activity has upper and lower bounds of confidence, and the summation may produce the intersection of the confidence ranges of the tests performed. This result may be used in step 130 to determine if the assessment of the software module with respect to the criterion or criteria has been satisfactory.

Invariant analysis 125, as described above, will identify S-and T-invariants applicable to the module. A crucial application of T-invariants in this instance is as follows. Fig. 8 is a flow chart showing the steps of the T-invariant delay verification. The arcs joining places and transitions in a timed Petri-net have timings associated with them. The T-invariant identifies a repeatable sequence of steps back to a given state; in this case, the "idle" state (or equivalent). Key path(s) of interest can be marked and identified in the protocol module definition (by noting the places and transitions involved). By identifying a key path of interest 202 along with the T-invariant 201 this path can be determined to be repeatable, deadlock free and hence reliable. The next stage of this analysis sums the timings on each arc in the path 203. This result is then compared against the QoS delay requirements 204, and a verification decision is reached.

To illustrate this, consider the simplified protocol module shown in Fig. 9, depicting a diagram of an example protocol module in Petri-net format. The module implements some of the Medium Access Control (MAC) functionality required for an IEEE 802.11 wireless local area network (WLAN) system (with some functionality removed, such as retries and back-offs, for clarity) using the Distributed Control Function (DCF).

To briefly explain the operation of this module, first consider packet transmission following the highlighted path in Fig. 10 which shows a Petri-net representation of the example protocol module illustrating key path 1: if the module is in the "idle" state and a packet is in the "pending_queue" then a clear-channel-assessment operation (to determine whether the medium is busy or not) is initiated. Once the medium is clear, the next transition is allowed to occur after a period of "DIFS" (DCF Inter-Frame Space), and the next after a random number of slots within the Contention Window (CW). The transmission of data is then initiated, and this module only allowed to return to idle once the data has been fully transmitted (a Physical Layer Convergence Protocol, PLCP, method is made available to the MAC to ascertain how long transmission will take for a given size of data packet).

Correspondingly, consider the behaviour at the destination station following the second highlighted path in Fig. 11, which represents a Petri-net illustrating key path 2 of the example protocol module: the indication of an incoming packet addressed to it is made by the "rx" event on the first transition making the net leave the idle state. Assuming the received packet is indeed a data packet (to prevent the acknowledgment of acknowledgements ad infinitum) then after a period of SIFS (Short Inter-Frame Space) a short acknowledgment is sent back to the original source.

These two paths are the key paths of interest here for the simple case of transmitting a packet with a certain delay requirement from one station to another.

Net reduction (removal of extraneous states and fusion of serial transitions) whilst retaining the crucial timing information for each constituent arc and transition results iii the greatly simplified net depicted in Fig. 12, showing a flow chart illustrating the example protocol module after reduction. T-invariants for this station are: rol ii 1 I, landi [0] OJ [1 from an initial marking M0 of [1]. The first T-invanant [0 0]T can be discounted as that corresponds to a return to the initial marking through not firing the net at all, which will clearly not satisf' any data transmission requirement and can be discounted automatically as a zero-term. The second sequence corresponds to a data transmission, and the third data reception and acknowledgment transmission.

The delay-time for the transmission of a data packet then is (as would be expected), DIFS CW+Data-duration (Fig. 10). To consider the delay until the source can be sure that the packet has been delivered, the acknowledgment path of SIFS+Ack-duration must also be considered (Fig. 11). The exact values of DIFS and SJFS are determined by the particular physical layer (PHY) in use (e.g. 802.1 lb's values are different to those for 802.11 a); the CW value is a variable, but within lower and upper bounds determined by the random number generator (and, if back-offs are considered' within this phase, by the loading of the network); the data duration is decided by both the PHY (i.e. the data transmission rate for the current P}{Y and the current mode within that PHY) and the application (the size of the frame); the acceptable delay is indicated by the application. All of these values are known either from the PHY or from the Q0S requirements of the application, allowing the station to determine a pass or fail for the verification test under the current conditions.

The more variable part of the delay analysis requires information on processing times at each station, and are greatly influenced by network load (numbers of contending terminals and numbers of packets being queued and transmitted). Stations can determine their local traffic generation rates and processing capabilities, which gives their contribution to the delay equation; in a centralised system the central coordinator knows the number of associated nodes and their traffic requirements, whereas in a distributed system this can be estimated from the number of collisions and failed contention attempts locally. The load is proportional to the Local Packet Generation Rate, the Global Packet Generation Rate and the Processing Delay of the station.

In more detail, the device models the entire medium as a queueing system. Assuming multiple queues in the MAC for service differentiation, a general system can be modelled as parallel M/M/l queueing systems (using Kendal Notation there to indicate a queueing system comprised of a emoryIess / Poisson arrival rate, a memoryless / Poisson service rate, and a single server).

Fig. 13 is a representation of a MAC queuing system. In the case of a pure TDMA medium access scheme, this is more accurately modelled as an MID/I system (with deterministic service time) where the deterministic service time is governed by the cycle time of the TDMA frame (i.e. how often this station's TDMA slot comes around). Such a system is well known and has recognised results, such as an expression for the delay experienced by a packet of D=Trl+ M [ 2(1-S)) where D is the packet delay, T the time taken to transmit a packet, M the number of users (which can be estimated by the station as a worst case from the number of collisions, or in the case of some protocols, such as WiMedia and pure TDMA, is explicitly known by all) and S the throughput. FDMA and CDMA systems have similar results, and all systems can be approximated from these forms.

Hence the load analysis module is able to analyse the expected performance of the protocol module with respect to the current state of the medium (i.e. how congested it is, a key factor).

State space exploration (step 127) can be conducted with matrix manipulation. Fig. 15 is a listing of program code for generation a reachability graph for state-space exploration.

This code was developed using version 7.1.9.246, release R14, service pack 3 of MATLABTM from The Mathworks Inc. That example, however, results in a graphical output not particularly amenable to automated analysis. The reachability graph obtained can then be further analysed with graph-theory techniques to identify cyclic paths in the graph (indicating unbounded behaviour); any leaf-nodes can be identified as termination points in the behaviour of the net.

With respect to delay analysis, the idea of this particular verification technique is that a candidate module needs to be analysed to determine whether the delay requirements of the current traffic flows can be met. The end-to-end delay (MAC SAP to MAC SAP) can be broken down into two main components. The first is the fixed absolute minimal transit time possible with the MAC and PHY in question -this can be determined in step 125 through invariant analysis and summation of transition-tinungs. The second component is load dependent (number of stations competing for resources, amount of traffic being generated) and this is detennined separately in step 126 for the purposes of this explanation.

After verification, the verification results for said software module may be shared with other terminals (peers) in the network to share and confirm these findings. Additional verification information that other devices may have been able to perform, that this device could not, may be added to the results obtained by analysis in step 128.

The resulting degree of confidence in the verification process and hence the protocol itself, from the fuzzy verification process in step 128, may be shared amongst peers in the network, if appropriate. This may confer two advantages. Firstly, it may provide a second opinion to the verification process, and as verification should be independent this is an advantage. Secondly, some devices may be more resource constrained than others, so by pooling resources a federation of devices may be able to perform more tests on a protocol than one device on its own could.

In the most explicit approach, the entire protocol module may be sent to the peer devices, along with a report of the tests performed and the results. Alternatively, a pre-arranged and unique identifier (UID in the example XML below) may be associated with the protocol in question and the protocol therefore referred to indirectly: the only benefit to this is that it saves the bandwidth and power of having to send the entire protocol as an accompaniment to the test results.

A typical test report could be based on an XML definition, as this example shows: <protocol-test-results> <protocol type=80211e UID=72523523905> <syntax> <test result = pass> <pnml version = 1.2> // In case there are different syntax definitions...

<I syntax> <state-space-exploration> <test result = partial pass> <state depth explored = 50> <early termination true> <deadlock = false> <dead states = false> <resources upper limit = 3> </state-space-exploration> <invariant -analysis> <test result = pass> <deadlock = false> <etc. .> </p-invariant-analysis> <etc. ...> </protocol-test -results> These XML test reports could also be sent back to a terminal with updated results (e.g. STAI sends protocol and XML to STA2; STA2 replies with an updated, or different, piece of XML giving its results).

Once the protocol has been subjected to this battery of tests, and passed a perquisite threshold of confidence (examples here would be that an emergency/dire-need reconfiguration, such as illustrated in Example 2 below could perhaps require a lower threshold if the coverage was dropping off particularly rapidly, as the station could be pressed for time and just need something quick-and-dirty to maintain service, dealing with less important criteria like QoS support later), the protocol must then be deployed as shown with reference to step 140 of Fig. 5. A modular architecture with encapsulating bridging functions between different architectural blocks may be employed such that alternative protocol modules may be be dynamically loaded into place. Advantageously, the protocol being replaced would be held on hot-standby in case the system has to revert to it for some reason; in any case, a station would preferably retain locally as many protocols as non-volatile memory reasonable allows, as users typically follow repetitive patterns of usage and it would be impractical to have to re-download and re-verify the same two protocols frequently.

In the event of a protocol failing to pass the verification tests, there are a number of options. Firstly, if the protocol were locally generated, and the failure is something that the protocol generator is capable of fixing, then the protocol could preferably be returned to that stage with appropriate feedback for iterative improvement. Secondly, if the protocol has been downloaded and a network connection still exists, then an XML report of the failure reasons should preferably be returned to the provider and an alternative protocol obtained. If no alternative or fixed protocols are available, then the station may attempt cycling through any previously installed protocols that it may have in non-volatile memory. If no suitable protocol can be identified, the terminal will have to either struggle on with the current mode or just lose service completely.

Optionally, more than one software module may be provided to the terminal for assessment. The software modules may then be assessed individually, and after satisfactory assessment, the one software module may be selected for deployment which best meets the selected cnterion or criteria.

Moreover, a computer program product comprises data processing device program code for performing the method according of the present invention when said program is run on a data processing device.

The computer program may be provided in the form of a computer-readable medium comprising computer-executable instructions to configure a configurable terminal to operate in accordance with the method of the present invention.

Additionally, a configurable terminal comprises means for providing at least one software module to said configurable terminal. The terminal has means for assessing said at least one software module in said configurable terminal prior to deployment.

means for determinmg in said configurable terminal whether the assessment of said at least one software module is satisfactory; andmeans for deploying one of said the at least one software modules in said configurable terminal after satisfactory assessment of said at least one software module,.

The configurable terminal may further comprise means for operating in accordance with the method according of the present invention.

The configurable terminal may preferably be a telecommunications terminal, such as a mobile telephone, a personal digital assistant (PDA) or a personal computer.

Currently, terminal manufacturers have to achieve type-approval and self-certification for their devices: when they start allowing third-party applications/protocols to assume control of their transceiver hardware they then must have means to verify their performance, or manufacturers will find themselves liable for interoperability issues, taking public cellular networks down (example: a badly defined GSM stack starts sliding its transmit slot into the next slot and taking out another user's link) and even perhaps health and safety issues. If the tests according to the present invention were not run, then the protocol could be incomplete or just plain buggy, resulting in the station becoming inoperable through deadlock or memory leaks; failing that, the applications would be unable to operate satisfactorily.

In order to fully appreciate the technical effect of present invention on the terminal device, let us consider as a first example a user having travelled from one country to another, and having obtained a plug-in SD (memory) card containing a localised PDC (personal digital cellular) protocol stack for his reconfigurable phone.

Upon detecting the insertion of a new memory card in the phone, and, on inspection, determining that the card contains a new protocol stack for installation defined preferably in PNML format, the security software wishes to run certain safety checks on the new modules. Alternatively, the protocol may arrive as an executable file, but is accompanied by a PNIvIL description of the protocol. There is then a requirement for a demonstrably strong link between the executable and the PNML (i.e. does the PNML truly represent what is in the.exe).

As a very first level of defence, of course, the modules are checked for viruses and the signatures of the suppliers are verified. Having ascertained that the module is relatively benign and comes from the supplier that it purports to come from, the next stage of analysis is that described by the present invention, which can be further broken down into two phases: safety and utility.

Safety is "first, do no harm", which has been partially addressed by the antivirus checks etc. already described. Further to this, the modules shown in Figure 5 are then invoked: the protocol is syntactically parsed for correctness. It is then reduced through application of the reduction rules where needed for the subsequent analysis. This stage could be pre-processed and performed off-line, with the reduced version supplied as part of the package, Eventually the protocol is subjected to the verification tests indicated in Figure 14 -this, for example, includes obtaining the invariants to determine whether the protocol definition is deadlock-free.

The "Utility" phase is then to match this supplied protocol against some requirements; this is discussed in more detail in the second and third examples below.

The downloaded protocol module, rather than being installed on trust, is analysed to detect deadlock, livelock and any unbounded resource consumption (amongst others).

In a conventional system, there is a risk that the protocol will have one of those undesirable qualities. If it dead-or live-locks then thesystem will exhibit zero throughput and would not release the transmission medium, thus also preventing others from using it. If the protocol consumes unlimited resources (e.g. by entering an unending loop for example) then the conventional device will finally run out of memory and "lock up" (offering symptoms similar to that of the deadllive lock). Typically, the conventional device will reset, as in most cases devices have a watchdog mechanism on the device that will reset if not kicked regularly.

It will be appreciated that according to the method and device described in the present invention, such deadlock or livelock will not occur, thereby clearly resulting in improved throughput and robustness.

In a second example, let us consider a user is currently using his PDA to participate in a video telephony call as he changes locations, but cellular coverage at the new location being poor, the only service provider available being e.g. WLAN.

The video telephony application has a specific requirement for end-to-end delay and jitter. As the cellular coverage drops, the application must determine whether to continue the video call using the WLAN stack on the device, or to advise the user that the call must drop to audio only (or perhaps drop entirely). The "safety" level checks in this scenario have already been performed, so the delay verification process according to the present invetion is invoked to determine which option is available.

For a deeper understanding of the invention it is beneficial to consider the consequences of what may well happen were this invention not present. If the WLAN stack were not able to offer sufficient support for the Q0S requirements of the video application then it may be able to work sporadically, but many packets would be dropped or corrupted, resulting in a very poor user experience. In such a situation, the present invention would allow to determine that the available WLAN is capable to support voice-only calls, which would have been far more acceptable to the user.

Considering as a third and final example a user having arrived in an area of poor coverage, his temiinal is currently out of range of any coverage of any modes installed on the phone, but is able to detect a distant cellular base-station.

It may then be possible to obtain service from the remote base-station by adjusting timings in the protocol (which the terminal already has) to allow for the extended round-trip delay at such extreme range. An onboard protocol evolution engine (see Lewis, T.; Fanning, N.; Clemo, G., supra) maybe invoked for generating a suitable new protocol. Alternatively, in a simpler approach the terminal may simply modify the existing protocol by extending the timings to cater for the distance. Referring to Fig. 8 again, in this instance, the fundamental structure of the net may be tmsted, but the key question is whether the delay is tolerable.

The present invention gives a manufacturer the confidence to use a relatively novel technique such as genetic programming, safe in the knowledge that whatever the technique comes up with will be validated. Potentially this invention could also be used as the utility function to grade and terminate the evolution process for example In this case, without the invention, then either you can't evolve a protocol at all, or you evolve/modify one and run the risk of deadlock and unbounded resources (leading to lock-ups, low throughput & utilisation, etc).

The present invention can also be applied to general verification of software modules or patches too, for example PCs or laptops downloading software for general application USC (all computer programs should be free of deadlock, not just communications protocols).

By being able to evaluate protocols on-line, this has the added business benefit of reducing the amount of time-consuming testing required by the developers.

Whilst the above description concentrates on re-configurable devices, this invention may also be applied in other systems such as wired PCs/tenninals that download modules, and these modules need not be only communications onentated.

The method according to the invention may also be used to test and verify multiple protocols, i.e. two (or more) candidate protocols could be downloaded, then tested, and whichever one scores the highest or meets the QoS-requirements best, is chosen and deployed.

This invention relates to an apparatus and a method to support the downloadlgeneration, reduction, analysis, dissemination and deployment of a module, as depicted in Fig. 2.

Additionally, a "degree of conformance" may be offered, where the verification process indicates its confidence in the result, either because there may only be a limited number of tests available, or because resource-limitations may have restricted the number of tests that can be performed. Finally, optional techniques for determining whether specific delay requirements can be met have been described.

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 (20)

1. A method of deploying a software module in a configurable terminal, said method comprising the steps of: providing (110) at least one software module to said configurable terminal; assessing (120) said at least one software module in said configurable terminal prior to deployment; determining (130) in said configurable tenninal whether the assessment of said at least one software module is satisfactory; and upon satisfactory assessment of said at least one software module, deploying (140) said software module in said configurable terminal.

2. The method according to claim 1, wherein the step of assessing (2) said software module further comprises analysing the network description of said software module with respect to at least one criterion.

3. The method according to claim 2, wherein the step of assessing (2) said software module further comprises determining a degree of conformance for said software module with respect to the at least one criterion.

4 The method according to claim 2 or 3, wherein the step of analysing the network description of said software module comprises at least one of the following: invariant analysis; load analysis; state- space exploration, or delay analysis.

5. The method according to any one of claims 2 to 4, wherein the step of analysing (120) said soft-ware module further comprises determining a degree of confidence for said software module with respect to the at least one criterion.

6. The method according any one of claims 2 to 5, wherein the at least one criterion is selected from the group comprising safety, liveness, reachability boundedness, and delay times.

7. The method according to any of the preceding claims, wherein the step of providing said at least one software module to said terminal comprises receiving at least a network description of said at least one software module from a source external to said terminal (101); or generating at least a network description of said at least one software module internally within said terminal (102).

8. The method according to claim 7, wherein the step of providing said software module to said terminal further comprises providing said network description of the software module in the Petri- net form.

9. The method according to any one of the preceding claims, wherein the step of venfying said software module further compnses checking (121) the syntax of the

software module andlor the network description.

10. The method according to any one of claims 7 to 9, wherein the step of verifying said software module further compnses reducing the network description of said software module.

11. The method according any one of the preceding claims, wherein after verification, the verification results for said software module are shared with other terminals.

12. The method according any one of the preceding claims, wherein after verification, the verification results for said software module are compared with those of other terminals.

13. The method according any one of the preceding claims, wherein a plurality of software modules are provided, the plurality of software modules being assessed individually, and after satisfactory assessment, selecting the software module for deployment which best meets the selected criterion or criteria

14. The method according to any of the preceding claims, wherein the software module is a comrnumcations protocol or enhancement

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

16. A computer-readable medium comprising computer-executable instructions to configure a configurable terminal to operate in accordance with any one of claim 1 to 14.

17. A configurable terminal comprising: means for providing at least one software module to said configurable terminal; means for assessing said at least one software module in said configurable terminal prior to deployment; means for determining in said configurable terminal whether the assessment of said at least one software module is satisfactory; and means for deploying one of said the at least one software modules in said configurable terminal upon satisfactory assessment of said at least one software module,.

18. The configurable terminal of claim 17 further comprising means for operating in accordance with any one of claims 1 to 14.

19. The device of claim 18, wherein the device is a telecommunications terminal.

20. The device of claim 18, wherein the device is a personal computer.