An Extension for MSC-2000 and its Application

1. An Extension for MSC-2000 and its Application Tong Zheng and Ferhat Khendek Department of Electrical and Computer Engineering Concordia University 1455 de Maisonneuve W., Montreal (P.Q.) Canada H3G 1M8 E-mail: {zhengt, khendek}@ece.concordia.ca Abstract. Message Sequence Charts (MSC) is a standard language widely used in telecommunication software engineering. The latest MSC standard, MSC-2000, includes new features such as time and data. In this paper, we propose a new construct called instance delay as an extension for timed MSC to enhance further its expressiveness. We define formally the semantics of the extension based on a partial order semantics of timed MSC. We demonstrate through an application the need for this extension. 1 Introduction Message Sequence Charts (MSC) [9] is a graphical and textual specification language developed by ITU-T. Since its first standardization, many features have been added to the language to enhance its expressiveness. Now it is widely used in telecommunication software engineering for specifying behavioral scenarios. It can be used to describe use cases and scenarios, to validate the behavior of distributed systems, or to specify test cases [15]. Recently, the new MSC standard, MSC-2000 [9], has added more features such as time constraints and data. With these new concepts, MSC can be used to specify quantified timing requirements. In this paper, we investigate further extensions to MSC for specifying timing requirements for systems with repeated behaviors. To specify a repeated scenario, we may need to specify how long the scenario takes and the interval between the repetitions. The MSC standard defines the relative time constraints between two different events, but it can not specify the delay between two occurrences of the same event. In high level MSCs (HMSC), the time offset can be used to specify the delay of a MSC, but it has some limitations as discussed in Section 3. Therefore we propose a new construct called instance delay. While the standard time offset is an offset to all the absolute time values in a MSC, an instance delay is only for one instance. Using this construct, we can specify the periodicity of instances. The periodicity of events can be specified implicitly with this construct. We define formally the semantics of instance delay and show its usage in the specification of the Radio Resource Control (RRC) protocol [1]. This paper is organized as follows. In Section 2, we briefly review the time concept in MSC-2000. In Section 3, we discuss the need for the extension. Then, in Section 4, we define formally its semantics based on our partial order semantics of timed MSC.

An application of the extension is given in Section 5 with the RRC protocol. In Section 6, we discuss related work, before we conclude in Section 7. 2 MSC and Time Constructs MSCs [9] consist of plain MSCs and HMSCs. In a plain MSC, the behaviors of processes are described explicitly. A process is represented by a vertical axis and called an instance. Messages between processes are shown as arrows connecting the axes. The communication is one-to-one and asynchronous. There is no explicit information about the communication media. Besides message exchanges, a plain MSC may also contain internal actions, timer events, conditions, and some structures, such as references, coregions. In this paper, we do not consider structures. A plain MSC without structures is referred to a basic MSC (bmsc). A bmsc specifies only a partial behavior or one scenario of a system. For a more complete specification of the system, different scenarios have to be combined. HMSCs are used to describe graphically the composition of MSCs. A HMSC is a directed graph. It contains a start node, end nodes and MSC references. A reference may refer to a bmsc or another HMSC. 2. MSC T offset 2 i j @[3, 4] a m [1, 2] @[4, 6] b Fig. 1. Time Constraints in MSC Time constraints are introduced in MSC-2000 so that real-time systems can be described using quantified time. In the MSC standard, time progress is the same for all instances in a MSC. All events are instantaneous. They do not consume time. A time constraint can be used to specify the delay between two events (relative time constraint), or the occurrence time of an event (absolute time constraint). A time constraint is an interval of time with upper and lower bounds. For example, in Figure 1, the time constraint between two events a and b in the MSC T is at least 1 second and at most 2 seconds. The time unit is omitted in the figure. If the time constraint is exactly 2 seconds, we can specify it as [2]. To specify that event a occurs between the third and the fourth second, we write @[3, 4] as shown in Figure 1. Similarly, if an event occurs at exactly the third second, the time constraint can be written as @[3].

