HLA Project Overview ACIMS Lab Prepared by Saurabh
HLA Project Overview ACIMS Lab Prepared by: Saurabh Mittal
To Start with… • Basic ideas on – Designing network environments with common parameters (e. g. mean distance, probability of connection, quantized or periodic updates, etx. ) – Modeling various components within these networks • Preliminary design of router completed • Basic tests conducted (eg. Ensuring packet routing etx. . )
Layered Architectural Framework Experimental Frame Layer Traffic Generator Parameter Controller / Evaluator Topology Designer Visualizer Network Modeling Layer Topology Sub-layer Routing Sub-layer DEVS Simulation Layer (nodes and links being simulated as per DEVS Formalism) Area encompassing components designed using DEVS Formalism
DEVS Modeling & Simulation HLA Network Framework Development of DEVS: • Modeling API for components in Application Layer • Routers • Links • Message Passing and other specialized features related to Application Layer components
System Entity Structure (SES) for Net-Framework
Improvise Router (network) Node for HLA implementation • Develop the router node as shown below and create a network Node Routing Capability Inside every network Node (taken form earlier Version of simulation-based Router) Real-time Routing Engine Routing/Lookup Table Message Passing to be implemented Traffic generator Generating packets Of different classes Forwarding Engine Payload Traffic Generator updates RTI Ambassador M/M/1 queuing system that routes packets based on the information from the forwarding engine. The queuing system characterizes the RTI capabilities Updates to specific destinations
HLA / RTI Implementation • Centralized and De-centralized versions of network HLA/RTI under consideration • Different experiments devised to gather information about – Thruput – Network delay – Link utilization • Transducers being implemented within components (links+routers) to gather individual data in an automated manner.
Conceptual Centralized HLA/RTI network • Network components – Centralized RTI Executive node • Receives packets being published • Broadcasts packets being subscribed – HLA Router • Generates traffic containing packets of different ‘classes’ – Links
Centralized HLA/RTI Network ‘Router. Node’ ‘HLA Router’ RTI Executive - a part of the Network - routers publish messages of different ‘classes’ to RTI - broadcasts messages to every other node - those subscribed to particular ‘class’ of messages, attend to it, others ignore Metrics - end-to-end Delay - average link utilization - thruput - queuing time at RTIExec
DEVS Demo with RTI Executive Example Topology being modeled Run network. HLAwith. RTIExec. java DEVS Network in sim. View HLA Router RTI Exec Router links 4 RTI Executive RTI Exec links 6 1 0 HLA Routers 2 3 5
Publish-Subscribe functionality public class Publish extends entity { • Each federate ///stores class. Names in string format – Publishes packets to ‘classes’ – Subscribes to particular ‘classes’ private Array. List classes; private Array. List classes. String; private Array. List classes. Double; public Publish() public Publish(String name) public void publish. Msg. Of. Class(String msg. Class) public void publish. Msg. Of. Classes(Array. List classes_) are published to destination RTI Exec public int get. Published. Class. Count() public String get. Class(int i) are broadcasted to other federates thrupublic it boolean is. Class. Of. Msg. Present(String msg. Class) public who void remove. Published. Class(String can be multicasted to only those federates subscribe to those msg. Class) If there is RTI Executive present • • • Packets classes If there in NO RTI Executive present • • Point-to-point network Packets generated to specific destinations } Similar is the ‘Subscribe’ class Benefits: • Can communicate in more than One data-type as opposed to just ‘Strings’ Better functionality and encapsulation by creating a Publish or Subscribe object
DEMO 1 Run network. HLAwith. RTIExec. java main function • Visualization of constructed DEVS Network in real-time manner LINK PANEL Adjusting of network parameters for observing behavior of the network • Modular GUI development and GUI created at run-time during the time the network gets created • EASY to IMAGINE what you want to achieve with your network ROUTER PANEL Real-time Simulation Controller
DEMO 2 Topology Designer • Attractive GUI • Change dynamically, – – Number of nodes Distance between nodes Link Properties Connection-density • Integrate with Demo 2 in progress • Run List. Select. java main function FAST Mode DEVS simulation inside devs. Network. HLA. java public void simulate(){ s. s("inside devs. Network. Hla. java simulate()"); coordinator c = new coordinator(this); c. initialize(); c. simulate(1000); } Snapshot of OUTPUT PACKET RECEIVED AT : HLA Router_node_8 Packet_from_0_to_8_cost_5. 0_type_0_Class_b_next. Hop_8 -----PACKET HAS REACHED ITS DESTINATION with the info: I am NOT SUBSCRIBED TO THIS CLASS: Class b. . . ignoring Packet_from_0_to_8_cost_5. 0_type_0_Class_b_next. Hop_8 -----PACKET RECEIVED AT : HLA Router_node_3 Packet_from_8_to_3_cost_5. 0_type_0_Class_d_next. Hop_3 -----PACKET HAS REACHED ITS DESTINATION with the info: I am NOT SUBSCRIBED TO THIS CLASS: Class c. . . ignoring Packet_from_1_to_0_cost_5. 0_type_0_Class_c_next. Hop_0 -----PACKET HAS REACHED ITS DESTINATION with the info: I am NOT SUBSCRIBED TO THIS CLASS: Class b. . . ignoring Packet_from_0_to_8_cost_5. 0_type_0_Class_b_next. Hop_8 -----PACKET HAS REACHED ITS DESTINATION with the info: I am NOT SUBSCRIBED TO THIS CLASS: Class d. . . ignoring Packet_from_1_to_3_cost_5. 0_type_0_Class_d_next. Hop_3 ------ Terminated Normally at ITERATION 1001 , time: 2. 191101580114225
Simulated Topological setup Each Federate publishing 3 types of packets and subscribed to 3 different class of packets. The receiver federate attends only to the subscribed packets and ignores other packets. Experiment No. 1 Experiment No. 2 3 3 4 5 2 1 1 6 0 HLA Routers connected in P 2 P network and communicating without RTI Executive 0 HLA Routers connected in P 2 P network and communicating THRU RTI Executive
P 2 P Run Time to Stabilize Thruput of Network Increase in Queue Lengths of Network due to Increase in Load Plot of Link Max Q length v/s Time INCREASE in Thruput Plot of Latency Max v/s Time Plot of Avg Thruput v/s Time to Stabilize after updating RTI Delay UPDATED Link Capacities UPDATED Load Packets in Links Packets in Routers Further INCREASE in Thruput
Centralized HLA: Broadcast Mode T= 4. 461 sec RESPONSE Time SNAPSHOT Time Thruput Stabilization for RTI Links Resulting Q Length for RTI Length during Stabilization Packets in Links
Centralized HLA-Multicast mode Resulting Q Length for RTI Length during Stabilization RESPONSE Time Thruput Stabilization for RTI Links SNAPSHOT Time Link Capacity Reduced to accommodate Stabilized load
Other Simulation Experiments • Various other case studies were conducted – Benchmarking and Tuning of this DEVS model based on reported results for RTI latency • Details can be looked in the Project report.
• Thanks for your Attention !!!
- Slides: 19