英文文獻(xiàn) 科技類 原文及翻譯 (電子 電氣 自動(dòng)化 通信)1【稻谷書屋】
《英文文獻(xiàn) 科技類 原文及翻譯 (電子 電氣 自動(dòng)化 通信)1【稻谷書屋】》由會(huì)員分享,可在線閱讀,更多相關(guān)《英文文獻(xiàn) 科技類 原文及翻譯 (電子 電氣 自動(dòng)化 通信)1【稻谷書屋】(22頁珍藏版)》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。
1、 外文文獻(xiàn)原文 On the deployment of VoIP in Ethernet networks: methodology and case study Khaled Salah, Department of Information and Computer Science, King Fahd University of Petroleum and Minerals, P.O. Box 5066, Dhahran 31261, Saudi Arabia Received 25 May 2004;? revised 3 June 2005;? accepted
2、 3 June 2005.? Available online 1 July 2005. Abstract Deploying IP telephony or voice over IP (VoIP) is a major and challenging task for data network researchers and designers. This paper outlines guidelines and a step-by-step methodology on how VoIP can be deployed successfully. The methodol
3、ogy can be used to assess the support and readiness of an existing network. Prior to the purchase and deployment of VoIP equipment, the methodology predicts the number of VoIP calls that can be sustained by an existing network while satisfying QoS requirements of all network services and leaving ade
4、quate capacity for future growth. As a case study, we apply the methodology steps on a typical network of a small enterprise. We utilize both analysis and simulation to investigate throughput and delay bounds. Our analysis is based on queuing theory, and OPNET is used for simulation. Results obtaine
5、d from analysis and simulation are in line and give a close match. In addition, the paper discusses many design and engineering issues. These issues include characteristics of VoIP traffic and QoS requirements, VoIP flow and call distribution, defining future growth capacity, and measurement and imp
6、act of background traffic. Keywords: Network Design,Network Management,VoIP,Performance Evaluation,Analysis,Simulation,OPNET 1 Introduction These days a massive deployment of VoIP is taking place over data networks. Most of these networks are Ethernet based and running IP protocol. Many netw
7、ork managers are finding it very attractive and cost effective to merge and unify voice and data networks into one. It is easier to run, manage, and maintain. However, one has to keep in mind that IP networks are best-effort networks that were designed for non-real time applications. On the other ha
8、nd, VoIP requires timely packet delivery with low latency, jitter, packet loss, and sufficient bandwidth. To achieve this goal, an efficient deployment of VoIP must ensure these real-time traffic requirements can be guaranteed over new or existing IP networks. When deploying a new network service su
9、ch as VoIP over existing network, many network architects, managers, planners, designers, and engineers are faced with common strategic, and sometimes challenging, questions. What are the QoS requirements for VoIP? How will the new VoIP load impact the QoS for currently running network services and
10、applications? Will my existing network support VoIP and satisfy the standardized QoS requirements? If so, how many VoIP calls can the network support before upgrading prematurely any part of the existing network hardware? These challenging questions have led to the development of some commercial too
11、ls for testing the performance of multimedia applications in data networks. A list of the available commercial tools that support VoIP is listed in [1,2]. For the most part, these tools use two common approaches in assessing the deployment of VoIP into the existing network. One approach is based on
12、first performing network measurements and then predicting the network readiness for supporting VoIP. The prediction of the network readiness is based on assessing the health of network elements. The second approach is based on injecting real VoIP traffic into existing network and measuring the resul
13、ting delay, jitter, and loss. Other than the cost associated with the commercial tools, none of the commercial tools offer a comprehensive approach for successful VoIP deployment. In particular, none gives any prediction for the total number of calls that can be supported by the network taking into
14、account important design and engineering factors. These factors include VoIP flow and call distribution, future growth capacity, performance thresholds, impact of VoIP on existing network services and applications, and impact background traffic on VoIP. This paper attempts to address those important
15、 factors and layout a comprehensive methodology for a successful deployment of any multimedia application such as VoIP and video conferencing. However, the paper focuses on VoIP as the new service of interest to be deployed. The paper also contains many useful engineering and design guidelines, and
16、discusses many practical issues pertaining to the deployment of VoIP. These issues include characteristics of VoIP traffic and QoS requirements, VoIP flow and call distribution, defining future growth capacity, and measurement and impact of background traffic. As a case study, we illustrate how our
17、approach and guidelines can be applied to a typical network of a small enterprise. The rest of the paper is organized as follows. Section 2 presents a typical network topology of a small enterprise to be used as a case study for deploying VoIP. Section 3 outlines practical eight-step methodology to
18、deploy successfully VoIP in data networks. Each step is described in considerable detail. Section 4 describes important design and engineering decisions to be made based on the analytic and simulation studies. Section 5 concludes the study and identifies future work. 2
19、 Existing network Fig. 1 illustrates a typical network topology for a small enterprise residing in a high-rise building. The network shown is realistic and used as a case study only; however, our work presented in this paper can be adopted easily for larger and general networks by following the
20、same principles, guidelines, and concepts laid out in this paper. The network is Ethernet-based and has two Layer-2 Ethernet switches connected by a router. The router is Cisco 2621, and the switches are 3Com Superstack 3300. Switch 1 connects Floors 1 and 2 and two servers; while Switch 2 connects
21、Floor 3 and four servers. Each floor LAN is basically a shared Ethernet connecting employee PCs with workgroup and printer servers. The network makes use of VLANs in order to isolate broadcast and multicast traffic. A total of five LANs exist. All VLANs are port based. Switch 1 is configured such th
22、at it has three VLANs. VLAN1 includes the database and file servers. VLAN2 includes Floor 1. VLAN3 includes Floor2. On the other hand, Switch 2 is configured to have two VLANs. VLAN4 includes the servers for E-mail, HTTP, Web and cache proxy, and firewall. VLAN5 includes Floor 3. All the links are s
23、witched Ethernet 100 Mbps full duplex except for the links for Floors 1–3 which are shared Ethernet 100 Mbps half duplex. 3 Step-by-step methodology Fig. 2 shows a flowchart of a methodology of eight steps for a successful VoIP deployment. The first four steps are independent and can be perfo
24、rmed in parallel. Before embarking on the analysis and simulation study, in Steps 6 and 7, Step 5 must be carried out which requires any early and necessary redimensioning or modifications to the existing network. As shown, both Steps 6 and 7 can be done in parallel. The final step is pilot deployme
25、nt. 3.1. VoIP traffic characteristics, requirements, and assumptions For introducing a new network service such as VoIP, one has to characterize first the nature of its traffic, QoS requirements, and any additional components or devices. For simplicity, we assume a point-to-point conversation for
26、 all VoIP calls with no call conferencing. For deploying VoIP, a gatekeeper or Call Manager node has to be added to the network [3,4,5]. The gatekeeper node handles signaling for establishing, terminating, and authorizing connections of all VoIP calls. Also a VoIP gateway is required to handle exter
27、nal calls. A VoIP gateway is responsible for converting VoIP calls to/from the Public Switched Telephone Network (PSTN). As an engineering and design issue, the placement of these nodes in the network becomes crucial. We will tackle this issue in design step 5. Other hardware requirements include a
28、VoIP client terminal, which can be a separate VoIP device, i.e. IP phones, or a typical PC or workstation that is VoIP-enabled. A VoIP-enabled workstation runs VoIP software such as IP Soft Phones . Fig. 3 identifies the end-to-end VoIP components from sender to receiver [9]. The first component
29、is the encoder which periodically samples the original voice signal and assigns a fixed number of bits to each sample, creating a constant bit rate stream. The traditional sample-based encoder G.711 uses Pulse Code Modulation (PCM) to generate 8-bit samples every 0.125 ms, leading to a data rate of
30、64 kbps . The packetizer follows the encoder and encapsulates a certain number of speech samples into packets and adds the RTP, UDP, IP, and Ethernet headers. The voice packets travel through the data network. An important component at the receiving end, is the playback buffer whose purpose is to ab
31、sorb variations or jitter in delay and provide a smooth playout. Then packets are delivered to the depacketizer and eventually to the decoder which reconstructs the original voice signal. We will follow the widely adopted recommendations of H.323, G.711, and G.714 standards for VoIP QoS requirements
32、. Table 1 compares some commonly used ITU-T standard codecs and the amount of one-way delay that they impose. To account for upper limits and to meet desirable quality requirement according to ITU recommendation P.800, we will adopt G.711u codec standards for the required delay and bandwidth. G.
33、711u yields around 4.4 MOS rating. MOS, Mean Opinion Score, is a commonly used VoIP performance metric given in a scale of 1–5, with 5 is the best. However, with little compromise to quality, it is possible to implement different ITU-T codecs that yield much less required bandwidth per call and rela
34、tively a bit higher, but acceptable, end-to-end delay. This can be accomplished by applying compression, silence suppression, packet loss concealment, queue management techniques, and encapsulating more than one voice packet into a single Ethernet frame. 3.1.1. End-to-end delay for a single voice p
35、acket Fig. 3 illustrates the sources of delay for a typical voice packet. The end-to-end delay is sometimes referred to by M2E or Mouth-to-Ear delay. G.714 imposes a maximum total one-way packet delay of 150 ms end-to-end for VoIP applications . In [22], a delay of up to 200 ms was considered to b
36、e acceptable. We can break this delay down into at least three different contributing components, which are as follows (i) encoding, compression, and packetization delay at the sender (ii) propagation, transmission and queuing delay in the network and (iii) buffering, decompression, depacketization,
37、 decoding, and playback delay at the receiver. 3.1.2. Bandwidth for a single call The required bandwidth for a single call, one direction, is 64 kbps. G.711 codec samples 20 ms of voice per packet. Therefore, 50 such packets need to be transmitted per second. Each packet contains 160 voice sample
38、s in order to give 8000 samples per second. Each packet is sent in one Ethernet frame. With every packet of size 160 bytes, headers of additional protocol layers are added. These headers include RTP+UDP+IP+Ethernet with preamble of sizes 12+8+20+26, respectively. Therefore, a total of 226 bytes, or
39、1808 bits, needs to be transmitted 50 times per second, or 90.4 kbps, in one direction. For both directions, the required bandwidth for a single call is 100 pps or 180.8 kbps assuming a symmetric flow. 3.1.3. Other assumptions Throughout our analysis and work, we assume voice calls are symmetric a
40、nd no voice conferencing is implemented. We also ignore the signaling traffic generated by the gatekeeper. We base our analysis and design on the worst-case scenario for VoIP call traffic. The signaling traffic involving the gatekeeper is mostly generated prior to the establishment of the voice call
41、 and when the call is finished. This traffic is relatively small compared to the actual voice call traffic. In general, the gatekeeper generates no or very limited signaling traffic throughout the duration of the VoIP call for an already established on-going call. In this paper, we will implement no
42、 QoS mechanisms that can enhance the quality of packet delivery in IP networks. A myriad of QoS standards are available and can be enabled for network elements. QoS standards may include IEEE 802.1p/Q, the IETF’s RSVP, and DiffServ. Analysis of implementation cost, complexity, management, and benefi
43、t must be weighed carefully before adopting such QoS standards. These standards can be recommended when the cost for upgrading some network elements is high and the network resources are scarce and heavily loaded. 3.2. VoIP traffic flow and call distribution Knowing the current telephone call usag
44、e or volume of the enterprise is an important step for a successful VoIP deployment. Before embarking on further analysis or planning phases for a VoIP deployment, collecting statistics about of the present call volume and profiles is essential. Sources of such information are organization’s PBX, te
45、lephone records and bills. Key characteristics of existing calls can include the number of calls, number of concurrent calls, time, duration, etc. It is important to determine the locations of the call endpoints, i.e. the sources and destinations, as well as their corresponding path or flow. This wi
46、ll aid in identifying the call distribution and the calls made internally or externally. Call distribution must include percentage of calls within and outside of a floor, building, department, or organization. As a good capacity planning measure, it is recommended to base the VoIP call distribution
47、on the busy hour traffic of phone calls for the busiest day of a week or a month. This will ensure support of the calls at all times with high QoS for all VoIP calls. When such current statistics are combined with the projected extra calls, we can predict the worst-case VoIP traffic load to be intro
48、duced to the existing network. Fig. 4 describes the call distribution for the enterprise under study based on the worst busy hour and the projected future growth of VoIP calls. In the figure, the call distribution is described as a probability tree. It is also possible to describe it as a probab
49、ility matrix. Some important observations can be made about the voice traffic flow for inter-floor and external calls. For all these type of calls, the voice traffic has to be always routed through the router. This is so because Switchs 1 and 2 are layer 2 switches with VLANs configuration. One can
50、observe that the traffic flow for inter-floor calls between Floors 1 and 2 imposes twice the load on Switch 1, as the traffic has to pass through the switch to the router and back to the switch again. Similarly, Switch 2 experiences twice the load for external calls from/to Floor 3. 3.3. Define per
51、formance thresholds and growth capacity In this step, we define the network performance thresholds or operational points for a number of important key network elements. These thresholds are to be considered when deploying the new service. The benefit is twofold. First, the requirements of the new
52、service to be deployed are satisfied. Second, adding the new service leaves the network healthy and susceptible to future growth. Two important performance criteria are to be taken into account. First is the maximum tolerable end-to-end delay; and second is the utilization bounds or thresholds of ne
53、twork resources. The maximum tolerable end-to-end delay is determined by the most sensitive application to run on the network. In our case, it is 150 ms end-to-end for VoIP. It is imperative to note that if the network has certain delay sensitive applications, the delay for these applications should
54、 be monitored, when introducing VoIP traffic, such that they do not exceed their required maximum values. As for the utilization bounds for network resources, such bounds or thresholds are determined by factors such as current utilization, future plans, and foreseen growth of the network. Proper res
55、ource and capacity planning is crucial. Savvy network engineers must deploy new services with scalability in mind, and ascertain that the network will yield acceptable performance under heavy and peak loads, with no packet loss. VoIP requires almost no packet loss. In literature, 0.1–5% packet loss
56、was generally asserted. However, in [24] the required VoIP packet loss was conservatively suggested to be less than 10. A more practical packet loss, based on experimentation, of below 1% was required in [22]. Hence, it is extremely important not to utilize fully the network resources. As rule-of-th
57、umb guideline for switched fast full-duplex Ethernet, the average utilization limit of links should be 190%, and for switched shared fast Ethernet, the average limit of links should be 85% [25]. The projected growth in users, network services, business, etc. must be all taken into consideration to e
58、xtrapolate the required growth capacity or the future growth factor. In our study, we will ascertain that 25% of the available network capacity is reserved for future growth and expansion. For simplicity, we will apply this evenly to all network resources of the router, switches, and switched-Ethern
59、et links. However, keep in mind this percentage in practice can be variable for each network resource and may depend on the current utilization and the required growth capacity. In our methodology, the reservation of this utilization of network resources is done upfront, before deploying the new ser
60、vice, and only the left-over capacity is used for investigating the network support of the new service to be deployed. 3.4. Perform network measurements In order to characterize the existing network traffic load, utilization, and flow, network measurements have to be performed. This is a crucial s
61、tep as it can potentially affect results to be used in analytical study and simulation. There are a number of tools available commercially and noncommercially to perform network measurements. Popular open-source measurement tools include MRTG, STG, SNMPUtil, and GetIF [26]. A few examples of popular
62、 commercially measurement tools include HP OpenView, Cisco Netflow, Lucent VitalSuite, Patrol DashBoard, Omegon NetAlly, Avaya ExamiNet, NetIQ Vivinet Assessor, etc. Network measurements must be performed for network elements such as routers, switches, and links. Numerous types of measurements and s
63、tatistics can be obtained using measurement tools. As a minimum, traffic rates in bits per second (bps) and packets per second (pps) must be measured for links directly connected to routers and switches. To get adequate assessment, network measurements have to be taken over a long period of time, at
64、 least 24-h period. Sometimes it is desirable to take measurements over several days or a week. One has to consider the worst-case scenario for network load or utilization in order to ensure good QoS at all times including peak hours. The peak hour is different from one network to another and it dep
65、ends totally on the nature of business and the services provided by the network. Table 2 shows a summary of peak-hour utilization for traffic of links in both directions connected to the router and the two switches of the network topology of Fig. 1. These measured results will be used in our ana
66、lysis and simulation study. 外文文獻(xiàn)譯文 以太網(wǎng)網(wǎng)絡(luò)電話傳送調(diào)度:方法論和案例分析 Khaled Salah , 信息與計(jì)算機(jī)科學(xué), Fahd University 皇家石油礦物大學(xué), 信箱5066, Dhahran 31261, 沙特阿拉伯半島 收到日期2004 年5月25 日; 校正日期2005 年6月3 日; 接受日期2005 年6月3 日。網(wǎng)上可用日期2005 年7月1 日。 摘 要 對(duì)網(wǎng)絡(luò)數(shù)據(jù)研究者和設(shè)計(jì)師來說,IP電話或語音IP電話調(diào)度是一項(xiàng)重大而艱巨的任務(wù)。本文概述的準(zhǔn)則和循序漸進(jìn)的方法,解釋了怎樣在IP上成功調(diào)度傳送語音。該方法可用于評(píng)估的支持,并準(zhǔn)備用在現(xiàn)有的網(wǎng)絡(luò)。此前購買并部署的網(wǎng)絡(luò)電話設(shè)備,這種方法預(yù)算出了在保證現(xiàn)有網(wǎng)絡(luò)服務(wù)質(zhì)量要求和日后足夠擴(kuò)充能力基礎(chǔ)上的網(wǎng)絡(luò)電話調(diào)用次數(shù)。作為一個(gè)研究的課題,我們把這種方法在一個(gè)典型的小型企業(yè)網(wǎng)上得到逐步應(yīng)用。我們運(yùn)用分析和模擬吞吐量和延遲區(qū)域。我們的分析基于排隊(duì)理論,并且OPNET用于模擬。理論分析和模擬結(jié)構(gòu)比較一致。此外,本文談?wù)摿嗽S多設(shè)計(jì)和
- 溫馨提示:
1: 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
2: 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
3.本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 裝配圖網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 領(lǐng)導(dǎo)班子2024年度民主生活會(huì)對(duì)照檢查材料范文(三篇)
- 金融工作主題黨課講稿范文(匯編)
- 鍋爐必備學(xué)習(xí)材料
- 鍋爐設(shè)備的檢修
- 主題黨課講稿:走中國特色金融發(fā)展之路加快建設(shè)金融強(qiáng)國(范文)
- 鍋爐基礎(chǔ)知識(shí):?jiǎn)t注意事項(xiàng)技術(shù)問答題
- 領(lǐng)導(dǎo)班子2024年度民主生活會(huì)“四個(gè)帶頭”對(duì)照檢查材料范文(三篇)
- 正常運(yùn)行時(shí)影響鍋爐汽溫的因素和調(diào)整方法
- 3.鍋爐檢修模擬考試復(fù)習(xí)題含答案
- 司爐作業(yè)人員模擬考試試卷含答案-2
- 3.鍋爐閥門模擬考試復(fù)習(xí)題含答案
- 某公司鍋爐安全檢查表
- 3.工業(yè)鍋爐司爐模擬考試題庫試卷含答案
- 4.司爐工考試題含答案解析
- 發(fā)電廠鍋爐的運(yùn)行監(jiān)視和調(diào)整