[Lecture Notes in Computer Science] SDL 2001: Meeting UML Volume 2078 || A General Approach for the...

A General Approach for the Specificationof Real-Time Systems with SDL�

Ralf Munzenberger, Frank Slomka, Matthias Dorfel, and Richard Hofmann

University of Erlangen-NurembergDepartment of Computer Networks and Communication Systems

Martensstr. 3, 91058 Erlangen, Germany{rfmuenze, slomka, doerfel, rhofmann}@informatik.uni-erlangen.de

Abstract. In contrast to protocols of the network or transport layer theprotocols for medium access have to consider the timing behavior of thecommunication medium. Although SDL is a widely used language forthe specification of communication systems, in most cases time criticalparts are not considered. In this paper, a design pattern is discussed thatallows the specification of time critical functionality sucg as multiplex-ers or Quality-of-Service (QoS) schedulers. In many applications suchservices are running in a synchronous manner with the communicationmedium. A notation for timing aspects is needed for the specification ofthis behavior which itself is only possible in a sensible way with a formalmodel of time. Clocks are used to define the term real-time in a formalway, leading to the specification of timing constraints, for example send-ing data packets in deterministic time intervals within a communicationsystem. In a case study from the mobile communication area, the designpattern was used to specify the MAC-Layer including time critical parts.

1 Introduction

The specification of large, distributed communication systems is a well knownapplication area of the specification and description language (SDL). SDL ismainly designed for the development of communication protocols. Many lan-guage constructs support the requirements needed by protocol development,such as non-deterministic choices, sending and receiving signals asynchronouslyand the specification of protocol timers.

Nearly all protocols specified with SDL are at layer 3 of the OSI referencemodel or above. Layer 2 functionality such as medium access is often imple-mented in a mixed hardware/ software architecture to achieve the performance� This work has been funded by the Deutsche Forschungsgemeinschaft (DFG) under

grant HE 1408/4-3 as a part of the program Rapid Prototyping of Embedded Con-trol Systems with Real-Time Constraints. We thank Lennard Kerber for his criticalcomments and ideas; Gunther Peitz and Georg Sandhaus of Tenovis for their supportduring the development of the DECT MAC-Layer and providing the Tenovis DECTtransceiver modules; additionally Kai Lampka for his work on the specification ofthe DECT MAC-Layer.

R. Reed and J. Reed (Eds.): SDL 2001, LNCS 2078, pp. 203–222, 2001.c© Springer-Verlag Berlin Heidelberg 2001

204 R. Munzenberger et al.

goals. The separate consideration of hardware and software has led to the useof different design methodologies for the two parts. Especially, the separatedconsideration often leads to errors during the integration phase. To improve thedesign process, an integrated specification language is needed where all aspectscan be formulated in an adequate way. Because of the wide usage of SDL atthe system level, it is desirable to use SDL also for the hardware/software partsof the system. To reach this goal, SDL needs a new time model which has toenable the definition of clocks, the specification of timing constraints and thespecification of synchronous behavior.

The current time model of SDL allows the use of timers as a way of defininga timing behavior. Unfortunately the value given to a timer has no unit. Thisleads to additional informal specifications given in comments or in separate doc-uments to determine which unit and resolution to use for the respective timers.For formal verification and integrated hardware/ software code generation it isimportant that this information is an integral part of the system specification.Even the reception of signals sent by expired timers is asynchronous because theconsumption of the timer signal has no relation to its expiration time. This is incontradiction to the former required deterministic and synchronous behavior ofreal-time systems.

The usage of the construct now as an alternative to timers is not sufficientto implement deterministic real-time behavior because now only accesses thesystem clock variable which has an implementation dependent behavior. Theimpossibility to specify the behavior of the system clock in a formal and codegenerator independent way clearly rules it out. The only valid assumption aboutnow is the relation nown <= nown+1 in two consecutive statements in the sametransition. Neither the size of a time step nor the linearity of the clock is definedby this.

Without a formal model of time, it is not possible to specify all aspects of real-time systems non-ambiguously. Currently, only the functional behavior can bespecified, or, in other words, only a system. Due to the aforementioned reasonsa formal model of clocks and timing constraints was developed. The timingconstraints are subdivided into two different aspects: First, a timing requirementdescribes a requirement to the system that has to be validated only during thedesign and the test phase of the system. Second, a timing condition describes arequirement which has to be augmented repeatedly during normal execution ofthe system and which triggers specified actions depending on validity.

Based on this insight, a design pattern was developed to specify real-timesystems. It enables the designer to specify synchronous reaction to medium ac-cess components, deterministic real-time behavior and layer 2 functionality asin packet multiplexers or schedulers. It can also be used to build a complex sys-tem, such as an IP based switch, by connecting different instances of the samepattern. This paper focusses on the specification of real-time systems with SDL.In [15] strategies for hardware/software partitioning and implementation of suchsystems are shown.

A General Approach for the Specification of Real-Time Systems with SDL 205

2 Related Work

Typically, in SDL [8] the timer mechanism and the construct now are used tospecify the timing behavior of the system. As mentioned, this is not sufficient tospecify timing constraints in general. Also the use of the timer active expressionor priority input for a timer signal is not a solution. For the specification oftiming constraints, even SDL-2000 [7] does not include any enhancements. Forthis purpose, even SDL-2000 [7] does not include any enhancements. The de-scription of timing requirements is considered in SDL* [13], an extension of SDLto specify non-functional aspects such as resource constraints or cost constraintsin annotations. The SDL extension described in [10] enables the specificationof a predefined set of timing requirements based on signal chains, which are se-quences of signals inside the SDL system. Complex timing requirements are notconsidered in both SDL extensions.

Message Sequence Charts (MSC) [9] is a language to describe the systembehavior by scenarios. MSCs are used during the analysis phase for analyzingthe behavior of the system in early design phases and to validate the behaviorof the implemented system against the specification. Functional behavior of thesystem cannot be specified sufficiently. During the last four years a few extensionsto MSC were defined to specify temporal aspects. Timed MSC [14], which hasbeen integrated in the upcoming standard MSC-2000, and Performance MSCs[3] consider the specification of timing constraints restricted to special aspectsof the system. Properties are not mentioned for the clock used to measuremethe specified values; hence again, there is the problem of having deterministicclocks with a reliable behavior usable for real-time systems. The same arguments(except the functional deficit) hold for QSDL [11]: an extension to SDL basedon queuing models.

