英文文献_科技类_原文及翻译_(电子_电气_自动化_通信)1

On the deployment of VoIP in Ethernet networks:

methodology and case study

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 methodology 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 adequate 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 obtained 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 impact 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 network 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 hand, 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 such 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 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 tools 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 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 resulting 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 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 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 discusses many practical issues pertaining to the deployment of VoIP. These issues include characteristics of VoIP

II

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 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 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 Existing network

III

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 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 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 that 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 switched 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

IV

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 performed 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 deployment.

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 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 external 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

V

hardware requirements include a 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 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 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 absorb 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.

Table 1 compares some commonly used ITU-T standard codecs and the amount of

VI

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.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 relatively 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 packet

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 be 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, 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 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 samples 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 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.

VII

3.1.3. Other assumptions

Throughout our analysis and work, we assume voice calls are symmetric and 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 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 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 benefit 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 usage 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, telephone 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 will 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 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.

VIII

When such current statistics are combined with the projected extra calls, we can predict the worst-case VoIP traffic load to be introduced 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 probability 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 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 performance 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 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.

IX

First is the maximum tolerable end-to-end delay; and second is the utilization bounds or thresholds of network 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 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 resource 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 was generally asserted. However, in [24] the required VoIP packet loss was conservatively suggested to be less than 105. 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-thumb 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 extrapolate 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-Ethernet 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 service, 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

X

measurements have to be performed. This is a crucial step 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 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 statistics 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 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 depends 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 analysis and simulation study.

XI

外文文献译文

以太网网络电话传送调度：方和案例分析

摘 要

对网络数据研究者和设计师来说，IP电话或语音IP电话调度是一项重大而艰巨的任务。本文概述的准则和循序渐进的方法，解释了怎样在IP上成功调度传送语音。该方法可用于评估的支持，并准备用在现有的网络。此前购买并部署的网络电话设备，这种方法预算出了在保证现有网络服务质量要求和日后足够扩充能力基础上的网络电话调用次数。作为一个研究的课题，我们把这种方法在一个典型的小型企业网上得到逐步应用。我们运用分析和模拟吞吐量和延迟区域。我们的分析基于排队理论，并且OPNET用于模拟。理论分析和模拟结构比较一致。此外，本文谈论了许多设计和工程问题。这些问题包括网络电话通信的特征和服务质量要求，网络电话流程和呼叫分配，定义未来增长容量，测定后台通信的影响。

XII

关键词：网络设计，网络管理，VoIP，性能评估，分析，模拟，OPNET

XIII

绪 论

最近大量的网络电话调度在数据网中占有相当的比例。其中大部分基于以太网和运行IP协议。不少网络管理员发现把语音和数据网合二为一非常有吸引力和具成本效应。这将更易于运行、管理和维护。然而，人们应该认识到IP网络目的是为了非实时应用服务；另一方面，网络电话要求带有低延迟、低抖动、低丢包率和充足的带宽。为了达到这一目标，必须保证在现有或新的IP网络中完成实时通信要求的高效网络电话调度。当在现有的网络部署譬如VoIP这样的新网络服务，许多网络架构师、经理、计划师、设计师和工程师面临着共同的目标和挑战。什么是网络电话的服务质量要求？新的网络电话负荷怎样冲击了当今运行中的网络服务和应用的质量？我们现有的网络将支持网络电话和将满足标准的服务质量要求吗？如果那样，在过早升级任何现有的网络硬件的零件前，能支持多少个的VoIP电话网络？这些富挑战性的问题导致了用于测试网络多媒体数据应用性能的商业工具的发展。支持网络电话的商用工具名单如表[1,2]。很大程度上，这些工具使用两种共同的方法把VoIP 部署入现有的网络。一种方法根据第一次执行的网络测量和然后预测支持VoIP的网络应该就绪情况。预测的网络情况是根据网络要素来估计的。第二种是根据加入到现有网络中VoIP的实时通信信息，然后测出延时时间、时基误差和丢包率。除相关的商业工具费用外，没有其它工具能够提供全面兼容的成功网络电话调度方法。特别是，无任何一个预测能给出网络可以支持的呼叫次数已提到设计和工程的议事日程上来。这些因素包括网络电话流程和呼叫分配、今后增长容量、性能极限、VoIP对现有网络服务和应用以及后台通信能力的冲击。本文尝试研究这些重要因素，规划出一个支持像网络电话和视频会议系统的全面可行方法。

