1 / 18

Ted – A language for Modeling Telecommunication Networks

Ted – A language for Modeling Telecommunication Networks Kalyan Perumall, Richard Fujimoto Georgia College of Technology Andrew Ogielski Rutgers university Presented By: Abhishek Chugh Introduction Designed mainly for modeling telecommunication networks

Mercy
Télécharger la présentation

Ted – A language for Modeling Telecommunication Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ted – A language for Modeling Telecommunication Networks Kalyan Perumall, Richard Fujimoto Georgia College of Technology Andrew Ogielski Rutgers university Presented By: Abhishek Chugh

  2. Introduction • Designed mainly for modeling telecommunication networks • Language specification is split into two distinct parts – • MetaTed • External language • MetaTed – incomplete language – more appropriately called a framework. • When MetaData is combined with any programming language, say £, complete language is formed. • £ - flavor of TeD. • concept of outsourcing.

  3. Objectives in the design of TeD Language • General for modeling current as well as future telecommunication networks. • Should provide for specification, description as well as simulation. • Support object orientation – encapsulation, inheritance and polymorphism. • Should provide support for user-definable and extensible libraries.

  4. Fundamental Concepts • Entity • Event • Channel • Architecture • State • Behavior • Process • Component • Result

  5. Concepts Overview • Physical and conceptual objects are modeled as entities. • Entities interact through channels. • Events – Information units which flow through channels. • Entities are highly modular. • The entity construct describes the entity’s external input/output view.

  6. Entity

  7. Concepts Overview • Architecture - Describes dynamic behavior of each entity. • Essentially describes the actions of entity on event arrival. • Processes are defined to act upon arriving events. • Components – Entities logically enclosed inside bigger entities. • Architecture construct describes the internal behavioral part of the object being modeled.

  8. Basic Framework of an Entity

  9. Physical Entity and its model in TeD

  10. Entity Declaration • Defines the external view of a physical or conceptual object. • Essentially defines the input and output specifications. Entity ATMMux ( int N ) { channels { in ATMChannel A[$PARAM(N)$] ; out ATMChannel B ; } }

  11. Event and Channel Declaration • Channel – port of input or output. • An output channel of an entity can be mapped to an input channel of another entity. • A channel type is defined as a set of event types. • Two channels can be mapped only if they are compatible. • Declarations Event ATMCell {$ char data[53]; $} Channel ATMChannel { ATMCEll }

  12. Architecture Declaration • Mainly consists of following parts: • Deferred Constants: Items whose value could be different for different instances of entity. • State: Variables that together form a part of the abstract state of the model. • Channels: Set of channels used for communication among internal processes and components of an architecture. • Behavior Processes: Threads of computation that act on events arriving on interface and internal channels. • Behavior Components: Set of entities that ft logically form sub entities of an entity’s behavior. • Result: A set of values that are an abstraction of result.

  13. Architecture Declaration Declaration: Architecture of ATMMux ( int N ) { dconst{$ int S, K; double T; $} state{$ int qlen, nsent, nlost; $ } behavior { process#1 scan( A ); process#2 update; } result{$ int totsent, totlost; $ } }

  14. Processes • Leaf elements in the behavior tree. • Acts on behalf of entities that own them. • Basic functionality consists of combination of two types of action: • Computation: using state variables. • Synchronization: using channels and time. • Processes can be categorized based on their channel-synchronization method: • Arrival-driven: Wait for activity on a set of channels and performcomputation actions upon arrival of events on that channels. • Self-Driven: Consists of combination of one or more computation and synchronization actions.

  15. Processes • Computation actions are specified using action statements in the external language. • Synchronization actions are specified using wait statement. • Wait onchannel-vars causes process to wait until at least one event arrives on at least one channel. • Wait untilcondition makes the process to wait until the condition evaluates to true. • Wait forexpression causes the process to wait for amount of time given by the expression.

  16. Process Declaration process #1 ATMMux : scan( A[ $0$ to $PARAM(N)-1$ ] ) { \{ for( int i=0, n=ASETSZ(A); i<n; i++ ) { if( STATE(qlen) < DCONST(S) ) STATE(qlen)++ ; else STATE(nlost)++ ; } \} } process #2 ATMMux : update { /{ if( STATE(qlen) > 0 ) { { CHANNEL(B) << EVENT(ATMCell,() ); STATE(qlen)--; STATE(nsent)++; } \} }

  17. External Code block • External language expressions and declarations are used for certain purposes. • External code blocks are any valid external language expressions enclosed between a pair of $ signs, or between \{ and \}.

  18. Applause !!

More Related