Despite the temporal specification gap, there are two case studies which dealwith the specification and implementation of real-time telecommunication sys-tems without considering timing constraints. While in [16] the design of a basestation for mobile communications (DECT) is discussed, the case study in [1]deals with the specification of an ATM network interface card. However, both ap-proaches avoid the specification of complex timing behavior of layer 2 protocols.In [16] only the layers without time-critical parts have been specified in SDL.All layers with needed real-time capability have been implemented using fixedhardware and software parts of an existing PBX framework. The case study pre-sented in [1] considers the specification of the whole system in SDL and discussesdifferent implementation alternatives with respect to hardware/software parti-tioning. The missing consideration of timing constraints leads to the mentionedproblems of having a large overhead for the runtime support system (RTSS) inthe implementation.

The case studies shown above clearly prove the demand for specificationsupport for timing constraints especially for medium access layer applications.Generally it is efficient to use design patterns for repeatedly arising problems.An SDL design pattern is an SDL module which can be used in different contextsfor different applications with only minor modifications. The concept especially


of SDL patterns and examples for well known protocols are described in [4] and[5]. None of these papers contains a pattern that considers any timing aspects.

3 Specification of Systems with SDL

3.1 Communication Systems

The specification of communication systems is a typical application domain forSDL. These systems can be subdivided into systems based on connection orientedservices and based on packet oriented services. In connection oriented systems(such as conventional telephone systems, wireless telephone systems — GSM,DECT, UMTS, or ATM networks) a negotiation phase is needed to setup aconnection before data can be transmitted.

The conventional telephone system based on line switching and wireless tele-phone systems, implicitly guarantees sufficient bandwidth for each connectioneven if it is not used. By selecting appropriately installed lines, Quality-of-Service(QoS) requirements (such as maximum tolerable delay) can be guaranteed underevery circumstance.

To achieve the same guaranteed quality in packet oriented networks likeATM, a virtual connection has to be reserved explicitly during the negotiationphase. To do this, the ATM protocol stack contains elements for connectionsetup and resource management. The implementation of layer 2 elements in thenetwork infrastructure has to consider the general QoS requirements (such asthe fixed packet delay in each network device, an efficiently used time-slottedmedium and a guaranteed data packet rate). The increasing demand for continu-ous media applications with real-time traffic such as teleconferencing, interactivemultimedia games or voice over IP requires more and more powerful networkswhich can only be implemented in reasonable time if the timing requirementsare already considered in the specification.

3.2 Specification of Stream-Oriented Services

The scheduler is a central component of layer 2 to realize QoS requirements instream-oriented networks. It has to be fast enough to serve the data rate of theoutput interface and to guarantee a maximum delay. In addition it has to be ontime if the medium access is time slotted.

Different queueing algorithms are currently used in internet devices for sche-duling, e.g. virtual clock [19], weighted fair queueing (WFQ) [18], or class basedqueueing (CBQ) [17]. To schedule real-time traffic, each packet belongs to areserved connection with a guaranteed QoS or gets best-effort service. Thesealgorithms uses at least one virtual time function to compute the virtual time ofa data packet in consideration of the QoS traffic parameters, generates a relativeordering of the data packets via their timestamp(s), and select the next packetfor transmission.


The SDL diagram in Fig. 1 shows an obvious approach to specify such ascheduler. The procedures SortInto and SortOut together contain the schedul-ing algorithm. After the process has received K signals Input1(Packet) an out-put signal is sent. From the K packets the procedure SortOut selects the onefor output.

This specification has several disadvantages: Signals can only be sent if theprocess input queue is not empty. It cannot be specified to send a signal at a par-ticular point of time. If the input data rate is bursty, the scheduler cannot servethe communication medium efficiently because the maximum duration betweentwo output signals is not bounded.

To fulfill these points a data packet has to be sent at least after the durationTout, independently of the number of signals in the process input queue. Thishas to be done also if there are no signals in the input queue, but buffered datapackets inside the process.

Summarizing, the input packet stream and the output packet stream of thescheduler have to be decoupled.

i < K

FALSETRUE

process Scheduler 2(2)

Read

Input1(Packet)

SortOut

Read

Output1(Packet)to

OutP

SortInto

i := i + 1

i := 0

Read

Fig. 1. SDL process Scheduler

SDL Process

EFSMTimer n Set-Timer

Reset-Timer

Consumed

Remove-Timer

Timer-Signal

RTSS

Time-Answer

Time-Request

Time-Answer

Time-Request

Signal

Self-Signal

Timer 2Timer 1

nown+1 nown

Fig. 2. SDL process with timers

3.3 Specification of Real-Time and Timing Constraints

The specification of temporal aspects is fundamental to describe the completebehavior of real-time systems. SDL contains the predefined expression now toget the actual time. As shown in Fig. 2 now represents a request (Time-Request)from the extended finite state machine (ESFM) to the system clock of the run-time support system (RTSS) to get the point of time (Time-Answer). If in thesame transition now is called twice, the return value of now is system dependentand implementation dependent, but has to follow the condition: nown+1 ≥ nown.


This temporal semantic of now’ is not sufficient to specify real-time systems, forexample to send a data packet on time.

In SDL processes, timers are a powerful method to specify protocol timers.They can be set (Set-Timer) and reset (Reset-Timer). The timer becomes activeafter it is set and becomes inactive when the timer signal is consumed or thetimer is reset. A timer gets the actual point of time from the RTSS and followsthe same rules as discussed above. If the set time has arrived, the timer sends asignal (Time-Signal) to the process input queue. The input queue sends a signal(Consumed) to the timer, after the signal was consumed from the process. Ifa timer is reset, an already existing timer signal is removed (Remove-Timer)from the input queue. The specification of timing constraints with timers isinsufficient in general, because after a timer has fired, the SDL process does notget this information immediately. As a result of the asynchronous semantics ofsending and receiving a timer signal, the specified duration of the timer does notcorrespond with the specified timing constraint, because it consists of two parts:the specified timer value and the delay to receive the timer signal. The delay isindeterminable, it is dependent on the number of signals in the input queue andthe time needed to perform them.

If the timer signal is the only priority input for a state, the timer transition istriggered immediately after the timer has fired, but only if no other transition isperformed by this point of time. Otherwise the timing constraint is not fulfilled.In addition, the restriction to use only one timer in each state is not sufficientin general as the case study in Sect. 5 shows.

A second possibility to prevent the asynchronous semantics of sending andreceiving a timer signal is the timer active expression. This predefined booleanexpression evaluates to true if the corresponding timer is active otherwise tofalse. The timer active expression can be used in an enabling condition or ina continuous signal to trigger a transition immediately after the timer becomesinactive. But it cannot be used to specify timing constraints in general, such asto perform the same send action every 10 ms: first, the timer still has no unit,so to set the timer value to 10 has no physical meaning; second, (as discussedabove) the temporal semantics of now is not sufficient.