无论如何，本文集中论述了网络电话服务调度新方法。文章同样包含了许多工程和设计指南，同时也讨论了许多与网络电话相关的实际问题。这些问题包括网络电话的通信和服务质量要求，网络电话数据流向和呼叫分配，定义今后的增长容量以及我们的方法和纲领怎样应用在像小型的企业网这样的典型网络中。其余部分作如下安排：第二部分论述了小型企业网的典型网络拓扑如何在网络电话中实现调度。第三部分大致描述了网络电话数据网调度实用的八个步骤。每一步骤都有详细的说明。第四部分介绍了基于分析和仿真研究得出的重要设计结论和工程结论。第五部分谈到了今后研究还需做的具体工作。

1

2 现有的网络

路由器 交换机1 交换机2 文件服数据库 务器 层2 互联网 打印机服务器 工作组服务器 一个小型企业网的逻辑图

图1 一个小型企业网的逻辑图

图1是在大厦中一个的小型企业网的典型网络拓扑图。图中所示真实网络情况仅用于研究目的；然而，我们文中提出的原理、框架和概念等工作成果将会更容易被大型网络采纳。这些网络都是通过一个路由连接的两个第二层以太网交换机。路由是卡西欧2621，交换机是3Com Superstack 3300。交换机1连接第一、二层和两个服务器；交换机2连接第三层和四个服务器。每一层的本地局域网就是一个连接有个人电脑的工作组和打印机服务器的共享以太网。网络利用虚拟局域网来隔离广播和组播拥塞。总计有五个局域网存在。所有虚拟局域网基于端口划分。交换机一配置三个虚拟局域网。虚拟局域网一包括数据库和文件服务器。虚拟局域网二包括层一。虚拟局域网三包括层二。另一方面，交换机二配置为含有两个虚拟局域网。虚拟局域网四包括邮件服务器、超文本协议、网页和缓存代理以及防火墙。虚拟局域网五包括层三。除了层1-3是100Mbps的半双工以太网其余链接都是100Mbps速率全双工的以太网。

2

3 步进的方

前面网络评估和更改 分析 模拟 前端调度 表明方法步骤的流程图 图 1表明方法步骤的流程图

图2表示了一个成功的网络电话调度八步骤流程图。前面四步是的，可以并行运行。在封装分析和模拟研究前，作为前面网络评估和更改的第5步必须先执行。如图，步骤6和7可以并行执行。最后一步是前端调度。 3.1 网络电话通信特征、要求和假想

要介绍像网络电话这样的服务，首先要概括出它通信的本质、服务质量要求和其它原因或设备问题。出于简单考虑，我们假定在一个没有呼叫协商的点对点对话网络电话呼叫。对网络电话调度来说，网络节点或呼叫管理器节点必须添加到网络[3,4,5]。网络节点处理用于建立、终止和受权所有网络电话呼叫的连接，同时也要处理外部的呼叫。网络电话负责转换网络电话呼叫到公共交换电话网(或反向)。作为一个工程和设计课题，如何放置这些网络中的节点变得至关紧要。在步骤5中我们会谈到如何处理这个问题。其它硬件要求包括网络电话客户终端(例如网络电话机或典型的个人电脑又或是含有激活网络电话的工作站)可以是的设备。激活网络电话的工作站运行着像IP电话这样

3

的软件。

编码 封装 解包 解码

图 2 网络电话端到端器件

图3表示了一个端对端网络电话的发送和接收器件。第一个器件是编码器，它用于周期性采集原始声音信号和分配固定的比特位给每一个样本，产生一个常速率的比特流。传统的样本采集编码器G.711利用脉冲编码调制来产生每0.125 ms 的8位比特的样本，从而产生 kbps的数据速率。压缩包随着编码器压入一定数量的语音标本到信息包，然后加入实时位置、用户数据报、网际协议和以太网报头等信息。语音信号包随之流向数据网络。在接收端有一个重要的元件，它是为了吸收变调的声音和抖动失真的录音回放缓冲器，同时也是为了提供平滑过度的释放。然后数据包被传送至解压器，最终还原成原始声音信号。我们会采用大量被推荐网络电话的H.323、 G.711、和G.714服务质量保证标准。

