OPNET Implementation of OPNET Implementation of OPNET - PDF document

OPNET Implementation of OPNET Implementation of OPNET Implementation of OPNET Implementation of the the the Megaco/H.248 Protocol: the Megaco/H.248 Protocol: Megaco/H.248 Protocol: Megaco/H.248 Protocol: Multi- Multi -Call and Multi Call and Multi- -Connection Connection Scenarios Scenarios Multi Multi - - Call and Multi Call and Multi - - Connection Connection Scenarios Scenarios Edlic Yiu, Edwood Yiu, and Ljiljana Trajkovi ć Simon Frase r Unive rsity Vancouve r, British Columbia, Canada E-mail: {e nyiu, e yiu, ljilja}@cs.sfu.ca Abstract Abstract Abstract Abstract simultaneously. Several MGs are connected to a single MGC via In this paper, we describe the OPNET implementation of a router. We verified all signaling commands and simulated the MEGACO/H.248 signaling protocol. The OPNET model allows MG registration, call-establishment, call-waiting, and call- for multi-call and multi-connection scenarios, where any number release scenarios. To verify that voice calls were actually of Media Gateways (MGs) can simultaneously connect to the established, we generated voice packets encoded using the RTP Media Gateway Controller (MGC). This design is important for protocol. simulations of simultaneous voice conversations. In our simulation scenario, multiple MGs can connect to one MGC via Section 2 describes the history and basic architecture of the a router. We simulated the call-establishment, call-waiting, and MEGACO/H.248 protocol. Sections 3 and 4 describe the design call-release scenarios by employing a complete set of of the MEGACO/H.248 protocol, while Section 5 describes its MEGACO/H.248 signaling commands. We also simulated voice OPNET implementation. Various call flow simulation scenarios transmission using packets encoded with the Real-Time are given in Section 6. Simulation results are presented in Transport Protocol (RTP). Section 7. We conclude with Section 8. 1. Introduction 1. Introduction 1. Introduction 1. Introduction 2. MEGACO/H.248 Protocol 2. MEGACO/H.248 Protocol 2. MEGACO/H.248 Protocol 2. MEGACO/H.248 Protocol 2.1. History 2.1. History 2.1. History 2.1. History Voice over IP (VoIP) technology is currently finding its place in the telecommunication market. It enables a telecommunication In traditional circuit-switched networks, call setups are company to cut cost by allowing a single network to transmit performed primarily through the backbone of the telephone both data and voice traffic. In addition, VoIP technology is network. As a result, a proprietary signaling protocol can be gaining popularity in both commercial and residential markets used for establishing and deleting connections. However, a well- because the voice quality resulting from packets transmitted over defined signaling protocol is required for VoIP because VoIP the IP network is comparable to the voice quality resulting from traffic is routed through the public network infrastructure. analog signals sent over the Public Switched Telephone Network (PSTN). The MEGACO/H.248 signaling protocol was Various signaling protocols have been designed to control VoIP introduced by the Internet Engineering Task Force (IETF) and traffic. Peer-to-peer protocols, such as SIP and H.323, have been International Telecommunication Union (ITU) to help control introduced. However, for large-scale deployments, these and manage the increasing volume of VoIP traffic. protocols have scalability problems. Hence, a new architecture for signaling protocols was proposed. The control and the media With the emergence of VoIP technology, voice traffic is no gateway components were re-defined using the master/slave longer restricted to the circuit-switched network. New IP-based architecture. Figure 1 shows the evolution of the products, such as IP phones and voice cable modems, have been MEGACO/H.248 protocol. introduced to integrate voice services over the data network. To properly manage and control these voice services, various signaling protocols have been developed. One of these protocols is MEGACO/H.248. It provides the master/slave architecture for controlling VoIP traffic. The MEGACO/H.248 signaling protocol employs a call control concept. The call control “intelligence” or the master server resides in the Media Gateway Controller (MGC), while the Media Gateway (MG) serves as the slave device (dumb terminal). This concept reduces the complexity of the gateway, making it easier and more suitable for mass deployment. In this paper, we describe the implementation and simulation of the MEGACO/H.248 protocol using OPNET. All eight Figure 1: Evolution of the MEGACO/H.248 Protocol [1]. MEGACO commands are implemented: Add, AuditCapabilities, AuditValue, Modify, Move, Notify, ServiceChange, and 2.2. Gateway 2.2. Gateway Architecture Architecture 2.2. Gateway 2.2. Gateway Architecture Architecture Subtract. The OPNET implementation permits the addition of The MEGACO/H.248 protocol employs the master/slave multiple MGs. This flexibility is important for realistic architecture, where the MGC acts as a master server, while the simulation scenarios where many voice conversations occur MG behaves like a slave device. Figure 2 illustrates the 1 1 1 1