4 Extensions for the Specification of Real-Time

4.1 Functional Approach

In Sect. 3.2 the problems with specifying stream-oriented services with SDL arediscussed. A solution of the problem is shown in Fig. 3, the functional SDL spec-ification of a QoS scheduler. It is divided into three main parts, a Control, anInput and an OutputTransition. The continuous signal concept (BuffCnt > 0)is used to decouple the input and the output data packet stream. This is neededto handle continuous, varying, and bursty traffic. Continuous signals have lowerpriority than input signals. A transition with a continuous signal is only triggeredif the boolean condition is true and the input queue contains no signals that canbe received in the state leading to the transition. The two procedures SortInto


2(2)

Read Read, Send

Input1(Packet)

i := i + 1,

SortInto SortOut

i < K

i := 0

Read Send

FALSETRUE

BuffCnt > 0

Read

Output1(Packet)

BuffCnt := BuffCnt + 1BuffCnt := BuffCnt - 1

*

Read

Control(Ctrl)

j := j + 1

Contrl

(j < M) or (BuffCnt = 0)

j := 0

Read Send

FALSETRUE

process Scheduler

Input Transition Output Transition*//*Control Transition

Fig. 3. Design pattern Decouple Module to specifiy a QoS scheduler

and SortOut contain the whole functionality of the scheduling algorithm includ-ing buffering. The constants K andM specify how many signals (Control(Ctrl)and Input1 (Packet)) can be received before the signal Output1 (Packet) is sent.The variable BuffCnt specifies the number of data packets currently buffered forscheduling.

The ControlTransition is responsible for all control information of the sched-uler, e.g. the QoS traffic parameter for each reserved connection. The procedureContrl contains this functionality. The constant M specifies how many con-trol signals (Control(Ctrl)) the Scheduler is able to receive (j < M) and stayin the state Read on the condition there is not a data packet that is buffered(BuffCnt = 0) for scheduling. If no packet is buffered, the process can receiveany number of control signals.

The InputTransition receives all data packets to be scheduled. After bufferingK data packets the state Send is reached. Now, it is only possible to trigger theOutputTransition. In the state Send the continuous signal condition (BuffCnt >0) is always true because at least the InputTransition was triggered once. Afteran output signal is sent the state Read is reached. In this state, the Control orInputTransition is triggered depending on the type of signal in the input queue.The OutputTransition can also be triggered in the state Read to prevent blockingup the sending of signals if the input queue is empty.

The SDL process in Fig. 3 is a solution for the above discussed decouplingproblem. It is a design pattern [5] because it can be used to specify applicationsthat collect and distribute data. This so called Decouple Module can be used formany systems, e.g. routers, control systems, or mobile communication systems.The two procedures SortInto and SortOut hide the whole functionality neededfor a dedicated application (except control).


If a complex protocol forthe control part is needed,the described design patternis not sufficient. In order tohave its own state machinethe ControlTransition has tobe specified in its own mod-ule. To prevent implementationoverhead the SDL service con-cept is used as shown in Fig. 4.The input and output transi-tion is specified as a service(InputOutput) with its own

2(2)

Output1 In1

process DecoupleModule

Control

InputOutputInput1

CtrIn Ctr

Out1

Set

Get

IO1

C1

CIO

IO2

CtrlOut

Fig. 4. Design pattern Decouple Module ingeneral

state machine and the same is done with the control transition (Control). Thetwo services can communicate via process variables (synchronous communica-tion) and/or via the signal mechanism (asynchronous communication).

In SDL-2000 the service concept is no longer available. Instead of services,process agents can contain further agents that execute alternating. The designpattern Decouple Module needs an agent for the Control service and an agentfor the InputOutput service. In order to share the constants M and K and thevariable BuffCnt between the contained agents they need to be specified in thecontaining process agent.

If signals for scheduling are buffered in the process DecoupleModule, themaximum duration between two output signals depends on the values of theconstants M and K and no longer on the number of signals in the input queue.But it is not feasible to send an output signal at a specified point of time.Therefore the specification of timing conditions is needed.

4.2 Temporal Approach

Clocks. In order to describe timing constraints a time measure is needed. Aninstrument called clock measures time and displays the measured value calledthe reading of the clock C(t). The aim of this section is to discuss different math-ematical models of clocks. The basic idea is to express the reading of the clockC(t) by mathematical functions. In Fig. 5 examples of different clock modelsare shown. A detailed description of these clocks including the mathematicalbackground can be found in [12].

The ideal clock Ci(t) is a linear function of time. In order to approximate thephysical properties of clocks more precisely, a continuous real clock Cc(t) requiresmore parameters: The start-offset is the reading of the clock at time t0 = 0s andthe accuracy of the clock is the gradient, often denoted in data sheets with a unitof parts per million (ppm). The efficient change of accuracy describes changesof working conditions that are influencing the clock, e.g. temperature variations.In Fig. 5 the efficient change of accuracy of the continuous real clock is zero andthe start-offset is 1s.


Fig. 5. Functional behavior of clocks

In contrast to the clocks discussed above, the temporal resolution imple-mented in real systems is finite. The discrete real clock Cr(t) has a granularityto describe the discrete changes of the reading of the clock. Due to the finitememory space to store the reading of the clock, the range of value has an over-flow. In the example in Fig. 5 the discrete real clock has a range of value of 8sand a granularity of 2s. Typically a watch has an overflow after 12 or 24 hoursand a granularity of 1s.

To handle interlocking slot schemes in mobile communication systems, clocksare needed to be derived from a reference clock. This concept is called derivedcounter Ca(t). The reading of the derived counter changes once after the dis-crete real clock has changed the number of times ticksofreferenceclock . The delaytime defines the delay between the changing of the reference clock and the incre-menting of the devived counter. The ticksofreferenceclock of the derived countershown in Fig. 5 is 2, the granularity is 1, the delay time is 0.2s, and the rangeof value is 3.

In order to specify the physicalproperties of a clock and to be able touse different clocks in an SDL system,each SDL system gets at least one clockof its own. The physical properties ofa clock are specified as an annotationin SDL* as shown in Fig. 6. SDL* isan extension of SDL to describe non-functional system aspects, such as re-source constraints or cost constraints,as annotations [13]. A timing annota-tion starts with the key word $definefollowed by the kind of the annota-tion (Clock) and the name of the clock(ProcessClock). The physical proper-ties of the clock are specified in braces.