表 1标准ITU-T编码器和其默认值

标准ITU-T编码器和其默认值 A/D转换延迟

表1对使用国际电信联盟标准的多媒体数字信号编解码器和大量强制要求的单声道的延迟标准作了一个比较。为了达到上层要求和满足国际电信联盟推荐的质量要求标准P.800,我们采用G.711u编解码器标准来满足延时和带宽要求。G.711u产生4.4等

4

级MOS。MOS，意思为一种经常用在网络电话性能指标中的评价标准，有1-5个等级，第5级为最好。然而，为了折衷小小的质量问题，最有可能执行每次呼叫需求带宽更少、相关程度稍高、更能接受的端到端的延迟时间的ITU-T编解码器的不同标准。这将通过用密集的、静默压缩的、隐蔽的小包丢失数、队列管理技术和把超过一个声音信号包封装在单个以太网帧中。 3.1.1 单声道的端到端延迟

图3阐述了典型语音包延迟的缘由。这端到端的延迟有时归结于M2E或口到耳的延迟。G.714提出了单声道最大总数不超过150ms的网络电话端到端应用。在[22]提到不超过200ms的延迟是可以接受的。我们能够通过下列最少三种起作用的元件降低延迟：(i)发送端的编码、压缩和解压延迟；(ii)传播、运输和网络中的排队延迟；(iii)接收端的缓冲、解压、解码、录音重放延迟。 3.1.2 单个呼叫的带宽

单个呼叫的带宽要求，一个参数就是 kbps。G.711多媒体编解码器每个语音包20ms的采样。因此，每秒必需有50个这样的数据包。每个包中包含160语音样本目的是为了达到8000每秒的采样率。每个包通过单个以太网帧传送。每个包有160字节大小，再加上协议各层的报头信息。这些报头包括12+8+20+26对应大小的RTP+UDP+IP+Ethernet信息。因此，总共有226字节(或1808位)的信息需要每秒传送50次，或一次传送90.4 kbps。对于每个参数来说，一次呼叫需求的带宽是100 脉冲/秒或均衡的180.8 kbps数据流。 3.1.3 其余假设

纵览我们的分析和研究工作，可以假设语音呼叫次数是均衡的而且语音协商被得到有效执行。我们也忽视了网关的信号拥塞。基于对网络电话呼叫拥塞最坏情况的分析和研究，网关最有可能在建立呼叫和拆除呼叫时产生发送拥塞。比起实际语音呼叫拥塞来说这还是相对较小的。总体上，在一个已经建立好并且在运行的网络电话呼叫持续时间内，网关中产生非常少或没有信号拥塞。本文我们将使用非服务质量 (能增强在IP网络层传输包的质量的一种服务) 的设备。许多的服务质量标准能够被网络设备运用。服务质量标准包括IEEE 802.1p/Q、 the IETF’s RSVP、和DiffServ。分析运行开支、复杂性、管理和利益必须在采用服务质量标准前好好衡量一下。当网络资源稀少且负荷严重需升级一些花费较贵的网络设备时就应该推荐这种标准。

5

3.2 网络电话信息流和呼叫分布情况

要明白现在的电话呼叫方法和企业的容量需求是成功的网络电话调度的重要步骤。在着手分析更深层意义的网络电话调度计划阶段，收集静止的现有呼叫量和网络电话的整体框架情况是很有必要的。像这样的信息是组织机构的专用分组交换机、电话清单。现有呼叫的关键问题包括呼叫次数、并发呼叫的次数、时间、持续时间等等。测定呼叫终端的位置显得很重要，例如源和目的地、传输路径和流向。这将有助于辨别呼叫分布情况和内外部的呼叫。呼叫分布情况必须包含在楼层里面和外面的呼叫百分比、建筑物、部门和组织机构。作为一个良好容量测量，建议基于一个星期或一个月中的最繁忙时期网络电话呼叫分布情况。这将能保证任何时期都有高服务质量的网络电话呼叫支持。当现今的数据表计划外的呼叫结合起来的时候，我们可以推测现有网络中最糟糕的网络电话负载。

网络电话呼叫分配概率树型图

图 3网络电话呼叫分配概率树型图