A MSC can be assigned a time offset as shown in Figure 1. According to the standard [9], it is an offset to all absolute time values within a MSC. So the occurrence time of event a in Figure 1 is actually [5, 6], and event b occurs in the interval [6, 8]. 3 Instance Delay To introduce the concept of instance delay, we first look at an example in a client-server system. A server in the system has to respond continuously to the requests from clients. We require that the server has to respond between 1 and 2 seconds after receiving a request. We also require that a client has to wait 2 seconds to send another request after receiving the response for the previous request. In a bmsc, the first requirement can be specified as a time constraint between two events, as shown in MSC Transaction in Figure 2. For the second requirement, however, we can not specify the delay between a response and the next request after it in a bmsc. 3. msc Transaction Client Server [1,2] Transaction a d request b response [1, 2] c Fig. 2. Time constraints on events and MSC The second requirement actually defines a delay between the executions of MSCs. If we consider this at the HMSC level, only the whole execution time of a MSC can be specified, such as the constraint on the MSC Transaction in Figure 2. We can not specify the delay between the first and the second execution of the MSC Transaction in the loop. We considered the usage of the time offset as defined in the standard to specify the delay between two MSCs indirectly. As mentioned in the last section, a time offset is an offset to all absolute time values within a MSC. Since the scope of a time offset is the whole MSC, it can not be used to specify some more complex timing requirements. For example, if another client is required to wait 3 seconds instead of 2 seconds to send a new request after receiving a response, the time offset cannot express the timing requirement for the two clients in a MSC, because the clients need different offsets. To solve this problem, we introduce a new concept called instance delay, which defines the delay between two MSCs in the manner of weak sequence. By the weak sequencing operation, two MSCs are connected instance by instance. An instance delay affects the occurrence time of events only at one instance, instead of the whole MSC. For example, in Figure 2, if we define the instance delay is 2 seconds for the instance Client in the MSC Transaction, and assume the Client receives the first

response at time t 1, then it can send the second request at time t 1 + 2. If it receives the second response at time t 2, it can send the third request at time t 2 + 2, and so on. If the event of sending a request itself is constrained by an absolute time constraint that is a range of time values, then all the occurrences of sending the request should be within that range. We define the syntax of instance delays as follows: <instance delay list> ::= instance delay <instance delay> <instance delay> ::= <instance name> <time range> [, <instance delay>] The <time range> is a range in the time domain with lower and upper bounds. Similar to the time constraints, if an instance delay is between 1 and 2 seconds, we write it as [1, 2]. If it is exactly 2 seconds, we write it as [2]. We state instance delays after the MSC name in a bmsc. If the instance delay of an instance is not specified, it can be any time value. Using an instance delay, the two requirements mentioned above can be specified as shown in Figure 3. 4. msc Transaction instance delay Client [2] Client Server Transaction a d request b response [1, 2] c Fig. 3. Usage of instance delays Since instance delays define the delay between two MSCs, they affect the occurrence time of events in the second and later execution of the MSC only. When the MSC Transaction in Figure 3 is executed for the first time, events a and d are not affected by the instance delay. Later on, their occurrences will be delayed. This is different from the time offset, which changes the occurrence time of events even in the first execution of the MSC. 4 Semantics of Instance Delays We defined the syntax of instance delay and described its meaning informally in the previous section. To verify or validate a MSC specification with instance delays, we need to define its semantics in a formal framework. In this section, we first introduce our semantics for timed MSC as defined in [17], then we extend our semantics to handle instance delays. Unlike our previous work [17], we only consider bmscs and HMSCs in this paper. So the semantics is simplified here.