physical properties of a discrete real clock:$define Clock ProcessClock [Accuracy 0.00001,Startoffset 1 s, EfficientChangeOfAccuracy 0 s,Granularity_c 1 ms, ClockPeriod 1 ms,RangeOfValue_c 10 ms]

SDL Process


Reset-Timer

Consumed

Remove-Timer

Timer-Signal

Time-Answer

Time-Request

Time-Answer

Time-Request

Signal

Self-Signal

Timer 2Timer 1

Set-Timer

ProcessClock

Fig. 6. Clock specification with SDL*


The EFSM as well as the timers can get the time from this clock in the sameway as it was discussed in Sect. 3.3.

In conformance to the hierarchical concept of SDL, clocks can be assigned toany entity of the hierarchy. All processes and services of a block/system can usea block/system clock. An example of an SDL system that has one system clock(ReferenceClock1) and five process clocks is shown in Fig. 7. There are threediscrete real clocks: Clock1 and Clock2 in ProcessA and Clock1 in ProcessB.ReferenceClock1 is the reference clock for the DerivedCounterA in the derivedcounters, all clocks are running independently of each other.

A new concept to access more than one clock is needed because SDL onlyallows the access to one system clock with the construct now. In order to con-

ReferenceClock1

SDL Process A


Reset-Timer

Consumed

Remove-Timer

Timer-Signal

Time-Answer

Time-Request

Time-Answer

Time-Request

Signal

Self-Signal

Timer 2Timer 1

SDL Process B


Reset-Timer

Consumed

Remove-Timer

Timer-Signal

Time-Answer

Time-Request

Time-Answer

Time-Request

Signal

Self-Signal

Timer 2Timer 1

Clock 1

Devived Counter A

Clock 2

Clock 1

Derived Counter B

physical proporties of clocks in process A:$define Clock Clock1 [Accuracy 0.00001, Startoffset 1 s, EfficientChangeOfAccuracy 0 s, Granularity_c1 ms, ClockPeriod 1 ms, RangeOfValue_c 10 ms]$define Clock Clock2 [Accuracy 0.00002, Startoffset 2 s, EfficientChangeOfAccuracy 0 s, Granularity_c200 ms, RangeOfValue_c 200 ms]$define DerivedCounter DerivedCounterA [ReferenceClock ReferenceClock1, TicksOfRefClock 2,Granularity_a 400, RangeOfValue_a 100]

physical properties of clocks in process B:$define Clock Clock1 [Accuracy 0.00002, Startoffset 4 s, EfficientChangeOfAccuracy 0 s, Granularity_c100 ms, ClockPeriod 10 ms, RangeOfValue_c 10 s]$define DerivedCounter DerivedCounterB [ReferenceClock ReferenceClock1, TicksOfRefClock 4,Granularity_a 200, RangeOfValue_a 1000]

physical properties of the reference clock:$define Clock ReferenceClock1 [Accuracy 0.00001, Startoffset 1 s, EfficientChangeOfAccuracy 0 s,Granularity_c 10 s, ClockPeriod 10 s, RangeOfValue_c 1 s]

Fig. 7. Specification of clocks with SDL* on different hierarchy


form with the SDL standard, the access to the clocks is described by the ab-stract data type Clock shown in Fig. 8. The abstract data type Clock definesthe operators that are needed for this purpose: The first parameter of the op-erator mkClock(. . . ) is a reference to the SDL* clock annotation, e.g. Clock1of ProcessA defined in Fig. 7 in ProcessA. The name of this clock is spec-ified as an SDL syntype. The operator getT ime(. . . ) accesses a discrete realclock and the operator setClock(. . . ) sets it to a certain value. In a similar waygetTicks(. . . ) and setCounter(. . . ) can be used for a derived counter. The oper-ators setT imer(. . . ) and resetT imer(. . . ) have the same semantics as the SDLtimer constructs, discussed in Sect. 3.3. In addition to each timer, a correlatedclock is referenced and used to fire the timer. Most operators have a parameterTimeUnit to specify the unit of the given value, e.g. ms, µs, or ns, but thedefault unit of Clock is second.

newtype Clockoperators

mkClock: Integer -> Clock;getTime: Clock, TimeUnit -> Time;getTicks: Clock -> Integer;setClock: Clock, Eventclass, Time, TimeUnit-> Void;setCounter: Clock, Eventclass, Integer -> Void;setTimer: Clock, Time, Integer, TimeUnit-> Void;resetTimer: Clock, Integer -> Void;

/* the operators will be specified algorithmically */endnewtype Clock;

newtype Voidliterals bottom;endnewtype Void;

synonym Clock1 Integer = 10;

newtype TimeUnitliterals s, ms, us, ns;/*all others are not defined yet*/endnewtype Time Unit;

Fig. 8. Abstract data type Clock

newtype EventKindliterals/* Queue events */

InQueueEvent,DeQueueEvent,FullQueueEvent,EmptyQueueEvent,

/* EFSM events */SDLEvent;

/*all others are not defined yet*/endnewtype EventKind;

newtype ActivationStatusliterals

ActivateAll, /*all operators can be performed*/ActivateNone, /*none operator can be performed*/ActivateObserve; /*operators for observation can be performed*/

endnewtype ActivationStatus;

newtype Eventclassoperators

mkEventclass: ActivationStatus, EventKind,Integer, Integer -> Eventclass;

recordEvent: Eventclass -> Void;getTimeEvent: Eventclass, Integer -> Time;removeEvent: Eventclass, Integer -> VoidnbOfEvents: Eventclass -> Integer;durationEvent: Eventclass, Integer, Eventclass,

Integer -> Duration;observe: Eventclass, Boolean, Boolean -> Void;

/* the operators will be specified algorithmically */endnewtype Eventclass;

Fig. 9. Abstract data type to specifiy timing requirements


This approach does not distinguish between SDL sorts Time and Duration.Every reading of a clock is the Duration since the starting point of Time, suchas 00:00 Uni-versal Coordinated Time (UTC), January 1, 1958, or since the lastoverflow.

