简介：本资源是《通信网基础》课程第7章核心讲义，系统讲解排队论的基本概念与建模方法，面向通信工程、网络工程及相关专业本科生与研究生，助力理解通信系统性能分析的理论根基。内容涵盖排队系统的四大构成要素（到达过程、排队结构、排队规则、服务过程），深入解析M/M/1等经典模型的建模逻辑，并结合电话网络、计算机系统、数据网络及交通系统等实际场景说明应用价值；同时梳理泊松过程、负指数分布、Erlang分布等关键概率模型及其在排队分析中的物理意义。资源为单个PDF文件（4.6MB），由高校教师整理，排版清晰、公式规范、案例详实，含典型习题分类与参数辨析训练。目前已有199人学习下载，适合课堂预习、课后巩固及通信网性能建模入门实践。
1. 排队论不是数学游戏：它决定你的基站资源够不够、信令延迟高不高、甚至5G切片能不能稳住SLA
你有没有遇到过这样的现场问题：核心网信令面CPU常年跑在85%以上，但抓包看单次SIP注册耗时却忽高忽低，有时200ms，有时2.3秒；或者做VoLTE容量仿真时，明明按话务量公式算出来能扛3000并发，一压测就出现大量408 Request Timeout？这时候翻遍日志查不到具体瓶颈点——不是CPU爆了，不是内存溢了，也不是链路断了。真相往往藏在「排队」里：呼叫请求在MGCF前的缓冲队列里等了470ms才被调度，短信在SMSC的处理队列中滞留了1.8秒才落库。《通信网基础》第7章讲的排队论，不是教科书里的抽象λ/μ模型，而是通信系统资源设计的底层尺子——它把“等待”量化成可计算、可预测、可优化的工程参数。这份PDF虽薄（仅28页），但覆盖了M/M/1、M/M/c、M/G/1三类通信场景最常建模的排队结构，含服务强度ρ、平均队长L、平均等待时间W的推导逻辑、适用边界和物理映射。适合网络规划工程师做容量预估、传输工程师调优QoS策略、核心网运维人员定位隐性拥塞点。别跳过它——很多“玄学延迟”问题，根源就是没把排队模型和实际网元队列深度、调度周期对上号。
2. 从话务模型到队列参数：为什么M/M/1是通信网建模的起点，而不是终点
2.1 M/M/1模型的通信语义：它到底在描述什么实体？
M/M/1中的三个字母不是符号游戏，每个都对应真实网元行为：
- 第一个M（Markovian）：指到达过程服从泊松分布。这在通信网中高度贴合——用户发起呼叫、发送短信、触发HTTP请求的时间间隔，在宏观统计尺度下（如每分钟数百次）确实近似随机独立，符合无记忆性。注意：它不适用于突发性强的IoT上报（如烟感集中告警），此时需换用M/G/1或带burst的模型。
- 第二个M：指服务时间服从负指数分布。这是关键简化假设——意味着处理一个呼叫的时长不可预测，但平均处理速率恒定。例如：一个IMS CSCF处理SIP INVITE的耗时，受消息长度、路由复杂度、后端数据库响应影响，实测直方图常呈右偏，负指数分布是工程上最简且有效的拟合。
- 1：代表单服务台。对应单核CPU处理信令、单条TCP连接承载HTTP请求、单个DSP核处理语音编解码等典型串行处理单元。
提示：M/M/1的稳态存在条件是ρ = λ/μ < 1。其中λ是单位时间平均到达率（如：呼叫数/秒），μ是单位时间平均服务率（如：呼叫处理数/秒）。ρ > 1时系统必然拥塞，队列无限增长——这不是理论警告，而是现网扩容的硬红线。某省IMS局点曾因未校验ρ值，将μ按理论峰值（1200 cps）取值，实际业务中因协议栈开销导致有效μ仅850 cps，ρ达1.08，最终引发大规模注册失败。
2.2 从PDF公式到现网配置：L、W、Wq参数的物理映射表
《通信网基础》第7章给出的核心公式必须落地为可测量、可配置的参数。下表列出关键指标与网元配置项的映射关系（以主流IMS设备为例）：
| 公式指标 | 物理含义 | 对应网元监控项 | 典型阈值（参考） | 超限后果 |
|---|---|---|---|---|
| L = ρ/(1-ρ) | 系统内平均顾客数（含正在服务+排队中） | CSCF当前会话数 / 最大并发会话数 | ρ ≤ 0.7 → L ≤ 2.33 | L > 5时，新请求排队概率陡增 |
| W = 1/(μ-λ) | 顾客在系统中平均逗留时间（含服务+等待） | SIP事务端到端时延（P-CSCF到I-CSCF） | W ≤ 500ms（VoLTE） | W > 1s时用户感知明显卡顿 |
| Wq = ρ/(μ-λ) | 顾客平均等待时间（纯排队） | CSCF内部队列等待毫秒数（需开启debug日志） | Wq ≤ 100ms | Wq > 300ms时，重传率上升，丢包加剧 |
验证方法：在CSCF上执行show system performance，提取Current Active Sessions和Max Concurrent Sessions得ρ；用Wireshark抓取1000个INVITE-200 OK事务，计算端到端时延均值即W；再比对公式W = 1/(μ-λ)反推实际μ——若偏差>15%，说明服务时间不服从负指数分布，需切换模型。
2.3 手动验算：用Python复现M/M/1稳态概率分布（附调试技巧）
PDF中公式(7-12)给出系统中有n个顾客的概率Pₙ = (1-ρ)ρⁿ。我们用Python生成分布并可视化，验证ρ变化对队列长度的影响：
import numpy as np import matplotlib.pyplot as plt def mm1_pn(rho, n_max=20): """计算M/M/1系统中恰好有n个顾客的概率""" if rho >= 1: raise ValueError("rho must be < 1 for steady state") n = np.arange(0, n_max + 1) pn = (1 - rho) * (rho ** n) return n, pn # 模拟三种ρ值：0.5（宽松）、0.75（常用）、0.9（临界） rhos = [0.5, 0.75, 0.9] plt.figure(figsize=(10, 6)) for rho in rhos: n, pn = mm1_pn(rho) plt.plot(n, pn, 'o-', label=f'ρ = {rho}', linewidth=2, markersize=4) plt.xlabel('Number of customers in system (n)') plt.ylabel('Steady-state probability Pₙ') plt.title('M/M/1 Queue: Probability Distribution vs ρ') plt.legend() plt.grid(True, alpha=0.3) plt.yscale('log') # 对数纵轴更清晰显示尾部概率 plt.show() # 输出关键值：P₀（空闲概率）、Pₙ≥5（排队超5人的概率） for rho in rhos: _, pn = mm1_pn(rho, n_max=10) p0 = pn[0] p_n_ge_5 = pn[5:].sum() print(f"ρ={rho:.2f} → P₀={p0:.3f}, P(n≥5)={p_n_ge_5:.3f}")代码逻辑说明：
mm1_pn()函数直接实现PDF公式(7-12)，输入ρ输出各n值对应概率；plt.yscale('log')是关键——线性坐标下ρ=0.9时Pₙ≥5几乎看不见，但对数坐标暴露其高达0.409，意味着41%的请求要排5人以上队；- 输出中
P(n≥5)是运维黄金指标：当该值>0.2时，建议扩容或启用负载分担。
参数调整实战：若现网测得ρ=0.85，P(n≥5)=0.57，单纯增加μ（如升级CPU）成本高。更优解是降低λ——通过接入层限速（如PCRF策略限制单用户最大并发注册数），将ρ压至0.7以下，P(n≥5)骤降至0.12，效果立竿见影。
3. M/M/c模型实战：为什么核心网网元从来不用单服务台？
3.1 M/M/c与M/M/1的本质差异：c个并行服务台如何改变游戏规则？
M/M/c模型中，c代表并行服务台数量，这是对真实网元的关键修正。例如：
- 一台4核CSCF服务器，Linux调度器将其视为c=4个独立服务台（每个核处理一个SIP事务）；
- 一个含8个DSP核的媒体网关，c=8；
- 一个部署在K8s集群上的微服务，副本数replicas=6，则c=6。
PDF中公式(7-25)给出M/M/c的系统空闲概率P₀： $$ P_0 = \left[ \sum_{n=0}^{c-1} \frac{(\lambda/\mu)^n}{n!} + \frac{(\lambda/\mu)^c}{c!} \cdot \frac{1}{1-\rho/c} \right]^{-1} $$ 其中ρ = λ/μ仍为总负载，但稳定条件变为ρ < c（而非ρ < 1）。这意味着：4核服务器可承受ρ=3.8的负载而不拥塞，远高于单核的ρ<1。
注意：c不是简单等于CPU核数。若服务台间存在共享资源竞争（如共用内存总线、同一磁盘IO），实际c会打折扣。某次VoLTE压测中，8核服务器理论c=8，但因所有核争抢同一块SSD日志写入，实测c_eff≈5.2——务必用实测数据校准c值。
3.2 用Excel快速计算M/M/c关键指标（免编程落地法）
对不熟悉Python的规划工程师，PDF附录B提供了一套Excel计算模板。以下是手动构建步骤（以c=4，λ=3200 cps，μ=1000 cps为例）：
- 计算ρ = λ/μ = 3.2→ 因ρ < c（3.2 < 4），系统稳态成立；
- 计算P₀：在Excel中输入公式
=1/(SUMPRODUCT((3.2^ROW(1:4)-1)/FACT(ROW(1:4)-1)) + (3.2^4)/FACT(4)/(1-3.2/4))
（注：ROW(1:4)生成1,2,3,4；需按Ctrl+Shift+Enter作为数组公式）
得P₀ ≈ 0.021； - 计算平均队长L：PDF公式(7-28)
L = ρ + (ρ^(c+1))/(c! * c * (1-ρ/c)^2) * P₀
Excel中：=3.2 + (3.2^5)/(FACT(4)*4*(1-3.2/4)^2)*0.021→ L ≈ 4.8； - 计算平均等待时间Wq：公式(7-30)
Wq = Lq / λ，其中Lq = L - ρ → Lq = 1.6，Wq = 1.6 / 3200 = 0.0005秒 = 0.5ms。
结论：该配置下平均等待时间仅0.5ms，远优于VoLTE要求的100ms。但若λ升至3800 cps（ρ=3.8），重新计算得Wq=12.7ms——仍在安全范围；而λ=4100 cps（ρ=4.1 > c）时，公式失效，系统崩溃。
3.3 避坑：M/M/c模型三大常见误用与血泪排查
现象1：按c=CPU核数配置后，压测Wq远高于公式预测值
原因：忽略了服务台间资源争抢。4核服务器若所有核共用同一PCIe SSD，IO成为瓶颈，实际c_eff < 4。
解决：用iostat -x 1监控%util，若持续>90%，说明IO饱和，需更换NVMe盘或分散存储路径；或用perf stat -e cycles,instructions,cache-misses分析CPU缓存未命中率，>5%表明内存带宽不足。
现象2：ρ < c时系统仍频繁超时
原因：到达过程不满足泊松假设。例如节假日彩铃平台突增流量，呈现脉冲式到达（burst），M/M/c失效。
解决：改用M/G/c或带burst的MAP（Markov Arrival Process）模型；短期应急可启用队列长度限速（如Linux tc命令设置qdisc limit），丢弃超长队列请求保核心。
现象3：P₀计算结果为负数或无穷大
原因：Excel公式中阶乘FACT(c)溢出（c>170时FACT失效），或ρ/c ≥ 1未提前校验。
解决：对c>100的场景，改用Python的math.gamma()计算（gamma(c+1) = factorial(c)），或直接使用PDF中提供的近似公式(7-32)。
4. M/G/1模型精要：当服务时间不服从负指数分布时怎么办？
4.1 为什么M/G/1是通信网的“后悔药”模型？
M/M/1和M/M/c的成功依赖于服务时间服从负指数分布这一强假设。但现实网元中，大量场景违背此假设：
- 媒体网关：语音编解码耗时取决于语音活动检测（VAD）状态，静音段短、语音段长，服务时间呈双峰分布；
- 防火墙：小包（SYN）处理快，大包（视频流）需深度检测，服务时间方差极大；
- DNS递归服务器：缓存命中时响应<10ms，缓存未命中需上游查询，耗时可达500ms+。
此时M/G/1模型登场——它只假设到达过程为泊松（M），服务时间服从任意分布（G），只需知道其均值E[S]和方差Var[S]。PDF公式(7-41)给出其平均等待时间： $$ W_q = \frac{\lambda E[S^2]}{2(1-\rho)} $$ 其中E[S²] = Var[S] + (E[S])²，方差项是关键：服务时间越不均匀（Var[S]越大），Wq越长。
4.2 用Wireshark实测E[S]和Var[S]：三步定位服务时间分布
以DNS服务器为例，获取真实服务时间分布：
- 抓包过滤：
udp.port == 53 && dns.flags.response == 1，导出为dns.pcap； - 提取服务时间：用tshark命令计算每个响应相对于其请求的延迟：
用Python脚本关联req.txt与resp.txt的dns.id，计算每个事务延迟Δt；tshark -r dns.pcap -Y "dns.flags.response==1" \ -T fields -e frame.time_epoch -e dns.id \ -o "gui.column.format:\"Time\",\"%Cus:frame.time_epoch\"" > resp.txt tshark -r dns.pcap -Y "dns.flags.response==0" \ -T fields -e frame.time_epoch -e dns.id \ -o "gui.column.format:\"Time\",\"%Cus:frame.time_epoch\"" > req.txt - 拟合分布：将Δt序列导入Python，用
scipy.stats.kstest检验是否服从负指数分布：from scipy import stats # 假设deltas是延迟列表（单位：秒） kstest_result = stats.kstest(deltas, 'expon', args=(0, np.mean(deltas))) print(f"KS test p-value: {kstest_result.pvalue}") # p < 0.05拒绝负指数假设
若p-value=0.002，确认服务时间不服从负指数分布，则必须用M/G/1。此时E[S] = mean(deltas)，Var[S] = var(deltas)，代入公式即可得真实Wq。
4.3 M/G/1的工程化简化：利用“服务时间方差放大系数”
PDF未明说，但一线经验是：对大多数通信网元，服务时间方差可表示为
$$ \text{Var}[S] = \alpha \cdot (E[S])^2 $$
其中α是方差放大系数。实测经验值：
- 理想负指数分布：α = 1；
- DNS缓存未命中主导：α ≈ 3~5；
- 视频转码服务：α ≈ 8~12。
则M/G/1的Wq可简化为：
$$ W_q = \frac{\lambda (1+\alpha) (E[S])^2}{2(1-\rho)} $$
对比M/M/1的Wq = λ(E[S])² / (2(1-ρ))，放大倍数为(1+α)。若α=4，则同样ρ下，等待时间是M/M/1的5倍！这就是为何DNS服务器需更大冗余度。
5. 排队论在现网的四大落地场景与参数校准法
5.1 场景1：IMS核心网容量规划——用ρ校准License与硬件配置
某运营商新建IMS局点，采购合同约定支持50万注册用户。规划步骤：
- 估算λ：按每人日均20次注册（含开机、漫游、重注册），忙时集中度30%，则忙时注册率λ = 500000 × 20 × 0.3 / 3600 ≈ 833 cps；
- 实测μ：在测试环境用SIPp压测单台CSCF，记录不同并发下的成功cps，拟合μ = 1100 cps（非标称值1200）；
- 选c：ρ = λ/μ = 0.757，取c=2（双机热备），ρ/c = 0.378 < 1，满足；
- 校准License：厂商License按“并发会话数”计费，公式L = ρc/(1-ρ) = 0.757×2/(1-0.757) ≈ 6.25，故需购买≥7万并发License（非50万用户数）。
提示：License采购常犯错——按用户数买，而非按L值买。实际L=6.25万，若买50万License，浪费43.75万额度；若只买5万，则拥塞。
5.2 场景2：传输网QoS策略制定——用Wq设定队列深度与丢弃门限
在PTN设备上配置EF（ Expedited Forwarding）队列保障VoLTE：
- 设VoLTE单用户峰值带宽128kbps，5000并发需640Mbps；
- 设备端口带宽1Gbps，剩余带宽360Mbps用于其他业务；
- 用M/M/1模型，λ=5000 cps（呼叫建立率），μ=6000 cps（端口处理能力），ρ=0.833；
- 计算Wq = ρ/(μ-λ) = 0.833/(6000-5000) = 0.000833s = 0.833ms；
- 要求端到端Wq ≤ 10ms，当前0.833ms达标；
- 队列深度设置：最大允许排队数 = λ × Wq_max = 5000 × 0.01 = 50个包；
- RED丢弃门限：设min-threshold=30，max-threshold=45，避免早丢包。
5.3 场景3：无线接入网拥塞识别——从KPI反推隐性排队
某4G小区PRB利用率95%，但用户投诉“上网慢”。常规排查无果。用排队论反推：
- 提取KPI：RRC连接建立成功率98.2%（正常），E-RAB建立成功率92.5%（偏低）；
- E-RAB建立失败主因：“No Resource Available”占73%；
- 此即排队论中的阻塞概率B，对应M/M/c/c模型（损失制，无排队）；
- 查Erlang-B公式表，当c=100（PRB数），B=0.075 → 查得ρ≈95%，与PRB利用率吻合；
- 结论：非故障，是真实拥塞，需扩容PRB或启用负荷均衡。
5.4 场景4：5G SA核心网切片SLA保障——用多队列模型分解端到端延迟
5G URLLC切片要求uRLLC业务端到端时延≤10ms。分解至各网元：
| 网元 | 模型 | ρ | Wq计算 | 贡献时延 |
|---|---|---|---|---|
| AMF | M/M/4 | 0.6 | 0.15ms | 0.15ms |
| SMF | M/G/1 (α=2) | 0.5 | 0.42ms | 0.42ms |
| UPF | M/M/8 | 0.7 | 0.28ms | 0.28ms |
| 合计 | — | — | — | 0.85ms |
剩余9.15ms留给传输与空口——证明切片SLA可行。若SMF实测α=5，则Wq升至1.05ms，总和超10ms，需为SMF单独分配更多vCPU。
6. 把PDF公式变成肌肉记忆：我的三次翻车与强制校验清单
第一次翻车是在做VoNR容量报告时。我直接用了设备商给的μ=1500 cps，算出ρ=0.68，结论“资源充足”。上线后首周，凌晨2点突发注册风暴，CSCF CPU飙到99%，Wq实测达3.2秒。复盘发现：设备商μ值是在理想网络条件下测的，现网因DNS解析延迟、HSS交互RTT增加，实际μ跌至920 cps，ρ=1.12 > 1。从此我养成了三必查习惯：
- 必查μ的实测来源：要求供应商提供在相同网络拓扑、相同后端依赖（DNS、HSS、ENUM）下的压测报告，而非实验室数据；
- 必查ρ的实时监控：在网管系统中固化ρ = 当前会话数 / 最大并发数 的KPI，并设置ρ > 0.85告警；
- 必查Wq的端到端验证：每月用SIPp模拟1000次注册，抓包计算Wq，与公式预测值比对，偏差>20%即触发模型复审。
第二次翻车是误用M/M/1于媒体网关。我按平均编解码耗时15ms算μ，得出ρ=0.4，认为冗余充足。但用户投诉视频卡顿。用Wireshark分析发现：VAD关闭时耗时5ms，VAD开启时耗时45ms，Var[S]极大，α≈8。按M/G/1重算Wq，飙升至18ms，远超视频流畅阈值。现在我处理任何媒体面网元，第一件事就是抓包跑KS检验，p<0.05就切M/G/1。
第三次翻车最痛——在5G切片设计中，我把UPF的c设为vCPU数8，但忽略其DPDK转发需独占CPU核，实际c_eff=6。导致SLA承诺失效。现在我的校验清单加了第4条：查服务台隔离性。对DPDK、SR-IOV等场景，c取可用独占核数，而非总核数。
从那以后我每次做容量设计，都强制走一遍这四条：查μ来源、盯ρ监控、验Wq实测、核c隔离。不是为了显得严谨，而是因为通信网的排队没有“差不多”，ρ=0.99和ρ=1.01之间，是平稳运行与全网雪崩的分界线。这份PDF的28页，我翻了17遍，每遍都在补一个坑。希望帮到你。
本文还有配套的精品资源，点击获取