4.1 Semantics of bmsc We define the semantics of timed MSC based on timed labelled partially ordered sets (lposet) [17]. Assume Time is the time domain. P(Time) is a power set of Time, that is, P(Time) is a set of all the subsets of Time. A timed lposet is a tuple (A, E,,l,D, T), in which A is a set of labels. E is a set of events. E E is a partial order on E. l : E A is a labeling function, which associates an event to a label. D : E P(Time) is an absolute delay function, which defines a range within which an event could occur, and T : E E P(Time) is a relative delay function, which defines possible delays between two events. The set of labels A actually defines the meaning of events. An event could be message output, message input, internal action, start timer, stop timer,ortimeout. The labels for these events are defined as follows: send(i, j, m): instance i sends a message m to instance j, receive(i, j, m): instance i receives a message m from instance j, action(i, a): instance i performs an internal action a, starttimer(i, T, n): instance i sets a timer T with a time-out period n, stoptimer(i, T): instance i cancels the timer T, and timeout(i, T): the timer T in instance i expires. We associate every event in a MSC with a unique label. If an instance sends a message m twice to another instance, we relabel them as m1 and m2. In the MSC standard, a message output or message input event can be associated with a message instance name to ensure that the textual notation corresponds to the graphical notation. So it is reasonable to consider that messages contained in a MSC can always be differentiated. Similarly, a timer T can also be associated with a timer instance name as defined in the standard. We also consider that timers can be differentiated. We say that an event e is a minimal element in E according to when there is no event e E such that e e and e e. An event e is a maximal element in E according to when there is no event e E such that e e and e e. Using φ to represent the empty set, we define a lposet ε =(A, E,,l,D, T) as an identity lposet in which A, E,, l, D and T are φ. In a MSC, if absolute or relative time constraints are not specified explicitly for some events, we consider them as [0, ). The semantics of a bmsc is defined as a lposet, which contains all the events in the bmsc and specifies the partial order between them. The orders are determined by message exchanges and instance axes. Along each instance axis, events are ordered from top to bottom. Between different instances, a message output event must occur before the corresponding message input event. For example, the semantics of the MSC Transaction in Figure 2 is a lposet (A, E,, l, D, T) where: 5.