Timing Constraints. A timing constraint consists of a timing bound and alogical condition to describe the temporal behavior of complex systems: The tim-ing bound describes the required execution time of system parts. It is a booleanexpression that specifies the relation (<,≤, >,≥,=, �=) between the required du-ration defined by a start event and an end event and the real duration. An eventis a particular change of system properties at a point of time, e.g. states, valuesof variables, or level of the input queue. The timing bound is false if the requiredduration is violated. In communication systems a timing bound has not to befulfilled in every case, e.g. if there are no data packets buffered in the schedulernothing can be sent. To specify such conditions, a boolean expression describingthe history of the system is needed. At least this logical condition is defined bythe relation between an event and the end event of the timing bound. The logicalcondition is false if the preconditions for the timing constraint are not met. Inthis case the timing constraint is always true because the timing bound does notapply. If the system does not fulfill the timing bound and the logical conditionis true the timing constraint is false.

If the scheduler discussed before has to perform a data rate of 1 Kbyte/s,it has to send a data packet of one byte every 1 ms. The timing bound of thistiming constraint is dependent on the number of data packets stored in theprocess buffer for scheduling. If the buffer is empty, the timing bound does nothave to be fulfilled because no data packet can be sent.

As practical experience has shown, timing constraints have to be subdividedinto timing requirements and timing conditions. A detailed description is givenin the following sections.

Timing Requirements. A timing requirement is the specification of a timingconstraint that has to be observed for validation during design and test phasesof the design cycle. They are not considered further after the installation of thefinal system. Different performance evaluation methods for validation of suchrequirements are state of the art. These methods are subdivided into monitor-ing, simulation, and analytical approaches. In all these cases, the mathematicalclock model for the validation has to be chosen carefully to approximate thesystem behavior sufficiently. In addition to this, the use of different clock modelscan cause errors, e.g. if for simulation continuous real clocks and for analyticalvalidation ideal clocks have been used. This has to be considered during thedefinition and the utilization of engineering models for system development.

The abstract data type concept is used to specify timing requirements in SDL.The abstract data type EventClass shown in Fig. 9 contains different operatorsto describe complex timing requirements and to observe the fulfilling of a timingrequirement online. An EventClass handles all events of the same kind, e.g. allevents writeintotheinputqueue or all events aparticularprogrampositioniscalled .


tn-2

. . . an-4 cn an-3 bn an-2 an-1 an . . .

tntn

observe(A,durationEvent(A, nbOfEvents(A) - 1, A, nbOfEvents(A)) < , true);

/* Informal: The duration between any two successive events ofevent class A has to be less than T. */

Logical Condition Event trace Instruction in the SDL Tasks

tn-3

. . . an-4 cn an-3 bn an-2 an-1 an . . .

tn-2 tntn

a) none

observe(A,durationEvent(A, nbOfEvents(A) - 1, A, nbOfEvents(A)) < T,durationEvent(A, nbOfEvents(A) - 1, B, nbOEvents(B)) < 0) ;

/* Informal: The duration between any two successive events ofevent class A has to be less than T, if no events of event class B arein between. */

b) not B

observe(A,durationEvent(A, nbOfEvents(A) - 1, A, nbOfEvents(A)) < T,(durationEvent(A, nbOfEvents(A) - 1, B, nbOEvents(B)) < 0) or(durationEvent(A, nbOfEvents(A) - 1, C, nbOEvents(B)) < 0))

/* Informal: The duration between any two successive events ofevent class A has to be less than T, if no events of event class B orevent class C are in between. */

c) not (B or C)

. . . an-1 cn-1 an-2 bn cn an-1 an . . .

tn

observe(A,durationEvent(A, nbOfEvents(A) - 1, A, nbOfEvents(A)) < T,(durationEvent(A, nbOfEvents(A) - 1, B, nbOEvents(B)) <0) and(durationEvent(A, nbOfEvents(A) - 1, C, nbOEvents(C)) <0))

/* Informal: The duration between any two events of event class Ahas to be less than T, if no events of event class B and event class Care in between. */

d) not (B and C)

. . . an-1 cn-1 an-2 bn cn an-1 an . . .

tntn-1

Fig. 10. Examples for the specification of timing requirements

The operator mkEventclass(. . . ) has four parameters for the initialization:ActivationStatus specifies which operators will be implemented in the target(executable) system or can be used by simulation, for example ActivateAll spec-ifies that all operators can be performed and ActivateObserve specifies thatonly the operators which are needed for observation are available. This makesit very comfortable to leave out unneeded operators in the final version. Tim-ing requirements can depend on events of the RTSS, e.g. a signal is writteninto the input queue (InQueueEvent), and events of the EFSM. The SDL typeEventKind denotes this determination. The last two parameters of the operatormkEventclass(. . . ) are a reference to a clock specified in an SDL* annotationand the maximal number of buffered events. The operator recordEvent(. . . ) callsthe operator getT ime(. . . ) of the abstract data type Clock to get the timestampof an event of the EFSM and buffers it in the internal data structure of the eventclass. Events of the RTSS are recorded in conjunction with the RTSS, e.g. if suchan event occurs, their timestamp is automatically saved in the data structureof the event class. getT imeEvent(. . . ) can be used to get the timestamp of arecorded event. After removeEvent(. . . ) is called, a recorded event is deleted.The operator nbOfEvents(. . . ) returns the index of the last recorded event of


the event class. The duration between two recorded events from the same orfrom different event classes is calculated by durationEvent(. . . ).

The operators discussed above are necessary for specifying timing require-ments that can be described by the operator observe(. . . ) in an SDL specifica-tion. The two boolean parameters are the specification of the timing bound andthe logical condition. As discussed above, for the timing constraint the systemrequirement is always fulfilled, if the logical condition is false or if both the tim-ing bound and the logical condition are true. The operator observe(. . . ) can belinked to a monitor for performance evaluation. We use our hardware monitor-ing system ZM4 to record timing requirements and our performance evaluationsystem SIMPLE to analyze the system behavior offline [6]. In a similar wayobserve(. . . ) can be used for simulation.

process Layer2

send

Output1(Layer2_sdu)

(getTime(Clock1, ms) = SlotTime) and MediumSync

send

send

Build_Layer2_sdu

send

Input1(Layer3_sdu)

GetTime(Clock1, ms) < SlotTime - Tmax1

/*Input Transition Output Transition*/

tmax<=Tmax1*/

send

ControlProc

send

CtrMsg(CtrData)

GetTime(Clock1, ms) < SlotTime - Tmax2

Control Transition

tmax<=Tmax2*/

Fig. 11. Specification of a timing condition