[MG → MGC] simplified gateway architecture. In a deployed telecommunication network, one MGC may control multiple • Notify – Notify the responder of an event (on- MGs. hook) 3. Design Architecture 3. Design Architecture 3. Design Architecture 3. Design Architecture We have designed two core modules for the MEGACO/H.248 protocol: MGC and MG. 3.1. MGC Architecture 3.1. MGC Architecture 3.1. MGC Architecture 3.1. MGC Architecture The MGC consists of three main components as shown in Figure 3: Message Receiver (MR), Message Processor (MP), and Message Sender (MS). Figure 2: The Master/Slave Architecture. 2.3. Media Gateway Controller 2.3. Media Gateway Controller 2.3. Media Gateway Controller 2.3. Media Gateway Controller The MGC is the central point of intelligence for call signaling. It maintains the states of each MG and responds appropriately to Figure 3: MGC Design Architecture [1]. any event notification. For instance, upon receiving an off-hook event from an MG, the MGC instructs the MG to play the dial The main responsibility of the Message Receiver is to parse the tone and listen for the dual tone multi-frequency (DTMF) tones. received messages. The Message Processor is built with the intelligence to handle all eight MEGACO/H.248 commands and 2.4. Media Gateway 2.4. Media Gateway 2.4. Media Gateway 2.4. Media Gateway to control all MGs in the system. The Message Sender is used to The master/slave architecture was designed to eliminate compose and transmit MEGACO messages to MGs. processor-intensive functionalities from the MG. Due to the reduced complexity, the cost of MG is much lower than the cost In our implementation, communications among three of MGC, making it more affordable to the commercial and components are achieved via local function calls. Upon residential markets. Essentially, the MG is a dumb terminal receiving an event notification message from the MG, the MGC awaiting commands from the MGC for its next actions. Upon the reads the statuses of the related MGs and instructs them with one successful creation of a connection, the MG is also responsible or more MEGACO/H.248 commands. The responsibilities of for streaming the voice packets over the IP backbone using each component are summarized in Table 1. various encoding/compression algorithms. Component Responsibility 2.5. MEGACO/H.248 Command Set 2.5. MEGACO/H.248 Command Set 2.5. MEGACO/H.248 Command Set 2.5. MEGACO/H.248 Command Set • Receive MEGACO messages from the MGs The commands supported by the MEGACO/H.248 protocol are: • Extract parameters from MEGACO Message Receiver messages [MGC ↔ MG] • Redirect message parameters to MP • ServiceChange – Notify the responder of the new service • Receive message parameters from MR state • Read statuses of the related MGs Message • Determine actions for the related MGs [MGC → MG] Processor • Request MS to compose response messages • AuditValue – Determine the characteristics of an if necessary endpoint • Receive requests from MP • AuditCapabilities – Determine the capability of an endpoint Message • Compose MEGACO messages • Add – Add a connection Sender • Send MEGACO messages to the MGs • Modify – Change a connection characteristic • Subtract – Tear down a connection Table 1: Component Responsibilities in the MGC. • Move – Move an endpoint from one connection to another connection (call-waiting) 3.2. MG Architecture 3.2. MG Architecture 3.2. MG Architecture 3.2. MG Architecture The MG consists of five components: Message Receiver (MR), Message Processor (MP), Message Sender (MS), User Interface 2 2 2 2