A: {send(client, Server, request), receive(server, Client, request), send(server, Client, response), receive(client, Server, response)} E: {a, b, c, d} : {(a, b) (c, d) (b, c) (a, d)} +. (the reflexive pairs such as (a, a), (b, b)... are omitted.) l: l(a) = send(client, Server, request), l(b) = receive(server, Client, request), l(c) = send(server, Client, response), l(d) = receive(client, Server, response). D: the absolute time constraints of all the events are not specified in the MSC. We consider them as [0, ). T: T(b, c) = [1, 2]. The relative time constraints between other events are not specified. We consider them as [0, ) also. 4.2 Semantics of HMSC To define the semantics of HMSC, we define sequential, alternative and parallel compositions on lposets first. For two lposets p = (A p,e p, p,l p,d p, T p ) and q = (A q, E q, q,l q,d q, T q ), in which E p and E q are disjoint, p φand q φ, their sequential composition ( ) is defined as: p q = (A p A q, E p E q, ( p q ) +, l p l q, D p D q, T p T q T), in which = i (E p i E q i ), E p i and E q i are the sets of events that occur at instance i, E p i E p, E q i E q T = {((e, e ), [n]) (e, e ) E p E q l p (e)=starttimer(i, Ti, n) l q (e )=timeout(i, Ti), or ((e, e ), (0, n)) (e, e ) E p E q l p (e)=starttimer(i, Ti, n) l q (e )=stoptimer(i, Ti) )} Informally, in the sequential composition, orders and time constraints in the lposets are preserved. New orders between events in the same process are added. Relative time constraints are implicit between timer events. If an event a corresponds to the starting of a timer with a time-out period n, and another event b corresponds to its expiration, a relative time constraint between them should be [n]. If event b corresponds to its termination, then event b occurs before the expiration. A relative time constraint between a and b should be (0, n). When composing sequentially a lposet p with itself, we need to relabel the events in the second occurrence of p to make them different from the events in the first occurrence. However, the time constraints are not changed. So all the occurrences of an event are constrained by the same time constraint. The alternative composition (#) of two lposets is a set of lposets: p # q = {p, q} = {(A p, E p, p, l p, D p, T p ), (A q, E q, q, l q, D q, T q )}. The parallel composition ( ) is a lposet: p q = (A p A q, E p E q, p q, l p l q, D p D q, T p T q ). For two sets of lposets P = {p 1,p 2,... p n }andq={q 1,q 2,... q k }, we define their sequential ( ), alternative (#) and parallel ( ) compositions as follows: P Q = {p i q j p i P, q j Q, 1 i n, 1 j k}, P # Q = P Q, 6.

P Q = {p i q j p i P, q j Q, 1 i n, 1 j k}. In a HMSC, MSC references are connected by the operation of sequence (seq), alternation (alt) or parallel (par). A MSC reference may refer to a bmsc or another HMSC. Since a bmsc is represented by a lposet, operations on bmscs can be mapped to compositions on lposets. Operations on HMSCs can be mapped to compositions on sets of lposets. Using M to represent the mapping of a bmsc (HMSC) to a lposet (a set of lposets), we have the following mappings for the operations on two MSCs A and B: M[A seq B] = M[A] M[B], M[A alt B] = M[A] # M[B], M[A par B] = M[A] M[B]. Moreover, a HMSC can specify the repeated behavior of a system by cycles. A cycle in HMSC can be translated to a loop expression. Using L to represent a bmsc, the notation loop <n, m> L means that L will be executed at least n times and at most m times. However, if some events in L are constrained by absolute time constraints, the number of times that M can be executed may be changed, because all the occurrences of an event have to satisfy its absolute time constraint according to the semantics of sequential composition. 7. MSC M i j MSC L i j @[1, 3] a m1 @[1, 3] a b@[2, 5] m1 b@[5] Fig. 4. MSC with absolute time constraints For example, let us consider a loop expression loop <inf> M, in which M is shown in Figure 4. All the occurrences of events a and b should satisfy their absolute time constraints (@[1, 3] and @[2, 5] respectively). If we choose non-negative real numbers as the time domain, then MSC M can be executed infinite times. However, if we choose non-negative integers as the time domain, event a and b can only be executed 3 times. In another example, we have a loop expression loop <2, 3> L, in which L is shown in Figure 4. In MSC L, event b is constrained by an absolute time constraint. It specifies event b can only occur at that absolute time point (the fifth second). So event b can only occur once. It results in that MSC L can only be executed once, although the loop boundary is <2, 3>. In these examples, the time constraints refine the loop boundary. It can terminate the loop before the loop boundary is reached. Without limiting the choices of time domain, the semantics of a loop can be defined as one of the following two sets of lposets:

8. M[loop <i, j> A] = { {M[Am ]}, m < i. {M[A i ], M[A i+1 ],..., M[A m ]}, i m j. Here m represents the maximal number of times that A can be executed without violating the absolute time constraints in A. The loop will terminate when the time constraints can not be satisfied, or the loop boundary is reached. How to determine m is not discussed in this paper. We define M[A 0 ]=ε and M[A k ]=M[A] M[A k-1 ], for k >0. When calculating M[A k ], we need to relabel message events and timer events in MSC A so that they are unique in the iteration. For an infinite loop, the set may contain an infinite number of lposets. With the compositions on lposets and the mapping of operations on MSCs to these compositions, the semantics of a HMSC is defined as a set of timed lposets. For example, using a lposet p to represent the MSC Transaction in Figure 2, the semantics of the HMSC in the same figure is an infinite set {p, p 2, p 3,...}. 4.3 Extending the Semantics for Instance Delays Now we consider the semantics of instance delays. We extend the definition of lposet as (I, A, E,,l,o,D, T), in which I is a set of instances, and o: I P(Time) is a function that associates an instance to a set of time values. In a lposet, we say an event e is the local minimal element in an instance when there is no event e in the same instance such that e e and e e. An event e is the local maximal element in an instance according to when there is no event e in the same instance such that e e and e e. The sequential, alternative and parallel compositions of lposets also need to be extended to take instance delays into account. For two lposets p = (I p,a p,e p, p,l p,o p, D p, T p )andq=(i q,a q,e q, q,l q,o q,d q, T q ), their sequential composition ( ) is defined formally as: p q=(i p I q, A p A q, E p E q,( p q ) +, l p l q, o p, D p D q, T p T q T T ), in which = i (E p i E q i ), E p i E p, E q i E q. E p i and E q i are the sets of events that occur in instance i, E p i E p, E q i E q T = {((e, e ), n) (e, e ) E p E q l p (e)=starttimer(i, Ti, n) l q (e )=timeout(i, Ti), or ((e, e ), (0, n)) (e, e ) E p E q l p (e)=starttimer(i, Ti, n) l q (e )=stoptimer(i, Ti) )}, and T ={((e, f), o q (i)) e E p i and it is the local maximal event in the instance i, f E q i and it is the local minimal event in the instance i, o q (i) is the instance delay of i in q} and T are same as before. T adds the new relative time constraints between the local maximal events in the lposet p and the local minimal events in the lposet q. The alternative composition (#) is a set of lposets: p # q = {p, q} = {(I p, A p, E p, p, l p, o p, D p, T p ), (I q, A q, E q, q, l q, o q, D q, T q )}. The parallel composition ( ) is a lposet: p q = (I p I q, A p A q, E p E q, p q, l p l q, o p o q, D p D q, T p T q ).

The semantics of a bmsc with instance delays is represented by an extended lposet. The semantics of a HMSC is a set of extended lposets. For example, the MSC Transaction in Figure 3 is given by an extended lposet p = (I, A, E,,l,o,D, T), in which E ={a, b, c, d}, T(b, c) = [1, 2], and o(client) = [2]. The semantics of the HMSC in Figure 3 is {p, p 2,p 3,...}. In p 2, for example, E ={a 1,b 1,c 1,d 1,a 2,b 2,c 2,d 2 }, a 1 (a 2 ) and b 1 (b 2 ) correspond to the sending and the reception of the first (second) request message, c 1 (c 2 ) and d 1 (d 2 ) correspond to the sending and the reception of the first (second) response message. T(b 1, c 1 ) = [1, 2], T(b 2, c 2 ) = [1, 2], T(d 1, a 2 ) = [2]. 5 An Application To demonstrate the need and the usage of the extension, we consider the measurement process in the Radio Resource Control (RRC) protocol. In the WCDMA wireless communication network, a User Equipment (UE) keeps measuring the power of radio signals received from Base Stations (BS). On the request of a BS, the measurement result can be sent back to the BS periodically. Specifically, a BS sends a Measurement Control message to indicate how often the UE should report the results. Then the UE sends Measurement Report messages periodically to the BS. Consider there are two kinds of UEs. One needs to report the result every 12 seconds, and another needs to report every 24 seconds. Using instance delays, we specify the measurement process of two UEs with different periods in Figure 5. For the sake of simplicity, we only show the measurement control and report messages. We also add absolute time constraints on the events of receiving the measurement control (@[2]) and sending the measurement report on UE1 and UE2 (@[2, 50] and @[2, 80] respectively). 9. Control msc Control BS UE1 UE2 msc Report instance delay UE1 [12], UE2 [24] BS UE1 UE2 Report a c control @[2] b control @[2] d report f @[2,50] e report h @[2,80] g Fig. 5. Specification of measurement process using instance delays The MSC Control in Figure 5 can be represented by a timed lposet M 1 =(I 1, A 1, E 1, 1, l 1, o 1, D 1, T 1 ) in which I 1 = {BS, UE1, UE2}, A 1 = {send(bs, UE1, control), receive(ue1, BS, control), send(bs, UE2, control), receive(ue2, BS, control)}, E 1 = {a, b, c, d},

l 1 = {(a, send(bs, UE1, control)), (b, receive(ue1, BS, control)), (c, send(bs, UE2, control)), (d, receive(ue2, BS, control))}, 1 = {(a, b), (c, d), (a, c)} +, those reflexive pairs such as (a, a), (b, b) are omitted. o 1 = {(BS, [0, )), (UE1, [0, )), (UE2, [0, ))}, the instance delays are not specified in the MSC, so we consider that they can be any time value. D 1 (b) = [2], D 1 (d) = [2], the absolute time constraint for event a and c are not specified in the MSC, we consider them as [0, ). For the function T 1, all the relative time constraints between events are not specified in the MSC, we consider their default values as [0, ). Similarly, we can use a timed lposet M 2 =(I 2, A 2, E 2, 2, l 2, o 2, D 2, T 2 ) to represent the MSC Report in Figure 5, in which l 2 = {(e, send(ue1, BS, report)), (f, receive(bs, UE1, report)), (g, send(ue2, BS, report)), (h, receive(bs, UE2, report))}, 2 = {(e, f), (g, h), (f, h)} +, those reflexive pairs are omitted. o 2 = {(BS, [0, )), (UE1, [12]), (UE2, [24])}, D 2 (e) = [2, 50], D 2 (g) = [2, 80]. The semantics of the HMSC in Figure 5 can be represented by a set of lposets: {M 1 M 2, M 1 M 2 M 2, M 1 M 2 M 2 M 2,...} In M 1, event b and d are the local maximal elements in UE1 and UE2 respectively. They are constrained by absolute time constraints (@[2]). When we calculate M 1 M 2, the occurrence time of event e (sending a report at UE1) should satisfy its absolute time constraint @[2, 50] and the relative time constraint between e and b, which is [12] defined by the instance delay of UE1. So event e occurs at 14 ([2, 50] [2 + 12] = 14). Similarly, the occurrence time of event g (sending a report at UE2) is [2, 80] [2 + 24] = [26]. For M 1 M 2, event e and g are the local maximal elements in UE1 and UE2 respectively. So when we calculate M 1 M 2 M 2, the occurrence time of the event sending the second measurement report at UE1 will be [2, 50] [14 + 12] = [26], and the occurrence time of the event sending the second measurement report at UE2 will be [2, 80] [26 + 24] = [50]. It is worth to note that when we calculate M 1 M 2 M 2 M 2 M2, the occurrence time of the event sending the fourth report in UE2 will be [2, 80] [74 + 24] = φ. It means that M 2 can only be executed three times. The absolute time constraint actually limits the times that M 2 can be executed. So the semantics of the HMSC in Figure 5 can be represented by a set of three lposets: {M 1 M 2, M 1 M 2 M 2, M 1 M 2 M 2 M 2 }. 6 Related Works Some extensions to MSC-2000 have been reported in several papers [4][5][7]. In [4], the HyperMSC concept is elaborated and enhanced by MSC connectors. The need for broadcast messages and timer tables is discussed in [5]. In the Interval project [7][16], the authors proposed a new symbol to express periodic occurrence of repetitive events. The symbol is associated with an event. 10.

We proposed the instance delay as an extension to MSC-2000. More importantly, we defined formally its semantics based on our denotational semantics for timed MSC. In this semantics, both relative and absolute time constraints defined in MSC-2000 are considered. A bmsc is represented by a timed lposet. A HMSC is represented by a set of timed lposets. If a HMSC contains infinite loops, this set is infinite. It is straightforward to describe the semantics of HMSCs using infinite sets of lposets. However, analysing HMSC specifications with infinite loops is challenging. Different approaches have been proposed to define the semantics of un-timed MSC ([2][6][8][10][11][13][14]). For timed MSC, P. L. Maigat and L. Helouët [12] associate each event and each communication in MSC with a duration. A MSC is transformed to order automata. In MSC-2000, a duration can be specified between any two events, not just between pair of communication events. R. Alur et al. [2] interpreted timed MSC as partial orders with timing functions that map each pair of events in the partial order to a time interval. In their timed MSC, time constraints can only be imposed on pair of events. They do not consider absolute time constraints for events, and only bmscs with sending and reception events are taken into account. Similarly, H. Ben-Abdallah and S. Leue [3] use timing delay intervals and timer events to express timing constraints. A MSC is interpreted as traces that are consistent with the partial order of events. They define a timing assignment that assigns a time stamp to each event in a trace. They do not consider absolute time constraints. 7 Conclusion To specify periodical behaviors more precisely, we introduced instance delays as an extension to MSC-2000. Using this extension, we can specify the delay between two MSCs in a HMSC, and the periodicity can be specified at the instance level. The concept of instance delays is consistent with the weak sequence composition. To define the semantics of this extension, we extended our partial order semantics of timed MSC. With the application to the RRC protocol, we demonstrated the need for this extension. Time constraints in HMSC bring some new challenges. Among them, for instance, the consistency of time constraints is an important one. In this paper, we did not discuss how to determine the number of times a loop can be repeated without violating time constraints of events in the loop. We are currently working on this issue. 11. Acknowledgements. This work has been partially supported by the National Sciences and Engineering Research Council (NSERC) of Canada. We would like to thank reviewers for their helpful comments. References 1. 3GPP, TS 25.331 Radio Resource Control (RRC) Protocol Specification, http:// www.3gpp.org. 2. R. Alur, G. J. Holzmann and D. Peled, An Analyzer for Message Sequence Charts. Proceedings of 2nd International Workshop on Tools and Algorithms for the

construction and Analysis of Systems, TACAS 96, Passau, Germany, March 1996, Lecture Notes in Computer Science, Vol. 1055, pp. 35-48. 3. H. Ben-Abdallah and S. Leue, Expressing and Analyzing Timing Constraints in Message Sequence Chart Specifications, Technical Report 97-04, Department of Electrical and Computer Engineering, University of Waterloo, April 1997. 4. J. Grabowski, P. Graubmann and E. Rudolph, HyperMSCs with Connectors for Advanced Visual System Modelling and Testing, Proceedings of 10th International SDL Forum, LNCS 2078, Copenhagen, Denmark, June 2001. 5. L. Helouët, Distributed System Modeling with Scenarios: The Example of the RMTP2 Protocol, Concordia Prestigious Workshop on Communication Software Engineering, Concordia University, Canada, September 2001. 6. S. Heymer, A Non-Interleaving Semantics for MSC, SAM 98, The 1st Workshop of the SDL Forum Society on SDL and MSC, Berlin, Germany, 1998. 7. D. Hogrefe, B. Koch and H. Neukirchen, Some Implications of MSC, SDL and TTCN Time Extensions for Computer-Aided Test Generation, Proceedings of 10th International SDL Forum, LNCS 2078, Copenhagen, Denmark, June 2001. 8. B. Jonsson and G. Padilla, An Execution Semantics for MSC-2000, Proceedings of 10th International SDL Forum, LNCS 2078, Copenhagen, Denmark, June 2001. 9. ITU-T, Message Sequence Charts, ITU-T Recommendation Z.120, November 1999. 10. J. P. Katoen and L. Lambert, Pomsets for Message Sequence Charts, SAM 98, The 1st Workshop of the SDL Forum Society on SDL and MSC, Berlin, Germany, 1998. 11. P. B. Ladkin and S. Leue, Interpreting Message Flow Graphs, Formal Aspects of Computing, 7(5):473-509, 1995. 12. P. L. Maigat and L. Helouët, A (MAX, +) Approach for Time in Message Sequence Charts, 5th Workshop on Discrete Event Systems, Ghent, Belgium, August, 2000, pp. 83~92. 13. S. Mauw and M. A. Reniers, Operational Semantics for MSC 96, Computer Networks and ISDN Systems, 31(17): 1785-1799, 1999. 14. S. Mauw and M. A. Reniers, High-level Message Sequence Charts, SDL 97: Time for Testing - SDL, MSC and Trends, Evry, France, September 1997. 15. S. Mauw, M. A. Reniers, and T. A. C. Willemse, Message Sequence Charts in the Software Engineering Process, Handbook of Software Engineering and Knowledge Engineering, Vol. 1, pages 437-463, World Scientific Publishing Co., December, 2001. 16. The Interval Project, http://www-interval.imag.fr. 17. T. Zheng, F. Khendek and L. Helouët, A Semantics for Timed MSC, International Workshop on Validation and Implementation of Scenario-based Specifications, Grenoble, France, Electronic Notes in Theoretical Computer Science, Vol. 65, Issue 7, April, 2002. 12.