In Fig. 10, some characteristic examples of timing requirements and theirspecification in SDL are shown. In each case, the event classes A, B, C, and Dhandle a set of events of the same kind. As a special case, all start and end eventsof the timing bound are members of the event class A with an ∈ A. The timingbound is true if two successive events of A are less than the duration T . Theoperator durationEvent(. . . ) compared with the required duration T specifiesthe timing bound in all cases. The events bn ∈ B, cn ∈ C, and dn ∈ D areused to specify the logical conditions. The logical condition in example a) isalways true because any other events can occur between two successive eventsof EventClassA. In examples b) to d) durationEvent(. . . ) and the relations orand and describe the logical conditions. Only a few language operators and thenew operators durationEvent(. . . ) and nbOfEvents(. . . ) are needed to specifysuch important logical conditions.

Timing Conditions. A timing condition is a kind of timing constraint that ac-tively controls the behavior of the system. In opposition to timing requirements,a timing condition needs to be part of the implementation. A timing condition


consists of a timing bound, a logical condition, and a reference to the code thathas to be performed if the timing bound and the logical condition are true. Atypical example is a communication system which performs the medium accessin a timed division multiplex scheme (TDMA). A TDMA frame is subdividedinto slots. Such a system has to send a data packet exactly in a defined slot.

In SDL-2000, it is possible to access the operators of abstract data typesin enabling conditions and continuous signals. So the pattern DecoupleModulecan be modified to specify the above mentioned timing condition. As shown inFig. 11, the output transition of the process Layer2 is triggered every time thereading of Clock1 has the value of the beginning of the assigned slot (SlotT ime).This happens periodically because the overflow of the discrete real clock is theduration of the TDMA frame. The variable MediumSync denotes that all com-munication partners are already synchronized. The enabling condition constructprevents triggering the InputTransition or the ControlTransition in the casethat the SlotT ime is reached. The enabling condition (getT ime(Clock1,ms) <SlotT ime−Tmax1) of the InputTransition takes into account the longest dura-tion Tmax1 of the InputTransition. In the same way (getT ime(Clock1,ms) <SlotT ime − Tmax2)) the longest duration Tmax2 of the ControlTransition isconsidered.

The timer active expression can be used in continuous signals or enablingconditions to trigger transitions after the timer has fired and has become inac-tive. As discussed in Sect. 3.3 this is not sufficient to specify timing conditionsin general. To allow this, each timer needs access to a clock whose physicalproperties are described as shown in Sect. 4.2.

The example shown in Fig. 11 needs three timers to specify the timing con-dition. The continuous signal contains a time expression to trigger the OutputTransition in the case the SlotTime is reached. The timer has to expire if thereading of the clock is SlotTime ms. The time expressions of both enabling con-ditions refer to different timers. The timer of the InputTransition has to expireif the reading of the clock is SlotTime ms - Tmax1 ms and the timer of theControlTransition has to expire at SlotTime ms - Tmax2 ms.

The specification of the timing condition based on timers that have an ex-tended semantic and the operator getT ime(. . . ) are identical in respect to trig-gering the OutputTransition at the defined time. But it is more elegant andintuitive to make a decision in dependency on the reading of the clock than touse timers. In the case the timing condition is periodically the timers have to beset every time again after their expiration. This needs not to be done if the op-erator getT ime(. . . ) is used. In addition, the automated synthesis of the systemspecification shown in Fig. 11 to an implementation is easier.

5 Case Study: Specification of the DECT MAC-Layer

The specification of the MAC-Layer [2] of the wireless communication systemDECT will be discussed in this section to demonstrate the usability of our ap-


physical clock properties of the reference dect clock:$define Clock ReferenceDECTClock [Accuracy 0.00001,StartOffset 1 s, EfficientChangeOfAcc 0.1 s sin(2 576 kHz),

physical properties of slot clock:$define Clock SlotClock [ReferenceClock ReferenceDECTClock,TicksOfRefClock 4320, Granularity_a 1, RangeOfTicks_a 24]

physical properties of bit clock:$define Clock BitClock [ReferenceClock ReferenceDECTClock,TicksOfRefClock 9, Granularity_a 1, RangeOfValue_a 480]

physical properties of frame clock:$define Clock FrameClock [ReferenceClock ReferenceDECTClock,TicksOfRefClock 103680, Granularity_a 1, RangeOfTicks_a 16]

reference clock: 10,368 MHz 237 Hz

bit clock

frame clock

slot clock

9 : 1

480 : 1

24 : 1

TDMA specification

Granularity_c 96.4506 ns, ClockPeriod 96.4506 ns,RangeOfValue_c 1 s]

Fig. 12. DECT: TDMA timing and SDL* specification of the clocks

proach.1 The case study focusses on the main functions of a DECT fixed partto specify the multiplexing scheme of the logical channels with SDL. Functionssuch as connection management, measurement of radio signal strength, and han-dover algorithms are not yet considered. The DECT example was used becausethe system behavior is well known and we already had experience developingDECT systems. In addition, this case study covers most real-time problems offuture mobile communication systems because DECT is very similar to GSM orUMTS. A detailed description of hardware/software partitioning alternatives ofthis SDL specification and their implementations on a rapid prototyping boardcan be found in [15].

The DECT protocol specification describes layer one, two and three of theOSI reference model for wireless speech and data services. It is designed to pro-vide large cordless private branch exchange (PBX) installations or wireless LANsand is also available for domestic consumers. The radio fixed parts (base stations)of the system are connected to a PBX via a standard telephone line interface(analog or digital). Portable parts, mobile phones, or laptops with a DECTinterface communicate with the telephone system via the air interface. DECTsupports seamless handover to change the radio fixed part being connected to aportable part, or to switch the radio channel if the quality of a connection getsworse. This may occur when the user leaves the area of the current radio fixedpart or other radio signals interfere with the radio channel.

1 The case study is supported by an industrial cooperation with the DECT develop-ment group of the Tenovis GmbH.


5.1 Specification of the Clocks for the TDMA Timing

The air interface is realized with TDMA to support high traffic load. A 10 msframe is subdivided into 24 time slots: 12 time slots for the uplink and 12 timeslots for the down-link result in 120 channels on 10 radio frequencies. In eachtime slot, a packet of 480 bits can be sent. A bit, slot, and frame clock is neededto send the data packets on time. The frequency of these clocks has to be derivedfrom the reference clock (10.368 MHz) as shown in Fig. 12 where the factor 9leads to the bit clock. Additionally the SDL* clock annotations are shown. Thereference clock is described as a discrete real clock while the bit, slot, and framecounters are derived from this reference clock.

Block MAC 1(3)

LLME (1,1) MBC (0,2)

A_CSF (1,4)

B_CSF2 (0,2)B_CSF1 (0,2)

BMC (1,1)

DLC

ME_SAP