图4描述了基于最繁忙时段的企业呼叫分布情况。在图中，呼叫分布情况被描述成概率树形式。这也可以说成是概率矩阵。一些重要资料可以通过内外部的语音信息流得出。对所有类型的呼叫来说，语音信息流都 要通过路由器进行路由选择。这是因为交换机1和2是第2层虚拟以太网设备。可以通过交换机1的层1和层2之间两次负载看出拥塞流向，因为信息包要通过交换机到达路由再返回到交换机。类似，交换机2从(到)第3层经历了两次外部呼叫的负载。

6

3.3 定义性能极限和增长容量

在这一步，我们对许多重要的网络关键设备进行了性能极限或操作点的定义。当调度新的服务时这些极限值得考虑。好处是双重的。首先是新服务调度要求令人满意；其次，增加新的设备使网络更健康良性发展。这两个性能标准正被提到议事日程上来。第一是端到端延迟的最大容忍极限；第二是网络资源的极限。端到端延迟的最大极限由运行在网络中的灵敏应用服务决定。在我们的案例中，对网络电话来说端到端的延迟是150ms。如果网络的灵敏应用有一定的延迟，当研究网络电话拥塞时对这些应用的延迟监控显得很有必要，这样他们就不会超过最大极限了。对网络资源的应用范围来说，这样的范围和极限由当前应用和将来的计划以及可预见的网络增长决定。恰当的资源和容量计划是至关紧要的。聪明的网络工程师必须把新服务调度的可量测性放在脑中，保证网络在重载和轻载的时候都会产生满意的性能和没有包的丢失。网络电话要求几乎没有包的丢失。在文献中，0.1～5%丢失包是经常的事。然而在文章[24]中网络电话丢失包被建议为减少至低于10。文章[22]提到了基于实验得出的一个更实际的包丢失数是低于1%。因此，不要全部使用网络资源显得非常重要。因为单凭经验得出对快速交换全双工以太网的方法，平均使用在85%以内。用户计划的增长数、网络服务、繁忙程度都必须纳入考虑范围之内以此推断增长容量要求和未来增长因素。在我们的研究中，我们假设有25%的网络空闲容量可以用做将来增长之用。同样的，我们甚至把这种应用到像路由、交换机和交换以太网链接这些网络设备中。尽管如此，在实际中，应该留有对每个网络资源的这种比例和对当前应用以及将来增长容量会变化的想法。在我们的拓扑图中，这种网络资源在新服务调度之前最先被保留利用，只有剩余容量被用来研究新服务调度的网络支持。 3.4 网络性能度量

为了表明现有网络通信负载、利用情况和流向，网络度量必须执行。这是一个关键性的步骤因为它可以潜在地影响分析研究和仿真结果。有很多商业或非商业工具可以用来进行网络度量。流行的开放资源度量工具有MRTG、STG、SNMPUtil和GetIF。一些流行的商业度量工具有HP OpenView, Cisco Netflow, Lucent VitalSuite, Patrol DashBoard, Omegon NetAlly, Avaya ExamiNet, NetIQ Vivinet Assessor等等。网络度量必须在诸如路由、交换机和链接的网络设备中运行。许多类型的度量数据和统计表可以通过度量工具获得。像一个最小的以比特每秒和包每秒的传输速度可通过直接链接到的路由器和交换机测量得出。为了得到恰当的估计，网络度量必须有一段时间，至少

7

5是24小时的周期。有时甚至需要测量几天或一个星期。为了保证有好的服务质量，我们必须考虑到网络负载的最坏使用情况，包括在最高峰时期。最高峰时期的网络各不相同，它由网络提供的服务的事务的性质决定。

表2最糟网络评估表

最糟网络评估表 比特率 包速率 利用率

表2显示了图1中双向链接的路由和两个交换机的网络拓扑图的最高峰拥塞情况。这些测量结果将会用于分析和仿真研究中。

摘自：《Int J Adv》 ，2005年创刊，第25期，Manuf Technol出版社出版，DOI收录期刊。 From: Int J Adv .Manuf Technol (2005) 25: 723–729 DOI 10.1007/s00170-003-1914-5

From: Khaled Salah, Department of Information and Computer Science, King Fahd University

of Petroleum and Minerals, 1 July 2005.

摘自：Khaled Salah , 《信息与计算机科学》, Fahd University 皇家石油矿物大学2005 年7月1 日。

8

9