IDENTreq,CONreq,DISreq,LINE_CONreq,LINE_DISreq

MV_SAP

MAC_CONind,MAC_CO_DATAind,MAC_CO_DTRind,MAC_DISind

MAC_CO_DATAreq,MAC_DISreq

DLC

ABHO_ALLind,RELEASEind

CT

RELEASEreq,CTreq

CTind,CT_DTRind,BEARERind,RELEASEind

NT

MAC_ME_CONind,MAC_ME_RELind,MAC_ME_ESTABLISHEDind

MAC_ME_RFP_PRELOADreq,MAC_ME_INFOreq,MAC_ME_CON_ALLreq

CDSAP

APL_TXreq

APL_RXind

RADIO

O

DSAP2BPL_TXreq

BPL_RXind

RADIO

N

RELEASEreq

DSAP1BPL_TXreq

BPL_RXind

RADIO

DLC

MA_SAP

MAC_PAGEreq

PT

PTreq

BEARERind,RELEASEind

LINE

AudioSPEECHind

SPEECHreq

RECONreq

RELEASEreqRECONreq

process A_CSF 1(2)

MTCtrl

AMUX

MEMEMT

MAC_ME_CON_ALLreq

MAC_ME_CONind,MAC_ME_RELind,MAC_ME_ESTABLISHEDind MBC

CTind,CT_DTRind,BEARERind,RELEASEind

RELEASEreq,CTreq

L

M_BMC

BEARERind,RELEASEind

M

MEMEMUX

MAC_ME_RFP_PRELOADreq,MAC_ME_INFOreq

CD

APL_TXreqAPL_RXindCDSAP

MA_BMC

PTreq

a)

b)

Fig. 13. DECT MAC: a) SDL specification overview, b) process A CSF

5.2 SDL Specification

The specification of the DECT MAC-Layer shown in Fig. 13 a) is split into sixdifferent SDL processes: The complete MAC-Layer is managed by the processLower Layer Management Entity (LLME). Multi Bearer Controller (MBC) andBroadcast Message Controller (BMC) perform the handover and broadcast man-agement. The cell site function (CSF) performs the control of the radio links. Theprocess A CSF performs the setup of the so called bearer - the radio link - whilethe other two CSF processes perform speech data transmission. Every bearersupports different logical channels identified by message types, e.g. Mt-messagesfor bearer setup or Pt-messages for paging.

The specification of the multiplexing scheme of the logical channels performedby the process A CSF is discussed in the following. As shown in Fig. 13 b) A CSFis divided into two services with synchronous communication between them:Service AMUX manages the multiplexing and the access to the radio modulewhile service MTCtrl contains the MAC protocol. The pattern Decouple Module


has been used to specify the strict DECT timing conditions that must be fulfilledonly by the AMUX service. In the same way the CSF functions B CSF1 andB CSF2 for transmitting speech can be specified.

service AMUX

4(4)send

FRAMECNT = FRM_NR_OFQT andBITCNT >= TIME2SND and

SLOTCNT = actualSN;priority 1

txAField(0) := txAField(0) or QT,txAField(1) := qtStatSysInfo(0) or nextSN,

txAField(2) := qtStatSysInfo(1),txAField(3) := qtStatSysInfo(2),

txAField(4) := qtStatSysInfo(3) or nextCN,txAField(5) := qtStatSysInfo(4)

FRAMECNT = i2o(0)

txPt := ZERO_PAGE;

APL_TXreq(txAfield)

receive

FRAMECNT mod I2O(2) = I2O(0) andBITCNT >= TIME2SND and

not (txMt = MT_NOCMD) andSLOTCNT = actualSN ;

priority 2

txAField(0) := txAField(0) or MT,txAField(1) := txMt,

txAField(2) := fmid(0),txAField(3) := fmid(1) or pmid(0),

txAField(4) := pmid(1),txAField(5) := pmid(2)

txMt = RELEASE and txCnt < 1

txMt := MT_NOCMD,txCnt := txCnt + 1

txCnt := 0

FRAMECNT mod I2O(2) = I2O(0) andBITCNT >= TIME2SND and

txCt andSLOTCNT = actualSN;

priority 3

txCtNo

txAField(0) := txAField(0) or CT1

txAField(1) := txCtail(0),txAField(2) := txCtail(1),txAField(3) := txCtail(2),txAField(4) := txCtail(3),txAField(5) := txCtail(4)

txAField(0) := txAField(0) or CT0

FRAMECNT mod I2O(2) = I2O(1) andnot (FRAMECNT = I2O(14)) and

BITCNT >= TIME2SND and((txPt = SHORT_PAGE) or (txPt = FULL_PAGE)) and

SLOTCNT = actualSN;priority 4

txAField(0) := txAField(0) or PT,txAField(1) := pTshort(0),txAField(2) := pTshort(1),txAField(3) := pTshort(2),txAField(4) := pTshort(3),txAField(5) := pTshort(4)

txPt := PT_NOCMD;

FRAMECNT mod I2O(2) = I2O(1) andnot (FRAMECNT = I2O(14)) and

BITCNT >= TIME2SND andtxPt = ZERO_PAGE andSLOTCNT = actualSN;

priority 5

txAField(0) := txAField(0) or PT,txAField(1) := pTzero(0),txAField(2) := pTzero(1),txAField(3) := pTzero(2),txAField(4) := pTzero(3),txAField(5) := pTzero(4)

BITCNT >= TIME2SND andSLOTCNT = actualSN;

priority 6

txAField(0) := txAField(0) or NT,txAField(1) := txNtail(0),txAField(2) := txNtail(1),txAField(3) := txNtail(2),txAField(4) := txNtail(3),txAField(5) := txNtail(4)

*

true

false

true false

true

false

recordEvent(B)

recordEvent(A)

recordEvent(C)

recordEvent(D) recordEvent(E)

recordEvent(F)observe(durationEvent(G, nbOfEvents(G) - 1, G, nbOfEvents(G)) < Tgg, true);observe(durationEvent(A, nbOfEvents(A), G, nbOfEvents(G)) < Tag, true);

recordEvent(G)

observe(durationEvent(B, nbOfEvents(B), G, nbOfEvents(G)) < Tbg, true);observe(durationEvent(C, nbOfEvents(C), G, nbOfEvents(G)) < Tcg, true);observe(durationEvent(D, nbOfEvents(D), G, nbOfEvents(G)) < Tdg, true);observe(durationEvent(E, nbOfEvents(E), G, nbOfEvents(G)) < Teg, true);observe(durationEvent(F, nbOfEvents(F), G, nbOfEvents(G)) < Tfg, true);

Fig. 14. DECT sending: MUX algorithm

The AMUX service shown in Fig. 14 consists of six transitions to multi-plex the logical channels. With the help of the continuous signal construct, thetiming condition of each logical channel is specified. The correct timing behav-ior of the MAC-Layer can easily be described and validated using the abovediscussed derived counters for bit-, slot-, and frame-timing and the operators ofthe abstract data type Clock. For the sake of clarity a macro is used for the op-erator getT icks(. . . ), e.g. FRAMECNT to get the reading of the derived framecounter. Depending on the desired values of these clocks the desired transitionfires synchronously. The used radio module has a fixed transmission latency. Thishas to be taken into account for the calculation of the transitions firing point. Inthe discussed specification, the constant TIME2SND describes this duration


including the runtime of the transitions. To validate that each send transitionhas finished within TIME2SND the operators observe(. . . ), recordEvent(. . . ),etc. of the abstract data type EventClass are used.

6 Conclusion

In this paper a new approach is presented that extends SDL with the abilityto specify timing aspects. The specification of timing aspects is important tosupport the development of communication systems with QoS requirements,such as mobile telephone systems. The formal time model consists of clocks andtiming constraints. Based on this model, a design pattern to specify Layer 2protocols was developed. The design pattern decouples the data input streamfrom the data output stream. Different data rates of the input and output datastream can be considered. For the specification of synchronous medium access itis possible to send signals at a particular point of time.

A typical example that shows that timing enhancements are needed to spec-ify real-time systems is the DECT MAC-Layer discussed in the case study. Cur-rently, we are starting a cooperation with an industrial partner to specify andimplement time critical parts of UMTS-mobiles. A key point of this cooperationis to prove the usefulness of our SDL extensions and the acceptance by industrialengineers.

References

1. J.M. Daveau, G. Marchioro, A.J. Jerraya. Hardware/Software Co-Design of anATM Network Interface Card: a Case Study. 6th International Workshop on Hard-ware/Software Codesign, IEEE Computer Society Press, Seattle, 1998.

2. ETSI. ETS 300-175-3, Digital Enhanced Cordless Telecommunications (DECT);Common Interface (CI); Part 3: Medium Access Control (MAC) layer. ETSI, 1996.

3. N. Faltin, L. Lambert, A. Mitschele-Thiel, F. Slomka. An Annotational Extensionof Message Sequence Charts to Support Performance Engineering. In A.Cavalli, A.Sarma (eds.), SDL’97 Time for Testing, SDL, MSC and Trends, 8th SDL Forum,Elsevier Science, 1997.

4. B. Geppert, R. Gotzhein, F. Roßler. Configuring Communication Protocols UsingSDL Patterns. In A.Cavalli, A. Sarma (eds.), SDL’97 Time for Testing, SDL, MSCand Trends, 8th SDL Forum, Elsevier Science, 1997.

5. B. Geppert, F. Roßler, R. L. Feldmann, S. Vorwieger. Combining SDL Patternswith Continuous Quality Improvement: An Experience Factor Tailored to SDLPatterns. In Proceedings of the 1st Workshop of the SDL Forum Society on SDLand MSC, Berlin, June 1998.

6. R. Hofmann, R. Klar, B. Mohr, A. Quick, M. Siegle. Distributed Performance Mon-itoring: Methods, Tools, and Applications. IEEE Trans. Parallel and DistributedSystems. Vol. 5, No. 6, June 1994.

7. ITU-T. Z.100 (11/99), ITU, Specification and Description Language. ITU, Speci-fication and description language (SDL), November 2000.

8. ITU-T. Z.100, Appendix I. ITU, Specification and Description Language. ITU,1993.


9. ITU-T. Z.120, Message Sequence Chart. ITU, 1996.10. P. Langendorfer, H. Konig. Specifying and Validating Quality of Service Require-

ments Using Signal Chains. Workshop on Performance and Time in SDL andMSC, Internal report IMMD-VII-1/98, University of Erlangen-Nuremberg, Febru-ary 1998.

11. B. Muller-Clostermann, M. Diefenbruch. Queueing SDL: A Language for the Func-tional and Quantitative Specification of Distributed Systems. Workshop on Per-formance and Time in SDL and MSC, Internal report IMMD-VII-1/98, Universityof Erlangen-Nuremberg, February 1998.

12. R. Munzenberger, F. Slomka, M. Dorfel, R. Hofmann. A New Time Model for theSpecification, Design, Validation and Synthesis of Embedded Real-Time Systems.Submitted to IEEE Transactions on VLSI Systems.

13. A. Mitschele-Thiel, F. Slomka. Codesign with SDL/MSC, In K. Buchenrieder, AlSedlmeier (eds.), International Workshop on Conjoint Systems Engineering (CON-SYSE’97), IT-press, 1999.

14. I. Schieferdecker, A. Rennoch, O. Mertens. Timed MSCs - an Extension to MSC’96.In A. Wolisz, I. Schieferdecker, A. Rennoch (eds.), Formale Beschreibungstechnikenfur verteilte Systeme, GI/ITG-Fachgesprach, Berlin, June 1997.

15. F. Slomka, M. Dorfel, R. Munzenberger. Generating Mixed Hardware/SoftwareSystems from SDL Specifications. Accepted for the International Symposium onHardware/Software Codesign, Codes 2001.

16. H.-J. Vogel, W. Kellerer, S. Sarg, M. Kober, A. Beckert, G. Einfalt. SDL basedprototyping of ISDN-DECT-PBX switching software. In Proceedings of the 1stWorkshop of the SDL Forum Society on SDL and MSC, Berlin, June 1998.

17. I. Wakeman, A. Ghosh, J. Crowcroft, V. Jacobson, S. Floyd: Implementing Real-Time Packet Forwarding Policies using Streams Proceedings of the USENIX Tech-nical Conference, Louisiana, New Orleans, Jan. 1995.

18. H. Zhang. Service Disciplines for Guaranteed Performance Service in Packet-Switching Networks. Proceedings of IEEE, Vol. 83, No. 10, October 1995.

19. L. Zhang. Virtual Clock: A New Traffic Control Algorithm for Packet-SwitchedNetworks. ACM Transactions on Computer Systems, Vol. 9, No. 2, May 1991.

Date post:	11-Oct-2016
Category:	Documents
Upload:	jeanne
View:	212 times
Download:	0 times

[Lecture Notes in Computer Science] SDL 2001: Meeting UML Volume 2078 || A General Approach for the...

Documents