Amazon Best VPN GoSearch

OnWorks 网站图标

ns-3-model-library - 云端在线

通过 Ubuntu Online、Fedora Online、Windows 在线模拟器或 MAC OS 在线模拟器在 OnWorks 免费托管服务提供商中运行 ns-3-model-library

这是命令 ns-3-model-library,可以使用我们的多个免费在线工作站之一在 OnWorks 免费托管服务提供商中运行,例如 Ubuntu Online、Fedora Online、Windows 在线模拟器或 MAC OS 在线模拟器

程序:

您的姓名


ns-3-model-library - ns-3 模型库

这是 ns-3 型号 自学资料库 文档。 ns-3 项目的主要文档
有五种形式:

· ns-3 Doxygen的: 模拟器的公共 API 的文档

· 教程、手册和模型库 (这个 文件) 等加工。为 最新 释放
发展

· ns-3 维基

这份文件是写在 reStructuredText的 人头狮身 并保持在
文档/模型 ns-3 的源代码目录。

业务组织


本手册汇编了用于 ns-3 模型和支持软件,使
用户构建网络模拟。 重要的是要区分 模块
模型:

· ns-3 软件被组织成单独的 模块 每个都作为单独的
软件库。 单独的 ns-3 程序可以链接他们需要的模块(库)
进行他们的模拟。

· ns-3 模型 是现实世界对象、协议、设备等的抽象表示。

An ns-3 模块可能包含多个模型(例如, 模块
包含 TCP 和 UDP 模型)。 一般来说,ns-3 模型不会跨越多个
然而,软件模块。

本手册提供了有关型号的文档 ns-3. 它补充了另外两个
关于模型的文件来源:

· 从编程的角度来看,模型 API 被记录在案,使用 Doxygen的. 多氧
适用于 ns-3 型号 on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 项目 卷筒纸 服务器.

· 这 ns-3 core 记录在开发人员手册中。 ns-3 模型利用
核心的设施,如属性、默认值、随机数、测试
框架等。请咨询 卷筒纸 网站 找到手册的副本。

最后,关于各个方面的附加文档 ns-3 可能存在于 项目
维基.

可以通过执行以下命令找到如何编写模型库文档的示例大纲
创建模块.py 程序并查看文件中创建的模板
新模块/文档/新模块.rst.

$ 光盘源
$ ./create-module.py 新模块

本文档的其余部分按模块名称的字母顺序组织。

如果你是新来 ns-3,您可能首先想阅读以下有关网络模块的信息,其中
包含模拟器的一些基本模型。 数据包模型,模型为
不同的地址格式,以及节点、网络等对象的抽象基类
那里讨论了设备、通道、套接字和应用程序。

动画


动画是网络仿真的重要工具。 尽管 ns-3 不包含
默认图形动画工具,我们目前有两种提供动画的方式,即
使用 PyViz 方法或 NetAnim 方法。 PyViz 方法在
http://www.nsnam.org/wiki/PyViz.

我们将在这里简要介绍 NetAnim 方法。

网动
NetAnim 是一个独立的、基于 Qt4 的软件可执行文件,它使用生成的跟踪文件
期间 ns-3 模拟以显示拓扑和动画之间的数据包流
节点。
[图片]有线链接上的数据包动画示例。 UNINDENT

此外,NetAnim 还提供了有用的功能,例如用于显示元数据的表格
如下图所示的数据包
[图像] 带有协议过滤器的数据包元数据表示例。UNINDENT

一种可视化移动节点轨迹的方法
[图像] 移动节点的轨迹示例。UNINDENT

一种在不同时间点显示多个节点的路由表的方法
[图片]

一种将与多个节点关联的计数器显示为图表或表格的方法
[图片]
[图片]

一种查看数据包发送和接收事件时间线的方法
[图片]

研究方法
类 ns3::AnimationInterface 负责创建跟踪 XML 文件。
AnimationInterface 使用跟踪基础设施来跟踪节点之间的数据包流。
AnimationInterface 将自身注册为 tx 和 rx 事件之前的跟踪钩子
模拟开始。 当一个数据包被安排发送或接收时,
调用 AnimationInterface 中相应的 tx 和 rx 跟踪钩子。 当 rx 挂钩时
被调用,AnimationInterface 将知道数据包之间的两个端点
已流动,并将此信息添加到跟踪文件中,以 XML 格式连同
相应的 tx 和 rx 时间戳。 XML 格式将在后面的部分中讨论。
需要注意的是,AnimationInterface 仅在 rx trace 时记录数据包
钩子被称为。 每个 tx 事件必须与一个 rx 事件匹配。

下载 网动
如果 NetAnim 在 ns-3 你下载的包,你可以做
在以下:

请确保您已安装 mercurial。 最新版本的 NetAnim 可以
使用 mercurial 使用以下命令下载:

$ hg 克隆 http://code.nsnam.org/netanim

建筑物 网动
硬件需求
构建 NetAnim 需要 Qt4(4.7 及更高版本)。 这可以使用以下方法获得
方法:

对于 Debian/Ubuntu Linux 发行版:

$ apt-get 安装 qt4-dev-tools

对于基于 Red Hat/Fedora 的发行版:

$ yum 安装 qt4
$ yum 安装 qt4-devel

对于 Mac/OSX,请参见 http://qt.nokia.com/downloads/

构建 步骤
要构建 NetAnim,请使用以下命令:

$ cd 网络动画
$ 清洁
$ qmake NetAnim.pro (MAC 用户:qmake -spec macx-g++ NetAnim.pro)
使

注意:在某些系统中,qmake 可能是“qmake-qt4”

这应该在同一目录中创建一个名为“NetAnim”的可执行文件:

$ ls -l 网络动画
-rwxr-xr-x 1 约翰约翰 390395 2012-05-22 08:32 NetAnim

用法
使用 NetAnim 是一个两步过程

步骤 1:在模拟过程中使用生成动画 XML 跟踪文件
“ns3::AnimationInterface”在 ns-3 代码库。

步骤2:使用离线的基于Qt1的动画器加载步骤4中生成的XML跟踪文件
名为网动。

步骤 1: 产生 XML 动画 追踪 文件
“src/netanim”下的“AnimationInterface”类使用底层 ns-3 追踪来源
以 XML 格式构造一个带时间戳的 ASCII 文件。

示例可在 src/netanim/examples 下找到示例:

$ ./waf -d 调试配置 --enable-examples
$ ./waf --run "哑铃动画"

以上将创建一个 XML 文件 dubbell-animation.xml

强制性
1. 确保您的程序的 wscript 包含“netanim”模块。 这样的一个例子
wscript 位于 src/netanim/examples/wscript。

2. 在你的测试程序中包含头文件 [#include "ns3/netanim-module.h"]

3. 添加语句

AnimationInterface 动画(“动画.xml”); // 其中“animation.xml”是任意文件名

[对于 ns-3.13 之前的版本,您还必须使用“anim.SetXMLOutput() 行来设置
XML 模式,也使用 anim.StartAnimation();]

可选
以下是可选但有用的步骤:

// 第1步
anim.SetMobilityPollInterval(秒(1));

AnimationInterface 默认每 250 ms 记录一次所有节点的位置。 这
上面的语句设置了 AnimationInterface 记录的周期间隔
所有节点的位置。 如果预计节点移动很少,则设置
高移动轮询间隔以避免大型 XML 文件。

// 第2步
anim.SetConstantPosition (Ptr< Node > n, double x, double y);

AnimationInterface 要求设置所有节点的位置。在 ns-3 这是由
设置关联的 MobilityModel。 "SetConstantPosition" 是一种快速设置 xy 的方法
静止节点的坐标。

// 第3步
动画.SetStartTime ((150)); 和 anim.SetStopTime ((150));

AnimationInterface 可以生成大型 XML 文件。 上面的语句限制了窗口
在 AnimationInterface 之间进行跟踪。 限制窗口仅用于聚焦
模拟的相关部分并创建易于管理的小型 XML 文件

// 第4步
AnimationInterface 动画(“animation.xml”,50000);

使用上面的构造函数可以确保每个动画 XML 跟踪文件只有 50000
数据包。 例如,如果 AnimationInterface 捕获了 150000 个数据包,则使用上述
构造函数将捕获拆分为 3 个文件

· animation.xml - 包含数据包范围 1-50000

· animation.xml-1 - 包含数据包范围 50001-100000

· animation.xml-2 - 包含数据包范围 100001-150000

// 第5步
anim.EnablePacketMetadata(真);

通过上面的语句,AnimationInterface 将每个数据包的元数据记录在
xml 跟踪文件。 NetAnim 可以使用元数据来提供更好的统计和过滤,
以及提供有关数据包的一些简要信息,例如 TCP 序列号
或数据包动画期间的源和目标 IP 地址。

注意:启用此功能将导致 XML 跟踪文件更大。 请不要
使用 Wimax 链接时启用此功能。

// 第6步
anim.UpdateNodeDescription (5, "Access-point");

通过上述语句,AnimationInterface 将文本“Access-point”分配给节点 5。

// 第7步
anim.UpdateNodeSize(6, 1.5, 1.5);

通过上面的语句,AnimationInterface 将节点大小设置为按 1.5 缩放。 网动
自动缩放图形视图以适应拓扑的边界。 这意味着
NetAnim,可以异常地将节点的大小缩放得过高或过低。 使用
AnimationInterface::UpdateNodeSize 允许您覆盖 NetAnim 中的默认缩放比例
并使用您自己的自定义比例。

// 第8步
anim.UpdateNodeCounter(89);

通过上面的语句,AnimationInterface 将计数器设置为 Id == 89,关联
节点 7 的值为 3.4。 使用 Id 89 的计数器获得
AnimationInterface::AddNodeCounter。 这方面的一个示例用法是
src/netanim/examples/resources_demo.cc。

步骤 2: 装载 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 XML in 网动
1. 假设NetAnim 已构建,使用命令“./NetAnim”启动NetAnim。 请
如果 NetAnim 不可用,请查看“构建 NetAnim”部分。

2. NetAnim打开后,点击左上角的文件打开按钮,选择
步骤 1 中生成的 XML 文件。

3. 点击绿色播放按钮开始动画。

这是一个说明这一点的视频 http://www.youtube.com/watch?v=tz_hUuNwFDs

百科
有关安装“NetAnim”、常见问题解答和加载 XML 跟踪文件的详细说明
(前面提到过)使用NetAnim请参考: http://www.nsnam.org/wiki/NetAnim

天线 模块


工艺设计 文件
概述
天线模块提供:

1. 一个新的基类(AntennaModel),它为模型的建模提供了一个接口
天线的辐射方向图;

2. 从这个基类派生的一组类,每个类都对辐射模式进行建模
不同类型的天线。

天线型号
AntennaModel 使用 [Balanis] 中采用的坐标系,如图所示
协调 系统 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 天线型号. 该系统是通过对笛卡尔坐标系进行平移而获得的
ns-3 MobilityModel 使用的坐标系到新的原点 o
天线的位置,然后变换每个通用点 p 的坐标
从笛卡尔坐标 (x,y,z) 到球坐标 (r, heta,hi) 的空间。
天线模型忽略径向分量r,只考虑角度分量
(赫塔,嗨)。
然后将天线辐射方向图表示为数学函数 g(heta, hi)
grightarrow thcal{R} 返回每个可能方向的增益(以 dB 为单位)
传输/接收。 所有角度均以弧度表示。
[图像] AntennaModel.UNINDENT 的坐标系

提供 模型
在本节中,我们将描述包含在
天线模块。

各向同性天线模型
此天线辐射模式模型为所有方向提供单一增益 (0 dB)。

余弦天线模型
这是【春鉴】中描述的余弦模型:天线增益确定为:

哪里嗨_{0}
是天线的方位角(即其最大增益方向)和
指数

确定所需的 3dB 波束宽度 hi_{3dB}。
请注意,此辐射图与倾角 heta 无关。

【春鉴】的模型和课堂上实现的一个主要区别
CosineAntennaModel 是只有元素因子(即上面描述的
公式)被考虑。 其实【春健】也考虑过增加一个天线阵
因素。 排除后者的原因是我们期望普通用户
希望准确地指定给定的波束宽度,而无需在
后一阶段实际上会改变结果的有效波束宽度
辐射模式。

抛物线天线模型
该模型基于主瓣辐射图的抛物线近似。 它
通常在蜂窝系统的背景下用于模拟细胞的辐射模式
部门,例如参见 [​​R4-092042a] 和 [Calcev]。 确定以 dB 为单位的天线增益
如:

哪里嗨_{0}
是天线的方位角方向(即最大增益的方向),
嗨_{3dB}
是其 3 dB 波束宽度,A_{max} 是天线的最大衰减(dB)。 笔记
这种辐射模式与倾角 heta 无关。

[巴拉尼斯]
CA Balanis,“天线理论 - 分析与设计”,Wiley,第 2 版。

【春建】
李春健,“三扇区WCDMA系统的高效天线模式”,硕士
科学论文,查尔姆斯理工大学,瑞典哥德堡,2003

[卡尔切夫]
George Calcev 和 Matt Dillon,“CDMA 网络中的天线倾斜控制”,在 Proc. 的
第二届年度国际无线互联网大会 (WICON),2

[R4-092042a]
3GPP TSG RAN WG4(无线电)会议 #51,R4-092042,模拟假设和
FDD HeNB RF 要求的参数。

用户 文件记录
天线模块可用于所有无线技术和物理层
支持它的模型。 目前,这包括基于
频谱物理有关详细信息,请参阅每个模型的文档。

测试 文件记录
在本节中,我们描述了天线模块中包含的测试套件,用于验证
它的正确功能。


单元测试套件 验证 Angles 类的构造是否正确
根据可用方法从 3D 笛卡尔坐标正确转换
(从单个向量和一对向量构建)。 对于每种方法,几个
提供了比较值的测试用例(嗨,
heta) 由构造函数确定为已知参考值。 如果对于每个
情况下,值等于参考高达 10^{-10} 的容差,这说明
对于数值误差。

度数到弧度
单元测试套件 度-弧度 验证方法 度数到弧度
弧度到度 通过与许多已知参考值进行比较来正常工作
测试用例。 如果比较等于 10^{-10} 的容差,则每个测试用例都通过
这说明了数值误差。

各向同性天线模型
单元测试套件 各向同性天线模型 检查是否 各向同性天线模型
正常工作,即,无论方向如何,始终返回 0dB 增益。

余弦天线模型
单元测试套件 余弦天线模型 检查是否 余弦天线模型 课堂作品
适当地。 提供了几个测试用例来检查计算的天线增益值
在不同的方向和不同的方向值,参考增益
和波束宽度。 参考增益是手工计算的。 如果每个测试用例通过
以 dB 为单位的参考增益等于返回的值 余弦天线模型
0.001 的容差,这说明了为计算所做的近似
参考值。

抛物线天线模型
单元测试套件 抛物线天线模型 检查是否 抛物线天线模型
工作正常。 提供了几个测试用例来检查天线增益值
在不同的方向和不同的方向值计算,
最大衰减和波束宽度。 参考增益是手工计算的。 每次测试
如果以 dB 为单位的参考增益等于由
抛物线天线模型 在 0.001 的容差内,这说明了近似值
用于计算参考值。

AD HOC 一经请求 距离 向量 (AODV)


该模型实现了 Ad Hoc On-Demand Distance Vector 的基本规范
(AODV) 协议。 实现是基于 RFC 3561.

该模型由 ITTP RAS 的 Elena Buchatskaia 和 Pavel Boyko 编写,基于
由 CMU/MONARCH 小组开发并由 Samir 优化和调整的 ns-2 AODV 模型
Das 和 Mahesh Marina,辛辛那提大学,以及 AODV-UU 实施
乌普萨拉大学的 Erik Nordström。

型号 描述
AODV 模型的源代码位于目录中 源代码/AODV.

工艺设计
增益级 ns3::aodv::路由协议 实现服务包交换的所有功能
并继承自 ns3::Ipv4路由协议. 基类定义了两个虚函数
用于数据包路由和转发。 第一个, ns3::aodv::路由输出, 是用来
本地产生的数据包,第二个, ns3::aodv::路由输入, 是用来
转发和/或传递接收到的数据包。

协议操作取决于许多可调参数。 参数
功能是属性 ns3::aodv::路由协议. 参数默认值为
从 RFC 中提取并允许启用/禁用协议功能,例如
广播 HELLO 消息,广播数据包等。

AODV 按需发现路由。 因此,AODV 模型缓存所有数据包,而
路由请求包(RREQ)被传播。数据包队列在
aodv-rqueue.cc。 一个指向数据包的智能指针, ns3::Ipv4RoutingProtocol::ErrorCallback,
ns3::Ipv4RoutingProtocol::UnicastForwardCallback, 并且IP头存储在这个
队列。 包队列实现旧包的垃圾回收和队列大小
限制。

路由表实现支持旧条目和状态的垃圾收集
机,在标准中定义。 它是作为 STL 映射容器实现的。 关键是一个
目标 IP 地址。

RFC 中没有描述协议操作的某些元素。 这些元素一般
关注不同 OSI 模型层的合作。 该模型使用以下
启发式:

· 这种AODV实现可以检测单向链路的存在并避免它们
如有必要。 如果模型收到 RREQ 的节点是邻居,则原因可能是
成为单向链路。 这种启发式取自 AODV-UU 实现,可以
被禁用。

· 协议操作强烈依赖断链检测机制。 该模型
实现了两个这样的启发式方法。 首先,这个实现支持 HELLO 消息。
然而,HELLO 消息并不是在无线网络中执行邻居感知的好方法。
环境(至少不超过 802.11)。 因此,一个人可能会遇到糟糕的表现
通过无线运行时。 这有几个原因:1) HELLO 消息是
广播。 在 802.11 中,广播通常以比单播更低的比特率完成,
因此,HELLO 消息可以比单播数据传播得更远。 2) HELLO 消息很小,
因此比数据传输更不容易出现误码,以及 3) 广播传输
与单播传输不同,不保证是双向的。 其次,我们使用
可能时使用第 2 层反馈。 如果帧传输,则认为链路断开
导致所有重试传输失败。 这种机制是为了主动
链接和工作比第一种方法更快。

第 2 层反馈实现依赖于 发送错误头 溯源,目前
仅在 AdhocWifiMac 中受支持。

适用范围 限制
该模型仅适用于 IPv4。 以下可选协议优化不是
已实施:

1. 扩大环搜索。

2.本地链接修复。

3. RREP、RREQ 和 HELLO 消息扩展。

这些技术需要直接访问 IP 标头,这与来自
AODV 在 UDP 上工作的 AODV RFC。 该模型为了简单起见使用 UDP,阻碍了
实现某些协议优化的能力。该模型不使用低层原始
插座,因为它们不便携。

未来 工作
没有公布的计划。

案例
用法
例子
助手
Attributes
追踪
记录
注意事项
验证
单位 测试
规模更大 性能 测试

申请


占位符

网络设备


占位符

可以在以下位置找到使用 Bridge NetDevice 的一些示例 例子/csma/ 目录。

英国 积分


该模型实现了波士顿大学代表互联网 BRITE 的接口
拓扑发电机[1]。 BRITE 是用于生成真实互联网的标准工具
拓扑。 此处描述的 ns-3 模型提供了一个帮助程序类以方便
使用 BRITE 配置文件生成 ns-3 特定拓扑。 BRITE 建立
在 ns-3 BriteTopolgyHelper 类中存储为节点和边的原始图。 在
BRITE 的 ns-3 集成,生成器生成拓扑,然后提供访问
到每个生成的 AS 的叶子节点。 ns-3 用户可以将自定义拓扑附加到
这些叶节点通过手动创建或使用提供的拓扑生成器
ns-3。

BRITE 提供三种主要的拓扑类型:路由器、AS 和
分层是AS和路由器的组合。 出于 ns-3 的目的
模拟,最有用的可能是 Router 和 Hierarchical。 路由器级
使用 Waxman 模型或 Barabasi-Albert 模型生成拓扑。 每个
模型具有影响拓扑创建的不同参数。 对于平面路由器拓扑,
所有节点都被认为在同一个 AS 中。

BRITE 分层拓扑包含两个级别。 首先是AS级别。 这个级别
也可以使用 Waxman 模型或 Barabasi-Albert 模型创建。
然后对于AS拓扑中的每个节点,构造一个路由器级拓扑。 这些
路由器级拓扑可以再次使用 Waxman 模型或 Barbasi-Albert 模型。
BRITE 按照 AS 级别的规定互连这些独立的路由器拓扑
拓扑。 一旦构建了层次拓扑,它就会被扁平化成一个大的
路由器级拓扑。

更多信息可以在 BRITE 用户手册中找到:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

型号 描述
该模型依赖于构建外部 BRITE 库,然后构建一些 ns-3
呼叫图书馆的帮手。 ns-3 助手的源代码位于
目录 src/brite/助手.

工艺设计
为了生成 BRITE 拓扑,ns-3 助手调用外部 BRITE 库,并且
使用标准的 BRITE 配置文件,BRITE 代码构建一个包含节点和
边缘根据这个配置文件。 请参阅 BRITE 文档或
src/brite/examples/conf_files 中的示例配置文件以更好地掌握
BRITE 配置选项。 BRITE 构建的图返回给 ns-3,一个 ns-3
构建了图的实现。 每个 AS 的叶子节点可供用户使用
要么附加自定义拓扑,要么直接安装 ns-3 应用程序。

案例
[1] Alberto Medina、Anukool Lakhina、Ibrahim Matta 和 John Byers。 BRITE:一种方法
通用拓扑生成。 在国际研讨会论文集
计算机和电信系统的建模、分析和仿真 - MASCOTS
'01,俄亥俄州辛辛那提,2001 年 XNUMX 月。

用法
可以参考 brite-generic-example 来查看 BRITE 接口的基本用法。 在
总结一下,BriteTopologyHelper 通过传入一个 BRITE
配置文件。 连同配置文件一个 BRITE 格式的随机种子文件
也可以传入,如果没有传入seed文件,helper会创建一个seed
文件使用 ns-3 的 UniformRandomVariable。 一旦 BRITE 生成拓扑,
调用 BuildBriteTopology() 来创建 ns-3 表示。 下一个 IP 地址可以是
使用 AssignIpv4Addresses() 或 AssignIpv6Addresses() 分配给拓扑。 它
需要注意的是,拓扑中的每条点对点链路都会被视为一个新的
网络因此对于 IPV4 应使用 /30 子网以避免浪费大量
可用的地址空间。

示例 BRITE 配置文件可以在 /src/brite/examples/conf_files/ 中找到。
ASBarbasi 和 ASWaxman 是仅 AS 拓扑的示例。 RTBarabasi 和 RTWaxman
文件是仅路由器拓扑的示例。 最后是 TD_ASBarabasi_RTWaxman
配置文件是使用 Barabasi-Albert 的分层拓扑的示例
AS 级别的模型和每个路由器级别拓扑的 Waxman 模型。
可以在 BRITE 用户中找到有关这些文件中使用的 BRITE 参数的信息
手册。

建筑物 英国 之路
第一步是下载并构建 ns-3 特定的 BRITE 存储库:

$ hg 克隆 http://code.nsnam.org/BRITE
$ CD BRITE
使

这将构建 BRITE 并在 BRITE 目录中创建一个库 libbrite.so。

成功构建 BRITE 后,我们继续使用 BRITE 支持配置 ns-3。
切换到 ns-3 目录:

$ ./waf 配置 --with-brite=/your/path/to/brite/source --enable-examples

确保它在“BRITE 集成”旁边显示“已启用”。 如果没有,那么有什么东西
出错了。 要么您忘记按照上述步骤首先构建 BRITE,要么
ns-3 找不到您的 BRITE 目录。

接下来,构建 ns-3:

$./waf

例子
对于演示 BRITE 集成运行的示例:

$ ./waf --run 'brite-generic-example'

通过启用详细参数,该示例将打印出节点和边
格式类似于标准 BRITE 输出的信息。 还有许多其他
命令行参数,包括 confFile、tracing 和 nix,描述如下:

配置文件
BRITE 配置文件。 许多不同的 BRITE 配置文件示例
存在于 src/brite/examples/conf_files 目录中,例如,
RTBarabasi20.conf 和 RTWaxman.conf。请参考conf_files目录
有关更多示例。

追踪
启用 ascii 跟踪。

尼克斯 启用 nix-vector 路由。 默认情况下使用全局路由。

假设 python 绑定,通用 BRITE 示例还支持使用 pyviz 的可视化
在 ns-3 中启用:

$ ./waf --run brite-generic-example --vis

涉及 BRITE 的模拟也可以与 MPI 一起使用。 MPI实例总数
传递给 BRITE 拓扑助手,其中使用模除法来分配节点
对于每个 AS 到一个 MPI 实例。 一个例子可以在 src/brite/examples 中找到:

$ mpirun -np 2 ./waf --run brite-MPI-example

有关使用 ns-3 设置 MPI 的信息,请参阅 ns-3 MPI 文档。

建筑 模块


cd .. include::replace.txt

工艺设计 文件
概述
建筑物模块提供:

1.一个新的类(建筑物) 在模拟中模拟建筑物的存在
设想;

2.一个新的类(移动建筑信息) 允许指定位置、大小和
模拟区域中存在的建筑物的特征,并允许放置
这些建筑物内的节点数;

3. 一个容器类,定义了最有用的路径损耗模型和
对应变量称为 建筑物传播损失模型.

4.一种新的传播模型(混合建筑传播损失模型) 与
刚刚介绍的移动模型,它允许对以下现象进行建模
存在建筑物的室内/室外传播。

5. 仅适用于奥村畑的简化模型(Oh建筑物传播损失模型)
考虑到存在室内/室外传播的现象
建筑物。

这些模型在设计时就考虑到了 LTE,尽管它们的实现实际上是
独立于任何 LTE 特定代码,并可与其他 ns-3 无线网络一起使用
技术(例如,wifi、wimax)。

- 混合建筑传播损失模型 包含的路径损耗模型是通过一个
几个众所周知的路径损耗模型的组合,以模拟不同的
城市、郊区和开放区域等环境场景。 此外,模型
考虑室外和室内 室内和室外通信必须包括在内
因为 HeNB 可能安装在建筑物内,也可能安装在室外。 如果是室内
通信,该模型还必须考虑室外 <-> 室内的建筑物类型
根据一些一般标准进行通信,例如穿墙损失
常用材料; 此外,它还包括一些内部的一般配置
室内通信中的墙壁。

- Oh建筑物传播损失模型 已创建路径损耗模型以简化
前一个删除了从一种模型切换到另一种模型的阈值。 为了做到这一点
它只使用了一种可用的传播模型(即 Okumura
羽田)。 模型中仍然考虑建筑物的存在; 因此所有的
上述关于建筑类型的考虑仍然有效。 相同
可以考虑环境情景和频率的问题,因为
它们都是所考虑模型的参数。

- 建筑物
该模型包括一个特定的类,称为 建筑物 其中包含一个 ns3 盒子 班级
定义建筑物的尺寸。 为实现其特点
包括路径损耗模型, 建筑物 类支持以下属性:

·建筑类型:

· 住宅(默认值)

· 办公室

· 商业的

· 外墙式

· 木头

· ConcreteWithWindows(默认值)

· 没有窗户的混凝土

· 石块

· 楼层数(默认值1,表示只有一楼)

· x 轴的房间数(默认值 1)

· y 轴的房间数(默认值 1)

Building 类基于以下假设:

· 一个建筑物被表示为一个长方体(即一个盒子)

· 壁平行于 x、y 和 z 轴

· 建筑物被划分为房间网格,由以下参数标识:

· 楼层数

· 沿 x 轴的房间数

· 沿y轴的房间数

· z轴为纵轴,即z轴增加楼层数增加
价值观

· x 和 y 房间索引从 1 开始并沿 x 和 y 轴增加
分别

· 建筑物中的所有房间大小相同

- 移动建筑信息
- 移动建筑信息 类,它继承自 ns3 类 摆件, 是在掌控下
维护有关节点相对于建筑物的位置的信息。 这
管理的信息 移动建筑信息 是:

· 节点是室内还是室外

· 如果是室内:

· 构建节点在哪

· 节点位于哪个房间(x、y 和楼层房间索引)

班级 移动建筑信息 由...使用 建筑物传播损失模型 类,其中
继承自 ns3 类 传播损失模型 并管理路径损耗计算
根据节点位置的单个组件及其组成。 而且,
它还实现了阴影,即由于主要路径中的障碍物造成的损失
(即植被、建筑物等)。

需要指出的是, 移动建筑信息 可以被任何其他传播模型使用。
但是,根据撰写本文时的信息,只有在
建筑模块的设计考虑了由
建筑物。
g
ITUR1238传播损失模型
本课程基于 ITU 实现了与建筑物相关的室内传播损耗模型
P.1238 modeg{ 包括由于建筑物类型(即住宅、办公室和
商业)ia 下面给出解析表达式。
nr
{r
aa
哪里:好吧。 : 电力流失
N = tr}住宅 \ 30 & 办公室 \ 22 & 商业\nd{阵列}
系数 [dB]
天。
L_f = t }住宅\ 15+4(n-1) & 办公室\ 6+3(n-1) & 商业\nd{数组}
{l
n : 基站和移动台之间的楼层数 (n 1)
l2
f : 频率 [MHz]
}&
d :距离(其中 d > 1)[m]
n
建筑宣传&损失模型
BuildingsPropagationLossModel 提供了一组额外的建筑相关
用于实现不同路径损耗逻辑的路径损耗模型元素。 这些
路径损耗模型元素在以下小节中描述。

外置 损失 (EWL)
该组件模拟室内到室外穿墙的穿透损失
通信,反之亦然。 这些值取自 [cost231] 模型。

· 木 ~ 4 dB

· 带窗户的混凝土(未金属化)~ 7 dB

· 没有窗户的混凝土 ~ 15 dB(COST10 中的跨度在 20 到 231 之间)

· 石块 ~ 12 dB

全内走线 墙壁 损失 (国际白字)
该组件模拟室内到室内通信中发生的穿透损耗
同一栋楼内。 总损失的计算假设每个内部
壁具有恒定的穿透损耗 L_{siw},并且近似于壁的数量
穿透发射器之间的曼哈顿距离(以房间数为单位)
和接收器。 详细地,让 x_1, y_1, x_2, y_2 表示沿 x 和
分别为用户 1 和 2 的 y 轴; 总损失 L_{IWL} 计算为

高度 Gain增益 型号 (汞)
由于发射设备在地板上,该组件模拟了增益
在地面之上。 在文献 [turkmani] 中,这个增益被评估为大约 2 dB
每层。 该增益可以应用于所有室内到室外的通信和
反之亦然。

遮蔽 型号
阴影是根据具有可变标准的对数正态分布建模的
作为 MobilityModel 相对位置(室内或室外)的函数的偏差
涉及的实例。 为每对 MobilityModel 抽取一个随机值,并保持不变
在整个模拟过程中该对的常数。 因此,该模型适用于
仅限静态节点。

该模型认为以 dB 为单位的阴影损耗的平均值始终为 0。对于
方差,该模型详细考虑了标准差的三个可能值:
右箭头 X_thrm{O}
· 户外的 (m_shadowingSigma户外, 默认值为 7 dB)
N(_thrm{O}, ma_thrm{O}^2)。
右箭头 X_thrm{I}
· 室内的 (m_shadowingSigma室内, 默认值为 10 dB)
N(_thrm{I}, ma_thrm{I}^2)。
右箭头
· 外墙穿透(m_shadowingSigmaExtWalls, 默认值 5 dB)
X_thrm{W} N(_thrm{W}, ma_thrm{W}^2)

模拟器根据节点的每个活动链接生成一个阴影值
第一次使用链接进行传输时的位置。 如果从传输
室外节点到室内节点,反之亦然,标准偏差 (ma_thrm{IO}) 必须
计算为标准的二次值之和的平方根
室外节点的偏差和外墙穿透的偏差。 这是
由于产生阴影的组件独立于每个
其他; 因此,由两个独立的总和产生的分布的方差
正常的是方差的总和。

路径损耗 逻辑
在下文中,我们描述了由实现的不同路径损耗逻辑
继承自 BuildingsPropagationLossModel。

混合建筑传播损失模型
- 混合建筑传播损失模型 包含的路径损耗模型是通过一个
几个众所周知的路径损耗模型的组合,以模拟不同的室外和
室内场景,以及室内到室外和室外到室内的场景。 详细,
班级 混合建筑传播损失模型 集成了以下路径损耗模型:

· OkumuraHataPropagationLossModel (OH)(在频率 > 2.3 GHz 时由
Kun2600Mhz传播损耗模型)

· ItuR1411LosPropagationLossModel 和 ItuR1411NlosOverRooftopPropagationLossModel
(I1411)

· ITUR1238PropagationLossModel (I1238)

· BuildingsPropagationLossModel 的路径损耗元素(EWL、HG、IWL)

以下伪代码说明了如何描述不同的路径损耗模型元素
以上都集成在 混合建筑传播损失模型:

如果(txNode 在室外)
然后
如果(rxNode 在室外)
然后
如果(距离 > 1 公里)
然后
if (rxNode 或 txNode 低于屋顶)
然后
L = I1411
其他
L = 哦
其他
L = I1411
否则(rxNode 在室内)
如果(距离 > 1 公里)
然后
if (rxNode 或 txNode 低于屋顶)
L = I1411 + EWL + HG
其他
L = OH + EWL + HG
其他
L = I1411 + EWL + HG
否则(txNode 在室内)
如果(rxNode 在室内)
然后
如果(同一栋楼)
然后
L = I1238 + IWL
其他
L = I1411 + 2*EWL
否则(rxNode 在室外)
如果(距离 > 1 公里)
然后
if (rxNode 或 txNode 低于屋顶)
然后
L = I1411 + EWL + HG
其他
L = OH + EWL + HG
其他
L = I1411 + EWL

我们注意到,对于屋顶级别以下的两个节点之间的通信情况,
距离大于 1 公里,我们仍然考虑 I1411 模型,因为 OH 是专门
专为宏蜂窝设计,因此适用于屋顶水平以上的天线。

对于 ITU-R P.1411 模型,我们考虑了 LOS 和 NLoS 版本。 特别是,我们
考虑短于可调阈值的距离的 LoS 传播
(m_itu1411Nlos阈值)。 在 NLoS 传播的情况下,屋顶模型是
考虑为宏 BS 和 SC 建模。 在 NLoS 的情况下,
参数场景依赖已被包括在内,例如平均街道宽度,
方向等。这些参数的值必须根据
场景实现后,该模型不会本地计算它们的值。 万一
提供了值,使用标准值,除了移动和 BS 的高度,
而是直接在代码中测试它们的完整性(即,它们必须是
大于零)。下面我们给出组件的表达式
模型。

我们还注意到使用不同的传播模型(OH、I1411、I1238 及其
HybridBuildingsPropagationLossModel 中的变体)可能导致
相对于距离的路径损耗。 适当调整属性(尤其是
距离阈值属性)可以避免这些不连续性。 然而,由于
每个模型的行为取决于其他几个参数(频率、节点高度等),
这些阈值没有默认值可以避免所有的不连续性
可能的配置。 因此,这些参数的适当调整留给
用户。

Oh建筑物传播损失模型
- Oh建筑物传播损失模型 创建类是作为解决问题的简单方法
不连续性问题 混合建筑传播损失模型 不做
特定场景的参数调整。 解决方案是仅使用一种传播损耗
模型(即 Okumura Hata),同时保留路径损耗逻辑的结构
计算其他路径损耗分量(例如穿墙损耗)。 结果是
一个没有不连续性的模型(除了那些由于墙壁造成的),但更少
对于具有建筑物和室外/室内用户的通用场景,总体而言是现实的,例如,
因为 Okumura Hata 既不适合室内通信也不适合室外
屋顶以下的通信。

详细来说,类 Oh建筑物传播损失模型 积分以下路径损耗
楷模:

·OkumuraHataPropagationLossModel (OH)

· BuildingsPropagationLossModel 的路径损耗元素(EWL、HG、IWL)

以下伪代码说明了如何描述不同的路径损耗模型元素
以上都集成在 Oh建筑物传播损失模型:

如果(txNode 在室外)
然后
如果(rxNode 在室外)
然后
L = 哦
否则(rxNode 在室内)
L = OH + EWL
否则(txNode 在室内)
如果(rxNode 在室内)
然后
如果(同一栋楼)
然后
L = OH + IWL
其他
L = OH + 2*EWL
否则(rxNode 在室外)
L = OH + EWL

我们注意到 OhBuildingsPropagationLossModel 是一个重要的简化
HybridBuildingsPropagationLossModel,因为总是使用 OH。 虽然这
在某些情况下(尤其是屋顶和室内以下)给出了不太准确的模型,它
有效避免路径损耗不连续性问题
混合建筑传播损失模型。

用户 文件记录
创新中心 使用 建筑物 in a 模拟
在本节中,我们将解释建筑物模型在模拟中的基本用法
程序。

包括 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。
在模拟程序的开头添加:

#包括

创建 a 建设
例如,让我们创建一个 10 x 20 x 10 的住宅建筑:

双 x_min = 0.0;
双 x_max = 10.0;
双 y_min = 0.0;
双 y_max = 20.0;
双 z_min = 0.0;
双 z_max = 10.0;
点b = 创建对象();
b->SetBoundaries (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Building::Residential);
b->SetExtWallsType (Building::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNroomsX (3);
b->SetNroomsY (2);

这座建筑有三层,内部有 3 x 2 网格,房间大小相同。

帮助类 GridBuildingAllocator 也可用于轻松创建一组
具有相同特征的建筑物放置在矩形网格上。 这是一个例子
如何使用它:

点网格建筑分配器;
gridBuildingAllocator = CreateObject ();
gridBuildingAllocator->SetAttribute("GridWidth", UintegerValue (3));
gridBuildingAllocator->SetAttribute("LengthX", DoubleValue (7));
gridBuildingAllocator->SetAttribute("LengthY", DoubleValue (13));
gridBuildingAllocator->SetAttribute("DeltaX", DoubleValue (3));
gridBuildingAllocator->SetAttribute ("DeltaY", DoubleValue (3));
gridBuildingAllocator->SetAttribute("高度", DoubleValue (6));
gridBuildingAllocator->SetBuildingAttribute ("NroomsX", UintegerValue (2));
gridBuildingAllocator->SetBuildingAttribute ("NroomsY", UintegerValue (4));
gridBuildingAllocator->SetBuildingAttribute ("NFloors", UintegerValue (2));
gridBuildingAllocator->SetAttribute("MinX", DoubleValue (0));
gridBuildingAllocator->SetAttribute("MinY", DoubleValue (0));
gridBuildingAllocator->创建(6);

这将创建一个由 3 个建筑物组成的 2x6 网格,每个建筑物为 7 x 13 x 6 m,内部有 2 x 4 个房间和
2个; 建筑物在 x 轴和 y 轴上的间距均为 3 m。

设置 节点 流动性 模型
节点和移动模型像往常一样配置,但是为了将它们与
您需要额外调用的建筑模型 BuildingsHelper::安装(),以便让
移动模型包括关于他们在建筑物中的位置的信息。 这是
一个例子:

MobilityHelper 移动性;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create(2);
移动性.安装(ueNodes);
BuildingsHelper::安装(ueNodes);

要注意的是,可以使用任何移动模型。 但是,建议用户
确保正在使用的移动模型的行为与
建筑物的存在。 例如,在整体上使用简单的随机移动性
存在建筑物的模拟区域可能很容易导致节点移入和移出
建筑物,无论是否存在墙壁。

地方 一些 节点
您可以使用多种方法在模拟中放置节点,这些方法在
以下。

百年传承 定位 方法
任何传统的 ns-3 定位方法都可用于在模拟中放置节点。 这
重要的附加步骤是例如,您可以像这样手动放置节点:

点mm0 = enbNodes.Get (0)->GetObject ();
点mm1 = enbNodes.Get (1)->GetObject ();
mm0->SetPosition (Vector (5.0, 5.0, 1.5));
mm1->SetPosition (Vector (30.0, 40.0, 1.5));

MobilityHelper 移动性;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create(2);
移动性.安装(ueNodes);
BuildingsHelper::安装(ueNodes);
mm0->SetPosition (Vector (5.0, 5.0, 1.5));
mm1->SetPosition (Vector (30.0, 40.0, 1.5));

或者,您可以使用任何现有的 PositionAllocator 类。 的坐标
节点将确定它是放置在室外还是室内,如果是室内,则在哪个位置
建筑和房间它被放置。

特定建筑 定位 方法
以下位置分配器类可用于将节点放置在特殊位置
关于建筑物:

· 随机建筑位置分配器: 通过随机选择一个位置来分配每个位置
从所有建筑物的列表中构建,然后在里面随机选择一个位置
建筑物。

· 随机房间位置分配器:通过随机选择一个房间来分配每个位置
所有建筑物中的房间列表,然后在里面随机选择一个位置
房间。

· 相同房间位置分配器:按顺序遍历给定的 NodeContainer,并且对于每个
节点在该节点的同一个房间中随机分配一个新位置。

· 固定房间位置分配器: 生成一个随机位置均匀分布在
所选建筑物内所选房间的体积。

根据 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 流动性 型号 一致:
重要: 每当你使用建筑物时,你必须在我们之后发出以下命令
已经在模拟中放置了所有节点和建筑物:

BuildingsHelper::使移动模型一致 ();

此命令将遍历所有节点和所有建筑物的列表,确定
每个用户是室内还是室外,如果是室内,它也将确定建筑物在
用户所在的位置以及建筑物内的相应楼层和编号。

建筑感知 路径损耗 模型
在模拟中放置建筑物和节点后,您可以使用建筑物感知
模拟中的路径损耗模型与使用任何常规路径损耗的方式完全相同
模型。 如何做到这一点取决于您正在考虑的无线模块(LTE、
wifi、wimax 等),因此请参阅该型号的文档以了解具体
指示。

主要 配置 属性
- 建筑物 类具有以下可配置参数:

· 建筑类型:住宅、办公和商业。

· 外墙类型:Wood、ConcreteWithWindows、ConcreteWithoutWindows 和 StoneBlocks。

· 建筑边界:a 盒子 与建筑边界的类。

· 楼层数。

· x 轴和 y 轴的房间数量(房间只能以网格方式放置)。

- 建筑移动性损失模型 ns3 属性系统可配置的参数是
由边界表示(字符串 边界) 的模拟区域,通过提供 盒子
与区域界限。 此外,通过其方法,可以得到以下参数
配置:

· 放置节点的楼层数(默认为 0)。

· 在房间网格中的位置。

- 建筑传播损失模型 类具有以下可配置参数
可使用属性系统进行配置:

· 频率:参考频率(默认2160 MHz),注意通过设置频率
相应地自动设置波长,反之亦然)。

· LAMBDA:波长(0.139 米,考虑到上述频率)。

· ShadowSigma户外:室外节点阴影的标准偏差(默认
7.0)。

· ShadowSigma室内:室内节点阴影的标准偏差(默认
8.0)。

· 暗影西格玛外墙: 外墙阴影的标准偏差
室外到室内通信的渗透(默认 5.0)。

· 屋顶层:建筑物屋顶的高度,以米为单位(默认为 20 米)。

· Los2NlosThr: sigth 和 line-of-sigth 之间切换点的距离值
以米为单位的非视距传播模型(默认为 200 米)。

· ITU1411距离Thr:短距离切换点的距离值
(ITU 1211) 通信和远程 (Okumura Hata) 以米为单位(默认 200 米)。

· 最小距离:用于评估的两个节点之间的最小距离(以米为单位)
路径损耗(在此阈值之前被认为可以忽略)(默认 0.5 米)。

· 环境:Urban、SubUrban 和 OpenAreas 之间的环境场景(默认
城市的)。

· 城市规模:城市在小、中、大之间的维度(默认为大)。

为了使用混合模式,要使用的类是
混合建筑MobilityLossModel,这允许选择合适的路径损耗模型
根据设计章节中介绍的路径损耗逻辑。 然而,这个解决方案
存在路径损耗模型切换点可能出现不连续性的问题
针对模型的不同特性。 这意味着根据具体的
场景,用于切换的阈值必须适当调整。 简单的
OhBuildingMobilityLoss模型 仅使用 Okumura Hata 模型克服了这个问题,
穿墙损失。

测试 文件记录
概述
为了测试和验证 ns-3 Building Pathloss 模块,提供了一些测试套件,其中
与 ns-3 测试框架集成。 要运行它们,您需要配置
以这种方式构建模拟器:

$ ./waf 配置 --enable-tests --enable-modules=buildings
$ ./测试.py

以上不仅会运行属于buildings模块的测试套件,还会运行
属于建筑物模块所依赖的所有其他 ns-3 模块的那些。 看
有关测试框架的一般信息的 ns-3 手册。

您可以通过以下方式获得更详细的 HTML 格式报告:

$ ./test.py -w 结果.html

上述命令运行后,您可以通过打开查看每个测试的详细结果
文件 结果.html 使用网络浏览器。

您可以使用以下命令分别运行每个测试套件:

$ ./test.py -s 测试套件名称

有关的更多详细信息 测试文件 和 ns-3 测试框架,请参考 ns-3
手册。

描述 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 测试 套房
建筑助手 测试
测试套件 建筑助手 检查该方法
BuildingsHelper::使所有实例一致 () 工作正常,即
BuildingsHelper 成功定位节点是室外还是室内,如果是室内
他们位于正确的建筑物、房间和楼层。 几个测试用例是
提供不同的建筑物(具有不同的大小、位置、房间和楼层)和
不同的节点位置。 如果每个节点都正确定位,则测试通过。

建筑位置分配器 测试
测试套件 建筑位置分配器 有两个测试用例来检查
RandomRoomPositionAllocator 和 SameRoomPositionAllocator 分别正常工作。 每个
测试用例涉及已知坐标处的单个 2x3x2 房间建筑(总共 12 个房间)和
分别为 24 和 48 个节点。 两个测试都检查每个节点中分配的节点数
房间是预期的,节点的位置也是正确的。

Buildings 路径损耗 测试
测试套件 建筑物路径损耗模型 提供不同的单元测试来比较
特定场景下建筑物路径损耗模块的预期结果
使用 Octave 脚本离线获得的计算值
(测试/参考/建筑-pathloss.m)。 如果两个值,则认为测试通过
等于 0.1 的容差,这被认为适用于
路径损耗值(以 dB 为单位)。

下面我们详细介绍了所考虑的场景,它们的选择是为了
涵盖了广泛的可能路径损耗逻辑组合。 路径损耗逻辑结果
因此隐式测试。

测试 #1 奥村 错误
在本次测试中,我们测试了标准的奥村畑模型; 因此 eNB 和 UE 都被放置
在 2000 m 的距离外。 使用的频率是 E-UTRA 频段 #5,它
对应于 869 MHz(参见 5.5 的表 1-36.101)。 测试还包括验证
区域扩展(即城市、郊区和开放区域)和城市规模
(小、中、大)。

测试 #2 成本 231 型号
该测试旨在验证 COST231 模型。 测试类似于奥村
Hata 一,除了使用的频率是 EUTRA 频段 #1 (2140 MHz) 并且测试
由于模型的原因,只能对城市场景中的大小城市进行
局限性。

测试 #3 2.6 GHz 模型
该测试验证了 2.6 GHz Kun 模型。 该测试类似于奥村畑一,除了
频率是 EUTRA 频段 #7 (2620 MHz) 并且测试只能在
城市场景。

测试 #4 国际电联1411 视距 模型
此测试旨在验证 ITU1411 模型在街道内视线的情况下
峡谷传输。 在这种情况下,UE 被放置在距离 eNB 100 米的地方,因为
在 LoS 和 NLoS 之间切换的阈值保留为默认值 200(即 XNUMX m。)。

测试 #5 国际电联1411 非视距 模型
此测试旨在验证 ITU1411 模型在非视距情况下
屋顶传输。在这种情况下,UE 被放置在距离 eNB 900 米处,在
为了高于在 LoS 和 NLoS 之间切换的阈值被保留为默认值
(即,200 米。)。

测试 #6 ITU1238 模型
此测试旨在验证室内传输情况下的 ITUP1238 模型。 在
在这种情况下,UE 和 eNB 都被放置在一个住宅建筑中,墙壁由
带窗户的混凝土。 Ue 位于二楼,距离 30 米远
eNB,位于一楼。

测试 #7 户外 -> 室内 - 奥村 错误 模型
该测试验证了远距离的室外到室内传输。 在这种情况下
UE 被放置在一栋住宅建筑中,墙壁由混凝土制成,带有窗户和
距离室外 eNB 2000 米。

测试 #8 户外 -> 室内 - 国际电联1411 模型
该测试验证了短距离的室外到室内传输。 在这种情况下
UE 被放置在一栋住宅建筑中,墙壁由混凝土制成,带有窗户和
距离室外 eNB 100 米。

测试 #9 室内 -> 户外 - 国际电联1411 模型
该测试验证了非常短距离的室外到室内传输。 在这
如果 eNB 放置在住宅楼的二楼,墙壁由
有窗户的混凝土,距离室外 UE 100 米(即 LoS
沟通)。 因此,高度增益必须包括在路径损耗评估中。

测试 #10 展位 室内 -> 户外 - 国际电联1411 模型
该测试验证了短距离的室外到室内传输。 在这种情况下
eNB 被放置在住宅楼的二楼,墙壁由
带有窗户且距离室外 UE 500 米的混凝土(即 NLoS
沟通)。 因此,高度增益必须包括在路径损耗评估中。

Buildings 遮蔽 测试
测试套件 建筑物阴影测试 是一个单元测试,旨在验证统计
由实现的阴影模型的分布 建筑物路径损失模型. 阴影
根据均值 = 0 和可变标准的正态分布建模
偏差 ma,根据文献中常用的模型。 三个测试用例是
提供,涵盖室内、室外和室内外通信的情况。
每个测试用例为不同的数据对生成 1000 个不同的阴影样本
给定场景中的 MobilityModel 实例。 通过减去得到阴影值
从返回的总损失值 混合建筑路径损失模型 路径损耗分量
对于每个测试用例,这是常数和预先确定的。 测试验证样品
阴影值的均值和样本方差在 99% 置信区间内
样本均值和样本方差。 该测试还验证了阴影值
同一对 MobilityModel 实例的连续时间返回是常数。

案例
[土库曼语]
Turkmani AMD、JD Parson 和 DG Lewis,“无线电传播到建筑物中
441、900 和 1400 MHz”,在 4 年第四届陆地移动无线电国际会议的过程中。

点击 MODULAR ROUTER 积分


Click 是一种用于构建可配置路由器的软件架构。 通过使用不同
称为元素的数据包处理单元的组合,可以使 Click 路由器
执行特定类型的功能。 这种灵活性提供了一个很好的平台
测试和试验不同的协议。

型号 描述
Click 模型的源代码位于目录中 来源/点击.

工艺设计
由于以下原因,ns-3 的设计非常适合与 Click 集成:

· ns-3 中的数据包在堆栈中向上/向下移动时被序列化/反序列化。 这允许
ns-3 数据包按原样传入和传出 Click。

· 这也意味着任何类型的 ns-3 流量生成器和传输都应该很容易工作
单击顶部。

· 通过努力将点击实现为一个 Ipv4RoutingProtocol 实例,我们可以避免
对 ns-3 代码的 LL 和 MAC 层进行了重大更改。

设计目标是使 ns-3-click 公共 API 足够简单,以便用户
只需要在节点上添加一个 Ipv4ClickRouting 实例,并通知每个 Click 节点
将使用的 Click 配置文件(.click 文件)。

该模型实现了 Click Modular Router 的接口,并提供了
Ipv4ClickRouting 类允许节点使用 Click 进行外部路由。 不同于正常
Ipv4RoutingProtocol 子类型,Ipv4ClickRouting 不使用 RouteInput() 方法,但是
相反,在适当的接口上接收数据包并相应地处理它。 笔记
您需要在 Click 图中有一个路由表类型元素才能使用 Click for
外部路由。 这是继承自的 RouteOutput() 函数所需要的
Ipv4 路由协议。 此外,基于 Click 的节点在
Ipv4L3ClickProtocol 的形式,它是 Ipv4L3Protocol 的精简版。
Ipv4L3ClickProtocol 将通过堆栈的数据包传递给 Ipv4ClickRouting
处理。

发展 a 模拟器 API ns-3 相互作用 - 点击
大部分 API 已经明确定义,允许单击以从以下位置探测信息
模拟器(如节点 ID、接口 ID 等)。 通过保留大部分
方法,应该可以编写特定于 ns-3 的新实现
功能。

因此,对于与 ns-3 的 Click 集成,名为 Ipv4ClickRouting 的类将处理
与 Click 的交互。 相同的代码可以在
src/click/model/ipv4-click-routing.{cc,h}.

小包装 折扣 之间 ns-3 点击
ns-3 和 Click 之间可以发生四种数据包切换。

· L4到L3

· L3到L4

· L3到L2

· L2到L3

为了克服这个问题,我们实现了 Ipv4L3ClickProtocol,一个精简版的
Ipv4L3 协议。 Ipv4L3ClickProtocol 将数据包传入和传出 Ipv4ClickRouting
适当地执行路由。

适用范围 限制
· 在当前状态下,NS-3 Click Integration 仅限于与 L3 一起使用,离开
NS-3 处理 L2。 我们目前也在努力添加 Click MAC 支持。 见
使用部分以确保您相应地设计您的 Click 图表。

· 此外,ns-3-click 仅适用于用户级元素。 完整名单
元素可在 http://read.cs.ucla.edu/click/elements. 具有的元素
可以使用它们旁边提到的“all”、“userlevel”或“ns”。

· 截至目前,Click 的 ns-3 接口仅为 Ipv4。 我们将添加 Ipv6 支持
未来。

案例
· Eddie Kohler、Robert Morris、Benjie Chen、John Jannotti 和 M. Frans Kashoek。 这
单击模块化路由器。 ACM 计算机系统交易 18(3), 2000 年 XNUMX 月,页
263-297。

· Lalith Suresh P. 和 Ruben Merz。 NS-3-click:单击 ns-3 的模块化路由器集成。
在过程中。 3rd International ICST Workshop on NS-3 (WNS3),西班牙巴塞罗那。 行进,
2011.

· Michael Neufeld、Ashish Jain 和 Dirk Grunwald。 Nsclick:桥接网络模拟
和部署。 MSWiM '02:第五届 ACM 国际建模研讨会论文集
无线和移动系统的分析和仿真,2002 年,美国佐治亚州亚特兰大。
http://doi.acm.org/10.1145/570758.570772

用法
建筑物 点击
第一步是从github存储库克隆Click并构建它:

$ git 克隆 https://github.com/kohler/click
$ cd 点击/
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
使

如果您不打算将 Click 与 Wifi 一起使用,则可能会跳过 --enable-wifi 标志。 *
注意:您不需要执行“make install”。

一旦 Click 成功构建,进入 ns-3 目录并配置 ns-3
使用 Click 集成支持:

$ ./waf 配置 --enable-examples --enable-tests --with-nsclick=/path/to/click/source

提示:如果您点击安装了 ns-3 上面的一个目录(例如在 ns-3-allinone
目录),并且目录的名称是“单击”(或指向目录的符号链接
被命名为“click”),则不需要 --with-nsclick 说明符; ns-3 构建
系统将成功找到该目录。

如果它在“NS-3 Click 集成支持”旁边显示“已启用”,那么您就可以开始了。
注意:如果运行模块化 ns-3,则运行所有 ns-3-click 所需的最小模块集
示例是 wifi、csma 和 config-store。

接下来,尝试运行以下示例之一:

$ ./waf --运行 nsclick-simple-lan

然后,您可以查看生成的 .pcap 跟踪记录,这些跟踪记录名为 nsclick-simple-lan-0-0.pcap
和 nsclick-simple-lan-0-1.pcap。

点击 图表 说明
制作点击图时应牢记以下几点:

· 只能使用用户级元素。

· 你需要用 FromSimDevice 和 ToDevice 元素替换 FromDevice 和 ToDevice 元素
ToSimDevice 元素。

· 使用 ToSimDevice(tap0,IP) 向内核发送数据包。

· 对于任何节点,向/从内核发送/接收数据包的设备被命名为
'tap0'。 其余接口应命名为 eth0、eth1 等(即使您是
使用无线网络)。 请注意,设备编号应从 0 开始。以后,这
将变得灵活,以便用户可以根据需要在他们的 Click 文件中命名设备。

· 路由表元素是必需的。 路由表元素的 OUTports 应该
对应于数据包将通过的设备的接口号
最终被发送出去。 违反此规则将导致非常奇怪的数据包跟踪。
然后应将此路由表元素的名称传递给 Ipv4ClickRouting 协议
对象作为模拟参数。 有关详细信息,请参阅 Click 示例。

· 当前的实现让 Click 主要具有 L3 功能,带有 ns-3 处理
L2。 我们很快将开始努力支持在 Click 上使用 MAC 协议。
这意味着截至目前,Click 的 Wifi 特定元素不能与 ns-3 一起使用。

调试 小包装 流动 点击
从 Click 图表中的任何一点,您都可以使用 Print (-
http://read.cs.ucla.edu/click/elements/print) 元素及其用于漂亮打印的变体
包内容。 此外,您可以生成流经一个的数据包的 pcap 跟踪
使用 ToDump (http://read.cs.ucla.edu/click/elements/todump) 元素为
好。 例如:

我的查询器
-> 打印(fromarpquery,64)
-> ToDump(out_arpquery,PER_NODE 1)
-> ethout;

并且...将打印流出 ArpQuerier 的数据包的内容,然后生成一个
pcap 跟踪文件,对于每个使用 Click 的节点,都有一个后缀“out_arpquery”
文件,然后将数据包推送到“ethout”。

帮手
要让节点运行 Click,最简单的方法是使用 ClickInternetStackHelper
模拟脚本中的类。 例如:

点击InternetStackHelper点击;
click.SetClickFile (myNodeContainer, "nsclick-simple-lan.click");
click.SetRoutingTableElement (myNodeContainer, "u/rt");
单击.安装(myNodeContainer);

里面的示例脚本 源代码/点击/示例/ 演示基于 Click 的节点的使用
不同的场景。 可以在里面找到帮助程序源
src/click/helper/click-internet-stack-helper.{h,cc}

例子
已经编写了以下示例,可以在 源代码/点击/示例/:

· nsclick-simple-lan.cc 和 nsclick-raw-wlan.cc:一个基于 Click 的节点与
没有 Click 的普通 ns-3 节点,分别使用 Csma 和 Wifi。 这也说明
在 Click 之上使用 TCP,这是原始 nsclick 实现的
NS-2 无法实现。

· nsclick-udp-client-server-csma.cc 和 nsclick-udp-client-server-wifi.cc:一个 3 节点局域网
(分别为 Csma 和 Wifi),其中 2 个基于 Click 的节点运行 UDP 客户端,该客户端发送
数据包到运行 UDP 服务器的第三个基于 Click 的节点。

· nsclick-routing.cc:一键式节点通过第三个节点与另一个节点通信
充当IP路由器(使用IP路由器点击配置)。 这说明
使用 Click 进行路由。

脚本可在 /配置/ 允许您生成 Click 文件
一些常见的场景。 使用的 IP 路由器 nsclick-routing.cc 是从
make-ip-conf.pl 文件并稍微适应了 ns-3-click。

验证
该模型已经过测试如下:

· 已编写单元测试来验证 Ipv4ClickRouting 的内部结构。 这可以
在发现 src/点击/ipv4-点击-路由-test.cc. 这些测试验证了这些方法是否
在 Ipv4ClickRouting 里面处理设备名称到 ID,IP 地址从设备名称
和设备名称绑定中的 Mac 地址按预期工作。

· 这些示例已用于在实际模拟场景中测试 Click。 这些可以
在发现 源代码/点击/示例/. 这些测试涵盖以下内容: 使用不同的
Click 之上的各种传输,TCP/UDP,Click 节点是否可以与
非基于 Click 的节点,Click 节点是否可以相互通信,使用 Click
使用静态路由来路由数据包。

· Click 已经过 Csma、Wifi 和点对点设备的测试。 使用说明是
在上一节中可用。

CSMA 网络设备


这是 CSMA NetDevice 章节的介绍,以补充 Csma 模型 doxygen。

概述 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 CSMA 模型
- ns-3 CSMA 设备以以太网的精神对简单的总线网络进行建模。 虽然它
没有对您可以构建或购买的任何真实物理网络进行建模,它确实提供了一些
非常有用的功能。

通常,当人们想到总线网络以太网或 IEEE 802.3 时就会想到。 以太网
使用 CSMA/CD(带碰撞检测的载波侦听多路访问
增加退避来争夺共享的传输介质。 这 ns-3 CSMA设备
仅使用全球可用通道的性质对该过程的一部分进行建模
提供瞬时(比光速)载波感知和基于优先级的碰撞
“回避。” 以太网意义上的冲突永远不会发生,因此 ns-3 CSMA设备
不模拟碰撞检测,任何正在进行的传输也不会被“阻塞”。

CSMA 型号
有许多用于描述分层通信的约定
文学和教科书中的建筑。 最常见的分层模型是
ISO 七层参考模型。 在此视图中,CsmaNetDevice 和 CsmaChannel 对
占据最低的两层——物理(第一层)和数据链路(第二层)
职位。 另一个重要的参考模型是由 RFC 1122 指定的,“要求
用于 Internet 主机 - 通信层。”在此视图中,CsmaNetDevice 和
CsmaChannel对占据最低层——链路层。 还有一种看似
在教科书和文献中发现了无穷无尽的替代描述。 我们
采用 IEEE 802 标准中使用的命名约定,即 LLC、MAC、MII
和 PHY 分层。 这些首字母缩写词定义为:

· LLC:逻辑链路控制;

· MAC:媒体访问控制;

· MII:媒体独立接口;

· PHY:物理层。

在这种情况下 有限责任公司MAC 是 OSI 数据链路层的子层和 信息产业部PHY
是 OSI 物理层的子层。

CSMA 设备的“顶部”定义了从网络层到数据层的过渡
链路层。 此转换由更高层通过调用
CsmaNetDevice::Send 或 CsmaNetDevice::SendFrom。

与 IEEE 802.3 标准相比,CSMA 中没有精确指定的 PHY
线类型、信号或引脚分配方面的模型。 的“底部”界面
CsmaNetDevice 可以被认为是一种媒体独立接口 (MII)
在“快速以太网”(IEEE 802.3u)规范中。 这个 MII 接口适合
CsmaChannel 上对应的媒体无关接口。 你不会找到
相当于 10BASE-T 或 1000BASE-LX PHY。

CsmaNetDevice 通过媒体独立接口调用 CsmaChannel。 有一个
使用该方法定义的方法来告诉通道何时开始“摆动电线”
CsmaChannel::TransmitStart,以及一个告诉通道什么时候传输过程的方法
完成,通道应该开始通过“线”传播最后一位:
CsmaChannel::TransmitEnd。

执行 TransmitEnd 方法时,通道将建模单个统一信号
介质中的传播延迟并将数据包的副本传递到每个设备
通过 CsmaNetDevice::Receive 方法附加到数据包。

设备媒体独立接口中有一个“pin”对应“COL”
(碰撞)。 通道的状态可以通过调用 CsmaChannel::GetState 来感知。 每个
设备将在开始发送之前查看此“引脚”并执行适当的退避
必要时进行操作。

正确接收的数据包通过 CsmaNetDevice 转发到更高级别
回调机制。 回调函数由高层初始化(当网络
设备已附加)使用 CsmaNetDevice::SetReceiveCallback 并在“正确”时调用
网络设备接收数据包,以便按照协议转发数据包
叠加。

CSMA 频道 型号
CsmaChannel 类模拟实际的传输介质。 没有固定的限制
连接到通道的设备数量。 CsmaChannel 模拟数据速率和
可以通过属性“DataRate”和“Delay”访问的光速延迟
分别。 提供给通道的数据速率用于设置所使用的数据速率
连接到通道的 CSMA 设备的发送器部分。 没有办法
在设备中独立设置数据速率。 由于数据速率仅用于计算
延迟时间,没有限制(除了保存值的数据类型)
CSMA 通道和设备的运行速度; 并且没有任何限制
一种PHY特性。

CsmaChannel 具有三种状态, , 传输传播. 这三种状态
被频道上的所有设备瞬间“看到”。 我们的意思是,如果一个
设备开始或结束模拟传输,通道上的所有设备都 立即
意识到状态的变化。 没有时间可以让一台设备看到
通道,而在物理上更远的冲突域中的另一个设备可能具有
开始与未沿信道传播到其他信道的相关信号一起传输
设备。 因此在 CsmaChannel 模型中不需要碰撞检测,它是
没有以任何方式实施。

顾名思义,我们确实对模型具有载波感知方面。 由于
模拟器是单线程的,访问公共通道会被序列化
模拟器。 这为竞争信道提供了确定性机制。 这
通道已分配(从状态转换 陈述 传输) 先到先得
先到先得。 通道总是经历一个三态过程:

空闲 -> 传输 -> 传播 -> 空闲

- 传输 状态模型源网络设备实际运行的时间
摆动电线上的信号。 这 传播 状态模型最后一位之后的时间
发送,当信号沿着电线传播到“远端”时。

过渡到 传输 状态由调用驱动
CsmaChannel::TransmitStart 由传输数据包的网络设备调用。 它
该设备有责任通过调用
CsmaChannel::TransmitEnd 在反映经过时间的适当模拟时间
将所有数据包位放在电线上。 当调用 TransmitEnd 时,通道
安排与单个光速延迟相对应的事件。 此延迟适用于
通道上的所有网络设备相同。 你可以想象一个对称的枢纽,其中
数据包位传播到一个中心位置,然后返回等长电缆到
通道上的其他设备。 单个“光速”延迟则对应于
所需时间: 1) 信号从一个 CsmaNetDevice 通过其电缆传播
到枢纽; 加上 2) 集线器将数据包转发出端口所需的时间; 加
3) 有问题的信号传播到目标网络所需的时间


CsmaChannel 为广播媒体建模,因此数据包被传递到所有设备
在传播时间结束时在通道(包括源)上。 它是
发送设备有责任确定它是否接收到数据包
通过频道广播。

CsmaChannel 提供以下属性:

· DataRate:连接设备上数据包传输的比特率;

· 延迟:通道的光速传输延迟。

CSMA 设备 型号
CSMA 网络设备看起来有点像以太网设备。 CsmaNetDevice
提供以下属性:

· 地址:设备的Mac48Address;

· SendEnable:如果为真则启用数据包传输;

· ReceiveEnable:如果为真则启用数据包接收;

· EncapsulationMode:要使用的链路层封装类型;

· RxErrorModel:接收错误模型;

· TxQueue:设备使用的传输队列;

· InterframeGap:“帧”之间的可选等待时间;

· Rx:接收数据包的跟踪源;

· Drop:丢弃数据包的跟踪源。

CsmaNetDevice 支持“接收错误模型”的分配。 这是个
用于模拟链接上的数据损坏的 ErrorModel 对象。

通过 CsmaNetDevice 发送的数据包总是通过传输队列路由到
为通过网络发送的数据包提供跟踪挂钩。 这个传输队列可以设置
(通过属性)来模拟不同的排队策略。

还可以通过属性配置设备使用的封装方法。 每一个
数据包获取包含目标和源 MAC 地址的 EthernetHeader,并且
长度/类型字段。 每个数据包还会获得一个包含 FCS 的 EthernetTrailer。
数据包中的数据可以以不同的方式封装。

默认情况下,或者通过将“EncapsulationMode”属性设置为“Dix”,封装是
根据 DEC、Intel、Xerox 标准。 这有时称为 EthernetII 成帧
并且是大家熟悉的目的MAC、源MAC、EtherType、Data、CRC格式。

如果“EncapsulationMode”属性设置为“Llc”,则由 LLC SNAP 进行封装。 在
在这种情况下,会添加一个包含 EtherType(IP 或 ARP)的 SNAP 标头。

其他实现的封装模式是 IP_ARP(将“EncapsulationMode”设置为“IpArp”)
其中以太网头的长度类型接收协议号
包; 或 ETHERNET_V1(将“EncapsulationMode”设置为“EthernetV1”),其中长度类型
以太网报头的长度接收数据包的长度。 “原始”封装模式是
已定义但未实现——使用 RAW 模式会导致断言。

请注意,必须将通道上的所有网络设备设置为相同的封装模式
正确的结果。 接收器不感测封装模式。

CsmaNetDevice 实现了一个随机指数退避算法,如果
频道被确定为忙(传输 or 传播) 当设备想要
开始传播。 这会导致最多 pow (2, retries) - 1 的随机延迟
尝试重试之前的微秒。 默认的最大重试次数为 1000。

运用 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 网络设备
CSMA 网络设备和通道通常使用
相关 Csma助手 目的。 各种种类 ns-3 设备助手通常以类似的方式工作
方式,并且在我们的许多示例程序中都可以看到它们的使用。

感兴趣的概念模型是您插入网络的裸计算机“外壳”
设备。 裸机是使用 节点容器 帮手。 你只要问这个
帮助创建尽可能多的计算机(我们称它们为 Nodes) 根据您的网络需要:

节点容器 csmaNodes;
csmaNodes.Create(nCsmaNodes);

一旦你有了你的节点,你需要实例化一个 Csma助手 并设置您的任何属性
可能想要改变。:

CsmaHelper csma;
csma.SetChannelAttribute("DataRate", StringValue("100Mbps"));
csma.SetChannelAttribute("延迟", TimeValue (NanoSeconds (6560)));

csma.SetDeviceAttribute("EncapsulationMode", StringValue("Dix"));
csma.SetDeviceAttribute ("FrameSize", UintegerValue (2000));

一旦设置了属性,剩下的就是创建设备并将它们安装在
所需的节点,并使用 CSMA 通道将设备连接在一起。 什么时候我们
创建网络设备,我们将它们添加到容器中,以便您将来使用它们。
这一切只需要一行代码:

NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

我们建议仔细考虑更改这些属性,因为它可能导致
让用户感到惊讶的行为。 我们允许这样做是因为我们相信灵活性很重要。
作为改变属性的一个可能令人惊讶的效果的例子,考虑
在以下:

Mtu 属性指示设备的最大传输单元。 这是尺寸
设备可以发送的最大协议数据单元 (PDU)。 此属性默认
最多 1500 个字节,对应于 RFC 894 中的一个数字,“A Standard for the
通过以太网传输 IP 数据报。”这个数字实际上来自
10Base5(全规格以太网)网络的最大数据包大小——1518 字节。 如果你
减去以太网数据包(18 字节)的 DIX 封装开销,您将得到一个
最大可能的数据大小 (MTU) 为 1500 字节。 还可以找到 IEEE 的 MTU
802.3 网络是 1492 字节。 这是因为 LLC/SNAP 封装增加了额外的八
数据包的开销字节。 在这两种情况下,底层网络硬件都是
限制为1518字节,但MTU不同,因为封装不同。

如果将 Mtu 属性保留在 1500 字节并更改封装模式属性
对于 Llc,结果将是一个使用 LLC/SNAP 封装 1500 字节 PDU 的网络
成帧产生 1526 字节的数据包。 这在许多网络中是非法的,但是
我们允许您这样做。 这导致模拟非常微妙地没有反映
您可能会期待什么,因为真正的设备会拒绝发送 1526 字节的数据包。

还存在巨型帧(1500 < MTU <= 9000 字节)和超巨型帧(MTU > 9000
字节)未经 IEEE 正式批准但在某些情况下可用的帧
高速(千兆)网络和 NIC。 在 CSMA 模型中,可以离开
封装模式设置为 Dix,并将 Mtu 设置为 64000 字节——即使关联的
CsmaChannel DataRate 保持在每秒 10 兆比特(当然不是千兆以太网)。
这基本上将模拟一个由吸血鬼窃听的 1980 年代风格制成的以太网交换机
支持超巨型数据报的 10Base5 网络,这当然不是
曾经制作过,也不太可能制作过; 但是你很容易
配置。

小心关于 CSMA 实际建模的内容以及如何建模的假设
配置(属性)可能会让你大大偏离现实。

CSMA 追踪
像所有 ns-3 设备,CSMA 模型提供了许多跟踪源。 这些痕迹
可以使用您自己的自定义跟踪代码挂钩源,或者您可以使用我们的帮助程序
安排在您指定的设备上启用跟踪的功能。

更高级别 (苹果电脑)
从在net device的tracing来看,有几个有趣的点
插入跟踪挂钩。 从其他模拟器继承的约定是数据包
注定要传输到附加网络的传输通过单个“传输队列”在
网络设备。 我们在数据包流的这一点上提供了跟踪钩子,它对应于
(抽象地)只是从网络层过渡到数据链路层,并称它们为
统称为设备 MAC 挂钩。

当一个数据包被发送到 CSMA 网络设备进行传输时,它总是通过
传输队列。 CsmaNetDevice 中的传输队列继承自 Queue,因此
继承三个跟踪源:

· 一个 Enqueue 操作源(参见 Queue::m_traceEnqueue);

· Dequeue 操作源(参见 Queue::m_traceDequeue);

· 一个 Drop 操作源(参见 Queue::m_traceDrop)。

实际上,CsmaNetDevice 的上层 (MAC) 跟踪挂钩正是这三个
跟踪设备的单个传输队列上的源。

m_traceEnqueue 事件在数据包被放入传输队列时触发。 这个
发生在 CsmaNetDevice::Send 或 CsmaNetDevice::SendFrom 被调用时
更高层对数据包进行排队以进行传输。

当一个数据包从传输队列中移除时,m_traceDequeue 事件被触发。
传输队列中的出队可能在三种情况下发生:1)如果底层
当调用 CsmaNetDevice::Send 或 CsmaNetDevice::SendFrom 时,通道处于空闲状态,a
数据包从传输队列中出列并立即传输; 2)如果
底层信道是空闲的,一个数据包可以出列并立即在一个
内部 TransmitCompleteEvent,其功能类似于发送完成中断
服务程序; 或 3) 如果超时是从随机指数退避处理程序
检测到。

情况 (3) 意味着如果一个数据包无法从传输队列中出列
根据退避规则传输。 重要的是要了解这将
显示为 Dequeued 数据包,很容易错误地假设该数据包是
传输,因为它通过了传输队列。 实际上,一个数据包实际上是
在这种情况下由网络设备丢弃。 这种行为的原因是由于
队列丢弃事件的定义。 根据定义,m_traceDrop 事件在
数据包无法在传输队列中排队,因为它已满。 此事件仅触发
如果队列已满并且我们不重载此事件以指示 CsmaChannel 已满
“满的。”

低等级 (物理层)
与上层跟踪钩子类似,下层也有跟踪钩子可用
网络设备的级别。 我们称这些为 PHY 挂钩。 这些事件从设备触发
直接与 CsmaChannel 对话的方法。

调用跟踪源 m_dropTrace 以指示设备丢弃的数据包。
这发生在两种情况下:首先,如果网络设备的接收端未启用
(参见 CsmaNetDevice::m_receiveEnable 和相关的属性“ReceiveEnable”)。

m_dropTrace 也用于指示一个数据包被丢弃为损坏,如果一个
使用接收错误模型(参见 CsmaNetDevice::m_receiveErrorModel 和相关的
属性“ReceiveErrorModel”)。

另一个低级跟踪源在接收到已接受的数据包时触发(请参阅
CsmaNetDevice::m_rxTrace)。 如果数据包的目的地是广播,则该数据包被接受
地址、多播地址或分配给网络设备的 MAC 地址。

总结
ns3 CSMA 模型是类以太网网络的简单模型。 它支持一个
载波侦听功能并允许对共享介质进行多次访问。 它不是
物理的,即介质的状态瞬间在所有人之间共享
设备。 这意味着此模型中不需要碰撞检测,也没有
被实施。 介质上永远不会出现数据包“堵塞”的情况。 进入
共享频道是由模拟器确定的,先到先得
调度器。 如果通过查看全局状态确定通道处于忙碌状态,则
执行随机指数退避并尝试重试。

Ns-3 属性提供了在设备中设置各种参数的机制和
通道,例如地址、封装模式和错误模型选择。 跟踪钩子是
以通常的方式提供一组对应于传输的上层挂钩
队列并用于 ASCII 跟踪; 还有一组用于 pcap 跟踪的较低级别的钩子。

虽然 ns-3 CsmaChannel 和 CsmaNetDevice 没有为任何类型的网络建模
可以构建或购买,它确实为我们提供了一些有用的功能。 你应该,
但是,请理解它明确不是以太网或任何类型的 IEEE 802.3,而是
有趣的子集。

数据 类别


本章介绍 ns-3 数据收集框架 (DCF),它提供
能够在模拟器中获取模型生成的数据,在线执行
减少和数据处理,并将原始或转换后的数据编组为各种输出
格式。

该框架目前支持不依赖任何外部的独立 ns-3 运行
程序执行控制。 DCF 提供的对象可能与 ns-3 追踪
源以启用数据处理。

类的源代码位于目录中 源/统计.

本章安排如下。 首先,架构的概述是
呈现。 接下来,介绍这些类的助手; 这种初步治疗
应该允许在许多用例中基本使用数据收集框架。 用户
希望在当前助手范围之外产生输出,或者希望创建
他们自己的数据收集对象,应该阅读本章的其余部分,其中
详细介绍所有基本 DCF 对象类型并提供低级编码
例子。

工艺设计
DCF 由三个基本类组成:

· 探头型号 是一种仪器和控制模拟数据输出的机制,即
用于监视有趣的事件。 它以一种或多种形式产生输出 ns-3
追踪来源。 探测对象连接到一个或多个迹线 (叫
捕收剂),它在线处理样本并准备输出。

· 收藏家 使用一个或多个 Probe 对象生成的数据。 它执行
对数据进行转换,例如归一化、归约和计算
基本统计。 收集器对象不产生由收集器直接输出的数据
ns-3 运行; 相反,它们将数据向下游输出到另一种类型的对象,称为
聚合,它执行该功能。 通常,收集器以
跟踪源的形式也是如此,允许收集器串联起来。

· 聚合 是由探测器和收集器网络收集的数据的终点。
聚合器的主要职责是整理数据及其对应的
元数据,转换成不同的输出格式,例如纯文本文件、电子表格文件或
数据库。

所有这三个类都提供了动态打开或关闭自己的能力
在整个模拟过程中。

任何独立的 ns-3 使用 DCF 的模拟运行通常会创建至少一个
以上三个类中的每一个的实例。
[图片] 数据收集框架概述。UNIDENT

数据处理的整体流程如下图所示 时间 购物 骨架 简介.
在左侧,一个正在运行的 ns-3 描绘了模拟。 在运行过程中
模拟,数据由模型通过跟踪源或其他方式提供。
该图描述了探针可以连接到这些跟踪源以接收数据
异步,或者探针可以轮询数据。 然后将数据传递给收集器对象
转换数据。 最后,聚合器可以连接到
收集器,用于生成绘图、文件或数据库。
[图片] 数据收集框架聚合.UNIDENT

上图的一个变体提供在 时间 购物 骨架 聚合.
第二个图说明了 DCF 对象可以以某种方式链接在一起
下游对象从多个上游对象获取输入。 图
从概念上表明,多个探针可能会生成输出到单个
集电极; 例如,输出两个计数器的比率的收集器将
通常从单独的探针获取每个计数器数据。 多个收集器也可以
输入单个聚合器,该聚合器(顾名思义)可以收集大量数据
流以包含到单个绘图、文件或数据库中。

时间 购物 助手
数据收集框架的全部灵活性由互连提供
探针、收集器和聚合器。 执行所有这些互连会导致
用户程序中的许多配置语句。 为了便于使用,一些最常见的
操作可以组合并封装在辅助函数中。 此外,一些
涉及的陈述 ns-3 由于限制,跟踪源没有 Python 绑定
绑定。

时间 购物 助手 概述
在本节中,我们概述了一些已创建的帮助程序类
简化一些常见用例的数据收集框架的配置。 这
助手允许用户在他们的 C++ 或
Python 程序。 但是,这种易用性的代价是显着减少
比低级配置可以提供的灵活性,并且需要显式编码
支持新的 Probe 类型到帮助程序中(以解决下面描述的问题)。

当前助手的重点是整理数据 ns-3 溯源到
gnuplot 绘图或文本文件,没有高度的输出定制或统计
处理(最初)。 此外,使用受限于可用的探针类型
ns-3. 本文档的后面部分将详细介绍如何创建新的
探针类型,以及有关将探针、收集器和聚合器连接在一起的详细信息
在自定义安排中。

迄今为止,已经实现了两个数据收集助手:

· Gnuplot 助手

· 文件助手

Gnuplot助手
GnuplotHelper 是一个辅助类,用于生成用于制作 gnuplot 的输出文件。 这
总体目标是为用户提供从导出的数据中快速绘制图表的能力
in ns-3 追踪来源。 默认情况下,执行最少量的数据转换;
目标是生成具有尽可能少(默认)配置语句的图
可能。

Gnuplot助手 概述
GnuplotHelper 将在模拟结束时创建 3 个不同的文件:

· 一个空格分隔的 gnuplot 数据文件

·一个gnuplot控制文件

· 用于生成 gnuplot 的 shell 脚本

生成绘图需要两个配置语句。 首先
语句配置绘图(文件名、标题、图例和输出类型,其中输出
如果未指定,类型默认为 PNG):

无效的 ConfigurePlot (const std::string &outputFileNameWithoutExtension,
const std::string &title,
const std::string &xLegend,
const std::string &yLegend,
const std::string &terminalType = ".png");

第二条语句挂钩感兴趣的跟踪源:

无效 PlotProbe (const std::string &typeId,
const std::string &path,
常量 std::string &probeTraceSource,
常量 std::string &title);

论据如下:

· typeId: 的 ns-3 探针的 TypeId

· path:路径中的路径 ns-3 配置命名空间到一个或多个跟踪源

· probeTraceSource:应该绘制探针的哪个输出(本身就是一个跟踪源)

· 标题:与数据集关联的标题(在 gnuplot 图例中)

上面 PlotProbe 的一个变体是指定第五个可选参数,用于控制
在图中放置键(图例)的位置。

一个完整的例子(来自 第七个.cc) 如下图所示:

// 创建 gnuplot 助手。
GnuplotHelper plotHelper;

// 配置绘图。
// 配置绘图。 第一个参数是文件名前缀
// 用于生成的输出文件。 第二个、第三个和第四个
// 参数分别是绘图标题、x 轴和 y 轴标签
plotHelper.ConfigurePlot ("第七包字节数",
“数据包字节数与时间”,
“时间(秒)”,
"数据包字节数",
“PNG”);

// 指定探测类型、跟踪源路径(在配置命名空间中)和
// 探测要绘制的输出跟踪源(“OutputBytes”)。 第四个论据
// 指定绘图上数据系列标签的名称。 最后
// 参数通过指定键的位置来格式化绘图。
plotHelper.PlotProbe(探针类型,
跟踪路径,
"输出字节",
"数据包字节数",
GnuplotAggregator::KEY_BELOW);

在这个例子中, 探针类型跟踪路径 如下(对于 IPv4):

probeType = "ns3::Ipv4PacketProbe";
tracePath = "/NodeList/*/$ns3::Ipv4L3Protocol/Tx";

probeType 是这个助手工作的关键参数。 此 TypeId 必须注册
在系统中,并且 Probe 的 trace sink 上的签名必须与 trace 的签名匹配
它被挂钩的来源。 为多种数据类型预定义了探针类型
对应 ns-3 跟踪值,以及其他一些跟踪源签名,例如
的“Tx”跟踪源 ns3::Ipv4L3协议 类。

请注意,指定的跟踪源路径可能包含通配符。 在这种情况下,多个
数据集绘制在一个图上; 每个匹配的路径一个。

产生的主要输出将是三个文件:

第七包字节计数.dat
第七包字节计数.plt
第七包字节计数.sh

此时,用户可以手动编辑 .plt 文件以进行进一步自定义,或者
只需通过 gnuplot 运行它。 跑步 sh 第七包字节计数.sh 简单地运行情节
通过gnuplot,如下图。
[图片] 2-D Gnuplot 创建者 Seventh.cc Example..UNIDENT

可以看出关键元素(图例、标题、图例放置、xlabel、ylabel、
和数据路径)都放在图上。 因为有两场比赛
提供的配置路径,显示两个数据系列:

· Packet Byte Count-0 对应 /NodeList/0/$ns3::Ipv4L3Protocol/Tx

· Packet Byte Count-1 对应 /NodeList/1/$ns3::Ipv4L3Protocol/Tx

Gnuplot助手 配置绘图
GnuplotHelper 的 配置绘图() 功能可用于配置绘图。

它有以下原型:

无效的 ConfigurePlot (const std::string &outputFileNameWithoutExtension,
const std::string &title,
const std::string &xLegend,
const std::string &yLegend,
const std::string &terminalType = ".png");

它有以下论点:

┌────────────────────────────────┬───────────────── ──────────────────┐
│论据 │ 描述 │
├────────────────────────────────┼───────────────── ──────────────────┤
│outputFileNameWithoutExtension │gnuplot 相关文件的名称 │
│ │ 不加扩展名。 │
├────────────────────────────────┼───────────────── ──────────────────┤
│title │ 绘图标题字符串用于 │
│ │ 这个情节。 │
└────────────────────────────────┴────────────────── ──────────────────┘

│xLegend │ x 水平的图例 │
│ │ 轴。 │
├────────────────────────────────┼───────────────── ──────────────────┤
│yLegend │ y 垂直的图例 │
│ │ 轴。 │
├────────────────────────────────┼───────────────── ──────────────────┤
│terminalType │终端类型设置字符串为 │
│ │ 输出。 默认终端│
│ │ 类型为“png”。 │
└────────────────────────────────┴────────────────── ──────────────────┘

GnuplotHelper 的 配置绘图() 函数为此配置绘图相关参数
gnuplot 助手,以便它将创建一个空格分隔的 gnuplot 数据文件,名为
outputFileNameWithoutExtension + ".dat",一个gnuplot控制文件,名为
outputFileNameWithoutExtension + ".plt",以及一个用于生成名为 gnuplot 的 shell 脚本
outputFileNameWithoutExtension + ".sh"。

如何使用此功能的示例可以在 第七个.cc 上面描述的代码
它的用途如下:

plotHelper.ConfigurePlot ("第七包字节数",
“数据包字节数与时间”,
“时间(秒)”,
"数据包字节数",
“PNG”);

Gnuplot助手 绘图探针
GnuplotHelper 的 绘图探针() 函数可用于绘制探针生成的值。

它有以下原型:

无效 PlotProbe (const std::string &typeId,
const std::string &path,
常量 std::string &probeTraceSource,
const std::string &title,
枚举 GnuplotAggregator::KeyLocation keyLocation = GnuplotAggregator::KEY_INSIDE);

它有以下论点:

┌──────────────────┬──────────────────────────────── ────┐
│论据 │ 描述 │
├──────────────────┼──────────────────────────────── ────┤
│typeId │ 探针的类型 ID │
│ │ 由这个助手创建。 │
├──────────────────┼──────────────────────────────── ────┤
│path │配置访问trace的路径│
│ │ 来源。 │
├──────────────────┼──────────────────────────────── ────┤
│probeTraceSource │探测跟踪源到 │
│ │ 访问。 │
├──────────────────┼──────────────────────────────── ────┤
│title │ 关联的标题 │
│ │ 这个数据集 │
├──────────────────┼──────────────────────────────── ────┤
│keyLocation │ key 在 │
│ │ 情节。 默认位置是│
│ │ 里面。 │
└──────────────────┴──────────────────────────────── ────┘

GnuplotHelper 的 绘图探针() 函数绘制通过挂钩生成的数据集 ns-3
使用助手创建的探针跟踪源,然后绘制来自
探针跟踪源。 数据集将具有提供的标题,并将由
每个时间戳的“newValue”。

如果配置路径由于存在通配符而在系统中有多个匹配项,则
将为每个匹配绘制一个数据集。 数据集标题将以
配置路径中每个通配符的匹配字符,以空格分隔。 为了
例如,如果建议的数据集标题是字符串“bytes”,并且有两个通配符
在路径中,然后像“bytes-0 0”或“bytes-12 9”这样的数据集标题将是可能的
绘制的数据集的标签。

如何使用此功能的示例可以在 第七个.cc 上面描述的代码
它的使用位置(带有变量替换)如下:

plotHelper.PlotProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"输出字节",
"数据包字节数",
GnuplotAggregator::KEY_BELOW);

其他 例子
诺普洛特 帮手 例如:
第七个.cc 示例可以在
src/stats/examples/gnuplot-helper-example.cc. 以下二维 gnuplot 是使用创建的
这个例子。
[图片] 2-D Gnuplot 创建者 gnuplot-helper-example.cc Example..UNIDENT

在此示例中,有一个 Emitter 对象根据
泊松过程,然后发出计数器的值作为跟踪源。

点发射器 = 创建对象();
Names::Add("/Names/Emitter", 发射器);

请注意,由于下面使用的路径中没有通配符,因此只有 1 个数据流
绘制在情节中。 图中的这个单一数据流被简单地标记为“发射器计数”,
没有额外的后缀,可以查看路径中是否有通配符。

// 创建 gnuplot 助手。
GnuplotHelper plotHelper;

// 配置绘图。
plotHelper.ConfigurePlot ("gnuplot-helper-example",
“发射器计数与时间”,
“时间(秒)”,
“发射器计数”,
“PNG”);

// 绘制探针生成的值。 我们提供的路径
// 有助于消除跟踪源的歧义。
plotHelper.PlotProbe ("ns3::Uinteger32Probe",
“/名称/发射器/计数器”,
“输出”,
“发射器计数”,
GnuplotAggregator::KEY_INSIDE);

文件助手
FileHelper 是一个帮助类,用于将数据值放入文件中。 总体目标是
为用户提供从导出的数据中快速制作格式化文本文件的能力
in ns-3 追踪来源。 默认情况下,执行最少量的数据转换;
目标是生成具有尽可能少(默认)配置语句的文件
可能。

文件助手 概述
FileHelper 将在模拟结束时创建 1 个或多个文本文件。

FileHelper 可以创建 4 种不同类型的文本文件:

· 格式化

· 空格分隔(默认)

· 逗号分隔

· 制表符分隔

格式化文件使用 C 风格的格式字符串和 sprintf() 函数来打印它们
正在写入的文件中的值。

以下带有 2 列格式化值的文本文件命名为
第七包字节计数0.txt 是使用添加到
原版的 ns-3 教程示例的代码。 仅显示此文件的前 10 行
在这里为简洁起见。

时间(秒)= 1.000e+00 数据包字节数 = 40
时间(秒)= 1.004e+00 数据包字节数 = 40
时间(秒)= 1.004e+00 数据包字节数 = 576
时间(秒)= 1.009e+00 数据包字节数 = 576
时间(秒)= 1.009e+00 数据包字节数 = 576
时间(秒)= 1.015e+00 数据包字节数 = 512
时间(秒)= 1.017e+00 数据包字节数 = 576
时间(秒)= 1.017e+00 数据包字节数 = 544
时间(秒)= 1.025e+00 数据包字节数 = 576
时间(秒)= 1.025e+00 数据包字节数 = 544

...

以下具有 2 列格式化值的不同文本文件命名为
第七包字节计数1.txt 也是使用添加到的相同新代码创建的
ns-3 教程示例的代码。 仅显示此文件的前 10 行
在这里为简洁起见。

时间(秒)= 1.002e+00 数据包字节数 = 40
时间(秒)= 1.007e+00 数据包字节数 = 40
时间(秒)= 1.013e+00 数据包字节数 = 40
时间(秒)= 1.020e+00 数据包字节数 = 40
时间(秒)= 1.028e+00 数据包字节数 = 40
时间(秒)= 1.036e+00 数据包字节数 = 40
时间(秒)= 1.045e+00 数据包字节数 = 40
时间(秒)= 1.053e+00 数据包字节数 = 40
时间(秒)= 1.061e+00 数据包字节数 = 40
时间(秒)= 1.069e+00 数据包字节数 = 40

...

为生成这两个文本文件而添加的新代码如下。 更多详情
这个 API 将在后面的部分中介绍。

请注意,因为路径中有 2 个通配符匹配,所以有 2 个单独的文本文件
被创造。 第一个文本文件,名为“seventh-packet-byte-count-0.txt”,
对应于通配符匹配,将“*”替换为“0”。 第二个文本文件,
命名为“seventh-packet-byte-count-1.txt”,对应通配符匹配
将“*”替换为“1”。 另外,请注意函数调用 写探针() 会给一个
如果包含通配符的路径没有匹配项,则会出现错误消息。

// 创建文件助手。
文件助手文件助手;

// 配置要写入的文件。
fileHelper.ConfigureFile ("第七包字节数",
文件聚合器::已格式化);

// 设置此格式化输出文件的标签。
fileHelper.Set2dFormat ("时间(秒) = %.3e\tPacket Byte Count = %.0f");

// 写入探针生成的值。
fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
“输出字节”);

文件助手 配置文件
文件助手的 配置文件() 函数可用于配置文本文件。

它有以下原型:

无效的 ConfigureFile (const std::string &outputFileNameWithoutExtension,
枚举 FileAggregator::FileType fileType = FileAggregator::SPACE_SEPARATED);

它有以下论点:

┌────────────────────────────────┬───────────────── ──────────────────┐
│论据 │ 描述 │
├────────────────────────────────┼───────────────── ──────────────────┤
│outputFileNameWithoutExtension │要写入的输出文件名│
│ │ 没有扩展名。 │
├────────────────────────────────┼───────────────── ──────────────────┤
│fileType │ 要写入的文件类型。 │
│ │ 默认文件类型为空格 │
│ │ 分开。 │
└────────────────────────────────┴────────────────── ──────────────────┘

文件助手的 配置文件() 函数配置文本文件相关参数
文件助手,以便它将创建一个名为 outputFileNameWithoutExtension plus 的文件
通配符匹配的可能额外信息加上“.txt”,其值打印为
由文件类型指定。 默认文件类型是空格分隔的。

如何使用此功能的示例可以在 第七个.cc 上面描述的代码
它的用途如下:

fileHelper.ConfigureFile ("第七包字节数",
文件聚合器::已格式化);

文件助手 写探针
文件助手的 写探针() 函数可用于将探针生成的值写入
文本文件。

它有以下原型:

无效 WriteProbe (const std::string &typeId,
const std::string &path,
常量 std::string &probeTraceSource);

它有以下论点:

┌──────────────────┬──────────────────────────────── ────┐
│论据 │ 描述 │
├──────────────────┼──────────────────────────────── ────┤
│typeId │ 探针的类型 ID │
│ │ 创建。 │
├──────────────────┼──────────────────────────────── ────┤
│path │配置访问trace的路径│
│ │ 来源。 │
├──────────────────┼──────────────────────────────── ────┤
│probeTraceSource │探测跟踪源到 │
│ │ 访问。 │
└──────────────────┴──────────────────────────────── ────┘

文件助手的 写探针() 函数创建通过挂钩生成的输出文本文件
ns-3 跟踪源,使用助手创建的探针,然后从
探针跟踪源。 输出文件名将文本存储在成员变量中
m_outputFileNameWithoutExtension 加上“.txt”,并且将包含每个处的“newValue”
时间戳记。

如果配置路径由于存在通配符而在系统中有多个匹配项,则
将为每个匹配创建一个输出文件。 输出文件名将包含
m_outputFileNameWithoutExtension 中的文本加上每个匹配的字符
配置路径中的通配符,用破折号分隔,加上“.txt”。 例如,如果值
m_outputFileNameWithoutExtension 中是字符串“packet-byte-count”,有两个
路径中的通配符,然后输出文件名,如“packet-byte-count-0-0.txt”或
“packet-byte-count-12-9.txt”可以作为将要创建的文件的名称。

如何使用此功能的示例可以在 第七个.cc 上面描述的代码
它的用途如下:

fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
“输出字节”);

其他 例子
文件 帮手 例如:
第七个.cc 示例可以在
src/stats/examples/file-helper-example.cc. 此示例仅使用 FileHelper。

以下带有 2 列格式化值的文本文件命名为 文件助手-example.txt
是使用示例创建的。 此处仅显示此文件的前 10 行
简洁。

时间(秒)= 0.203 计数 = 1
时间(秒)= 0.702 计数 = 2
时间(秒)= 1.404 计数 = 3
时间(秒)= 2.368 计数 = 4
时间(秒)= 3.364 计数 = 5
时间(秒)= 3.579 计数 = 6
时间(秒)= 5.873 计数 = 7
时间(秒)= 6.410 计数 = 8
时间(秒)= 6.472 计数 = 9
...

在此示例中,有一个 Emitter 对象根据
泊松过程,然后发出计数器的值作为跟踪源。

点发射器 = 创建对象();
Names::Add("/Names/Emitter", 发射器);

请注意,由于下面使用的路径中没有通配符,因此只有 1 个文本文件
创建的。 这个单一的文本文件被简单地命名为“file-helper-example.txt”,没有额外的
后缀,例如您会看到路径中是否有通配符。

// 创建文件助手。
文件助手文件助手;

// 配置要写入的文件。
fileHelper.ConfigureFile ("file-helper-example",
文件聚合器::已格式化);

// 设置此格式化输出文件的标签。
fileHelper.Set2dFormat ("时间 (秒) = %.3e\tCount = %.0f");

// 写入探针生成的值。 我们走过的路
// 提供有助于消除跟踪源的歧义。
fileHelper.WriteProbe ("ns3::Uinteger32Probe",
“/名称/发射器/计数器”,
“输出”);

适用范围 限制
目前,只有这些 Probes 已经实现并连接到 GnuplotHelper 和
到 FileHelper:

· 布尔探针

· 双探头

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· 时间探针

· 包探

· 应用包探测

· IPv4PacketProbe

因此,这些 Probe 是唯一可用于 绘图探针()
写探针().

在接下来的几节中,我们将介绍每种基本对象类型(Probe、Collector、
和聚合器)更详细地展示它们如何使用
较低级别的 API。

探头
本节详细介绍 Probe 类提供给 ns-3
模拟,并举例说明如何在程序中对它们进行编码。 本节适用于
有兴趣使用 ns-3 工具和使用数据
Collection Framework,其中 Probe 类是其中的一部分,用于生成数据输出
他们的模拟结果。

探头型号 概述
Probe 对象应该连接到模拟中的变量,其值
整个实验都与用户相关。 探测器将记录
变量在整个模拟过程中假定的值并将这些数据传递给另一个
数据收集框架的成员。 虽然这超出了本节的范围
讨论 Probe 产生输出后会发生什么,这样说就足够了,通过
模拟结束时,用户将获得有关哪些值的详细信息
存储在模拟期间被探测的变量中。

通常,探头连接到 ns-3 跟踪源。 以这种方式,每当
跟踪源导出一个新值,探测器使用该值(并将其导出到下游
通过它自己的跟踪源到另一个对象)。

Probe 可以被认为是跟踪源的一种过滤器。 主要原因
可能连接到 Probe 而不是直接连接到跟踪源如下:

· 可以在模拟过程中通过调用来动态打开和关闭探针 使能够()
禁用(). 例如,数据的输出可能会在
模拟预热阶段。

· 探针可以对数据执行操作以从更复杂的数据中提取值
结构; 例如,从接收到的 ns3::Packet 中输出数据包大小值。

· 探针在 ns3::Config 命名空间中注册一个名称(使用 名称::添加 ()) 使其他
对象可以引用它们。

· Probes 提供了一种静态方法,允许通过名称来操作 Probe,例如
ns2measure [Cic06] 中做了什么

Stat::put ("my_metric", ID, sample);

上述 ns3measure 代码的 ns-2 等效项是,例如

DoubleProbe::SetValueByPath ("/path/to/probe", 示例);

创建
请注意,不能创建 Probe 基类对象,因为它是抽象基类
类,即它具有尚未实现的纯虚函数。 一个对象
类型 DoubleProbe,它是 Probe 类的子类,将在此处创建以显示
需要做什么。

使用智能指针类(Ptr)在动态内存中声明一个 DoubleProbe )。 至
使用智能指针在动态内存中创建一个 DoubleProbe,只需调用
ns-3 方法 创建对象():

点myprobe = 创建对象();

上面的声明使用其属性的默认值创建 DoubleProbes。
DoubleProbe 类中有四个属性; 基类对象中的两个
DataCollectionObject,以及 Probe 基类中的两个:

·“名称”(DataCollectionObject),一个StringValue

·“启用”(DataCollectionObject),一个BooleanValue

·“开始”(Probe),一个TimeValue

·“停止”(Probe),一个TimeValue

可以使用以下方法在创建对象时设置此类属性:

点myprobe = CreateObjectWithAttributes (
"名称", StringValue ("myprobe"),
“启用”,布尔值(假),
“开始”,时间值(秒(100.0)),
“停止”,TimeValue(秒(1000.0)));

Start 和 Stop 是时间变量,它决定了 Probe 的动作间隔。 这
仅当模拟的当前时间在该时间范围内时,探针才会输出数据
间隔。 Stop 的特殊时间值 0 秒将禁用此属性(即
在整个模拟过程中保持 Probe 开启)。 已启用是打开探测器的标志或
关闭,并且必须设置为 true 才能让 Probe 导出数据。 Name 是对象的名称
在 DCF 框架中。

输入 出口 data
ns-3 跟踪源是强类型的,因此将探针挂钩到跟踪的机制
源和导出数据属于其子类。 例如,默认
的分布 ns-3 提供了一个 DoubleProbe 类,旨在挂钩到跟踪
源导出双精度值。 接下来我们将详细介绍 DoubleProbe 的操作,以及
然后讨论用户如何定义其他 Probe 类。

双探头 概述
DoubleProbe 连接到双值 ns-3 跟踪源,并且本身导出一个
不同的双值 ns-3 跟踪源。

以下代码,取自 src/stats/examples/double-probe-example.cc, 显示基本
将 DoubleProbe 连接到模拟中的操作,它正在探测计数器
由发射器对象(Emitter 类)导出。

点发射器 = 创建对象();
Names::Add("/Names/Emitter", 发射器);
...

点probe1 = 创建对象();

// 将探针连接到发射器的计数器
bool connected = probe1->ConnectByObject(“计数器”,发射器);

以下代码正在探测由同一个发射器对象导出的同一个 Counter。 这个
然而,DoubleProbe 使用配置命名空间中的路径来生成
联系。 请注意,发射器在配置命名空间之后注册了自己
它被创造了; 否则,ConnectByPath 将不起作用。

点probe2 = 创建对象();

// 注意,这里没有检查返回值
probe2->ConnectByPath ("/Names/Emitter/Counter");

下面显示的下一个 DoubleProbe 将使用其路径设置其值
配置命名空间。 请注意,这一次 DoubleProbe 在
创建后的配置命名空间。

点probe3 = 创建对象();
probe3->SetName ("StaticallyAccessedProbe");

// 我们必须将它添加到配置数据库
Names::Add("/Names/Probes", probe3->GetName(), probe3);

发射器的 Count() 函数现在可以将此 DoubleProbe 的值设置为
如下:

无效
发射器::计数(无效)
{
...
m_counter += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
...
}

上面的示例显示了调用 Probe 的代码如何不必具有显式
引用 Probe,但可以通过 Config 命名空间直接设置值。
这在功能上类似于 统计::放 ns2measure论文介绍的方法
[Cic06],并允许用户临时插入 Probe 语句,如 的printf 声明
在现有的 ns-3 楷模。 请注意,为了能够在此使用 DoubleProbe
像这样的例子,有两件事是必要的:

1. stats模块头文件包含在示例.cc文件中

2. 该示例依赖于其 wscript 文件中的 stats 模块。

需要做类似的事情才能在其他地方添加其他探针 ns-3
代码库。

DoubleProbe 的值也可以使用函数 DoubleProbe::SetValue() 设置,
而 DoubleProbe 的值可以使用该函数获得
双探针::GetValue()。

DoubleProbe 在其“输出”跟踪源中导出双精度值; 下游对象
可以将跟踪接收器 (NotifyViaProbe) 挂接到此,如下所示:

connected = probe1->TraceConnect("输出",probe1->GetName(),MakeCallback(&NotifyViaProbe));

其他 探头
除了 DoubleProbe,还提供以下探头:

· Uinteger8Probe 连接到一个 ns-3 跟踪源导出 uint8_t。

· Uinteger16Probe 连接到一个 ns-3 跟踪源导出 uint16_t。

· Uinteger32Probe 连接到一个 ns-3 跟踪源导出 uint32_t。

· PacketProbe 连接到一个 ns-3 跟踪源导出数据包。

· ApplicationPacketProbe 连接到一个 ns-3 跟踪源导出数据包和套接字
地址。

· Ipv4PacketProbe 连接到一个 ns-3 跟踪源导出数据包、IPv4 对象和
一个界面。

创造 探头型号 类型
要创建新的 Probe 类型,您需要执行以下步骤:

· 确保您的新 Probe 类派生自 Probe 基类。

· 确保你的新 Probe 类继承自
实现了探测基类。

· 查找一个现有的 Probe 类,该类使用与类型最接近的跟踪源
您的 Probe 将使用的跟踪源类型。

· 将现有 Probe 类的头文件 (.h) 和实现文件 (.cc) 复制到两个
名称与您的新探针匹配的新文件。

· 用适当的替换复制文件中的类型、参数和变量
为您的探头键入。

· 进行必要的修改以使代码编译并使其行为符合您的意愿
喜欢。

例子
这里将详细讨论两个例子:

· 双探头示例

· IPv4 包图示例

探头型号 例如:
双探头示例之前已讨论过。 可以找到示例程序
in src/stats/examples/double-probe-example.cc. 总结这个程序中发生的事情,
有一个发射器输出一个根据泊松过程递增的计数器。
特别是,显示了两种发送数据的方式:

1. 通过与一个 Probe 挂钩的跟踪变量:

跟踪值m_counter; // 通常这将是整数类型

2. 通过一个计数器,其值被发布到第二个探测器,由其名称引用
配置系统:

无效
发射器::计数(无效)
{
NS_LOG_FUNCTION(这个);
NS_LOG_DEBUG ("计数" << Simulator::Now ().GetSeconds ());
m_counter += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
Simulator::Schedule (Seconds (m_var->GetValue ()), &Emitter::Count, this);
}

让我们更仔细地看一下 Probe。 探针可以多次接收它们的值
方法:

1. 通过 Probe 直接访问跟踪源并将跟踪接收器连接到它

2. 由 Probe 通过 config 命名空间访问 trace 源并连接一个
追踪到它

3.通过调用代码显式调用Probe的 设定值() 方法

4.由调用代码显式调用 按路径设置值
("/path/through/Config/namespace", ...)

前两种技术预计是最常见的。 同样在示例中,
显示了正常回调函数的挂钩,通常在 ns-3。 这
回调函数与 Probe 对象无关。 下面我们将这种情况称为 0)。

// 这是一个测试将原始函数挂钩到跟踪源的函数
无效
NotifyViaTraceSource(std::字符串上下文,双oldVal,双newVal)
{
NS_LOG_DEBUG("context:" << context << " old " << oldVal << " new " << newVal);
}

首先,需要设置发射器:

点发射器 = 创建对象();
Names::Add("/Names/Emitter", 发射器);

// Emitter 对象没有与 ns-3 节点关联,所以
// 它不会自动启动,所以我们需要自己做
Simulator::Schedule (Seconds (0.0), &Emitter::Start, 发射器);

示例中的各种 DoubleProbe 与发射器交互,如下所示。

案例0):

// 下面显示了没有探针的典型功能
//(将接收器函数连接到跟踪源)
//
已连接 = 发射器->TraceConnect ("计数器", "示例上下文", MakeCallback (&​​NotifyViaTraceSource));
NS_ASSERT_MSG(已连接,“未连接跟踪源”);

情况1):

//
// Probe1 将直接与 Emitter 跟踪源对象挂钩
//

// probe1 将被挂接到 Emitter 跟踪源
点probe1 = 创建对象();
// 探针的名称可以作为其在跟踪中的上下文
probe1->SetName ("ObjectProbe");

// 将探针连接到发射器的计数器
connected = probe1->ConnectByObject(“计数器”,发射器);
NS_ASSERT_MSG (connected, "Trace source not connected to probe1");

情况2):

//
// Probe2 将通过以下方式连接到 Emitter 跟踪源对象
// 通过 Config 数据库中的路径名访问它
//

// 创建另一个类似的探针; 这将通过配置路径连接
点probe2 = 创建对象();
probe2->SetName ("PathProbe");

// 注意,这里没有检查返回值
probe2->ConnectByPath ("/Names/Emitter/Counter");

案例 4)(案例 3 在此示例中未显示):

//
// Probe3 将被发射器直接通过
// 静态方法 SetValueByPath()。
//
点probe3 = 创建对象();
probe3->SetName ("StaticallyAccessedProbe");
// 我们必须将它添加到配置数据库
Names::Add("/Names/Probes", probe3->GetName(), probe3);

最后,该示例显示了如何挂钩探针以生成输出:

// 探针本身应该生成输出。 我们提供的上下文
// 到这个探针(在这种情况下,探针名称)将有助于消除歧义
//跟踪的来源
已连接 = probe3->TraceConnect(“输出”,
"/Names/Probes/StaticallyAccessedProbe/Output",
MakeCallback (&​​NotifyViaProbe));
NS_ASSERT_MSG (connected, "Trace source not .. connected to probe3 Output");

出于说明目的,以下回调与此示例中的 Probe 挂钩;
通常,Probe 会与 Collector 对象挂钩。

// 这是一个测试钩子到探针输出的函数
无效
NotifyViaProbe(std::字符串上下文,双oldVal,双newVal)
{
NS_LOG_DEBUG("context:" << context << " old " << oldVal << " new " << newVal);
}

IPv4 小包装 情节 例如:
IPv4 数据包图示例基于来自 ns-3 教程。 它
可以发现 src/stats/examples/ipv4-packet-plot-example.cc.

节点 0 节点 1
+----------------+ +----------------+
| ns-3 TCP | | ns-3 TCP |
+----------------+ +----------------+
| 10.1.1.1 | | 10.1.1.2 | XNUMX
+----------------+ +----------------+
| 点对点 | | 点对点 |
+----------------+ +----------------+
| |
+----------+

我们只看一下 Probe,因为它说明 Probes 也可以从
结构(在本例中为数据包)并将这些值报告为跟踪源输出,而不是
而不仅仅是传递相同类型的数据。

此示例的其他方面将在文档后面进行说明。
导出的两种类型的数据是数据包本身(输出) 和计数
数据包中的字节数(输出字节).

类型标识
Ipv4PacketProbe::GetTypeId ()
{
静态 TypeId tid = TypeId ("ns3::Ipv4PacketProbe")
.SetParent ()
.AddConstructor ()
.AddTraceSource ( "输出",
"作为此探测输出的数据包及其 IPv4 对象和接口",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_output))
.AddTraceSource ( "OutputBytes",
"数据包中的字节数",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_outputBytes))
;
返回时间;
}

当 Probe 的 trace sink 收到一个数据包时,如果 Probe 被启用,那么它将输出
其上的数据包 输出 跟踪源,但它也会输出上的字节数
输出字节 跟踪源。

无效
Ipv4PacketProbe::TraceSink (Ptr 数据包,Ptr ipv4,uint4_t 接口)
{
NS_LOG_FUNCTION (this << packet << ipv4 << interface);
如果(启用())
{
m_packet = 数据包;
m_ipv4 = ipv4;
m_interface = 接口;
m_output(数据包,ipv4,接口);

uint32_t packetSizeNew = packet->GetSize();
m_outputBytes (m_packetSizeOld, packetSizeNew);
m_packetSizeOld = packetSizeNew;
}
}

案例
[CIC06]
Claudio Cicconetti、Enzo Mingozzi、Giovanni Stea,“一个综合框架
使用 ns2 实现有效的数据收集和统计分析,研讨会
ns-2 (WNS2),意大利比萨,2006 年 XNUMX 月。

捕收剂
此部分是一个占位符,用于详细说明 Collector 提供的功能
类到 ns-3 模拟,并举例说明如何在程序中对它们进行编码。

请注意: 截至 ns-3.18,收集器仍在开发中,尚未作为一部分提供
的框架。

聚合器
本节详细介绍了 Aggregator 类提供给 ns-3
模拟。 本节适用于有兴趣使用
ns-3 工具并使用数据收集框架,其中 Aggregator 类是
部分,用他们的模拟结果生成数据输出。

聚合 概述
一个 Aggregator 对象应该连接到一个或多个跟踪源,以便
接收输入。 聚合器是网络收集数据的终点
模拟期间的探测器和收集器。 收集这些是聚合器的工作
值并将它们转换为最终输出格式,例如纯文本文件,
电子表格文件、绘图或数据库。

通常,聚合器连接到一个或多个收集器。 以这种方式,每当
收集器的跟踪源导出新值,聚合器可以处理该值,以便
它可以用于最终输出格式,其中数据值将在
模拟。

请注意以下有关聚合器的信息:

· 聚合器可以在模拟过程中动态打开和关闭,调用
使能够()禁用(). 例如,数据的聚合可能会在
模拟预热阶段,这意味着这些值不会包含在决赛中
输出介质。

· 聚合器通过回调从收集器接收数据。 当收集器关联时
对于聚合器,调用 TraceConnect 以建立聚合器的跟踪
sink 方法作为回调。

迄今为止,已经实施了两个聚合器:

· Gnuplot聚合器

· 文件聚合器

Gnuplot聚合器
GnuplotAggregator 生成用于制作 gnuplot 的输出文件。

GnuplotAggregator 将在模拟结束时创建 3 个不同的文件:

· 一个空格分隔的 gnuplot 数据文件

·一个gnuplot控制文件

· 用于生成 gnuplot 的 shell 脚本

创建
将在这里创建一个 GnuplotAggregator 类型的对象来显示需要做什么。

使用智能指针类在动态内存中声明一个 GnuplotAggregator
(点)。 要使用智能指针在动态内存中创建 GnuplotAggregator,只需
需要调用 ns-3 方法 创建对象(). 以下代码来自
src/stats/examples/gnuplot-aggregator-example.cc 展示了如何做到这一点:

string fileNameWithoutExtension = "gnuplot-aggregator";

// 创建一个聚合器。
点聚合器 =
创建对象(fileNameWithoutExtension);

构造函数的第一个参数 fileNameWithoutExtension 是
gnuplot 相关文件无需扩展即可写入。 这个 GnuplotAggregator 将创建一个
空格分隔的 gnuplot 数据文件,名为“gnuplot-aggregator.dat”,一个 gnuplot 控制文件
命名为“gnuplot-aggregator.plt”,以及一个用于生成名为 + 的 gnuplot 的 shell 脚本
“gnuplot-aggregator.sh”。

创建的 gnuplot 可以在 4 个不同的位置拥有其密钥:

· 没有钥匙

· 剧情内键(默认)

· 情节上方的钥匙

· 情节下方的键

允许以下 gnuplot 键位置枚举值指定键的位置:

枚举 KeyLocation {
无键,
KEY_INSIDE,
KEY_ABOVE,
KEY_BELOW 键
};

如果希望有下面的键而不是里面的默认位置,那么
您可以执行以下操作。

聚合器->SetKeyLocation(GnuplotAggregator::KEY_BELOW);

例子
这里将详细讨论一个示例:

· Gnuplot 聚合器示例

诺普洛特 聚合 例如:
一个练习 GnuplotAggregator 的例子可以在
src/stats/examples/gnuplot-aggregator-example.cc.

以下二维 gnuplot 是使用示例创建的。
[图像] 2-D Gnuplot 创建者 gnuplot-aggregator-example.cc Example..UNIDENT

示例中的这段代码显示了如何构建 GnuplotAggregator 所讨论的
以上。

无效的 Create2dPlot ()
{
使用名称空间std;

string fileNameWithoutExtension = "gnuplot-aggregator";
string plotTitle = "Gnuplot 聚合器图";
string plotXAxisHeading = "时间(秒)";
字符串 plotYAxisHeading = "双值";
字符串 plotDatasetLabel = "数据值";
字符串 datasetContext = "数据集/上下文/字符串";

// 创建一个聚合器。
点聚合器 =
创建对象(fileNameWithoutExtension);

设置了各种 GnuplotAggregator 属性,包括将要生成的 2-D 数据集
绘制。

// 设置聚合器的属性。
聚合器->SetTerminal ("png");
聚合器->SetTitle (plotTitle);
聚合器->SetLegend (plotXAxisHeading, plotYAxisHeading);

// 将数据集添加到聚合器。
聚合器->Add2dDataset (datasetContext, plotDatasetLabel);

// 聚合器必须打开
聚合器->启用();

接下来,计算二维值,并将每个值单独写入
GnuplotAggregator 使用 写2d() 功能。

双倍时间;
双倍价值;

// 创建二维数据集。
对于(时间 = -5.0;时间 <= +5.0;时间 += 1.0)
{
// 计算二维曲线
//
//2
// 价值 = 时间。
//
价值=时间*时间;

// 将此点添加到绘图中。
聚合器->Write2d(数据集上下文,时间,值);
}

// 禁用聚合器的数据记录。
聚合器->禁用();
}

文件聚合器
FileAggregator 将接收到的值发送到文件。

FileAggregator 可以创建 4 种不同类型的文件:

· 格式化

· 空格分隔(默认)

· 逗号分隔

· 制表符分隔

格式化文件使用 C 风格的格式字符串和 sprintf() 函数来打印它们
正在写入的文件中的值。

创建
将在此处创建一个 FileAggregator 类型的对象以显示需要做什么。

使用智能指针类(Ptr)在动态内存中声明一个 FileAggregator )。
要使用智能指针在动态内存中创建 FileAggregator,只需调用
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 ns-3 方法创建对象。 以下代码来自
src/stats/examples/file-aggregator-example.cc 展示了如何做到这一点:

string fileName = "文件聚合器格式化值.txt";

// 创建一个具有格式化值的聚合器。
点聚合器 =
创建对象(文件名, FileAggregator::FORMATTED);

构造函数的第一个参数 filename 是要写入的文件的名称; 这
第二个参数,fileType,是要写入的文件类型。 这个 FileAggregator 将创建一个
名为“file-aggregator-formatted-values.txt”的文件,其值按指定打印
fileType,即在这种情况下格式化。

允许使用以下文件类型枚举值:

枚举文件类型 {
格式化,
SPACE_SEPARATED,
逗号分隔,
TAB_SEPARATED
};

例子
这里将详细讨论一个示例:

· 文件聚合器示例

文件 聚合 例如:
一个练习 FileAggregator 的例子可以在
src/stats/examples/file-aggregator-example.cc.

使用逗号分隔的以下包含 2 列值的文本文件是使用
例。

-5,25
-4,16
-3,9
-2,4
-1,1
0,0
1,1
2,4
3,9
4,16
5,25

示例中的此代码显示了如何构造所讨论的 FileAggregator
以上。

无效 CreateCommaSeparatedFile ()
{
使用名称空间std;

string fileName = "文件聚合器-逗号分隔的.txt";
字符串 datasetContext = "数据集/上下文/字符串";

// 创建一个聚合器。
点聚合器 =
创建对象(文件名,FileAggregator::COMMA_SEPARATED);

FileAggregator 属性已设置。

// 聚合器必须打开
聚合器->启用();

接下来,计算二维值,并将每个值单独写入
使用 FileAggregator 写2d() 功能。

双倍时间;
双倍价值;

// 创建二维数据集。
对于(时间 = -5.0;时间 <= +5.0;时间 += 1.0)
{
// 计算二维曲线
//
//2
// 价值 = 时间。
//
价值=时间*时间;

// 将此点添加到绘图中。
聚合器->Write2d(数据集上下文,时间,值);
}

// 禁用聚合器的数据记录。
聚合器->禁用();
}

以下具有 2 列格式化值的文本文件也是使用
例。

时间 = -5.000e+00 值 = 25
时间 = -4.000e+00 值 = 16
时间 = -3.000e+00 值 = 9
时间 = -2.000e+00 值 = 4
时间 = -1.000e+00 值 = 1
时间 = 0.000e+00 值 = 0
时间 = 1.000e+00 值 = 1
时间 = 2.000e+00 值 = 4
时间 = 3.000e+00 值 = 9
时间 = 4.000e+00 值 = 16
时间 = 5.000e+00 值 = 25

示例中的此代码显示了如何构造所讨论的 FileAggregator
以上。

无效的 CreateFormattedFile ()
{
使用名称空间std;

string fileName = "文件聚合器格式化值.txt";
字符串 datasetContext = "数据集/上下文/字符串";

// 创建一个具有格式化值的聚合器。
点聚合器 =
创建对象(文件名, FileAggregator::FORMATTED);

设置了 FileAggregator 属性,包括要使用的 C 样式格式字符串。

// 设置值的格式。
聚合器->Set2dFormat ("时间 = %.3e\tValue = %.0f");

// 聚合器必须打开
聚合器->启用();

接下来,计算二维值,并将每个值单独写入
使用 FileAggregator 写2d() 功能。

双倍时间;
双倍价值;

// 创建二维数据集。
对于(时间 = -5.0;时间 <= +5.0;时间 += 1.0)
{
// 计算二维曲线
//
//2
// 价值 = 时间。
//
价值=时间*时间;

// 将此点添加到绘图中。
聚合器->Write2d(数据集上下文,时间,值);
}

// 禁用聚合器的数据记录。
聚合器->禁用();
}

适配器
本节详细介绍 Adapter 类提供给 ns-3
模拟。 本节适用于有兴趣使用
ns-3 工具并使用数据收集框架,其中适配器类是其中的一部分,
用他们的模拟结果生成数据输出。

注意:术语“适配器”也可以拼写为“适配器”; 我们选择了拼写对齐
与 C++ 标准。

适配器 概述
适配器用于在不同类型的 DCF 对象之间建立连接。

迄今为止,已经实现了一个适配器:

· 时间序列适配器

时间 系列 适配器
TimeSeriesAdaptor 让探针直接连接到聚合器,而不需要任何
介于两者之间的收藏家。

两个实现的 DCF 助手都使用 TimeSeriesAdaptors 来探测
不同类型的值并输出当前时间加上两者转换后的值
双打。

TimeSeriesAdaptor 类的角色是一个适配器,它接受原始值
探测不同类型的数据并输出两个双精度值的元组。 第一个是一个
时间戳,可以设置为不同的分辨率(如秒、毫秒等)
未来,但目前被硬编码为秒。 第二个是转换
非双精度值到双精度值(可能会丢失精度)。

范围/限制
本节讨论数据收集框架的范围和限制。

目前,在 DCF 中只实现了这些 Probe:

· 布尔探针

· 双探头

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· 时间探针

· 包探

· 应用包探测

· IPv4PacketProbe

目前,DCF 中没有可用的收集器,尽管 BasicStatsCollector 在
发展。

目前,在 DCF 中仅实现了以下聚合器:

· Gnuplot聚合器

· 文件聚合器

目前,DCF中只实现了这个Adapter:

时间序列适配器。

未来 工作
本节讨论未来在数据收集框架上要做的工作。

以下是一些仍然需要做的事情:

· 连接更多的跟踪源 ns-3 从模拟器中获取更多值的代码。

· 实施比目前更多类型的探测器。

· 实现的不仅仅是单一的当前二维收集器,BasicStatsCollector。

· 实施更多聚合器。

· 实施的不仅仅是适配器。

数码单反 路由


目的地序列距离矢量 (DSDV) 路由协议是一种主动的、
由 Charles E. Perkins 和 Pravin 开发的 MANET 的表驱动路由协议
1994 年的 Bhagwat。它使用跳数作为路由选择的度量标准。

该模型由 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 弹性网 研究 在堪萨斯大学。 一个
关于这个模型的论文存在于 Free Introduction 网址.

数码单反 路由 概述
DSDV 路由表:每个节点都会维护一个表,列出它拥有的所有其他节点
直接或通过一些邻居知道。 每个节点在
路由表。 该条目将包含有关节点 IP 地址的信息,最后为人所知
序列号和到达该节点的跳数。 除了这些细节,表格
还跟踪到达目标节点的下一跳邻居,时间戳
该节点收到的最后一次更新。

DSDV 更新消息由三个字段组成,目的地址、序列号和
跳数。

每个节点使用 2 种机制来发送 DSDV 更新。 他们是,

1.

定期 最新动态
在每个 m_periodicUpdateInterval(默认值:15s)之后发送定期更新。
在此更新中,节点广播其整个路由表。

2.

触发端口 最新动态
触发更新是定期更新之间的小更新。 这些更新
每当一个节点收到一个 DSDV 数据包导致其
路由表。 原始论文没有明确提及何时进行哪些更改
表中应发送 DSDV 更新。 当前的实现发送
无论路由表中的更改如何,都会进行更新。

根据特定节点的度量标准接受更新。 第一个因素
决定接受更新的是序列号。 它必须接受更新
如果无论度量标准如何,更新消息的序列号都更高。 如果
接收到具有相同序列号的更新,然后具有最小度量 (hopCount) 的更新
被优先考虑。

在高度移动的场景中,路线波动的可能性很大,因此我们有
加权稳定时间的概念,其中不会随着度量的变化而更新
向邻居宣传。 节点等待建立时间以确保它没有
在发送该更新之前从其旧邻居接收更新。

当前的实现涵盖了 DSDV 的所有上述功能。 目前的
实现还有一个请求队列来缓冲没有路由到的数据包
目的地。 默认设置为每个目标最多缓冲 5 个数据包。

案例
论文链接: http://portal.acm.org/citation.cfm?doid=190314.190336

DSR 路由


动态源路由(DSR)协议是一种专门设计的反应式路由协议
用于移动节点的多跳无线自组织网络。

该模型由 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 弹性网 研究 在堪萨斯大学。

DSR 路由 概述
该模型实现了动态源路由 (DSR) 协议的基本规范。
实施是基于 RFC 4728, 对 RFC 进行了一些扩展和修改
规格。

DSR 在按需行为上运行。 因此,我们的 DSR 模型缓冲所有数据包,而
路由请求包 (RREQ) 被分发。 我们在
dsr-rsendbuff.cc。 数据包队列实现了旧数据包的垃圾收集和一个
队列大小限制。 当数据包从发送缓冲区发出时,它会在队列中
用于下一跳确认的维护缓冲区。

然后维护缓冲区缓存已经发出的数据包并等待
数据包传递的通知。 协议操作强烈依赖断链
检测机制。 我们将基于 RFC 推荐的三种启发式方法实现为
如下:

首先,我们尽可能使用链路层反馈,这也是最快的机制
这三个来检测链接错误。 如果帧传输,则认为链路断开
导致所有重试传输失败。 这种机制是为了主动
链接和工作比没有它时快得多。 DSR 能够检测到链路层
传输失败并通知已损坏。 将触发重新计算路线
需要的时候。 如果用户不想使用链路层确认,可以通过
在“dsr-routing.cc”中将“LinkAcknowledgment”属性设置为 false。

其次,应尽可能使用被动确认。 节点开启
“混杂”接收模式,它可以接收不是发往自己的数据包,以及
当节点确保该数据包传送到它的目的地时,它取消
被动确认定时器。

最后,我们使用网络层确认方案来通知数据包的接收。 路线
请求数据包不会被确认或重传。

Route Cache 实现支持旧条目和状态的垃圾收集
机器,如标准中所定义。 它实现为 STL 地图容器。 关键是
目标 IP 地址。

DSR 直接访问 IP 报头,在网络和传输之间运行
层。 当数据包从传输层发出时,它会将自己传递给 DSR 和 DSR
附加标题。

我们有两种缓存机制:路径缓存和链接缓存。 路径缓存保存整个
缓存中的路径。 路径是根据跳数排序的,只要有一条路径
无法使用,我们换到下一条路径。 链接缓存稍微好一点
在某种意义上设计它使用不同的子路径并使用实现的链接缓存使用
Dijsktra 算法,这部分由宋鸾实现[电子邮件保护]>.

未实现以下可选协议优化:

· 流动状态

·第一跳外部(F),最后一跳外部(L)标志

· 处理未知的 DSR 选项

·

类型 of 错误 标头:

1.流状态不支持选项

2. 不支持的选项(模拟中不会发生)

DSR 更新 in ns-3.17
我们最初在 Ptr 中使用了“TxErrHeader” 来指示一个传输错误
链路层中的特定数据包,然而,它不能完全正确地工作,因为即使
数据包被丢弃,此标头未记录在跟踪文件中。 我们曾经
实现链路层通知机制的不同路径。 我们调查
通过查找数据包接收事件跟踪文件。 如果我们找到数据的一个接收事件
数据包,我们将其视为数据传输成功的指标。

有用 参数
+---------------------------- +------------------------ --------------+-------------+
| 参数 | 说明 | 默认 |
+===========================+====================== ===============+==============+
| MaxSendBuffLen | 最大数据包数 | 64 |
| | 存储在发送缓冲区中 | |
+---------------------------- +------------------------ --------------+-------------+
| 最大发送缓冲时间 | 数据包可以排队的最长时间 | (30)|
| | 在发送缓冲区中 | |
+---------------------------- +------------------------ --------------+-------------+
| MaxMaintLen | 最大数据包数 | 50 |
| | 存储在维护缓冲区中| |
+---------------------------- +------------------------ --------------+-------------+
| 最大维护时间 | 数据包可以排队的最长时间 | (30)|
| | 在维护缓冲区| 高分辨率照片| CLIPARTO |
+---------------------------- +------------------------ --------------+-------------+
| 最大缓存长度 | 最大路由条目数 | 64 |
| | 可以存储在路由缓存中 | |
+---------------------------- +------------------------ --------------+-------------+
| 路由缓存超时 | 路由缓存的最大时间 | (300)|
| | 在路由缓存中排队 | |
+---------------------------- +------------------------ --------------+-------------+
| RreqRetries | 最大重传次数 | 16 |
| | 用于请求发现路由 | |
+---------------------------- +------------------------ --------------+-------------+
| 缓存类型 | 使用链接缓存或使用路径缓存 | “链接缓存” |
| | | |
+---------------------------- +------------------------ --------------+-------------+
| 链接致谢 | 启用链路层确认 | 真 |
| | 机制 | |
+---------------------------- +------------------------ --------------+-------------+

实施 修改
·

- DsrFs头 具有 添加 3 字段: 消息 类型, 资源 ID 目的地 ID 这些
变化 仅由 后处理

1. 消息类型用于区分数据包和控制包

2. source id用​​于识别数据包的真实来源,因为我们有
逐跳传递数据包,并且 ipv4header 没有携带真实的
根据需要源和目标 IP 地址

3.目的地ID与上述相同

· Route Reply header 在 DSR RFC 中不是 word-aligned,在 DSR RFC 中将其更改为 word-aligned
履行

· DSR 充当传输和网络协议之间的 shim 标头,它需要自己的
转发机制,我们正在将数据包传输更改为逐跳传递,所以
我们在 dsr 固定头中添加了两个字段来通知数据包的传递

电流 路线 缓存 履行
本实现使用了“路径缓存”,实现简单,保证无循环
路径:

· 路径缓存有自动过期策略

· 缓存为某个目的地保存多个路由条目并对条目进行排序
基于跳数

· MaxEntriesEachDst 可以调整以更改为单个保存的最大条目
目的地

· 为一个目的地添加多条路线时,路线比较基于
hop-count 和 expire time,跳数少或者路由比较新的是
青睐

· 未来的实现可能包括“链接缓存”作为另一种可能性

DSR 说明
将 DSR 作为路由协议运行时应牢记以下几点:

· NodeTraversalTime 是遍历两个相邻节点的时间,应该是
选择适合传输范围

· PassiveAckTimeout 是维护缓冲区中的数据包等待被动的时间
确认,通常设置为 NodeTraversalTime 的两倍

· RouteCacheTimeout 应在节点速度变高时设置较小的值。
默认值为 300 秒。

帮手
要让节点运行 DSR,最简单的方法是使用 DsrHelper 和 DsrMainHelpers
在您的模拟脚本中。 例如:

DsrHelper dsr;
DsrMainHelper dsrMain;
dsrMain.Install(dsr,adhocNodes);

里面的示例脚本 src/dsr/示例/ 演示基于 DSR 的节点的使用
不同的场景。 可以在里面找到帮助程序源
src/dsr/helper/dsr-main-helper.{h,cc}src/dsr/helper/dsr-helper.{h,cc}

例子
该示例可以在 src/dsr/示例/:

· dsr.cc 使用 DSR 作为传统 MANETs 环境中的路由协议[3]。

DSR也内置在路由比较案例中 示例/路由/:

· manet-路由比较.cc 是与内置 MANET 路由协议的比较案例,并且
可以产生自己的结果。

验证
该模型已经过测试如下:

· 已编写单元测试来验证 DSR 的内部结构。 这可以在
src/dsr/test/dsr-test-suite.cc. 这些测试验证 DSR 模块内部的方法是否
处理数据包缓冲区,标头正常工作。

· 与[3] 类似的模拟案例已经过测试并具有可比较的结果。

· manet-routing-compare.cc 已用于将 DSR 与其他三个路由进行比较
协议。

在 3 年的 ns-2011 研讨会上发表了一篇关于这些结果的论文。

限制
该模型不完全符合 RFC 4728. 例如,Dsr 固定大小标头具有
已扩展,它比 RFC 规范长了四个八位字节。 作为结果,
Wireshark 无法正确解码 DSR 标头。

未来计划完全符合 RFC 的模型。

案例
[1] 原论文: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

[2] RFC 4728 http://www6.ietf.org/rfc/rfc4728.txt

[3] 布罗赫的比较论文: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

仿真 产品详情


ns-3 专为集成到测试平台和虚拟机环境而设计。 我们
通过提供两种网络设备来满足这一需求。 第一种装置
是一个文件描述符网络设备(Fd网络设备),这是一种通用设备类型,可以
从文件描述符读取和写入。 通过将此文件描述符与不同的
主机系统上的东西,可以提供不同的能力。 例如,
FdNetDevice 可以与底层数据包套接字关联以提供仿真
能力。 这允许 ns-3 模拟在“真实”网络上发送数据。 第二
种,叫a 敲打 网络设备 允许“真正的”主持人参与 ns-3 模拟为
如果它是模拟节点之一。 一个 ns-3 模拟可以用任何构造
模拟或仿真设备的组合。

请注意: 在 ns-3.17 之前,仿真能力由一个特殊的设备提供,称为
an 网络设备; 这 NetDevice 已被 Fd网络设备.

我们想要支持的用例之一是测试平台。 一个具体的例子
这种环境就是 ORBIT 测试平台。 ORBIT 是一个实验室仿真器/现场试验
网络排列为 400 个 802.11 无线电节点的二维网格。 我们与
ORBIT 通过使用他们的“成像”过程来加载和运行 ns-3 ORBIT上的模拟
大批。 我们可以使用我们的 仿真网络设备 驱动测试平台中的硬件,我们可以
累积结果要么使用 ns-3 跟踪和日志记录功能,或本机
ORBIT 数据收集技术。 看 http://www.orbit-lab.org/ 有关 ORBIT 的详细信息
测试台。

这种模拟如下图所示:
[图片] 测试台仿真的示例实现..UNIDENT

您可以看到有单独的主机,每个主机运行一个“全局”的子集
模拟。 而不是一个 ns-3 连接主机的通道,我们使用真实的硬件
由测试平台提供。 这允许 ns-3 应用程序和协议栈附加到
模拟节点通过真实硬件进行通信。

我们预计此配置的主要用途是生成可重复的
真实世界网络环境中的实验结果,包括所有 ns-3
跟踪、记录、可视化和统计收集工具。

在本质上可以被视为逆配置的情况下,我们允许“真实”机器
运行本机应用程序和协议栈以与 ns-3 模拟。
这允许模拟连接到真实机器的大型网络,并且还
启用虚拟化。 这种模拟如下图所示:
[image] 模拟通道的实现概述..UNIDENT

在这里,您将看到有一个主机运行着许多虚拟机
在上面。 一个 ns-3 模拟显示在中心显示的虚拟机中运行
图。 该模拟有许多节点与相关联的 ns-3 应用程序和
正在与 ns-3 通过原生模拟渠道 ns-3
设备。

图中的最左侧和最右侧还显示了两个虚拟机。
这些虚拟机正在运行本机 (Linux) 应用程序和协议栈。 虚拟机是
通过 Linux Tap 网络设备连接到模拟中。 的用户模式处理程序
Tap 设备在模拟中被实例化并连接到代理节点,该代理节点
表示模拟中的本机 VM。 这些处理程序允许 Tap 设备在
本机虚拟机的行为就像它们是 ns-3 模拟 VM 中的网络设备。 这,在
反过来,允许本地虚拟机中的本地软件和协议套件相信
它们连接到模拟 ns-3 频道。

我们预计此环境的典型用例将是分析
存在大型模拟的本地应用程序和协议套件 ns-3
网络。

文件 描述 网络设备
- src/fd-net-设备 模块提供 Fd网络设备 类,它能够阅读和
使用用户提供的文件描述符写入流量。 这个文件描述符可以是
与 TAP 设备、原始套接字、用户空间进程相关联
流量等。用户可以完全自由地定义外部流量的产生方式和
ns-3 流量被消耗。

可以通过以下方式提供将模拟与外部流量相关联的不同机制
助手类。 提供了三个特定的助手:

· EmuFdNetDeviceHelper(关联 ns-3 主机中带有物理设备的设备
机)

· TapFdNetDeviceHelper(将ns-3设备与来自tap的文件描述符相关联
主机中的设备)

· PlanteLabFdNetDeviceHelper(在PlaneLab节点中自动创建tap设备,
使 ns-3 可以通过 Internet 发送和接收流量的模拟
行星实验室资源。

型号 描述
该模块的源代码位于目录中 src/fd-net-设备.

FdNetDevice 是一种特殊类型的 ns-3 从文件读取流量的 NetDevice
描述符。 也就是说,与将帧写入和写入的纯模拟 NetDevice 对象不同,
来自模拟通道,此 FdNetDevice 将模拟中的帧定向到文件
描述符。 文件描述符可能与 Linux TUN/TAP 设备、套接字、
或用户空间进程。

由该设备的用户提供文件描述符。 文件类型
提供的描述符确定正在建模的内容。 例如,如果文件
描述符为主机上的 WiFi 卡提供一个原始套接字,该设备是
建模是一个 WiFi 设备。

从设备的概念“顶部”向下看,它看起来像模拟节点
支持可桥接的 48 位 IEEE MAC 地址的设备,支持广播和
使用 IPv4 ARP 或 IPv6 邻居发现,尽管这些属性可以在
每个用例的基础。

工艺设计
FdNetDevice 实现使用了一个读取器对象,从 阅读器
在课堂上 ns-3 源代码/核心 模块,它管理一个独立于主线程的线程 ns-3
执行线程,以便从文件描述符中读取流量。

在调用 启动设备 方法,读取器对象被初始化并启动
阅读线程。 在设备启动之前,必须先将文件描述符关联到
FdNetDevice 与 设置文件描述符 调用。

文件描述符的创建和配置可以留给许多助手,
下面更详细地描述。 完成后,调用 设置文件描述符 is
助手的责任,不得由用户直接调用。

从文件描述符中读取传入帧后,阅读器会将帧传递给
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 接收回调 方法,其任务是调度帧的接收
设备作为 ns-3 模拟事件。 由于新帧是从阅读器线程传递到
ns-3 模拟线程,线程安全问题通过使用
带上下文的调度 调用而不是常规调用 活动行程 呼叫。

为了避免在传入数据速率过高时使调度程序不堪重负,
计数器保存当前计划接收的帧数
设备。 如果此计数器达到由 接收队列大小 属性在
设备,则新帧将被静默丢弃。

设备实际接收到的新帧发生在预定时间 福特战争
方法由模拟器调用。 这个方法就像一个新的帧已经从一个
连接到设备的通道。 然后设备解封装框架,移除任何层
2个标头,并将其转发到节点的上层网络堆栈层。 这 前进
方法将删除帧头,根据定义的帧封装类型
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 封装模式 属性,并调用传递 IP 数据包的接收回调。

当文件描述符关联到
在未设置 IFF_NO_PI 标志的情况下创建的 TAP 设备。 这个额外的标题是
删除如果 封装模式 设置为 DIXPI 值。

在相反的方向,模拟内部生成的数据包被发送出去
通过该设备,将被传递到 发送 方法,该方法将依次调用
发件人 方法。 后一种方法将添加必要的第 2 层标头,并且只需
将新创建的帧写入文件描述符。

适用范围 限制
警告此设备的用户,文件中没有流控制
描述符边界,在仿真模式下使用时。 也就是说,在 Linux 系统中,如果
写入网络数据包的速度超过了底层物理设备的能力
缓冲数据包,将应用到写入应用程序的背压以避免
本地丢包。 文件描述符接口没有提供这样的流控制,
所以用户必须意识到这个限制。

如前所述,RxQueueSize 属性限制了可以接收的数据包数量
等待设备接收。 从文件描述符中读取的帧,而
待处理的数据包数量达到最大值时将被静默丢弃。

设备的 mtu 默认为 Ethernet II MTU 值。 然而,助手应该
将mtu设置为正确的值以反映网络接口的特性
关联到文件描述符。 如果没有使用助手,则由
为设备设置正确的 mtu 值回退给用户。 读取的大小
文件描述符读取器上的缓冲区设置为 启动设备 方法。

FdNetDevice类目前支持三种封装模式,DIX for Ethernet II
帧、用于 802.2 LLC/SNAP 帧的 LLC 和用于以太网 II 帧的 DIXPI
TAP PI 标头。 这意味着遍历文件描述符的流量预计为
以太网 II 兼容。 将 FdNetDevice 连接到无线接口是可能的
只要驱动程序向套接字 API 提供以太网 II 帧。 请注意,要关联
a FdNetDevice 到 ad-hoc 模式下的无线网卡,必须设置设备的 MAC 地址
到真正的卡 MAC 地址,否则任何传入流量都将是假 MAC 地址
被司机丢弃。

如前所述,fd-net-device 模块提供了三个帮助程序。 每个
单个助手(文件描述符类型)可能有平台限制。 例如,
线程、实时仿真模式和创建 TUN/TAP 设备的能力是
使用提供的帮助程序的先决条件。 对这些模式的支持可以在
的输出 WAF 配置 步骤,例如:

线程原语:启用
实时模拟器:启用
模拟网络设备:启用
点击桥:启用

值得一提的是,在测试 Fd网络设备 我们找到了一个上限
使用 1Mbps 的 60Gb 以太网链路时 TCP 吞吐量的限制。 这个限制最
可能是由于测试中涉及的计算机的处理能力。

用法
此类设备的使用模式类似于其他带有助手的网络设备
安装到节点指针或节点容器。 使用底座时 FdNet设备助手
用户负责自己创建和设置文件描述符。

FdNetDeviceHelper fd;
NetDeviceContainer 设备 = fd.Install(节点);

// 文件描述符生成
...

设备->SetFileDescriptor (fd);

最常见的 FdNetDevice 将用于与主机系统交互。 在这些情况下
几乎可以肯定,用户想要在实时仿真模式下运行,并且
启用校验和计算。 典型的程序语句如下:

GlobalValue::Bind ("SimulatorImplementationType", StringValue ("ns3::RealtimeSimulatorImpl"));
GlobalValue::Bind ("ChecksumEnabled", BooleanValue (true));

设置与 Linux 主机系统交互的实验的最简单方法是用户
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 敲打 帮手。 也许这些助手实现中最不寻常的部分
涉及到执行某些具有超级用户权限的代码的要求。
我们没有强制用户以 root 身份执行整个模拟,而是提供了一个小的
“创建者”程序以 root 身份运行并执行任何所需的高权限套接字工作。
为“创建者”程序设置正确权限的最简单方法是启用
--启用须藤 表演时打旗 WAF 配置.

我们为两者做类似的事情 敲打 设备。 高层的观点是
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 创建文件描述符 方法创建本地进程间 (Unix) 套接字、分叉和
执行小型创作程序。 以 suid root 身份运行的小程序创建了一个
原始套接字并通过 Unix 套接字发回原始套接字文件描述符
作为参数传递给它。 原始套接字作为控制消息传递(有时
称为 SCM_RIGHTS 类型的辅助数据。

助手
EmuFdNet设备助手
EmuFdNetDeviceHelper 创建一个到底层物理设备的原始套接字,并且
向 FdNetDevice 提供套接字描述符。 这允许 ns-3 模拟到
从主机上的网络设备读取和写入帧。

仿真助手允许透明地集成模拟的 ns-3 节点成
由真实节点组成的网络。

+----------------------+ +----------------------+
| 主机 1 | | 主机 2 |
+----------------------+ +----------------------+
| ns-3 模拟 | | |
+------------------------+ | Linux |
| ns-3 节点 | | 网络堆栈 |
| +----------------+ | | +----------------+ |
| | ns-3 TCP | | | | 技术支持 | |
| +----------------+ | | +----------------+ |
| | ns-3 IP | | | | 知识产权 | |
| +----------------+ | | +----------------+ |
| | 网络设备 | | | | | |
| | 10.1.1.1 | | | | | |
| +----------------+ | | + 以太网 + |
| | 原始套接字 | | | | | |
|--+----------------+--| | +----------------+ |
| | eth0 | | | | eth0 | |
+--------+------+--------+ +--------+------+-------+

10.1.1.11 10.1.1.12

| |
+----------------------------------------+

这个助手替换了 EmuNet设备 在发现 ns-3 在 ns-3.17 之前,
通过将这种类型的设备引入 FdNetDevice 的通用框架。 这
EmuNet设备 被弃用,取而代之的是这个新的助手。

该设备配置为执行 MAC 欺骗以分离模拟网络流量
来自可能流入和流出主机的其他网络流量。

可以在模拟所在的主机的测试平台情况下使用此帮助程序
running 有一个感兴趣的特定接口,它驱动测试台硬件。 你会
还需要将此特定接口设置为混杂模式并提供适当的
设备名称 ns-3 模拟。 此外,分割的硬件卸载和
校验和应该被禁用。

仅当底层接口启动并处于混杂模式时,帮助程序才有效。 数据包
将通过设备发送出去,但我们使用 MAC 欺骗。 MAC 地址将是
生成(默认)使用组织唯一标识符 (OUI) 00:00:00 作为
根据。 此供应商代码未分配给任何组织,因此不应与
任何真正的硬件。

始终由用户决定是否可以在您的设备上使用这些 MAC 地址
网络并且不会与其他任何东西冲突(包括使用此类的另一个模拟
设备)在您的网络上。 如果您使用的是模拟的 FdNetDevice 配置
单独的模拟,您必须考虑全局 MAC 地址分配问题并确保
MAC 地址在所有模拟中都是唯一的。 仿真网络设备尊重
中提供的 MAC 地址 企业地址 属性,因此您可以手动执行此操作。 对于较大的
模拟时,您可能需要在 MAC 地址分配函数中设置 OUI。

在调用之前 安装 方法,必须在设备上配置正确的设备名称
助手使用 设置设备名称 方法。 需要设备名称来识别哪个
应使用物理设备打开原始套接字。

EmuFdNetDeviceHelper 鸸;
emu.SetDeviceName(设备名);
NetDeviceContainer devices = emu.Install(节点);
点设备=设备。获取(0);
device->SetAttribute("地址", Mac48AddressValue (Mac48Address::Allocate ()));

TapFdNetDeviceHelper
Tap 设备是一种特殊类型的 Linux 设备,设备的一端似乎
内核作为虚拟网络设备,另一端作为文件描述符提供给
用户空间。 这个文件描述符可以传递给 FdNetDevice。 转发到的数据包
内核的 TAP 设备将显示在 FdNetDevice 中 ns-3.

用户应注意,TAP 设备的这种用法不同于
TapBridge NetDevice 发现于 src/tap桥. 这个助手中的模型如下:

+ ------------------------------------------------- +
| 主持人 |
+ ------------------------------------------------- +
| ns-3 模拟 | |
+------------------------+ |
| ns-3 节点 | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | 网络设备 | | |
|--+----------------+--+ +------+ |
| | 水龙头 | | eth0 | |
| +-----+ +-----+ |
| 192.168.0.1 | 年|
+-------------------------------|------+
|
|
- - - - - - (互联网) - - -

上面的配置要求主机能够转发流量
模拟生成到网上。

TapBridge中的模型(在另一个模块中)如下:

+--------+
| Linux |
| 主持人 | +----------+
| ------ | | 鬼 |
| 应用程序 | | 节点 |
| ------ | | ------ |
| 堆栈 | | 知识产权 | +----------+
| ------ | | 堆栈 | | 节点 |
| 水龙头 | |===========| | -------- |
| 设备 | <----- IPC ------> | 水龙头 | | 知识产权 |
+--------+ | 桥 | | 堆栈 |
| ------ | | ------ |
| ns-3 | | ns-3 |
| 净 | | 净 |
| 设备 | | 设备 |
+-----------+ +-----------+
|| ||
+----------------------------+
| ns-3 频道 |
+----------------------------+

在上面,数据包改为遍历 ns-3 网络设备和通道。

此示例的使用模式是用户设置 MAC 地址和任一(或
两者)设备上的 IPv4 和 IPv6 地址和掩码,以及 PI 标头(如果需要)。
例如:

TapFdNetDeviceHelper 助手;
helper.SetDeviceName(设备名称);
helper.SetModePi(modePi);
helper.SetTapIpv4Address (tapIp);
helper.SetTapIpv4Mask (tapMask);
...
helper.Install(节点);

PlanetLabFdNetDeviceHelper
PlanetLab 是一个全球分布式网络测试平台,由连接到
互联网。 在 PlanetLab 节点中运行 ns-3 模拟,使用
PlanetLabFdNetDeviceHelper 允许将 ns-3 生成的模拟流量直接发送到
互联网。 此设置可用于验证 ns-3 Internet 协议或其他未来
ns-3 中实现的协议。

要使用 PlanetLab 节点运行实验,需要拥有 PlanetLab 帐户。 仅有的
PlanetLab 合作机构的成员可以获得此类帐户(更多信息
访问 http://www.planet-lab.org/ or http://www.planet-lab.eu )。 一旦账户
获得,PlanetLab 必须请求才能进行实验。 一片
表示与一组 PlanetLab 用户相关的实验单元,可以关联
到不同 PlanetLab 节点中的虚拟机。 切片也可以通过添加来定制
配置标签(这是由 PlanetLab 管理员完成的)。

PlanetLabFdNetDeviceHelper 在 PlanetLab 节点上使用特定的
PlanetLab 机制(即 vsys 系统),并将 TAP 设备与
ns-3 中的 FdNetDevice。 这个助手提供的功能类似于
由 FdTapNetDeviceHelper 提供,但创建
TAP 设备不同。

+ ------------------------------------------------- +
| PlanetLab 主持人 |
+ ------------------------------------------------- +
| ns-3 模拟 | |
+------------------------+ |
| ns-3 节点 | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | 网络设备 | | |
|--+----------------+--+ +------+ |
| | 水龙头 | | eth0 | |
| +-----+ +-----+ |
| 192.168.0.1 | 年|
+-------------------------------|------+
|
|
- - - - - - (互联网) - - -

为了能够将私有 IPv4 地址分配给 TAP 设备,帐户持有人
必须要求 vsys_vnet 标记将由 PlanetLab 管理员添加到他们的切片中。
vsys_vnet 标记与专用网段相关联,并且仅来自该网段的地址
段可用于实验。

使用此帮助器创建 TAP 设备的语法与用于创建 TAP 设备的语法相似。
先前描述的助手:

PlanetLabFdNetDeviceHelper 助手;
helper.SetTapIpAddress (tapIp);
helper.SetTapMask (tapMask);
...
helper.Install(节点);

PlanetLab 节点具有基于 Fedora 的发行版,因此 ns-3 可以安装在
ns-3 Linux 安装说明。

Attributes
- Fd网络设备 提供了许多属性:

· 企业地址:设备的MAC地址

· 开始: 启动设备线程的模拟开始时间

· Stop 停止: 停止设备线程的模拟开始时间

· 封装模式: 链路层封装格式

·

接收队列大小: - 缓冲 尺寸 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 队列 on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 文件 描述符
线程(默认为 1000 个数据包)

开始 Stop 停止 通常不需要指定,除非用户想要限制
此设备处于活动状态的时间。 企业地址 需要设置为某种独特的
MAC地址,如果模拟将以某种方式与其他真实设备交互
真实的 MAC 地址。 典型代码:

device->SetAttribute("地址", Mac48AddressValue (Mac48Address::Allocate ()));

输出
Ascii 和 PCAP 跟踪的提供与其他类似 ns-3 NetDevice 类型,通过
助手,例如(例如):

:: EmuFdNetDeviceHelper 鸸; NetDeviceContainer devices = emu.Install (node);
emu.EnablePcap ("emu-ping", device, true);

提供了标准的 Mac 级 NetDevice 跟踪源集。

· 最大发送量:跟踪源触发时 ns-3 为设备提供要发送的新帧

· 最大发送丢包率: 如果写入文件描述符失败,则跟踪源

· 最大PromiscRx:只要收到任何有效的 Mac 帧

· 最大接收量: 每当收到此设备的有效 Mac 帧时

· 嗅探器: 非混杂数据包嗅探器

· Promisc嗅探器:混杂数据包嗅探器(用于类似 tcpdump 的跟踪)

例子
提供了几个例子:

· 虚拟网络.cc:这个简单的例子创建了两个节点并将它们与一个
通过将文件描述符从套接字对传递到 FdNetDevice 的 Unix 管道
各个节点的对象。

· 实时虚拟网络.cc: 与 dummy-network.cc 相同,但使用实时模拟器
实现而不是默认实现。

· fd2fd-onoff.cc: 这个例子旨在测量 FdNetDevice 在
纯粹的模拟。 为此目的,两个 FdNetDevices,连接到不同的节点,但在
同样的模拟,都是使用socket pair连接的。 TCP 流量以
饱和数据速率。

· fd-emu-onoff.cc: 这个例子旨在测量 FdNetDevice 的吞吐量
当使用 EmuFdNetDeviceHelper 将模拟设备附加到真实设备时
主机。 这是通过使用 TCP 流量使通道饱和来实现的。

· fd-emu-ping.cc:此示例使用 EmuFdNetDeviceHelper 通过
真实渠道。

· fd-emu-udp-echo.cc:此示例使用 EmuFdNetDeviceHelper 发送 UDP 流量
一个真正的频道。

· fd-planetlab-ping.cc: 这个例子展示了如何设置一个实验来发送 ICMP
从 PlanetLab 节点到 Internet 的流量。

· fd-tap-ping.cc:此示例使用 TapFdNetDeviceHelper 通过
真实渠道。

敲打 网络设备
Tap NetDevice 可用于允许主机系统或虚拟机与之交互
一个模拟。

塔桥 型号 概述
Tap Bridge 旨在集成“真正的”互联网主机(或更准确地说,主机
支持 Tun/Tap 设备)到 ns-3 模拟中。 目标是让它看起来
“真正的”主机节点,因为它有一个 ns-3 网络设备作为本地设备。 一个概念
“真实主机”有点滑,因为“真实主机”实际上可以使用虚拟化
VMware、VirtualBox 或 OpenVZ 等现成的技术。

因为我们本质上是将 ns-3 网络设备的输入和输出连接到
Linux Tap net 设备的输入和输出,我们称这种布置为 Tap Bridge。

用户可以使用此设备的三种基本操作模式。 基本的
功能基本相同,但模式在细节上有所不同
如何创建和配置安排; 什么设备可以住在哪一边
桥。

我们将这三种模式称为 ConfigureLocal、UseLocal 和 UseBridge 模式。 首先
驼峰式模式标识符中的“word”表示谁负责创建
并配置水龙头。 例如,ConfigureLocal 模式下的“Configure”表示
是 TapBridge 负责配置分接头。 正在使用本地
模式和 UseBridge 模式,“Use”前缀表示要求 TapBridge “Use”
现有配置。

换句话说,在 ConfigureLocal 模式下,TapBridge 负责创建
并配置 TAP 设备。 在 UseBridge 或 UseLocal 模式下,用户提供一个
配置和 TapBridge 适应该配置。

塔桥 配置本地 时尚
在ConfigureLocal模式下,tap设备的配置为ns-3
以配置为中心。 配置信息取自 ns-3 中的设备
模拟和匹配 ns-3 属性的抽头设备会自动创建。 在
在这种情况下,Linux 计算机看起来好像直接连接到一个
模拟 ns-3 网络。

如下图所示:

+--------+
| Linux |
| 主持人 | +----------+
| ------ | | 鬼 |
| 应用程序 | | 节点 |
| ------ | | ------ |
| 堆栈 | | 知识产权 | +----------+
| ------ | | 堆栈 | | 节点 |
| 水龙头 | |===========| | -------- |
| 设备 | <----- IPC ------> | 水龙头 | | 知识产权 |
+--------+ | 桥 | | 堆栈 |
| ------ | | ------ |
| ns-3 | | ns-3 |
| 净 | | 净 |
| 设备 | | 设备 |
+-----------+ +-----------+
|| ||
+----------------------------+
| ns-3 频道 |
+----------------------------+

在这种情况下,“ghost node”中的“ns-3 net device”看起来就好像它实际上是
更换 Linux 主机中的 TAP 设备。 ns-3 模拟在
底层 Linux 操作系统并配置 TAP 设备的 IP 和 MAC 地址以匹配
分配给模拟 ns-3 网络设备的值。 上面显示的“IPC”链接是
底层操作系统中的网络分流机制。 整个安排就像一个传统的
桥; 而是恰好具有相同共享 MAC 和 IP 的设备之间的桥梁
地址。

在这里,用户不需要提供任何特定于
轻敲。 一个 tap 设备将由 ns-3 根据其默认值创建和配置,并且
Tap 设备的名称将由底层操作系统根据
它的默认值。

如果用户需要访问创建的 Tap 设备,他或她可以选择
提供“设备名称”属性。 在这种情况下,创建的 OS tap 设备将被命名为
因此。

ConfigureLocal 模式是 Tap Bridge 的默认操作模式。

塔桥 使用本地 时尚
UseLocal 模式与 ConfigureLocal 模式非常相似。 显着差异
是,正如模式名称所暗示的,TapBridge 将“使用”现有的水龙头设备
以前由用户创建和配置。 这种模式是特别有用的,当
虚拟化方案自动创建 Tap 设备,使用 ns-3 提供
这些设备的模拟网络。

+--------+
| Linux |
| 主持人 | +----------+
| ------ | | 鬼 |
| 应用程序 | | 节点 |
| ------ | | ------ |
| 堆栈 | | 知识产权 | +----------+
| ------ | | 堆栈 | | 节点 |
| 水龙头 | |===========| | -------- |
| 设备 | <----- IPC ------> | 水龙头 | | 知识产权 |
| MAC X | | 桥 | | 堆栈 |
+--------+ | ------ | | ------ |
| ns-3 | | ns-3 |
| 净 | | 净 |
| 设备 | | 设备 |
| MAC Y | | MAC Z |
+-----------+ +-----------+
|| ||
+----------------------------+
| ns-3 频道 |
+----------------------------+

在这种情况下,“Tap 设备”(MAC X)的预配置 MAC 地址将不是
与上图中所示的桥接“ns-3 网络设备”(MAC Y)相同。 在
为了桥接到不支持 SendFrom() 的 ns-3 网络设备(尤其是无线
STA 节点)我们要求只有一个 Linux 设备(具有一个唯一的 MAC 地址
-- 这里 X) 生成流经 IPC 链路的流量。 这是因为 MAC
跨 IPC 链路的流量地址将被“欺骗”或更改以使其看起来
Linux 和 ns-3 认为它们具有相同的地址。 也就是说,流量从 Linux
到 ns-3 幽灵节点的主机将其 MAC 地址从 X 更改为 Y,流量从
连接到 Linux 主机的 ghost 节点的 MAC 地址将从 Y 更改为 X。
设备之间是一一对应的,可能只有一个MAC源
从 Linux 端流出。 这意味着 Linux 桥接多个网络设备
添加与 UseLocal 模式不兼容。

在 UseLocal 模式下,用户需要完全创建和配置一个 tap 设备
在 ns-3 模拟的范围之外,使用类似的东西:

$ sudo tunctl -t tap0
$ sudo ifconfig tap0 硬件以太 08:00:2e:00:00:01
$ sudo ifconfig tap0 10.1.1.1 网络掩码 255.255.255.0 向上

为了告诉 TapBridge 发生了什么,用户可以直接设置
TapBridge 或通过 TapBridgeHelper,“DeviceName”属性。 在这种情况下
上面的配置,“DeviceName”属性将设置为“tap0”和“Mode”
属性将设置为“UseLocal”。

此模式的一个特定用例是在 OpenVZ 环境中。 有可能
在“硬件节点”上创建一个 Tap 设备并将其移动到虚拟专用服务器中。
如果 TapBridge 能够使用现有的 Tap 设备,则可以避免
该环境中操作系统桥的开销。

塔桥 使用桥 时尚
对于熟悉 Linux 网络的人来说,最简单的模式是 UseBridge 模式。 再次,
“使用”前缀表示 TapBridge 将使用现有配置。
在这种情况下,TapBridge 将逻辑上将 Linux 桥扩展为 ns-3。

如下图所示:

+----------+
| Linux | +----------+
| -------- | | 鬼 |
| 应用程序 | | 节点 |
| -------- | | -------- |
| 堆栈 | | 知识产权 | +----------+
| -------- | +--------+ | 堆栈 | | 节点 |
| 虚拟 | | 水龙头 | |===========| | -------- |
| 设备 | | 设备 | <----工控机-----> | 水龙头 | | 知识产权 |
+---------+ +--------+ | 桥 | | 堆栈 |
|| || | ------ | | ------ |
+--------------------------------+ | ns-3 | | ns-3 |
| 操作系统 (brctl) 桥 | | 净 | | 净 |
+--------------------+ | 设备 | | 设备 |
+-----------+ +-----------+
|| ||
+----------------------------+
| ns-3 频道 |
+----------------------------+

在这种情况下,运行 Linux 应用程序、协议等的计算机连接到一个
ns-3 模拟网络以使 Linux 主机看起来 TAP
device 是参与 Linux 网桥的真实网络设备。

在 ns-3 模拟中,创建了一个 TapBridge 来匹配每个 TAP 设备。 的名称
使用“DeviceName”属性将 TAP 设备分配给 Tap Bridge。 TapBridge
然后在逻辑上扩展 OS 桥以包含 ns-3 网络设备。

由于这种模式在逻辑上扩展了一个 OS 桥,因此可能有许多 Linux 网络设备在
桥的非ns-3侧。 因此,就像任何网桥上的网络设备一样,ns-3 网络
设备必须处理可能的许多源地址。 因此,ns-3 设备必须
支持 SendFrom()(NetDevice::SupportsSendFrom() 必须返回 true)才能
配置为在 UseBridge 模式下使用。

预计用户将执行以下操作来配置网桥
并在 ns-3 之外完全点击:

$ sudo brctl addbr mybridge
$ sudo tunctl -t mytap
$ sudo ifconfig mytap 硬件以太 00:00:00:00:00:01
$ sudo ifconfig mytap 0.0.0.0 向上
$ sudo brctl addif mybridge mytap
$ sudo brctl addif mybridge ...
$ sudo ifconfig mybridge 10.1.1.1 网络掩码 255.255.255.0 向上

为了告诉 TapBridge 发生了什么,用户可以直接设置
TapBridge 或通过 TapBridgeHelper,“DeviceName”属性。 在这种情况下
上面的配置,“DeviceName”属性将设置为“mytap”和“Mode”
属性将设置为“UseBridge”。

这种模式在虚拟化的情况下特别有用,其中配置
虚拟主机可能由另一个系统决定,并且不能更改以适应 ns-3。
例如,特定的 VM 方案可能会创建虚拟“vethx”或“vmnetx”设备,
对虚拟主机显示为本地。 为了连接到这样的系统,需要
在主机系统上手动创建 TAP 设备并将这些 TAP 设备连接到
现有 (VM) 虚拟设备。 在这种情况下,Tap Bridge 的工作是扩展
桥接加入 ns-3 网络设备。

塔桥 配置本地 操作
在 ConfigureLocal 模式下,出现 TapBridge 及其关联的 ns-3 网络设备
Linux 主机作为网络设备,就像任意的“eth0”或“ath0”一样
可能会出现。 TAP 设备的创建和配置由 ns-3 完成
仿真,用户无需手动配置。 IP地址,MAC
从模拟中提取创建的 TAP 设备的地址、网关等
通过查询 ns-3 设备的配置和 TapBridge 属性来获取自身。

由于 Linux 端和 ns-3 端的 MAC 地址相同,我们可以使用
ns-3 设备上的 Send() 可在所有 ns-3 网络设备上使用。 由于 MAC
地址是相同的,不需要将混杂回调挂钩到
接收方。 因此对网络设备的种类没有限制
可在 ConfigureLocal 模式下使用。

TapBridge 在 ns-3 模拟中显示为无通道网络设备。 这个设备
不能有与之关联的 IP 地址,但桥接 (ns-3) 网络设备必须
有一个IP地址。 请注意,这是 ns-3 BridgeNetDevice(或
一般的传统网桥),它要求其网桥端口没有 IP 地址,
但允许桥接设备本身拥有一个 IP 地址。

主机将在模拟中显示为“幽灵”节点,其中包含一个
正在桥接的每个 NetDevice 的 TapBridge。 从模拟的角度来看,
幽灵节点和任何其他节点之间的唯一区别是存在
TapBridge 设备。 但是请注意,TapBridge 的存在确实会影响
网络设备与幽灵节点的 IP 堆栈的连接。

地址信息和 ns-3 设备的配置不会以任何方式更改,如果
TapBridge 存在。 TapBridge 将从 ns-3 中获取寻址信息
它所连接的网络设备(它的“桥接”网络设备)并使用该信息来
在真实主机上创建和配置 TAP 设备。

这样做的最终结果是一种情况,例如,可以使用标准 ping
真实主机上的实用程序来 ping 模拟的 ns-3 节点。 如果将正确的路线添加到
互联网主机(这预计将在未来的 ns-3 版本中自动完成),
ns-3 中的路由系统将启用跨模拟 ns-3 的数据包的正确路由
网络。 有关这方面的示例,请参见示例程序 tap-wifi-dumbbell.cc
ns-3 分布。

Tap Bridge 生活在一个介于 Linux 主机和 ns-3 之间的灰色世界中
桥接装置。 从 Linux 的角度来看,此代码显示为用户模式处理程序
一个 TAP 网络设备。 在 ConfigureLocal 模式下,此 Tap 设备由
ns-3 模拟。 当 Linux 主机写入其中一个自动创建的
/dev/tap 设备,写入被重定向到 ns-3 世界中的 TapBridge;
并且从这个角度来看,Linux 上的数据包写入变成了 Tap 中的数据包读取
桥。 换句话说,Linux 进程将一个数据包写入一个 tap 设备,这个数据包
由网络分流机制重定向到一个 ns-3 进程,在该进程中由
TapBridge 作为读取操作的结果出现了。 TapBridge 然后将数据包写入
桥接的 ns-3 网络设备; 因此它看起来好像是 Linux 主机
直接通过 ns-3 网络设备将数据包发送到 ns-3 网络。

在另一个方向,连接到 Tap 的 ns-3 网络设备接收到一个数据包
Bridge 通过接收回调发送到 TapBridge。 TapBridge 然后接受
数据包并使用网络分接机制将其写回主机。 这写给
device 将在 Linux 主机上出现,就好像数据包已到达网络设备一样; 和
因此,就好像 ns-3 网络设备在模拟过程中收到的数据包出现了
在真正的 Linux 网络设备上。

结果是 Tap Bridge 似乎桥接了 Linux 主机上的 Tap 设备。
“真实世界”到模拟中的 ns-3 网络设备。 因为 TAP 设备和
桥接 ns-3 网络设备具有相同的 MAC 地址并且网络分接头 IPC 链接不
外部化,这种特殊类型的桥使得 ns-3 网络设备看起来像是
实际安装在Linux主机上。

为了在 ns-3 端实现这一点,我们需要模拟中的“幽灵节点”来
握住桥接的 ns-3 网络设备和 TapBridge。 这个节点实际上不应该做
模拟中的任何其他内容,因为它的工作只是让网络设备出现在
Linux。 这不仅仅是武断的政策,而是因为:

·从ghost节点中的更高层发送到TapBridge的比特(使用TapBridge
发送方法)被完全忽略。 TapBridge 本身并没有连接到任何
网络,既不在 Linux 也不在 ns-3 中。 您永远不能通过
来自幽灵节点的 TapBridge。

· 桥接的 ns-3 网络设备的接收回调与 ns-3 节点断开连接,并且
重新连接到 Tap Bridge。 然后将发送桥接设备接收到的所有数据
到 Linux 主机,并且不会被节点接收。 从
幽灵节点,您可以通过此设备发送,但永远无法接收。

当然,如果你了解所有问题,你就可以掌握自己的命运
做任何你想做的事——我们不会主动阻止你使用幽灵节点
你决定的任何事情。 您将能够对 ghost 执行典型的 ns-3 操作
如果您愿意,可以使用节点。 例如,互联网堆栈必须在那里并且可以正常运行
该节点以参与 IP 地址分配和全局路由。 然而,
如上所述,与任何 TapBridge 或相关桥接网络设备通信的接口
不会完全工作。 如果您确切了解自己在做什么,则可以设置
鬼节点上的其他接口和设备并使用它们; 或利用
桥接设备的操作发送端创建流量生成器。 我们一般
建议您将此节点视为 Linux 主机的幽灵并留给它自己,
虽然。

塔桥 使用本地 时尚 操作
如上所述,TapBridge 就像一座从“真实”世界到现实世界的桥梁。
模拟 ns-3 世界。 在 ConfigureLocal 模式的情况下,生活很容易,因为 IP
Tap 设备的地址与 ns-3 设备的 IP 地址和 MAC 地址相匹配
Tap设备匹配ns-3设备的MAC地址; 并且有一对一的
设备之间的关系。

当 Tap 设备外部配置一个
与 ns-3 网络设备不同的 MAC 地址。 处理这种情况的常规方法
一种区别是在桥接设备中使用混杂模式来接收数据包
发往不同的 MAC 地址并将它们转发到 Linux。 为了移动
以另一种方式发送数据包,传统的解决方案是 SendFrom(),它允许调用者
“欺骗”或更改源 MAC 地址以匹配不同的 Linux MAC 地址。

我们确实有一个特定的要求,能够将 Linux 虚拟机桥接到
无线STA节点。 不幸的是,802.11 规范并没有提供一个很好的方法来
实现 SendFrom(),所以我们必须解决这个问题。

为此,我们提供了 Tap Bridge 的 UseLocal 模式。 该模式允许您
就像您正在使用单个网络设备创建网桥一样处理问题。 一个
Linux 端允许的地址在 TapBridge 中被记住,并且所有的数据包来
使用 ns-3 设备 MAC 源从 Linux 端重复出 ns-3 端
地址。 从 ns-3 端进来的所有数据包都在 Linux 端重复使用
记住的 MAC 地址。 这允许我们在 ns-3 设备端使用 Send()
可在所有 ns-3 网络设备上使用。

UseLocal 模式与 ConfigureLocal 模式相同,除了创建和
Tap设备的配置和MAC地址欺骗。

塔桥 使用桥 操作
如 ConfigureLocal 模式部分所述,当 Linux 主机写入其中一个
/dev/tap 设备,写入被重定向到 ns-3 世界中的 TapBridge。
在 UseBridge 模式的情况下,这些数据包将需要在 ns-3 上发送出去
就像它们是在参与 Linux 网桥的设备上发送的一样。 这表示
在桥接设备上调用 SendFrom() 方法并提供源 MAC 地址
在数据包中找到。

在另一个方向,ns-3 网络设备接收到的数据包通过回调挂钩到
TapBridge。 这必须在混杂模式下完成,因为目标是桥接 ns-3
net 设备到 TAP 设备所属的操作系统 (brctl) 网桥上。

由于这些原因,只有支持 SendFrom() 并具有可挂钩的 ns-3 网络设备
允许混杂接收回调参与 UseBridge 模式 TapBridge
配置。

敲打 频道 型号
没有与 Tap Bridge 关联的通道模型。 其实本意是做
看来真正的互联网主机连接到桥接网络的通道


敲打 追踪 型号
与大多数 ns-3 设备不同,TapBridge 不提供任何标准跟踪源。 这个
是因为桥是一个中介,本质上是一个函数调用
桥接设备。 我们预计桥接设备中的跟踪挂钩将是
对大多数用户来说足够了,

运用 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 塔桥
我们预计大多数用户将通过以下方式与 TapBridge 设备进行交互
点击桥接助手。 其他帮助类的用户,例如 CSMA 或 Wifi,应该是
对那里使用的成语感到满意。

能源 框架


能源消耗是无线设备和无线网络研究人员的关键问题
经常需要调查节点或整个网络的能耗,同时
在 ns-3 中运行网络模拟。 这就需要ns-3来支持能耗
造型。 此外,随着燃料电池和能量清除等概念的兴起
可行的低功率无线设备,结合这些新兴的影响
技术进入模拟需要支持对不同能源进行建模
ns-3。 ns-3 能源框架为能源消耗、能源来源提供了基础
和能量收集建模。

型号 描述
能源框架的源代码目前位于: 源/能源.

工艺设计
ns-3 能源框架由 3 部分组成:能源、设备能源模型和
能量收集器。 该框架被实施到 src/能源/模型 文件夹中。

新能源 来源
Energy Source 代表每个节点上的电源。 一个节点可以有一个或多个
能源,每个能源可以连接多个设备能源模型。
将能源连接到设备能源模型意味着相应的设备
从源头汲取能量。 能源的基本功能是提供
节点上设备的能量。 当能量从能量源中完全耗尽时,
它通知节点上的设备,以便每个设备都可以对此事件作出反应。 更远,
每个节点都可以访问能源对象以获取诸如剩余能量或
能量分数(电池电量)。 这使得能源感知协议的实施成为可能
在 ns-3 中。

为了对电池等各种电源进行建模,Energy Source 必须
能够捕捉这些用品的特性。 有2个重要
与实用电池相关的特性或效果:

赔率 容量 影响
当电流消耗高于额定值时电池寿命缩短
电池。

修复工具 影响
当电池在放电和放电之间交替时延长电池寿命
空闲状态。

为了结合速率容量效应,能源使用来自
同一节点上的所有设备计算能耗。 此外,多
能量收集器可以连接到能量源以补充能量。
Energy Source 定期轮询同一设备上的所有设备和能量收集器
节点来计算总电流消耗,从而计算能耗。 当一个设备
改变状态,其对应的设备能量模型将通知能量源
变化和新的总电流消耗将被计算。 同样,每个能量收集器
更新触发对连接的能源的更新。

Energy Source 基类保存设备列表(设备能源模型对象)和
使用特定能源的能量收集器(能量收集器对象)
作为电源。 当能量完全耗尽时,能量源将通知所有
此列表中的设备。 然后,每个设备可以独立处理此事件,基于
在断电的情况下应遵循的期望行为。

设备 新能源 型号
设备能源模型是安装在节点上的设备的能源消耗模型。
它被设计为基于状态的模型,其中假设每个设备具有多个
状态,并且每个状态都与一个功耗值相关联。 每当状态
设备发生变化,相应的设备能量模型将通知能量源
设备的新电流消耗。 能源然后将计算新的总数
当前消耗和更新剩余能量。

设备能量模型也可用于没有有限数量的设备
状态。 例如,在电动汽车中,确定电机的电流消耗
以其速度。 由于车辆的速度可以在一定范围内取连续值,
定义一组离散的操作状态是不可行的。 但是,通过转换
将速度值直接转换为电流,同一套设备能量模型 API 仍然可以
使用。

新能源 收割机
能量收集器代表从环境和环境中收集能量的元素
为其连接的能量源充电。 能量收集器包括
实际能量收集设备(例如太阳能电池板)的完整实施和
环境(例如,太阳辐射)。 这意味着在实施能源
收割机,环境的能量贡献和额外的能量
能量收集装置的要求,例如转换效率和
设备的内部功耗需要联合建模。

WiFi 广播电台 新能源 型号
WiFi无线电能量模型是Wifi网络设备的能量消耗模型。 它
为 PHY 层的每个可用状态提供一个状态:空闲、CcaBusy、Tx、Rx、
通道开关,睡眠。 每个这样的状态都与一个值(以安培为单位)相关联
当前绘制(请参阅下面的相应属性名称)。 Wifi 无线电能量模型
PHY 侦听器注册到 Wifi PHY,以便收到每个 Wifi PHY 状态的通知
过渡。 在每次转换时,都会计算前一个状态消耗的能量,并且
通知能源以更新其剩余能量。

Wifi Tx 电流模型提供了计算电流消耗的可能性
发射状态作为标称发射功率(以 dBm 为单位)的函数,如在几个
实验测量。 为此,Wifi Radio Energy Model PHY Listener 是
通知用于传输当前帧的标称 tx 功率并通过这样的
Wifi Tx Current Model 的值,该模型负责更新 Tx 中的电流消耗
状态。 因此,即使 Wifi Remote Station 也能正确计算能耗
管理器执行每帧功率控制。 目前,线性 Wifi Tx 电流模型是
实现将 tx 电流计算为线性函数(根据参数
可以由用户指定)的标称发射功率(dBm)。

Wifi 无线电能量模型提供了指定调用的回调的可能性
当能源耗尽时。 如果 Wifi 时没有指定这样的回调
Radio Energy Model Helper 用于在设备上安装模型,回调是
隐含地使 Wifi PHY 处于睡眠模式(因此没有帧
之后发送或接收)当能量源耗尽时。 同样,它是
可以指定在能量源充电时调用的回调(其中
在能量收集器连接到能源的情况下可能会发生)。 如果这样一个
使用 Wifi Radio Energy Model Helper 安装
设备上的模型,隐式进行回调,以便 Wifi PHY 从
电源充电时的睡眠模式。

未来 工作
对于设备能量模型,我们计划包括对其他 PHY 层模型的支持
在 ns-3 中提供,例如 WiMAX,并模拟其他非
通信设备,如通用传感器和 CPU。 对于能源,我们是
计划包括新型能源,例如超级电容器和镍金属
氢化物 (Ni-MH) 电池。 对于能量收集器,我们计划实施能源
根据定义的功率水平对能源进行充电的收割机
用户可定制的真实测量数据集。

案例
[1] ns-2 能量模型:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] H. Wu、S. Nabar 和 R. Poovendran。 网络模拟器 3 的能源框架
(ns-3)。

[3] M. Handy 和 D. Timmermann。 精确的移动无线网络仿真
非线性电池效应建模。 在过程中。 应用模拟与建模
(ASM),2003 年。

[4] DN Rakhmatov 和 SB Vrudhula。 用于分析的高级电池模型
便携式电子系统的能量管理。 在过程中。 IEEE/ACM 国际
计算机辅助设计会议 (ICCAD'01),第 488-493 页,2001 年 XNUMX 月。

[5] DN Rakhmatov、SB Vrudhula 和 DA Wallach。 电池寿命预测
能量感知计算。 在过程中。 2002 年低功耗国际研讨会
电子与设计 (ISLPED'02),第 154-159 页,2002 年。

[6] C. Tapparello、H. Ayatollahi 和 W. Heinzelman。 扩展能源框架
网络模拟器 3 (ns-3)。 ns-3 (WNS3) 研讨会,海报会议,佐治亚州亚特兰大,
美国。 2014 年 XNUMX 月。

用法
ns-3 用户通常与 Energy Framework 交互的主要方式是通过
帮助程序 API 并通过框架的公开可见属性。 帮手
API 定义在 src/能源/助手/*.h.

为了使用能源框架,用户必须为节点安装能源
感兴趣的是网络设备的相应设备能量模型,如果
必要时,一个或多个能量收集器。 能源(对象)被聚合到
每个节点由能源助手。 为了允许每个节点有多个能源,
我们聚合一个能源容器,而不是直接聚合一个源对象。

Energy Source 对象保留了 Device Energy Model 和 Energy Harvester 对象的列表
使用源作为电源。 设备能量模型对象安装到
能量源由设备能量模型助手,而能量收集器对象是
由能量收集器助手安装。 用户可以访问设备能量模型对象
通过Energy Source对象获取个体的能源消耗信息
设备。 此外,用户可以访问能量收集器对象以收集
有关当前可收集的功率和收集的总能量的信息
收割机。

例子
示例目录, src/例子/能源例子/能量, 包含一些基本代码
这显示了如何设置框架。

助手
新能源 来源 帮手
Energy Source 对象的基础助手类,此助手聚合 Energy Source 对象
到一个节点上。 此类的子实现创建实际的能源对象。

设备 新能源 型号 帮手
设备能量模型对象的基础助手类,此助手附加设备能量
将对象建模到能源对象上。 此类的子实现创建
实际的设备能量模型对象。

新能源 野生捕捞 帮手
Energy Harvester 对象的基础助手类,此助手附加 Energy Harvester
对象到能源对象。 这个类的子实现创建了实际的
能量收集器对象。

Attributes
能源、设备能源模型和能量收集器之间的属性不同
具体实现请看具体的子类。

基础版 新能源 来源
· 基本能量源初始能量J:存储在基本能源中的初始能量。

· 基本能源供应电压V: 基本能源的初始电源电压。

· 周期性能量更新间隔:两次连续周期性能量更新之间的时间。

RV 电池 型号
· RvBatteryModelPeriodicEnergyUpdateInterval:RV电池模型采样间隔。

· Rv电池模型开路电压:RV电池模型开路电压。

· Rv电池模型截止电压: RV 电池型号截止电压。

· Rv电池模型Alpha值:RV 电池模型 alpha 值。

· Rv电池型号Beta值:RV 电池型号的 beta 值。

· Rv电池型号NumOfTerms:估计电池的无限和的项数
水平。

WiFi 广播电台 新能源 型号
· 空闲电流A:默认的无线电空闲电流,以安培为单位。

· Cca忙线A:默认的无线电 CCA 忙碌状态电流,以安培为单位。

· 发射电流A:以安培为单位的无线电 Tx 电流。

· 接收电流A:以安培为单位的无线电 Rx 电流。

· 开关电流A:默认无线电频道切换电流,以安培为单位。

· 睡眠电流A:以安培为单位的无线电休眠电流。

· TxCurrent模型:指向附加的 tx 当前模型的指针。

基础版 新能源 收割机
· 定期收获功率更新间隔:两次连续定期更新之间的时间
收获的力量。

· 收获稳定的力量:表示提供的电量的随机变量
由能量收集器。

追踪
能源、设备能源模型和能源收集器之间的跟踪值不同
具体实现请看具体的子类。

基础版 新能源 来源
· 剩余能量:BasicEnergySource 的剩余能量。

RV 电池 型号
· Rv电池型号电池电量:RV 电池型号电池电量。

· Rv电池型号电池寿命: RV 电池模型电池寿命。

WiFi 广播电台 新能源 型号
· 总能耗:无线电设备的总能耗。

基础版 新能源 收割机
· 收获的力量:BasicEnergyHarvester 提供的当前功率。

· 总能量收获:BasicEnergyHarvester 收集的总能量。

验证
尚未将能源框架与实际设备进行比较。 当前的
对能源框架的实施进行数值检查以查找计算错误。 这
通过将结果与原始数据进行比较来验证 RV 电池模型
房车电池模型纸。

监控


型号 描述
新模块的源代码位于目录中 src/流量监视器.

Flow Monitor 模块的目标是提供一个灵活的系统来测量
网络协议。 该模块使用安装在网络节点中的探针来跟踪
节点交换的数据包,它将测量许多参数。 数据包是
根据它们所属的流进行划分,其中每个流是根据其定义的
探测器的特征(例如,对于 IP,流被定义为具有相同
{协议,源(IP,端口),目标(IP,端口)}元组。

为每个流收集的统计信息可以以 XML 格式导出。 此外,
用户可以直接访问探针以请求有关每个流的特定统计信息。

工艺设计
Flow Monitor 模块采用模块化设计。 它可以通过子类化来扩展
ns3::流量探测器ns3::流分类器.

[FlowMonitor] 中描述了完整的模块设计

适用范围 限制
目前,探针和分类器可用于 IPv4 和 IPv6。

每个探测都会将数据包分为四点:

· 当一个数据包被发送时(SendOutgoing IPv[4,6] traces)

· 当一个数据包被转发时(UnicastForward IPv[4,6] traces)

· 收到数据包时(LocalDeliver IPv[4,6] 跟踪)

· 丢包时(Drop IPv[4,6] traces)

由于数据包是在 IP 级别跟踪的,因此由 L4 协议引起的任何重传
(例如,TCP)将被探测器视为一个新数据包。

一个标签将被添加到数据包中(ns3::Ipv[4,6]FlowProbeTag)。 标签将携带基本
包的数据,对包的分类有用。

必须强调的是,到目前为止,只有 L4(TCP、UDP)数据包被分类。 而且,
只有单播数据包会被分类。 这些限制将来可能会被取消。

为每个流收集的数据是:

· timeFirstTxPacket:流中第一个包被传输的时间;

· timeLastTxPacket:传输流中最后一个数据包的时间;

· timeFirstRxPacket:当流中的第一个数据包被端节点接收到时;

· timeLastRxPacket:接收到流中最后一个数据包的时间;

· delaySum:流的所有接收数据包的所有端到端延迟的总和;

· jitterSum:所有端到端延迟抖动(延迟变化)值的总和
接收到的数据包,如定义 RFC 3393;

· txBytes, txPackets:为流传输的字节/数据包总数;

· rxBytes, rxPackets:流接收到的字节/数据包总数;

· lostPackets:假定丢失的数据包总数(未报告超过 10
秒);

· timesForwarded:数据包被报告转发的次数;

· delayHistogram, jitterHistogram, packetSizeHistogram:直方图版本为延迟,
抖动和数据包大小,分别;

· packetDropped, bytesDropped:丢包和字节数,根据
丢失原因代码(在探测中定义)。

值得指出的是,探测器测量包括 IP 标头在内的数据包字节。
L2 标头不包含在度量中。

这些统计数据将根据请求以 XML 形式写入(请参阅“使用”部分)。

案例
[流量监视器]

G. Carneiro、P. Fortuna 和 M. Ricardo。 2009. FlowMonitor:网络监控框架
用于网络模拟器 3 (NS-3)。 在第四届国际 ICST 会议记录中
绩效评估方法和工具会议(VALUETOOLS '09)。
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

用法
模块使用非常简单。 助手会照顾好一切。

典型的用途是:

// 流量监视器
点流量监控器;
FlowMonitorHelper 流助手;
flowMonitor = flowHelper.InstallAll();

模拟器::Stop (Seconds(stop_time));
模拟器::运行();

flowMonitor->SerializeToXmlFile("NameOfFile.xml", true, true);

这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 序列化到 XmlFile () 函数第 2 和第 3 个参数分别用于
激活/停用直方图和每个探测器的详细统计信息。

其他可能的替代方案可以在 Doxygen 文档中找到。

助手
助手 API 遵循普通助手的模式使用。 通过助手你可以
在节点中安装监视器,设置监视器属性,并打印统计信息。

一件重要的事是: ns3::流量监控助手 必须在
主要的。

Attributes
该模块提供以下属性 ns3::流监视器:

· MaxPerHopDelay(Time,默认10s):应该考虑的最大每跳延迟;

· StartTime(Time,默认0s):监控开始的时间;

·DelayBinWidth(double,默认0.001):延迟直方图中使用的宽度;

· JitterBinWidth(double,默认0.001):抖动直方图中使用的宽度;

· PacketSizeBinWidth (double, default 20.0):packetSize直方图中使用的宽度;

· FlowInterruptionsBinWidth (double, 默认0.25):使用的宽度
流量中断直方图;

· FlowInterruptionsMinTime (double, default 0.5): 最小到达间隔时间,即
视为流量中断。

输出
主要模型输出是关于流量统计的 XML 格式报告。 一个例子是:




























输出由从 10.1.3.1 到 10.1.2.2 的 TCP 流生成。

值得注意的是,索引 2 探测报告的数据包和字节数比
其他问题。 这是一个完全正常的行为,因为数据包在 IP 上被分段
该节点中的级别。

还应该观察到接收节点的探测(索引 4)不计算
碎片,因为重组是在探测点之前完成的。

例子
示例位于 src/流监控器/示例.

此外,以下示例使用 flow-monitor 模块:

·examples/matrix-topology/matrix-topology.cc

· 示例/路由/manet-routing-compare.cc

· 示例/路由/simple-global-routing.cc

·examples/tcp/tcp-variants-comparison.cc

·examples/wireless/multirate.cc

·examples/wireless/wifi-hidden-terminal.cc

故障排除
不要定义多个 ns3::流量监控助手 在模拟中。

验证
参考文献中的论文包含针对模块验证的完整描述
测试网络。

提供测试以确保直方图功能正确。

INTERNET 模型


网络
网络 聚合
一个裸班 Node 按原样不是很有用; 其他对象必须聚合到它以
提供有用的节点功能。

- ns-3 源代码目录 源/互联网 提供 TCP/IPv4 的实​​现和
IPv6 相关组件。 这些包括 IPv4、ARP、UDP、TCP、IPv6、邻居发现和
其他相关协议。

互联网节点不是节点类的子类; 它们只是具有
一堆与 IP 相关的对象聚合到他们身上。 它们可以手工组装,也可以通过
辅助功能 InternetStackHelper::安装 () 它对所有节点执行以下操作
作为参数传入:

无效
InternetStackHelper::安装 (Ptr 节点)常量
{
如果(m_ipv4Enabled)
{
/* IPv4 堆栈 */
if (node->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): 聚合"
“一个 InternetStack 到具有现有 IPv4 对象的节点”);
返回;
}

CreateAndAggregateObjectFromTypeId (node, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (node, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (node, "ns3::Icmpv4L4Protocol");
// 设置路由
点ipv4 = 节点->GetObject ();
点ipv4Routing = m_routing->创建(节点);
ipv4->SetRoutingProtocol (ipv4Routing);
}

如果(m_ipv6Enabled)
{
/* IPv6 堆栈 */
if (node->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): 聚合"
“一个 InternetStack 到具有现有 IPv6 对象的节点”);
返回;
}

CreateAndAggregateObjectFromTypeId (node, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (node, "ns3::Icmpv6L4Protocol");
// 设置路由
点ipv6 = 节点->GetObject ();
点ipv6Routing = m_routingv6->创建(节点);
ipv6->SetRoutingProtocol (ipv6Routing);

/* 注册 IPv6 扩展和选项 */
ipv6->注册扩展();
ipv6->注册选项();
}

如果(m_ipv4Enabled || m_ipv6Enabled)
{
/* UDP 和 TCP 堆栈 */
CreateAndAggregateObjectFromTypeId (node, "ns3::UdpL4Protocol");
节点->AggregateObject (m_tcpFactory.Create ());
点工厂 = 创建对象();
节点->AggregateObject(工厂);
}
}

存在多个实现的地方 ns-3 (TCP,IP路由),这些对象是由
工厂对象 (TCP) 或路由助手 (m_routing)。

请注意,路由协议是在此功能之外配置和设置的。 默认,
添加了以下协议:

无效 InternetStackHelper::Initialize ()
{
SetTcp("ns3::TcpL4Protocol");
ipv4StaticRoutingHelper 静态路由;
ipv4GlobalRoutingHelper 全局路由;
ipv4ListRoutingHelper listRouting;
ipv6ListRoutingHelper listRoutingv6;
ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add(staticRouting, 0);
listRouting.Add(全局路由,-10);
listRoutingv6.Add(staticRoutingv6, 0);
SetRoutingHelper(listRouting);
SetRoutingHelper(listRoutingv6);
}

默认情况下,启用 IPv4 和 IPv6。

网络 Node 结构体
一个支持 IP 的节点(一个 ns-3 通过聚合增强的节点具有一个或多个 IP 堆栈)
具有以下内部结构。

层3 协议
位于网络设备之上的最低层是“第 3 层”协议,包括
IPv4、IPv6、ARP等。 班上 IPv4L3协议 是一个实现类,其
公共接口通常是类 Ipv4, 但也使用了 Ipv4L3Protocol 公共 API
目前在国内。

在 Ipv4L3Protocol 类中,下面描述的一种方法是 收集现金 ():

/ **
* 底层调用L3Demux::Lookup后调用该方法
* ARP 子类需要知道这个来自哪个 NetDevice
* 数据包即将到达:
* - 实现每个网络设备的 ARP 缓存
* - 在正确的设备上发回 arp 回复
*/
无效接收(Ptr 设备,Ptr p,uint16_t 协议,
const Address &from, const Address &to, NetDevice::PacketType packetType);

首先,请注意 收集现金 () 函数具有与 ReceiveCallback 匹配的签名
在课堂里 Node. 这个函数指针被插入到节点的协议处理程序中,当
添加接口 () 叫做。 实际注册是通过声明完成的,例如
如下:

RegisterProtocolHandler ( MakeCallback (&​​Ipv4Protocol::Receive, ipv4),
Ipv4L3协议::PROT_NUMBER, 0);

Ipv4L3Protocol 对象聚合到Node; 只有一个这样的 Ipv4L3Protocol
目的。 具有要向下发送到 Ipv4L3Protocol 的数据包的更高层协议
对象可以调用 获取对象 () 获取指针,如下:

点ipv4 = m_node->GetObject ();
如果(ipv4!= 0)
{
ipv4->发送(数据包,saddr,daddr,PROT_NUMBER);
}

这个类很好地展示了我们在 ns-3 将对象绑定在一起:
回调和对象聚合。

一旦 IPv4 路由确定数据包是发往本地节点的,它将向上转发
堆栈。 这是通过以下功能完成的:

无效
Ipv4L3Protocol::LocalDeliver (Ptr 数据包,Ipv4Header const&ip,uint32_t iif)

第一步是根据 IP 协议号找到正确的 Ipv4L4Protocol 对象。
例如,TCP 在 demux 中注册为协议号 6。最后, 收到()
Ipv4L4Protocol 上的函数(例如 TcpL4Protocol::接收 叫做。

我们还没有介绍 Ipv4Interface 类。 基本上,每个 NetDevice 都是配对的
具有此类设备的 IPv4 表示。 在 Linux 中,这个类 ipv4接口 περίπου
对应于 结构 设备内; 主要目的是提供address-family
有关接口的特定信息(地址)。

所有类都有适当的跟踪,以便跟踪发送、接收和丢失的数据包。
鼓励用户使用它们来确定是否(以及在何处)丢弃了数据包。 一个
常见的错误是在发送数据包时忘记本地队列的影响,例如,
ARP 队列。 在发送巨型数据包或数据包突发时,这可能特别令人费解
使用 UDP。 ARP 缓存挂起队列是有限的(3 个数据报),IP 数据包可能
碎片化,很容易溢出 ARP 缓存队列大小。 在这些情况下,它很有用
将 ARP 缓存挂起大小增加到适当的值,例如:

Config::SetDefault ("ns3::ArpCache::PendingQueueSize", UintegerValue (MAX_BURST_SIZE/L2MTU*3));

IPv6 实现遵循类似的架构。 双堆叠节点(一个带有
支持 IPv4 和 IPv6)将允许 IPv6 套接字接收 IPv4 连接作为
标准的双堆叠系统。 绑定并监听 IPv6 端点的套接字可以
接收 IPv4 连接并将远程地址作为 IPv4 映射地址返回。
当前不存在对 IPV6_V6ONLY 套接字选项的支持。

层4 协议 插座
接下来我们将描述传输协议、套接字和应用程序如何结合在一起。 在
总之,每个传输协议实现都是一个套接字工厂。 一个应用程序
需要一个新的插座

例如,要创建 UDP 套接字,应用程序将使用代码片段,例如
在以下:

点udpSocketFactory = GetNode ()->GetObject ();
点m_socket = socketFactory->CreateSocket();
m_socket->绑定(m_local_address);
...

上面将查询节点以获取指向其 UDP 套接字工厂的指针,将创建一个
这样的套接字,并将使用具有类似于基于 C 的套接字 API 的 API 的套接字,例如
as 连接 ()发送 (). 传递给的地址 捆绑 (), 连接 ()发送 ()
函数可能是 IPv4地址, IPv6地址企业地址。 如果一个 企业地址 传入和
包含除 a 以外的任何内容 IPv4地址 or IPv6地址,这些函数将返回一个
错误。 这 捆绑 (空白)绑定6 (空白) 函数绑定到“0.0.0.0”和“::”


套接字也可以绑定到特定的 NetDevice,尽管 绑定到网络设备
(点 网络设备) 功能。 绑定到网络设备 (点 网络设备) 会绑定
套接字到“0.0.0.0”和“::”(相当于调用 捆绑 ()绑定6 (),除非
套接字已经绑定到特定地址。 总结,正确的顺序
是:

点udpSocketFactory = GetNode ()->GetObject ();
点m_socket = socketFactory->CreateSocket();
m_socket->BindToNetDevice (n_netDevice);
...

要么:

点udpSocketFactory = GetNode ()->GetObject ();
点m_socket = socketFactory->CreateSocket();
m_socket->绑定(m_local_address);
m_socket->BindToNetDevice (n_netDevice);
...

以下引发错误:

点udpSocketFactory = GetNode ()->GetObject ();
点m_socket = socketFactory->CreateSocket();
m_socket->BindToNetDevice (n_netDevice);
m_socket->绑定(m_local_address);
...

见章节 ns-3 套接字以获取更多信息。

到目前为止,我们已经描述了一个套接字工厂(例如 乌德普) 和一个套接字,它可能是
专业(例如,类 UDPSocket)。 还有一些与
将数据包解复用到一个或多个接收套接字的特殊任务。 钥匙
此任务中的对象是类 Ipv4EndPointDemux. 这个解复用器存储对象
IPv4端点. 此类保存寻址/端口元组(本地端口,本地
地址、目标端口、目标地址)与套接字关联,以及接收
打回来。 这个接收回调有一个由套接字注册的接收函数。 这
查找 () Ipv4EndPointDemux 的函数返回 Ipv4EndPoint 对象的列表(可能有
是一个列表,因为多个套接字可能匹配数据包)。 第 4 层协议副本
将数据包发送到每个 Ipv4EndPoint 并调用其 前进 () 方法,然后调用
收集现金 () 套接字注册的函数。

在实际系统上使用套接字 API 时出现的一个问题是需要
使用某种类型的 I/O(例如,阻塞、非阻塞、
异步,...)。 ns-3 实现套接字 I/O 的异步模型; 应用程序
设置一个回调来通知接收到的数据准备好被读取,并且回调是
当数据可用时由传输协议调用。 此回调指定为
如下:

无效套接字::SetRecvCallback(回调 ,
点,
常量地址&>接收数据);

正在接收的数据在数据包数据缓冲区中传送。 一个示例用法是
数据包接收器:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, this));

总而言之,在内部,UDP 实现组织如下:

· 一种 udpImpl 实现 UDP 套接字工厂功能的类

· 一种 UdpL4协议 实现与套接字无关的协议逻辑的类

· 一种 UDPSocketImpl 实现 UDP 的套接字特定方面的类

· 一个类叫 IPv4端点 存储寻址元组(本地端口,本地地址,
与套接字关联的目标端口、目标地址和接收
套接字的回调。

支持 IP 节点 接口
支持 IP 的节点的许多实现细节或内部对象本身
对象不会在模拟器公共 API 中公开。 这允许不同的
实施; 例如,替换原生 ns-3 带有移植 TCP/IP 堆栈的模型
码。

所有这些对象的 C++ 公共 API 都可以在 源/网络 目录,
主要包括:

· 地址.h

· 套接字文件

· 节点.h

· 数据包.h

这些通常是基类对象,它们实现了在
实现,实现访问方法来获取/设置状态变量、主机属性和
实施向客户公开的公开可用的方法,例如 创建套接字.

例如: of a
这两个图显示了数据包如何通过 Internet 流动的示例堆栈跟踪
节点对象。
[image] 数据包的发送路径..UNIDENT
[image] 数据包的接收路径..UNIDENT

IPv4
占位符

IPv6
本章介绍了 ns-3 IPv6 模型的功能和限制及其
用法和例子。

IPv6 模型 描述
IPv6 模型是在 Linux 实现之后松散地设计的; 实施是
不完整,因为 IPv6 的某些功能对模拟研究没有太大兴趣,并且
IPv6 的某些特性还没有在模型中建模 ns-3.

基类 Ipv6 定义了一个通用 API,而类 IPv6L3协议 是实际的
实现协议的类。 IPv6 堆栈使用的实际类位于
主要在目录 源/互联网.

IPv6 的实现包含在以下文件中:

src/internet/model/icmpv6-header.{cc,h}
src/internet/model/icmpv6-l4-protocol.{cc,h}
src/互联网/模型/ipv6.{cc,h}
src/internet/model/ipv6-address-generator.{cc,h}
src/internet/model/ipv6-autoconfigured-prefix.{cc,h}
src/internet/model/ipv6-end-point.{cc,h}
src/internet/model/ipv6-end-point-demux.{cc,h}
src/internet/model/ipv6-extension.{cc,h}
src/internet/model/ipv6-extension-demux.{cc,h}
src/internet/model/ipv6-extension-header.{cc,h}
src/internet/model/ipv6-header.{cc,h}
src/internet/model/ipv6-interface.{cc,h}
src/internet/model/ipv6-interface-address.{cc,h}
src/internet/model/ipv6-l3-protocol.{cc,h}
src/internet/model/ipv6-list-routing.{cc,h}
src/internet/model/ipv6-option.{cc,h}
src/internet/model/ipv6-option-demux.{cc,h}
src/internet/model/ipv6-option-header.{cc,h}
src/internet/model/ipv6-packet-info-tag.{cc,h}
src/internet/model/ipv6-pmtu-cache.{cc,h}
src/internet/model/ipv6-raw-socket-factory.{cc,h}
src/internet/model/ipv6-raw-socket-factory-impl.{cc,h}
src/internet/model/ipv6-raw-socket-impl.{cc,h}
src/internet/model/ipv6-route.{cc,h}
src/internet/model/ipv6-routing-protocol.{cc,h}
src/internet/model/ipv6-routing-table-entry.{cc,h}
src/internet/model/ipv6-static-routing.{cc,h}
src/internet/model/ndisc-cache.{cc,h}
src/network/utils/inet6-socket-address.{cc,h}
src/network/utils/ipv6-address.{cc,h}

IPv6还涉及一些助手:

src/internet/helper/internet-stack-helper.{cc,h}
src/internet/helper/ipv6-address-helper.{cc,h}
src/internet/helper/ipv6-interface-container.{cc,h}
src/internet/helper/ipv6-list-routing-helper.{cc,h}
src/internet/helper/ipv6-routing-helper.{cc,h}
src/internet/helper/ipv6-static-routing-helper.{cc,h}

模型文件大致可以分为:

· 协议模型(例如,ipv6、ipv6-l3-protocol、icmpv6-l4-protocol 等)

· 路由模型(即任何名称中带有“路由”的东西)

· 套接字和接口(例如,ipv6-raw-socket、ipv6-interface、ipv6-end-point 等)

· 地址相关的东西

· 标头、选项标头、扩展标头等。

· 附属类(例如,ndisc-cache)

用法
以下描述基于使用示例代码中的典型帮助程序。

IPv6 不需要在节点中激活。 它会自动添加到可用的
安装 Internet 堆栈后的协议。

为了 而不去 安装 IPv6 和 IPv4,可以使用
ns3::InternetStackHelper 方法 设置Ipv6Stack安装 (布尔 使能够) 在安装之前
InternetStack 中的节点。

请注意,只有 IPv6 的网络(即,不在节点中安装 IPv4 堆栈)
应该用 ns3::InternetStackHelper 方法 设置Ipv4Stack安装 (布尔 使能够)
堆栈安装。

例如,在以下代码中,节点 0 将同时具有 IPv4 和 IPv6,节点 1 仅
仅限 IPv6 和节点 2 IPv4:

节点容器 n;
n.创建 (3);

InternetStackHelper 互联网;
InternetStackHelper internetV4only;
InternetStackHelper internetV6only;

internetV4only.SetIpv6StackInstall(假);
internetV6only.SetIpv4StackInstall(假);

互联网安装(n.Get(0));
internetV6only.Install(n.Get(1));
internetV4only.Install(n.Get(2));

IPv6 地址 分配
为了在网络上使用 IPv6,首先要做的是分配 IPv6 地址。

任何启用 IPv6 的 ns-3 节点将至少有一个 NetDevice: ns3::环回网络设备.
环回设备地址为 :: 1. 所有其他 NetDevice 将拥有一个或多个 IPv6
地址:

· 一个链接本地地址: fe80::接口 ID,其中 接口 ID 源自于
网络设备 MAC 地址。

· 零个或多个全局地址,例如, 2001:db8 :: 1.

通常,接口上的第一个地址将是链路本地地址,全局地址
地址是以下的。

IPv6 全局地址可能是:

· 手动分配

· 自动生成

ns-3 可以同时使用这两种方法,理解其含义非常重要
都。

手动 分配 IPv6 地址
这可能是最简单和最常用的方法。 举个例子:

点n0 = 创建对象();
点n1 = 创建对象();
节点容器网络(n0,n1);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("分配 IPv6 地址。");
ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Assign (ndc);

此方法将向节点添加两个全局 IPv6 地址。 请注意,与 IPv6 一样,
所有节点也将有一个链接本地地址。 通常在第一个地址
接口将是链路本地接口,全局地址如下
的。

请注意,全局地址将来自 MAC 地址。 作为结果,
希望有类似的地址 2001:db8::200:ff:fe00:1.

可以重复上述操作以将多个全局地址分配给一个节点。
但是,由于 ipv6地址助手 单例性质,首先应该分配所有
网络的地址,然后更改网络基础(集基),然后做一个新的任务。

或者,可以为节点分配特定地址:

点n0 = 创建对象();
节点容器网络 (n0);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("具体分配一个 IPv6 地址。");
ipv6AddressHelper ipv6;
点设备 = ndc.Get (0);
点节点 = 设备->GetNode ();
点ipv6proto = 节点->GetObject ();
int32_t ifIndex = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (设备);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

自动生成 IPv6 地址
这是通过依赖类实现的 RADVD 协议来完成的 辐射。 在
这个应用程序没有助手的时候,使用起来比较困难(见
示例/ipv6/radvd.cc).

使用此方法后,节点将动态获取(即在模拟期间)
根据 RADVD 配置的一个(或多个)全局地址。 这些地址
将基于 RADVD 宣布的前缀和节点的 EUI-64。

随机生成 IPv6 地址
而 IPv6 真实节点将使用随机生成的地址来保护隐私, ns-3
没有这个能力。 到目前为止,这个功能还没有被认为是有趣的
模拟。

复制 企业地址 检测 (爸)
节点将执行 DAD(可以使用 Icmpv6L4协议 属性)。 之上
但是,收到 DAD 后,节点不会对其做出反应。 原样:DAD 反应不完整,所以
远的。 主要原因在于缺少随机生成的地址能力。 而且,
ns-3 节点通常表现良好,不应该有任何重复地址。
这可能会在未来改变,以避免与现实世界集成的问题
模拟。

主办方 路由器 行为 in IPv6 ns-3
在 IPv6 中有明显的区别 路由器为了. 正如人们所预料的那样,
路由器可以将数据包从一个接口转发到另一个接口,而主机丢弃
未定向到他们的数据包。

不幸的是,转发并不是唯一受这种区别影响的事情,而且
转发本身可能会被微调,例如,转发从接口传入的数据包
并从另一个接口丢弃数据包。

In ns-3 一个节点被配置为 主持人 默认。 主要有两种改变方式
这种行为:

· 使用 ns3::Ipv6InterfaceContainer 设置转发(uint32_t i, 布尔 路由器) 哪里 i
容器中的接口索引。

· 改变 ns3::IPv6 属性 转发.

在模拟过程中可以使用任何一个。

一个细粒度的设置可以通过使用来完成 ns3::Ipv6接口 集转发 (布尔
向前); 它允许基于每个接口更改行为。

请注意,节点范围的配置仅用作启用/禁用的便捷方法
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 ns3::Ipv6接口 具体设置。 一个 Ipv6Interface 添加到带有转发的节点
enabled 也将设置为转发。 当一个节点有
模拟过程中添加的接口。

ns3::Ipv6接口 转发状态,会发生以下情况:

· 转发关闭

· 节点不会回复Router Solicitation

· 节点将对Router Advertisement做出反应

· 节点会定期发送Router Solicitation

· 路由协议必须丢弃未定向到节点的数据包

· 转发开启

· 节点会回复Router Solicitation

· 节点不会对Router Advertisement做出反应

· 节点不会发送Router Solicitation

· 路由协议必须转发数据包

行为匹配 ip-sysctl.txt (‐
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) 不同的是
使用深奥的设置(例如,转发但
接受路由器通告,accept_ra=2,或转发但发送路由器请求
转发=2)。

仔细考虑数据包转发的含义。 例如,一个节点不会
从接口发送 ICMPv6 PACKET_TOO_BIG 消息并关闭转发。 这是
完全正常,因为路由协议会​​在尝试之前丢弃数据包
转发它。

助手
通常在 IPv6 设置中使用的助手是:

· ns3::InternetStackHelper

· ns3::Ipv6AddressHelper

· ns3::Ipv6InterfaceContainer

用法几乎与相应的 IPv4 案例相同,例如:

节点容器 n;
n.创建 (4);

NS_LOG_INFO ("创建 IPv6 Internet 堆栈");
InternetStackHelper internetv6;
internetv6.安装(n);

NS_LOG_INFO ("创建频道。");
CsmaHelper csma;
NetDeviceContainer d = csma.Install(n);

NS_LOG_INFO(“创建网络并分配 IPv6 地址。”);
ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Assign (d);

此外,一项常见任务是在其中一个节点上启用转发并设置一个
在其他节点中指向它的默认路由,例如:

iic.SetForwarding(0, true);
iic.SetDefaultRouteInAllNodes(0);

这将在节点上启用转发 0 并将设置默认路由
ns3::Ipv6静态路由 在所有其他节点上。 请注意,这需要
Ipv6StaticRouting 存在于节点中。

IPv6 路由助手使用户能够在特定的
路由算法并打印路由表。

Attributes
很多班级在 ns-3 IPv6 实现包含属性。 最有用的是:

· ns3::IPv6

· 转发,布尔值,默认为假。 全局启用或禁用所有 IP 转发
当前和未来的 IPv6 设备。

· Mtu发现,布尔值,默认为真。 如果禁用,每个接口都有自己的 MTU
设置为 1280 字节。

· ns3::Ipv6L3协议

· 默认Ttl, uint8_t, 默认 64。所有传出数据包默认设置的 TTL 值
在这个节点上生成。

· 发送Icmpv6重定向,布尔值,默认为真。 适当时发送 ICMPv6 重定向。

· ns3::Icmpv6L4协议

· DAD,布尔值,默认为真。 始终进行 DAD(重复地址检测)检查。

· ns3::NdiscCache

· 未解决队列大小, uint32_t, 默认 3. 等待 NA 的数据包队列的大小
回复。

输出
IPv6 堆栈提供了一些有用的跟踪源:

· ns3::Ipv6L3协议

· Tx, 将 IPv6 数据包发送到出接口。

· Rx, 从传入接口接收 IPv6 数据包。

· Drop, 丢弃 IPv6 数据包。

· ns3::Ipv6 扩展

· Drop, 丢弃 IPv6 数据包。

当数据包包含阻止其的未知选项时,将生成最新的跟踪源
处理。

请注意 ns3::NdiscCache 也可以丢弃数据包,并且它们没有记录在跟踪中
来源(还)。 这可能会在发送/接收数据包计数器中产生一些混乱。

先进的 用法
IPv6 最多 传输 单元 (MTU) 碎片
ns-3 NetDevices 根据 L2 模拟 Device 定义 MTU。 IPv6 要求
最小 MTU 为 1280 字节,因此所有 NetDevice 都必须至少支持此
MTU。 这是链路 MTU。

为了支持源-目的路径中的不同 MTU, ns-3 IPv6模型可以
执行分片。 这可以通过接收大于
来自 L4 协议(UDP、TCP 等)的链接 MTU,或通过接收 ICMPv6 PACKET_TOO_BIG
信息。 该模型模仿 RFC 1981,但有以下明显例外:

· L4 协议不会被告知 Path MTU 的变化

· TCP 不能根据 Path-MTU 改变其 Segment Size。

这两个限制都将在适当的时候被取消。

Path-MTU 缓存当前基于源-目标 IPv6 地址。 更远
分类(例如,流标签)是可能的,但尚未实施。

Path-MTU 默认有效时间为 10 分钟。 缓存项过期后,
路径 MTU 信息被删除,下一个数据包将(最终)触发新的 ICMPv6
PACKET_TOO_BIG 消息。 请注意,1)这与 RFC 规范一致,2)
L4 协议负责重传数据包。

例子
IPv6 的示例在目录中 例子/ipv6. 这些例子集中在最
有趣的 IPv6 特性,例如分片、重定向等。

此外,大多数 TCP 和 UDP 示例位于 例子/udp, 例子/tcp等有一个
使用 IPv6 而不是 IPv4 的命令行选项。

故障排除
使用时需要避免一些陷阱 ns-3 IPv6。

路由 循环
由于(到目前为止)唯一可用于 IPv6 的路由方案是 ns3::Ipv6静态路由,
默认路由器必须手动设置。 当网络中有两个或更多路由器时
(例如,节点 A 和节点 B),避免使用辅助函数 在所有节点中设置默认路由
多个路由器。

结果将是在 A 中安装到 B 的默认路由和默认路由指向
到B中的A,产生一个循环。

全球 地址 泄漏
请记住,IPv6 中的地址是 全球化 根据定义。 将 IPv6 与
仿真 ns-3 能力,不惜一切代价避免地址泄漏到全球互联网。
建议设置外部防火墙以防止泄漏。

2001:DB8::/32 地址
IPv6 标准 (RFC 3849) 定义了 2001:DB8::/32 的地址类 文件.
本手册使用此约定。 但是,此类中的地址仅可用于
一个文件,路由器应该丢弃它们。

验证
IPv6 协议尚未针对实际实现进行广泛验证。
实际测试主要涉及使用 Wireshark 对 .pcap 跟踪文件进行检查,
结果是积极的。

路由 简介
ns-3 旨在支持传统的路由方法和协议,支持端口
开源路由实现,并促进对非正统路由的研究
技巧。 整体路由架构如下所述 路由 架构.
希望阅读有关如何为有线拓扑配置全局路由的用户可以
全球 集中 路由. 单播路由协议在 单播
路由. 多播路由记录在 多播 路由.

路由 架构
[图片] 路由概述.UNIDENT

概述 of 路由 显示了 IPv4 的整体路由架构。 关键对象是
Ipv4L3Protocol, Ipv4RoutingProtocol(s)(所有路由/转发都已被
从 Ipv4L3Protocol 委托)和 Ipv4Route(s)。

Ipv4L3Protocol 在模拟时必须至少添加一个 Ipv4RoutingProtocol
设置时间。 这是通过调用 Ipv4::SetRoutingProtocol () 显式完成的。

抽象基类 Ipv4RoutingProtocol() 声明了一个最小接口,包括
两种方法:RouteOutput() 和RouteInput()。 对于出站的数据包
主机,传输协议将向 Ipv4 查询 Ipv4RoutingProtocol 对象
接口,并将通过 Ipv4RoutingProtocol::RouteOutput() 请求路由。 一个 Ptr 到
返回 IPv4Route 对象。 这类似于 Linux 中的 dst_cache 条目。 这
Ipv4Route 被带到 Ipv4L3Protocol 以避免在那里进行第二次查找。 然而,
某些情况(例如 Ipv4 原始套接字)将需要直接从
Ipv4L3 协议。

对于接收到的用于转发或传递的入站数据包,将执行以下步骤。
Ipv4L3Protocol::Receive() 调用 Ipv4RoutingProtocol::RouteInput()。 这通过
Ipv4RoutingProtocol 对象的数据包所有权。 有四个关联的回调
用这个电话:

· 本地交付

· 单播转发

· 组播转发

· 错误

Ipv4RoutingProtocol 最终必须为每个数据包调用这些回调之一
它负责。 这基本上是输入路由过程的工作方式
Linux操作系统。
[图片] IPv4路由专业化..UNIINDENT

这种整体架构旨在支持不同的路由方法,包括
(未来)类似 Linux 的基于策略的路由实现,主动和
按需路由协议,以及模拟用户时的简单路由协议
并不真正关心路由。

IPv4路由 专业化。 说明多个路由协议如何由此派生
基类。 一个类 Ipv4ListRouting(实现类 Ipv4ListRoutingImpl)提供
现有的列表路由方法 ns-3. 其API与基类相同
Ipv4Routing 除了能够添加多个优先路由协议
(Ipv4ListRouting::AddRoutingProtocol(),Ipv4ListRouting::GetRoutingProtocol())。

这些路由协议的详细信息如下所述 单播 路由。 For now,目前,
我们将首先从一个基本的单播路由功能开始,该功能旨在全球
在模拟时间 t=0 为不关心的模拟用户建立路由表
动态路由。

全球 集中 路由
全局集中式路由有时被称为“上帝”路由; 这是一个特殊的
遍历仿真拓扑并运行最短路径算法的实现,以及
填充每个节点的路由表。 没有实际的协议开销(在模拟链路上)
采用这种方法会招致。 它确实有一些限制:

· 接线 只要: 它不适用于无线网络。

· 单播 只要: 它不进行多播。

· 可扩展性: 一些在大型拓扑(例如 1000 个节点)上使用此功能的用户已经注意到
当前的实现不是很可扩展。 全球集中式路由将是
将来进行修改以减少计算和运行时性能。

目前,基于点对点和共享的全球集中式 IPv4 单播路由
(CSMA) 链接受支持。

默认情况下,当使用 ns-3 helper API 和默认的 InternetStackHelper,全局
路由功能将被添加到节点,并且全局路由将作为
优先级低于静态路由的路由协议(即用户可以插入路由
通过 Ipv4StaticRouting API,它们将优先于全局找到的路由
路由)。

全球 单播 路由 API
公共 API 非常少。 用户脚本包括以下内容:

#include "ns3/internet-module.h"

如果使用默认的 InternetStackHelper,那么全局路由的实例将是
聚合到每个节点。 配置IP地址后,调用如下函数
将导致所有具有 IPv4 接口的节点接收转发表
GlobalRouteManager 自动输入:

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

请注意: 提醒 wifi NetDevice 可以工作,但不会产生任何无线影响
考虑到。 对于无线,我们推荐下面描述的 OLSR 动态路由。

可以在模拟过程中再次调用此函数,使用
以下附加公共功能:

ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

它刷新旧表,查询节点以获取新接口信息,以及
重建路线。

例如,此调度调用将导致表在 5 秒时重建:

Simulator::Schedule (秒 (5),
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

有两个属性控制行为。 第一个是
Ipv4GlobalRouting::RandomEcmpRouting。 如果设置为 true,数据包将随机路由
等价多路径路由。 如果设置为 false(默认),则只有一个路由是一致的
用过的。 第二个是 Ipv4GlobalRouting::RespondToInterfaceEvents。 如果设置为真,
根据接口通知事件动态重新计算全局路由(上/下,或
添加/删除地址)。 如果设置为 false(默认),路由可能会中断,除非用户手动
在此类事件之后调用 RecomputeRoutingTables()。 默认设置为 false 以保留
遗产 ns-3 程序行为。

全球 路由 实施
本节适用于关心如何实现的读者。 单身人士
对象(GlobalRouteManager)负责填充每个节点上的静态路由,
使用该节点的公共 IPv4 API。 它查询拓扑中的每个节点
“全局路由器”接口。 如果找到,它使用该接口的 API 来获取“链接
状态通告 (LSA)”。链路状态通告用于 OSPF
路由,我们遵循它们的格式。

重要的是要注意所有这些计算都是在数据包流动之前完成的
在网络中。 特别是,没有开销或控制数据包被交换
使用此实现时。 相反,这个全局路由管理器只是遍历列表
节点构建必要的信息并配置每个节点的路由表。

GlobalRouteManager 使用从整个网络收集的 LSA 填充链接状态数据库
拓扑。 然后,对于拓扑中的每个路由器,GlobalRouteManager 执行 OSPF
对数据库进行最短路径优先 (SPF) 计算,并在
每个节点。

斑驴(http://www.quagga.net) OSPF 实施被用作
路由计算逻辑。 遵循现有 OSPF SPF 实施的一个好处是
OSPF 已经为所有常见类型的网络定义了链路状态通告
链接:

· 点对点(串行链接)

· 点对多点(帧中继、ad hoc 无线)

· 非广播多路访问(ATM)

·广播(以太网)

因此,我们认为现在启用这些其他链接类型将更加直接
底层 OSPF SPF 框架已到位。

目前,我们可以处理 IPv4 点对点、编号链接以及共享广播
(CSMA) 链接。 还支持等价多路径。 虽然无线链路类型是
由实施支持,请注意,由于此实施的性质,任何
将不考虑通道效应,并且路由表将假定每个节点
同一共享通道上的每个其他节点都可以访问(即,它将被处理
像广播 CSMA 链接)。

GlobalRouteManager 首先遍历节点列表并聚合一个 GlobalRouter
每个接口如下:

typedef std::vector < Ptr >::iterator 迭代器;
for (迭代器 i = NodeList::Begin (); i != NodeList::End (); i++)
{
点节点 = *i;
点globalRouter = 创建对象(节点);
节点->AggregateObject (globalRouter);
}

该接口稍后被查询并用于为每个
路由器,并将此链路状态数据库馈入 OSPF 最短路径计算逻辑。
IPv4 API 最终用于填充路由本身。

单播 路由
目前为 IPv4 定义了七种单播路由协议,为 IPv6 定义了三种:

· 类 Ipv4StaticRouting(涵盖单播和多播)

· IPv4 优化的链路状态路由 (OLSR)(一种 MANET 协议,定义在 RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV)(一种 MANET 协议,定义在 RFC 3561)

· IPv4 Destination Sequenced Distance Vector (DSDV)(一种 MANET 协议)

· IPv4 动态源路由 (DSR)(一种 MANET 协议)

· Ipv4ListRouting 类(用于存储路由协议的优先级列表)

· 类 Ipv4GlobalRouting(用于存储由全局路由管理器计算的路由,如果
使用)

· class Ipv4NixVectorRouting(更高效的全局路由版本,存储
包头域中的源路由)

· Ipv6ListRouting 类(用于存储路由协议的优先级列表)

· 类 IPv6StaticRouting

· RipNg 类——IPv6 RIPng 协议(RFC 2080)

将来,这种架构也应该允许有人实现类似 Linux 的
使用路由缓存或 Click 模块化路由器实现,但这些超出了范围
目前。

ipv[4,6]列表路由
本节介绍当前的默认值 ns-3 Ipv[4,6] 路由协议。 通常,
用户空间支持多种路由协议,并协调编写单个
内核中的转发表。 目前在 ns-3, 该实现反而允许
多个路由协议来建立/保持自己的路由状态,以及 IP
实现将查询这些路由协议中的每一个(按照由
模拟作者),直到找到一条路线。

我们选择这种方法是因为它可以更好地促进不同的集成
可能难以将写入协调到单个表的路由方法,
比目标 IP 地址(例如源路由)更多信息的方法
用于确定下一跳,以及数据包必须到达的按需路由方法
缓存。

ipv[4,6]4ListRouting::AddRoutingProtocol
Ipv4ListRouting 和 Ipv6ListRouting 类提供纯虚函数声明
对于允许添加路由协议的方法:

无效的 AddRoutingProtocol (Ptr 路由协议,
int16_t 优先级);

无效的 AddRoutingProtocol (Ptr 路由协议,
int16_t 优先级);

这些方法分别由类 Ipv4ListRoutingImpl 和类实现
Internet 模块中的 Ipv6ListRoutingImpl。

上面的优先级变量控制路由协议的优先级
插入。 请注意,它是一个有符号整数。 默认在 ns-3,助手类将
实例化一个 Ipv[4,6]ListRoutingImpl 对象,并向其添加一个 Ipv[4,6]StaticRoutingImpl
优先级为零的对象。 在内部,存储了一个 Ipv[4,6]RoutingProtocols 列表,并且
并且每个路由协议都按照优先级递减的顺序进行查询以查看
是否找到匹配项。 因此,如果您希望您的 Ipv4RoutingProtocol 具有优先权
低于静态路由,以小于0的优先级插入; 例如:

点myRoutingProto = CreateObject ();
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

在调用 RouteOutput() 或 RouteInput() 时,列表路由对象将搜索列表
路由协议的优先级顺序,直到找到路由。 此类路由协议
将调用适当的回调,并且不会搜索进一步的路由协议。

优化 链接 路由 (OLSR)
此 IPv4 路由协议最初是从 ns-2 的 OLSR-UM 实现移植而来的。
该实现位于 src/olsr 目录中,示例脚本位于
示例/简单点对点 olsr.cc。

通常,OLSR 在主程序中通过使用安装的 OlsrHelper 类启用
OLSR 到 Ipv4ListRoutingProtocol 对象中。 以下示例命令将启用
OLSR 在模拟中使用此帮助器类以及其他一些路由帮助器对象。
优先级值 10 的设置,在 staticRouting 优先级 0 之前,意味着
将在节点的静态路由表之前咨询 OLSR 以获取路由。:

节点容器 c:
...
// 启用 OLSR
NS_LOG_INFO ("启用 OLSR 路由。");
OlsrHelper olsr;

ipv4StaticRoutingHelper 静态路由;

Ipv4ListRoutingHelper 列表;
列表.Add(静态路由,0);
列表.Add(olsr, 10);

InternetStackHelper 互联网;
internet.SetRoutingHelper(列表);
互联网.安装 (c);

安装后,可以使用 SetMainInterface() 命令设置 OLSR“主界面”。
如果用户没有指定主地址,协议会选择第一个主IP
它找到的地址,首先启动环回接口,然后是下一个
找到非环回接口,按 Ipv4 接口索引的顺序。 的环回地址
未选择 127.0.0.1。 此外,许多协议常量定义在
olsr-路由-protocol.cc。

基于对 Object::Start() 的调用,Olsr 在模拟的零时间启动
最终调用 OlsrRoutingProtocol::DoStart()。 注意:允许用户启动的补丁
并在其他时间停止协议将受到欢迎。

目前,OLSR 仅限于与 Ipv4ListRouting 对象一起使用,并且不响应
动态更改设备的 IP 地址或链接上/下通知; 即拓扑
变化是由于无线信道上的连接丢失/获得。

翻录
此 IPv6 路由协议 (RFC 2080) 是众所周知的 RIPv1 和 RIPv2 的演变
(见 RFC 1058RFC 1723) IPv4 的路由协议。

协议非常简单,一般适用于扁平、简单的网络
拓扑。

RIPng 强烈地基于 RIPv1 和 RIPv2,它们具有相同的目标和
限制。 特别是,RIP 考虑任何度量等于或大于 16 的路由
作为不可及。 因此,最大跳数是网络必须更少
大于15(未设置路由器数量)。 鼓励用户阅读 RFC 2080RFC
1058 全面了解 RIPng 行为和限制。

路由 收敛
RIPng 使用 Distance-Vector 算法,路由根据
Bellman-Ford 算法(有时称为 Ford-Fulkerson 算法)。 该算法有一个
O(|V|*|E|) 的收敛时间,其中 |V| 和 |E| 是顶点(路由器)的数量和
边缘(链接)分别。 需要强调的是,收敛时间是数
算法中的步骤,每个步骤都由一条消息触发。 自触发以来
更新(即更改路由时)有 1-5 秒的冷却时间,拓扑可以
需要一段时间才能稳定下来。

用户应注意,在路由表构建期间,路由器可能会丢弃
数据包。 数据流量应仅在足够长的时间以允许 RIPng 构建后发送
网络拓扑。 通常 80 秒应该足以产生次优(但
工作)路由设置。 这包括将路线传播到最
带有触发更新的远程路由器(16 跳)。

如果网络拓扑发生变化(例如,链路断开),恢复时间可能
相当高,甚至可能高于初始设置时间。 此外,网络
拓扑恢复受水平分割策略的影响。

这个例子 示例/路由/ripng-simple-network.cc 显示网络设置和
网络恢复阶段。

分裂 地平线
水平分割是一种防止路由不稳定的策略。 三个选项是可能的:

· 没有水平分割

· 水平分割

· 毒逆

在第一种情况下,路由会在所有路由器的接口上发布。 在第二
在这种情况下,路由器不会在其获知的接口上通告路由。
Poison Reverse 会在学习它的接口上通告路由,但是
度量为 16(无穷大)。 有关这三种技术的完整分析,请参阅 RFC
1058,第2.2节。

这个例子 ripng-simple-network.cc 基于 RFC 中描述的网络拓扑,
但它没有显示那里描述的效果。

原因是触发更新,以及当路由器
使路由无效,它将立即传播路由不可达性,因此
防止 RFC 中描述的大多数问题。

但是,对于复杂的拓扑,仍然可能出现路由不稳定现象
类似于 RFC 中描述的链路故障后的情况。 结果,所有
关于水平分割的考虑仍然有效。

默认 路线
应该安装 RIPng 协议 仅由 在路由器上。 结果,节点将不知道
什么是默认路由器。

为了克服这个限制,用户应该手动安装默认路由(例如,
通过诉诸 Ipv6StaticRouting)或使用 RADVd。 RADVd 可用于 ns-3 ,在
Applications 模块,强烈建议使用。

协议 参数 选项
RIPng ns-3 实现允许更改与路由关联的所有计时器
更新和路由生命周期。

此外,用户可以在每个节点的基础上更改接口指标。

水平分割的类型(以避免路由反向传播)可以在一个
每个节点的基础,选择是“不分裂水平”,“分裂水平”和“毒药
反向”。见 RFC 2080 了解更多详情,以及 RFC 1058 完整的讨论
水平分割策略。

限制
不支持 Next Hop 选项 (RFC 2080,第 2.1.1 节)。 下一跳
当 RIPng 不在网络上的所有路由器上运行时,该选项很有用。 支持
因为将来可能会考虑这个选项。

不支持 CIDR 前缀聚合。 因此,路由表和
路由通告可能比需要的大。 前缀聚合可以添加到
的未来。

多播 路由
以下函数用于向节点添加静态多播路由:

无效
Ipv4StaticRouting::AddMulticastRoute(Ipv4Address 来源,
IPv4地址组,
uint32_t 输入接口,
标准::向量输出接口);

多播路由必须指定源 IP 地址、多播组和输入
网络接口索引作为条件并提供输出网络接口的向量
发送匹配条件的数据包的索引。

通常有两种主要类型的多播路由:使用第一类路由
在转发过程中。 必须明确提供所有条件。 第二种
路由用于从本地节点获取数据包。 区别在于输入
界面。 用于转发的路由将始终具有指定的显式输入接口。
离开节点的路由将始终将输入接口设置为由指定的通配符
索引 Ipv4RoutingProtocol::IF_INDEX_ANY。

对于本地节点通配符的路由,可以在源组和多播组中使用
地址。 用于 Ipv4Adresses 的通配符是返回的地址
Ipv4Address::GetAny ()——通常是“0.0.0.0”。 通配符的使用允许指定
不同程度的默认行为。

例如,将源地址设为通配符,但保留多播组
具体允许一个(在具有多个接口的节点的情况下)创建不同的
为每个多播组使用不同的输出接口的路由。

如果将源地址和多播地址设为通配符,则您基本上创建了一个
默认组播地址,可以转发到多个接口。 将此与
实际默认多播地址,仅限于指定单个输出接口
为了与其他系统中的现有功能兼容。

另一个命令设置默认多播路由:

无效
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t 输出接口);

这是单播版本 SetDefaultRoute 的多播等效项。 我们告诉
路由系统在特定路由到目标多播的情况下要做什么
找不到组。 系统将数据包转发到希望的指定接口
那个“外面的东西”更清楚如何路由数据包。 此方法仅用于
最初从主机发送数据包。 不咨询默认组播路由
在转发期间——在这种情况下,必须使用 AddMulticastRoute 指定确切的路由。

因为我们基本上是向某个实体发送数据包,我们认为可能更清楚该做什么,
我们不关注原始地址之类的“细微之处”,也不担心
转发出多个接口。 如果设置了默认组播路由,则返回
作为从 LookupStatic 中选择的路由,与源或多播组无关,如果
未找到另一条特定路线。

最后,提供了许多附加功能来获取和删除多播
路线:

uint32_t GetNMulticastRoutes (void) 常量;

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (void) const;

bool RemoveMulticastRoute(Ipv4Address 来源,
IPv4地址组,
uint32_t 输入接口);

无效 RemoveMulticastRoute(uint32_t 索引);

TCP 模型 in ns-3
本章描述了可用的 TCP 模型 ns-3.

通用 支持 TCP
ns-3 是为了支持多种 TCP 实现而编写的。 实现继承自
一些常见的头文件类 源/网络 目录,以便用户代码可以换出
对脚本进行最小更改的实现。

有两个重要的抽象基类:

· 班级 的TCPSocket:这是定义在 src/internet/model/tcp-socket.{cc,h}. 这节课
存在用于托管可以跨不同重用的 TcpSocket 属性
实施。 例如,属性 初始Cwnd 可用于任何
从类派生的实现 的TCPSocket.

· 班级 TcpSocket工厂:这被第 4 层协议实例用来创建 TCP
正确类型的插座。

目前有三种 TCP 实现可用于 ns-3.

· 为 ns-3 原生实现的 TCP

· 支持 网络 教学帖子 座充 (NSC)

· 支持 直接 代码 执行 (大连)

还应该提到的是,将虚拟机与 ns-3
还提供了一些额外的 TCP 实现,但这些超出了
这一章。

ns-3 TCP
直到 ns-3.10 发布, ns-3 包含来自 TCP 模型的端口 GT网络。 这
Adriam Tam 为 ns-3.10 大幅重写了实现。 该模型是一个完整的
TCP,因为它是双向的,并尝试对连接建立和关闭进行建模
逻辑。

TCP 的实现包含在以下文件中:

src/internet/model/tcp-header.{cc,h}
src/internet/model/tcp-l4-protocol.{cc,h}
src/internet/model/tcp-socket-factory-impl.{cc,h}
src/internet/model/tcp-socket-base.{cc,h}
src/internet/model/tcp-tx-buffer.{cc,h}
src/internet/model/tcp-rx-buffer.{cc,h}
src/互联网/模型/tcp-rfc793.{cc,h}
src/internet/model/tcp-tahoe.{cc,h}
src/internet/model/tcp-reno.{cc,h}
src/internet/model/tcp-westwood.{cc,h}
src/internet/model/tcp-newreno.{cc,h}
src/internet/model/rtt-estimator.{cc,h}
src/网络/模型/序列号.{cc,h}

通过对公共基础进行子类化来支持 TCP 拥塞控制的不同变体
TCPSocketBase. 支持多种变体,包括 RFC 793 (没有拥堵
控制)、Tahoe、Reno、Westwood、Westwood+ 和 NewReno。 默认使用 NewReno。 看
本文档的使用部分,了解如何更改在中使用的默认 TCP 变体
模拟。

用法
在很多情况下,TCP 的使用是在应用层通过告诉 ns-3
应用程序使用哪种套接字工厂。

使用定义在 源代码/应用程序/助手src/网络/助手, 这里
是如何创建 TCP 接收器的:

// 在星“集线器”上创建一个数据包接收器来接收这些数据包
uint16_t 端口 = 50000;
地址 sinkLocalAddress(InetSocketAddress (Ipv4Address::GetAny (), port));
PacketSinkHelper sinkHelper ("ns3::TcpSocketFactory", sinkLocalAddress);
ApplicationContainersinkApp=sinkHelper.Install(serverNode);
sinkApp.Start(秒(1.0));
sinkApp.Stop(秒(10.0));

同样,以下代码段将 OnOffApplication 流量源配置为使用 TCP:

// 创建 OnOff 应用程序以向服务器发送 TCP
OnOffHelper clientHelper("ns3::TcpSocketFactory", Address());

细心的读者会注意到上面我们已经指定了抽象基的 TypeId
TcpSocket工厂. 剧本是如何讲述的 ns-3 它想要本地人 ns-3 TCP
与其他人相比? 好吧,当 Internet 堆栈添加到节点时,默认 TCP
聚合到节点的实现是 ns-3 TCP。 这可以被覆盖为
我们在下面展示了使用网络模拟摇篮时的情况。 因此,默认情况下,当使用 ns-3
helper API,聚合到具有 Internet 堆栈的节点的 TCP 是本机的 ns-3
TCP。

为了配置 TCP 的行为,许多参数通过 ns-3
属性系统。 这些记录在 Doxygen的
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> 上课 的TCPSocket。 对于
例如,最大段大小是一个可设置的属性。

要在创建任何与 Internet 堆栈相关的对象之前设置默认套接字类型,一个
可以在仿真程序的顶部放置以下语句:

Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe"));

对于希望有一个指向实际套接字的指针的用户(以便套接字操作像
Bind(),设置套接字选项等可以在每个套接字的基础上完成),Tcp 套接字可以
通过使用创建 套接字::CreateSocket() 方法。 传递给的 TypeId
CreateSocket() 必须是类型 ns3::套接字工厂, 所以配置底层套接字
type 必须通过旋转与底层 TcpL4Protocol 关联的属性来完成
目的。 最简单的方法是通过属性配置
系统。 在下面的示例中,访问节点容器“n0n1”以获取第零个
元素,并在此节点上创建一个套接字:

// 创建并绑定套接字...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
Config::Set("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue(tid));
点本地套接字 =
Socket::CreateSocket(n0n1.Get (0), TcpSocketFactory::GetTypeId ());

上面,节点号的“*”通配符传递给属性配置系统,
这样所有节点上的所有未来套接字都设置为 Tahoe,而不仅仅是节点'n0n1.Get (0)'。
如果想将其限制为仅指定的节点,则必须执行以下操作:

// 创建并绑定套接字...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
std::stringstream 节点ID;
nodeId << n0n1.Get(0)->GetId();
std::string specificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set(SpecificNode, TypeIdValue(tid));
点本地套接字 =
Socket::CreateSocket(n0n1.Get (0), TcpSocketFactory::GetTypeId ());

一旦创建了 TCP 套接字,就需要遵循传统的套接字逻辑,或者
connect() 和 send()(对于 TCP 客户端)或 bind()、listen() 和 accept()(对于 TCP
服务器)。 请参阅 Sockets-APIs 以了解如何使用套接字 ns-3.

验证
几个 TCP 验证测试结果可以在 维基 描述这个
实施。

电流 限制
· 不支持 SACK

网络 教学帖子 座充
- 网络 教学帖子 座充 (NSC) 是一个用于包装真实世界网络代码的框架
到模拟器中,允许以很少的额外成本模拟现实世界的行为。 这个
工作已经通过比较使用相同的测试网络的情况得到验证
模拟器中的情况。 迄今为止,已经证明 NSC 能够生产
极其准确的结果。 NSC 支持四种现实世界的堆栈:FreeBSD、OpenBSD、lwIP
和 Linux。 重点放在不要手动更改任何网络堆栈。 不是
在任何网络协议实现中更改了一行代码
以上四叠。 但是,构建了一个自定义 C 解析器以编程方式更改
源代码。

NSC 之前已移植到 ns-2 和 OMNeT++,并被添加到 ns-3 九月
2008 年(ns-3.2 版本)。 本节介绍 ns-3 NSC 的端口以及如何使用它。

在某种程度上,NSC 已被 Linux 内核支持所取代 直接 代码
执行 (大连). 但是,NSC 仍然可以通过烘焙构建系统获得。 国家安全委员会
支持 Linux 内核 2.6.18 和 2.6.26,但没有更新版本的内核
移植。

硬件需求
目前,NSC 已经过测试并证明可以在以下平台上工作:Linux i386 和 Linux
x86-64。 NSC 不支持 powerpc。 不支持在 FreeBSD 或 OS X 上使用(尽管它
或许可以工作)。

构建 NSC 需要软件包 flex 和 bison。

配置 下载
从 ns-3.17 或更高版本开始,NSC 必须从其自己的存储库中单独下载,
或使用时下载 建立 系统 of ns-3.

对于 ns-3.17 或更高版本,使用烘焙时,必须将 NSC 配置为
“allinone”配置,如:

$ cd烘烤
$ python bake.py 配置-e ns-allinone-3.19
$ python bake.py 下载
$ python bake.py 构建

可以通过指定使用 ns-3 开发版本而不是发布版本
“ns-3-allinone”到上面的配置步骤。

NSC 也可以从 它的 download 网站 使用 Mercurial:

$ hg 克隆 https://secure.wand.net.nz/mercurial/nsc

在 ns-3.17 发布之前,NSC 包含在 allinone tarball 中,并且发布的
版本不需要单独下载。

建筑物 证实
NSC 可以作为烘焙构建过程的一部分进行构建; 或者,可以通过以下方式构建 NSC
自己使用其构建系统; 例如:

$ cd nsc-开发
$蟒蛇scons.py

手动或通过烘焙系统构建 NSC 后,更改为 ns-3
源目录并尝试运行以下配置:

$ ./waf 配置

如果 NSC 之前已被 waf 构建并找到,那么您将看到:

网络模拟底座:启用

如果未找到 NSC,您将看到:

网络模拟摇篮:未启用(未找到 NSC(请参阅选项 --with-nsc))

在这种情况下,您必须将相对或绝对路径传递给 NSC 库,并使用
“--with-nsc”配置选项; 例如

$ ./waf 配置 --with-nsc=/path/to/my/nsc/directory

对于 ns-3 ns-3.17 版本之前的版本,使用 构建.py ns-3-allinone 中的脚本
目录,NSC 会默认构建,除非平台不支持。 至
构建时明确禁用它 ns-3,键入:

$ ./waf 配置 --enable-examples --enable-tests --disable-nsc

如果 waf 检测到 NSC,则构建 ns-3 使用 NSC 的方式与使用 waf 的方式相同
没有它。 一次 ns-3 构建完成后,尝试运行以下测试套件:

$ ./test.py -s ns3-tcp-互操作性

如果 NSC 已成功构建,结果中应显示以下测试:

通过测试套件 ns3-tcp 互操作性

这确认 NSC 已准备好使用。

用法
有几个示例文件。 尝试:

$ ./waf --运行 tcp-nsc-zoo
$ ./waf --运行 tcp-nsc-lfn

这些例子会存一些 .pcap 目录中的文件,可以通过以下方式检查
tcpdump 或wireshark。

让我们看一下 示例/tcp/tcp-nsc-zoo.cc 一些典型用法的文件。 怎么做的
不同于使用原生 ns-3 TCP? 使用 NSC 时有一个主要配置行
ns-3 需要设置的辅助 API:

InternetStackHelper 互联网堆栈;

internetStack.SetNscStack ("liblinux2.6.26.so");
// 这会将节点 0 和 1 切换到 NSCs Linux 2.6.26 堆栈。
互联网堆栈. 安装 (n.获取(0));
互联网堆栈. 安装 (n.获取(1));

关键线是 设置NscStack. 这告诉 InternetStack 助手聚合
NSC TCP 实例而不是本机实例 ns-3 TCP 到其余节点。 这很重要
调用这个函数 before 称呼 安装() 功能,如上图。

可以使用哪些堆栈? 目前,重点是 Linux 2.6.18 和 Linux
2.6.26 堆栈为 ns-3. 要查看构建了哪些堆栈,可以执行以下查找
命令在 ns-3 顶级目录:

$ find nsc -name "*.so" -type f
NSC/linux-2.6.18/liblinux2.6.18.so
NSC/linux-2.6.26/liblinux2.6.26.so

这告诉我们,我们可以传递库名称 liblinux2.6.18.so 或
liblinux2.6.26.so 到上面的配置步骤。

配置
NSC TCP 与 TCP 套接字共享相同的配置属性,如
如上所述并记录在 Doxygen的

此外,NSC TCP 将大量配置变量导出到 ns-3 属性
系统,通过 系统控制- 类似的界面。 在里面 示例/tcp/tcp-nsc-zoo 例如,你可以看到
以下配置:

// 这会禁用节点 1 上的 TCP SACK、wscale 和时间戳(属性
表示 sysctl 值)。
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
字符串值(“0”));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
字符串值(“0”));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
字符串值(“0”));

这些额外的配置变量不适用于本机 ns-3 TCP。

另请注意,TCP 属性的默认值 ns-3 TCP 可能与 nsc TCP 不同
执行。 具体在 ns-3:

1. TCP 默认 MSS 为 536

2. TCP 延迟确认计数为 2

因此,在比较使用 nsc 和 ns-3 TCP,关心
必须采取以确保正确设置这些值。 看
/examples/tcp/tcp-nsc-comparision.cc 例如。

NSC API
本小节描述 NSC 提供给的 API ns-3 或任何其他模拟器。 国家安全委员会
以许多类的形式提供其 API,这些类在
sim/sim_interface.h 在 nsc 目录中。

· 网络堆栈 INetStack 包含操作系统网络的“低级”操作
堆栈,例如在网络堆栈中输入和输出函数(将其视为
'网络驱动程序接口'。 还有一些功能可以创建新的 TCP 或 UDP 套接字。

· 发送回调 当一个数据包应该被发送到网络时,这由 NSC 调用。
此模拟器应使用此回调将数据包重新注入模拟器,以便
实际数据可以传送/路由到其目的地,最终将到达目的地
交给 Receive() (并最终通过
INetStack->if_receive())。

· INetStreamSocket 这是定义特定连接端点的结构(文件
描述符)。 它包含在此端点上操作的方法,例如连接、断开连接、
接受,收听,发送数据/读取数据,...

· 中断回调 这包含唤醒回调,每当 NSC 调用它
有趣的事情发生了。 将 wakeup() 视为操作的替代品
系统唤醒功能:每当操作系统唤醒一个具有
一直在等待操作完成(例如 TCP 握手期间
connect()),NSC 调用 wakeup() 回调以允许模拟器检查状态
其连接端点的变化。

ns-3 履行
- ns-3 实现利用上述NSC API,实现如下。

三个主要部分是:

· ns3::NscTcpL4协议:Ipv4L4Protocol 的子类(和两个 nsc 类:ISendCallback
和 IInterruptCallback)

· ns3::NscTcpSocketImpl: TcpSocket 的子类

· ns3::NscTcpSocketFactoryImpl:创建新 NSC 套接字的工厂

src/互联网/模型/nsc-tcp-l4-协议 是主要课程。 在初始化时,它会加载一个
要使用的 nsc 网络堆栈(通过 dlopen())。 此类的每个实例都可以使用不同的
堆。 要使用的堆栈(=共享库)是使用 SetNscLibrary() 方法设置的(在此
通过互联网堆栈帮助程序间接调用它的时间)。 然后设置 nsc 堆栈
相应地(计时器等)。 NscTcpL4Protocol::Receive() 函数将数据包交给它
接收(必须是完整的 tcp/ip 数据包)到 nsc 堆栈以进行进一步处理。 至
能够发送数据包,这个类实现了 nsc send_callback 方法。 这种方法
每当 nsc 堆栈希望将数据包发送到网络时由 nsc 调用。 它的
参数是一个原始缓冲区,包含一个完整的 TCP/IP 数据包和一个长度值。 这个
因此,方法必须将原始数据转换为 Ptr 可用 ns-3。 为了
避免各种 ipv4 标头问题,不包括 nsc ip 标头。 相反,tcp
标头和实际有效负载放入 Ptr ,在此之后数据包是
向下传递到第 3 层以将数据包发送出去(无需进一步特殊处理
在发送代码路径中)。

这个类调用 ns3::NscTcpSocketImpl 来自 nsc wakeup() 回调和来自
接收路径(以确保可能排队的数据被安排发送)。

src/互联网/模型/nsc-tcp-socket-impl 实现 nsc 套接字接口。 每个实例
有自己的nscTcpSocket。 Send() 的数据将通过
m_nscTcpSocket->send_data()。 (而不是nsc-tcp-l4,这是比较的主要区别
ns-3 TCP)。 该类还将 Send() 的数据排队在底层之前
描述符已进入 ESTABLISHED 状态。 这个类是从 nsc-tcp-l4 调用的
类,当 nsc 调用 nsc-tcp-l4 wakeup() 回调时。 然后是 nsc-tcp-socket-impl
检查当前连接状态(SYN_SENT、ESTABLISHED、LISTEN...)和时间表
根据需要进行适当的回调,例如 LISTEN 套接字将安排 Accept 以查看是否有新的
连接必须被接受,一个 ESTABLISHED 套接字调度任何待写入的数据,
安排读取回调等

需要注意的是 ns3::NscTcpSocketImpl 不直接与 nsc-tcp 交互:相反,数据是
重定向到国家安全委员会。 nsc-tcp 在唤醒回调时调用节点的 nsc-tcp-sockets
由 nsc 调用。

限制
· NSC 仅适用于单接口节点; 尝试在多接口节点上运行它
会导致程序错误。

· 不支持 Cygwin 和 OS X PPC; OS X Intel 不受支持,但可以工作

· 不支持 NSC 的非 Linux 堆栈 ns-3

· 并非所有套接字 API 回调都受支持

欲了解更多信息,请参阅 Free Introduction 维基 .

代码 队列 履行 in ns-3
本章介绍 CoDel ([Nic12], [Nic14]) 队列的实现 ns-3.

由 Kathleen Nichols 和 Van Jacobson 开发,作为缓冲膨胀的解决方案 [Buf14]
问题,CoDel(受控延迟管理)是一种使用数据包的队列规则
停留时间(排队时间)来决定丢包。

型号 描述
CoDel 模型的源代码位于目录中 源/互联网/模型
由2个文件组成 编码队列.h代码队列.cc 定义一个 CoDelQueue 类和一个
助手 CoDelTimestampTag 类。 代码被移植到 ns-3 由安德鲁·麦格雷戈基于
由 Dave Täht 和 Eric Dumazet 实现的 Linux 内核代码。

· 班级 编码队列: 这个类实现了主要的 CoDel 算法:

· CoDelQueue::DoEnqueue ():这个程序用当前时间标记一个数据包之前
将其推入队列。 时间戳标签由 CoDelQueue::DoDequeue() 函数
计算数据包的逗留时间。 如果数据包到达时队列已满,则
例程将丢弃数据包并记录由于队列溢出而丢弃的数量,
存储在 m_dropOverLimit.

· CoDelQueue::应该丢弃 (): 这个程序是 CoDelQueue::DoDequeue() 函数的助手例程
它根据数据包的停留时间确定是否应丢弃数据包。
如果逗留时间超过 m_目标 并至少持续保持在上面
m_间隔,例程返回 true 表示可以丢弃数据包。
否则,它返回 false.

· CoDelQueue::DoDequeue ():这个例程执行实际的数据包丢弃基于
CoDelQueue::应该丢弃 ()的返回值并安排下一次下降。

· 班级 代码删除时间戳标签:这个类实现了一个数据包的时间戳标记。 这个
标签用于计算数据包的停留时间(与
数据包出队和被推入队列的时间)。

有2个分店 CoDelQueue::DoDequeue ():

1.如果队列当前处于dropping状态,则表示逗留时间有
保持在上面 m_目标 超过 m_间隔,例程确定是否可以
离开下降状态,或者是下一次下降的时候了。 什么时候 CoDelQueue::应该丢弃 ()
回报 false,队列可以移出丢弃状态(设置 m_droppingfalse).
否则,队列会不断丢弃数据包并更新下一次丢弃的时间
(m_dropNext) 直到满足以下条件之一:

1.队列为空,队列离开dropping状态并退出
CoDelQueue::应该丢弃 () 常规;

2. CoDelQueue::应该丢弃 () 回报 false (意思是逗留时间在下面
m_目标) 队列离开丢弃状态;

3.现在还不是下一次下降的时间(m_dropNext 小于当前时间)
队列等待下一个数据包出队再次检查条件。

2. 如果队列不处于 drop 状态,则例程进入 drop 状态并
丢弃第一个数据包,如果 CoDelQueue::应该丢弃 () 回报 true (意思是逗留
时间已经过去 m_目标 至少 m_间隔 第一次或者它已经消失了
队列离开丢弃状态后再次上图)。

案例
[尼克12]

K. Nichols 和 V. Jacobson,控制队列延迟,ACM 队列,卷。 10 第 5 期,2012 年 XNUMX 月。
可以在线获得 http://queue.acm.org/detail.cfmid = 2209336.

[尼克14]

K. Nichols 和 V. Jacobson,互联网草案:受控延迟主动队列管理,
2014 年 XNUMX 月。
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[缓冲区14]
缓冲膨胀网。 可在线获取 http://www.bufferbloat.net/.

Attributes
CoDelQueue 类拥有的关键属性包括:

· 模式: CoDel 操作模式(字节、数据包或非法)。 默认模式是字节。

· 最大数据包: 队列可以容纳的最大数据包数。 默认值为
DEFAULT_CODEL_LIMIT,即 1000 个数据包。

· 最大字节数: 队列可以容纳的最大字节数。 默认值为 1500 *
DEFAULT_CODEL_LIMIT,即 1500 * 1000 字节。

· 最小字节: CoDel 算法 minbytes 参数。 默认值为 1500 字节。

· 间隔: 滑动最小窗口。 默认值为 100 毫秒。

· Target: CoDel 算法目标队列延迟。 默认值为 5 毫秒。

例子
第一个例子是 codel-vs-droptail-basic-test.cc 位于 源代码/互联网/示例。 至
运行文件(下面的第一个调用显示了可用的命令行选项):

$ ./waf --run "codel-vs-droptail-basic-test --PrintHelp"
$ ./waf --run "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

前面命令的预期输出是两个文件: 编码器.pcap 文件和
cwndCoDel.tr (ASCII 跟踪)文件 .pcap 文件可以使用 wireshark 或
tcptrace:

$ tcptrace -l -r -n -W codel.pcap

第二个例子是 codel-vs-droptail-asymmetry.cc 位于 源代码/互联网/示例.
此示例旨在模拟典型的电缆调制解调器部署方案。 运行
文件:

$ ./waf --run "codel-vs-droptail-asymmetric --PrintHelp"
$ ./waf --运行 codel-vs-droptail-asymmetry

前面命令的预期输出是六个 pcap 文件:

· codel-vs-droptail-asymmetry-CoDel-server-lan.pcap

· codel-vs-droptail-asymmetry-CoDel-router-wan.pcap

· codel-vs-droptail-asymmetry-CoDel-router-lan.pcap

· codel-vs-droptail-不对称-CoDel-cmts-wan.pcap

· codel-vs-droptail-不对称-CoDel-cmts-lan.pcap

· codel-vs-droptail-asymmetry-CoDel-host-lan.pcap

一个属性文件:

· codel-vs-droptail-asymmetry-CoDel.attr

五个 ASCII 跟踪文件:

· codel-vs-droptail-asymmetry-CoDel-drop.tr

· codel-vs-droptail-asymmetry-CoDel-drop-state.tr

· codel-vs-droptail-asymmetry-CoDel-sojourn.tr

· codel-vs-droptail-asymmetry-CoDel-length.tr

· codel-vs-droptail-asymmetry-CoDel-cwnd.tr

验证
使用 CoDel 模型进行测试 CoDel队列测试套件 类定义在
src/internet/test/codel-queue-test-suite.cc. 该套件包括 5 个测试用例:

· 测试 1:第一个测试检查没有丢包的入队/出队,并确保
CoDel 属性可以正确设置。

· 测试 2:第二个测试检查由于队列溢出而导致的队列丢失。

· 测试 3:第三个测试针对 Linux 的显式端口检查 NewtonStep() 算法
履行

· 测试 4:第四个测试检查 ControlLaw() 与 Linux 的显式端口
履行

· 测试 5:第五次测试根据 CoDel 检查 enqueue/dequeue with drop
算法

可以使用以下命令运行测试套件:

$ ./waf 配置 --enable-examples --enable-tests
$ ./waf 构建
$ ./test.py -s 编码队列

or

$ NS_LOG="CoDelQueue" ./waf --run "test-runner --suite=codel-queue"
分页符

低利率 无线 个人 国家 / 地区 网络 (LR-WPAN)


本章描述了 ns-3 模型的实现,用于低速率、无线
IEEE 标准 802.15.4 (2006) 规定的个域网 (LR-WPAN)。

型号 描述
lr-wpan 模块的源代码位于目录中 src/lr-wpan.

工艺设计
从架构的角度来看,模型设计紧密遵循标准。
[图片] lr-wpan 模型的架构和范围。UNIINDENT

图中的灰色区域(改编自 IEEE Std. 3-802.15.4 的图 2006)表示
模型的范围。

Nicola Baldo 的 Spectrum NetDevice 是实施的基础。

实现还计划借鉴郑和李开发的ns-2模型
在未来。

APIs
API 严格遵循标准,适用于 ns-3 命名约定和惯用语。 这
API 是围绕服务原语的概念组织的,如下所示
图改编自 IEEE 标准的图 14。 802.15.4-2006。
[图片] 服务原语.UNIDENT

API 围绕四个概念性服务和服务访问点 (SAP) 进行组织:

· MAC数据服务(MCPS)

· MAC管理服务(MLME)

· PHY数据服务(PD)

· PHY管理服务(PLME)

一般来说,原语的标准化如下(例如 IEEE 的 Sec 7.1.1.1.1
802.15.4-2006)::

MCPS-DATA.请求(
源地址模式,
目标地址模式,
目标 PANId,
目标地址,
msdu长度,
女士们,
msdu句柄,
发送选项,
安全级别,
KeyId模式,
关键来源,
关键索引
)

这映射到 ns-3 类和方法,例如:

结构 McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;
...
};

无效
LrWpanMac::McpsDataRequest(McpsDataRequestParameters 参数)
{
...
}

MAC
MAC 目前实现无时隙 CSMA/CA 变体,没有信标。 目前
不支持协调器和相关 API。

实现的 MAC 类似于 Contiki 的 NullMAC,即没有睡眠功能的 MAC。
假设无线电始终处于活动状态(接收或发送),完全关闭
下。 执行 CCA 时不会禁用帧接收。

支持的主要 API 是数据传输 API (McpsDataRequest/Indication/Confirm)。
支持根据 Stc 802.15.4-2006 第 7.5.1.4 节的 CSMA/CA。 帧接收和
根据 Std 802.15.4-2006 的拒绝,支持第 7.5.6.2 节,包括
致谢。 只有短寻址完全实现。 各种跟踪源是
支持,并且跟踪源可以连接到接收器。

PHY
物理层组件包括一个 Phy 模型、一个错误率模型和一个损失
模型。 错误率模型目前模拟 IEEE 802.15.4 2.4 GHz 的错误率
用于 OQPSK 的 AWGN 通道; 型号描述可在 IEEE Std 802.15.4-2006 中找到,
第 E.4.1.7 节。 Phy 模型基于 SpectrumPhy 并遵循规范
IEEE Std 6-802.15.4 第 2006 节中描述。 它模拟 PHY 服务规范,
PPDU 格式、PHY 常量和 PIB 属性。 目前只支持发送
根据第 2.4 节在 6.5.3.1 GHz 中指定的功率谱密度模板。 噪声功率
密度假设在频带上均匀分布热噪声。 损失
模型可以充分利用所有现有的简单(非频谱 phy)损失模型。 物理模型
使用现有的单频谱通道模型。 物理层以数据包为模型
级,即不进行前导码/SFD检测。 数据包接收将开始于
前导码的第一位(未建模),如果 SNR 大于 -5 dB,请参阅
IEEE Std 802.15.4-2006,附录 E,图 E.2。 数据包的接收将在之后完成
数据包已完全传输。 接收期间到达的其他数据包将加起来
到干扰/噪声。

目前,接收器灵敏度设置为 -106.58 dBm 的固定值。 这个
对应于该信号的 1 字节参考数据包的 20% 数据包错误率
功率,根据 IEEE Std 802.15.4-2006,第 6.1.7 节。 未来我们将提供
支持将灵敏度更改为不同的值。
[图片] 数据包错误率与信号功率。UNIDENT

网络设备
尽管预计其他技术配置文件(如 6LoWPAN 和 ZigBee)将
编写自己的NetDevice类,提供了一个基本的LrWpanNetDevice,它封装了
创建通用 LrWpan 设备并将事物连接在一起的常见操作。

适用范围 限制
本文档的未来版本将包含类似于附录 D 的 PICS 形式
IEEE 802.15.4-2006。 当前的重点是 802.15.4 操作的非时隙模式
用于 Zigbee,范围仅限于启用具有基本功能的单一模式 (CSMA/CA)
数据传输能力。 尚不支持与 PAN 协调员的关联,也不支持
使用扩展寻址。 干扰被建模为 AWGN,但目前不是
彻底测试。

NetDevice Tx队列不受限制,即永远不会因为队列而丢弃数据包
变得饱满。 由于过多的传输重试或通道访问,它们可能会被丢弃
失败。

案例
· 无线媒体访问控制 (MAC) 和物理层 (PHY) 规范
低速率无线个域网 (WPAN)、IEEE 计算机协会、IEEE 标准
802.15.4-2006,8 年 2006 月 XNUMX 日。

·

J. Zheng 和 Myung J. Lee,“IEEE 802.15.4 的综合性能研究”,传感器
网络运营,IEEE 出版社,Wiley Interscience,第 4 章,第 218-237 页,2006 年。

用法
启用 LR-WPAN
添加 LR-WPAN 使用 ns-3 构建的模块列表。

帮手
助手在其他设备助手之后被模式化。 特别是,跟踪(ascii 和
pcap) 同样启用,并执行所有 lr-wpan 日志组件的启用
相似地。 帮助器的使用示例在 示例/lr-wpan-data.cc. 对于ASCII
跟踪,发送和接收跟踪在 Mac 层挂钩。

使用此帮助器时,添加到通道的默认传播损失模型是
具有默认参数的 LogDistancePropagationLossModel。

例子
已经编写了以下示例,可以在 src/lr-wpan/示例/:

· lr-wpan-data.cc:显示端到端数据传输的简单示例。

· lr-wpan-错误距离-plot.cc:绘制数据包成功变化的示例
比率作为距离的函数。

· lr-wpan-错误模型-plot.cc: 一个测试 phy 的例子。

· lr-wpan-数据包打印.cc: 打印 MAC 标头字段的示例。

· lr-wpan-phy-test.cc: 一个测试 phy 的例子。

特别是,该模块支持非常简化的端到端数据传输场景,
实施 lr-wpan-data.cc. 该图显示了触发的一系列事件
当 MAC 接收到来自更高层的 DataRequest 时。 它调用一个清晰​​的通道
来自 PHY 的评估 (CCA),如果成功,则将帧向下发送到 PHY
通过通道传输并在对等节点上产生 DataIndication。
[图片] 简单 LR-WPAN 数据端到端传输的数据示例。UNIDENT

这个例子 lr-wpan-错误距离-plot.cc 将数据包成功率 (PSR) 绘制为
距离函数,使用默认的 LogDistance 传播损失模型和
802.15.4 错误模型。 通道(默认 11)、数据包大小(默认 20 字节)和
发射功率(默认 0 dBm)可以通过命令行参数改变。 该程序
输出一个名为 802.15.4-psr-距离.plt. 将此文件加载到 gnuplot 中会产生一个
文件 802.15.4-psr-距离.eps,可以转换成pdf或者其他格式。 这
默认输出如下所示。
[image] 程序的默认输出 lr-wpan-错误距离-plot.cc.取消缩进

检测
编写了以下测试,可以在 src/lr-wpan/测试/:

· lr-wpan-ack-test.cc: 检查确认是否在
正确的顺序。

· lr-wpan-碰撞测试.cc: 测试正确接收有干扰的数据包和
碰撞。

· lr-wpan-错误-模型-test.cc:检查误差模型是否给出了可预测的值。

· lr-wpan-数据包-test.cc:测试 802.15.4 MAC 标头/尾标类

· lr-wpan-pd-plme-sap-test.cc:根据 IEEE 802.15.4 测试 PLME 和 PD SAP

· lr-wpan-spectrum-value-helper-test.cc:测试电源之间的转换
(表示为标量)和光谱功率,然后再回来,落在 25% 以内
在可能的通道和输入功率范围内的容差。

验证
该模型尚未针对真实硬件进行验证。 错误模型已
根据 IEEE Std 802.15.4-2006 第 E.4.1.7 节(图 E.2)中的数据进行验证。 这
MAC 行为(CSMA 退避)已针对预期行为进行了手动验证。 这
下图是错误模型验证的示例,可以通过运行重现
lr-wpan-错误模型-plot.cc:
[image] 程序的默认输出 lr-wpan-错误模型-plot.cc.取消缩进

LTE的 模块


工艺设计 文件记录
概述
LTE-EPC仿真模型概览如图所示 概述 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。
LTE-EPC 模拟 模型. 有两个主要组成部分:

· LTE 模型。 该模型包括 LTE 无线电协议栈(RRC、PDCP、RLC、MAC、
物理层)。 这些实体完全驻留在 UE 和 eNB 节点内。

· EPC 模型。 该模型包括核心网络接口、协议和实体。
这些实体和协议驻留在 SGW、PGW 和 MME 节点内,部分
在 eNB 节点内。
[图片] LTE-EPC 仿真模型概述。UNIDENT

工艺设计 标准
LTE的 型号
LTE 模型旨在支持对 LTE 的以下方面的评估
系统:

· 无线电资源管理

· QoS感知包调度

· 小区间干扰协调

· 动态频谱接入

为了将 LTE 系统建模到足以允许正确
综合以上各方面的评价,提出了以下要求
经过考虑的:

1.在无线电层面,模型的粒度至少应该是
资源块 (RB)。 事实上,这是用于资源的基本单位
分配。 如果没有这个最小粒度级别,就不可能建模
准确的分组调度和小区间干扰。 原因是,由于
分组调度是在每个 RB 的基础上完成的,一个 eNB 可能只在一个子集上传输
所有可用的 RB,因此仅在那些 RB 上干扰其他 eNB
它正在传输。 请注意,此要求排除了采用系统
水平模拟方法,仅在
呼叫/承载建立的粒度。

2.模拟器应该扩展到数十个eNB和数百个用户设备(UE)。
这排除了使用链路级模拟器,即无线电模拟器
接口以高达符号级别的粒度进行建模。 这是因为
有符号级模型有必要实现所有 PHY 层信号
处理,其巨大的计算复杂性严重限制了模拟。 实际上,
链路级模拟器通常仅限于单个 eNB 和一个或几个 UE。

3. 应该可以在模拟中配置不同的单元,以便
它们使用不同的载波频率和系统带宽。 使用的带宽
应该允许不同的小区重叠,以支持动态频谱
许可解决方案,例如 [Ofcom2600MHz] 和 [RealWireless] 中描述的解决方案。
干扰的计算应该适当地处理这种情况。

4. 更能代表LTE标准,尽可能接近
对于现实世界的实现,模拟器应该支持 MAC 调度器 API
由 FemtoForum [FFAPI] 发布。 该接口预计将由
femtocell 制造商用于实施调度和无线电资源
管理(RRM)算法。 通过在
模拟器,我们可以让 LTE 设备商和运营商在一个
模拟环境与将在真实环境中部署的算法完全相同
系统。

5. LTE 仿真模型应该包含它自己的 API 实现
[FFAPI]。 二进制文件和数据结构都与特定供应商不兼容
期望实现相同的接口; 因此,兼容层
每当供应商特定的 MAC 调度程序与
模拟器。 这个要求是允许模拟器独立的必要条件
来自此接口规范的特定于供应商的实现。 我们注意到
[FFAPI] 只是一个逻辑规范,它的实现(例如,翻译
到某些特定的编程语言)留给供应商。

6.该模型用于模拟上层对IP包的传输
层。 在这方面,应考虑在 LTE 中,调度和
无线电资源管理不直接使用 IP 数据包,而是使用 RLC
PDU,通过对 IP 数据包进行分段和连接获得
RLC 实体。 因此,应该对 RLC 层的这些功能进行建模
准确。

EPC 型号
EPC 模型的主要目标是为端到端的仿真提供手段。
LTE 模型上的 IP 连接。 为此,它支持互联
多个 UE 到 Internet,通过多个 eNB 的无线接入网络连接到
单个SGW/PGW节点,如图 概述 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 LTE-EPC 模拟 模型.

为 EPC 模型做出了以下设计选择:

1. 唯一支持的分组数据网络 (PDN) 类型是 IPv4。

2. SGW和PGW功能实体在一个节点内实现,即
因此称为 SGW/PGW 节点。

3. 具有跨 SGW 移动性的场景不感兴趣。 因此,单个 SGW/PGW
节点将出现在所有模拟场景中

4. EPC模型的一个要求是它可以用来模拟端到端
实际应用的性能。 因此,应该可以使用
EPC 为任何在 TCP 或 UDP 之上工作的常规 ns-3 应用程序建模。

5. 另一个要求是模拟网络拓扑的可能性
存在多个 eNB,其中一些可能配备回程
连接能力有限。 为了模拟这样的场景,用户
应该对 eNB 和 SGW/PGW 之间使用的数据平面协议进行建模
准确。

6.单个UE应该可以使用不同的应用程序
QoS 配置文件。 因此,每个 UE 应该支持多个 EPS 承载。 这个
包括在 UE 上完成的基于 IP 的 TCP/UDP 流量的必要分类
上行链路和下行链路的 PGW。

7、EPC模型的重点主要在EPC数据平面。 准确的建模
EPC 控制平面暂时不是必需的; 因此,
必要的控制平面交互可以通过简化的方式建模
利用不同模拟对象之间的直接交互
提供了辅助对象。

8. EPC 模型的重点是在 ECM 连接模式下模拟活跃用户。
因此,所有仅与 ECM 怠速模式相关的功能(特别是,
跟踪区域更新和分页)根本没有建模。

9. 该模型应允许在两个之间执行基于 X2 的切换
基站。

卓越
LTE的 型号
UE 架构
UE 的 LTE 无线协议栈模型的架构如图所示:
数字 LTE的 无线电电路 协议 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 data 平面LTE的 无线电电路
协议 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 控制 平面 分别突出显示
数据平面和控制平面。
[图片] 数据平面上 UE 的 LTE 无线电协议栈架构。UNIINDENT
[图片] 控制平面上 UE 的 LTE 无线电协议栈架构。UNIDENT

UE的PHY/信道模型的架构如图所示 PHY
渠道 模型 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE.
[图片] UE.UNIDENT 的 PHY 和信道模型架构

基站 架构
eNB 的 LTE 无线电协议栈模型的架构表示在
数字 LTE的 无线电电路 协议 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基站 on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 data 平面LTE的 无线电电路
协议 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基站 on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 控制 平面 分别突出显示
数据平面和控制平面。
[图片] 数据平面上 eNB 的 LTE 无线电协议栈架构。UNIDENT
[图片] 控制平面上 eNB 的 LTE 无线电协议栈架构。UNIDENT

eNB的PHY/信道模型的架构如图所示 PHY
渠道 模型 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基站.
[图片] eNB.UNIDENT 的 PHY 和通道模型架构

EPC 型号
EPC data 平面
在图中 LTE-EPC data 平面 协议 ,我们代表端到端的 LTE-EPC 数据
平面协议栈,因为它是在模拟器中建模的。 从图中可以看出
数据平面模型中引入的最大简化是包含
单个 SGW/PGW 节点内的 SGW 和 PGW 功能,无需 S5
或 8GPP 规定的 S3 接口。 另一方面,对于 S1-U 协议栈
和 LTE 无线电协议栈 3GPP 指定的所有协议层都存在。
[图片] LTE-EPC 数据平面协议栈。UNIDENT

EPC 控制 平面
控制平面模型的实现架构如图所示 EPC
控制 模型. 显式建模的控制接口是 S1-AP、X2-AP
和 S11 接口。

我们注意到 S1-AP 和 S11 接口以简化的方式建模,通过
仅使用一对接口类来模拟实体之间的交互
驻留在不同的节点上(S1-AP 接口的 eNB 和 MME,以及 MME 和
S11 接口的 SGW)。 在实践中,这意味着这些原语
接口映射到两个对象之间的直接函数调用。 在另一
手,X2-AP 接口正在使用通过 X2 链路发送的协议数据单元建模
(建模为点对点链路); 为此,X2-AP接口模型更
实际的。
[图片] EPC控制模型.UNIDENT

频道 传播
出于信道建模目的,LTE 模块使用 频谱频道 提供的接口
由频谱模块。 在撰写本文时,此类接口的两个实现
可用: 单模频谱信道多模型频谱信道, 和 LTE
模块需要使用 多模型频谱信道 为了正常工作。 这个
是因为需要支持不同的频率和带宽配置。 全部
支持的传播模型 多模型频谱信道 可以在
LTE 模块。

使用 VHDL 语言编写 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 Buildings 模型 - LTE的
与 LTE 模块一起使用的推荐传播模型是由
Buildings 模块,实际上是专门为 LTE 设计的(尽管它可以
与其他无线技术一起使用)。 请参考文档
Buildings 模块,用于提供有关其提供的传播模型的一般信息。

在本节中,我们将重点介绍一些特别适用于
Buildings 模块与 LTE 模块一起使用。

下面使用的命名约定将是:

· 用户设备:UE

·宏基站:MBS

· 小蜂窝基站(例如,微微/毫微微蜂窝):SC

LTE模块只考虑FDD,实现上下行传播
分别地。 因此,执行以下路径损耗计算

· MBS <-> UE(室内和室外)

· SC(室内和室外)<-> UE(室内和室外)

LTE 模型不提供以下路径损耗计算:

· UE <-> UE

· MBS <-> MBS

· MBS <-> SC

· SC <-> SC

Buildings 模型不知道节点的实际类型; 即,它不知道
发射机节点是UE、MBS还是SC。 相反,建筑物模型只关心
关于节点的位置:是室内还是室外,z轴是什么
相对于屋顶水平。 因此,对于放置在室外的 eNB 节点,
在屋顶平面以上的 z 坐标处,MBS 的典型传播模型将是
由建筑物模块使用。 相反,对于放置在室外但低于
屋顶或室内,将使用典型的 pico 和 femtocells 传播模型。

对于涉及至少一个室内节点的通信,相应的穿墙
损失将由建筑物模型计算。 这涵盖了以下用例:

· MBS <-> 室内UE

· 室外SC <-> 室内UE

· 室内 SC <-> 室内 UE

· 室内 SC <-> 室外 UE

有关实际模型的详细信息,请参阅 Buildings 模块的文档
在每种情况下使用。

衰退 型号
LTE 模块包括一个基于迹线的衰落模型,该模型源自
GSoC 2010 [Piro2011]。 该模型的主要特点是
模拟运行期间的衰落评估基于每次计算的轨迹。 这是
这样做是为了限制模拟器的计算复杂度。 另一方面,它需要
用于存储痕迹的巨大结构; 因此,数量之间的权衡
必须找到可能的参数和内存占用。 最重要的是:

· users' speed:用户之间的相对速度(影响多普勒频率,在
匝数影响衰落的时变特性)

· 抽头数(和相对功率):考虑的多条路径的数量,其中
影响衰落的频率特性。

· 跟踪的时间粒度:跟踪的采样时间。

· 跟踪的频率粒度:要评估的频率值的数量。

· 走线长度:理想情况下与模拟时间一样大,可以通过加窗来减少
机制。

· 用户数量:要使用的独立跟踪的数量(理想情况下,每个跟踪一个
用户)。

关于数学信道传播模型,我们建议使用由
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 雷利坎 Matlab 的功能,因为它提供了一个被广泛接受的通道
时域和频域建模。 欲了解更多信息,读者是
参考[数学]。

模拟器提供matlab脚本
(src/lte/model/fading-trace/fading-trace-generator.m) 用于生成基于
模拟器使用的格式。 详细来说,使用 rayleighchan 创建的通道对象
函数用于对离散时间脉冲信号进行滤波以获得
信道脉冲响应。 对不同的 TTI 重复滤波,从而产生
随后的时间相关通道响应(每个 TTI 一个)。 那么信道响应是
处理与 韦尔奇 获得其功率谱密度值的函数,其中
然后以与模拟器模型兼容的正确格式保存在文件中。

由于变量的数量非常多,因此请考虑所有变量来生成跟踪
可能会产生大量巨大的痕迹。 在这个问题上,我们考虑了
以下基于 3GPP 衰落传播条件的参数假设
(参见 [TS2] 的附件 B.36104):

· 用户速度:通常只考虑几个离散值,即:

· 0 和 3 公里/小时的行人场景

· 30 和 60 公里/小时的车辆场景

· 0、3、30 和 60 用于城市场景

·通道抽头:通常只考虑有限数量的通道抽头组,
例如,[TS2] 的附件 B.36104 中提到了三个模型。

· 时间粒度:我们需要每个 TTI 一个衰落值,即每 1 毫秒(因为这是
ns-3 LTE PHY 模型的时间粒度)。

· 频率粒度:我们需要每个 RB 一个衰落值(即频率
ns-3 LTE 模型使用的频谱模型的粒度)。

· 跟踪长度:模拟器包括实现的窗口机制
在 GSoC 2011 期间,它包括拾取每个窗口的跟踪窗口
长度以随机方式。

· 每用户衰落过程:用户共享相同的衰落轨迹,但每个用户都有一个
轨迹中不同的起点是随机选取的。 这个选择是为了
避免需要为每个用户提供一个衰落跟踪。

根据我们考虑的参数,下面的公式详细表示
衰落痕迹的总大小 S_{traces}:

其中 S_{sample} 是以字节为单位的样本大小(例如,在双精度的情况下为 8,
4 在浮点精度的情况下),N_{RB} 是要考虑的 RB 或 RB 集的数量,
T_{trace} 是迹线的总长度,T_{sample} 是迹线的时间分辨率
(1 ms),N_{scenarios} 是所需的衰落场景的数量(即,
不同组的通道抽头和用户速度值的组合)。 我们提供痕迹
适用于 3 种不同的场景,每个抽头配置在附录 B.2 中定义
[TS36104]:

· 行人:节点速度为 3 公里/小时。

· 车载:节点时速60公里。

· 市区:节点速度为 3 公里/小时。

因此 N_{scenarios} = 3。所有轨迹的 T_{trace} = 10 s 和 RB_{NUM} = 100。结果
在总共 24 MB 字节的跟踪中。

天线
基于 光谱物理, LTE PHY 模型支持通过 ns-3 进行天线建模
天线型号 班级。 因此,任何基于此类的模型都可以与任何 eNB 或
UE 实例。 例如,使用 余弦天线模型 与 eNB 设备相关联
允许对宏基站的一个扇区进行建模。 默认情况下, 各向同性天线模型
用于 eNB 和 UE。

PHY
概述
此 LTE 模拟器中提供的物理层模型基于
[Piro2011],具有以下修改。 该模型现在包括电池间
干扰计算和上行流量的模拟,包括数据包
传输和 CQI 生成。

子框架 结构
子帧分为控制和数据部分,如图所示 LTE的 子帧
师。.
[图片] LTE 子帧划分..UNIDENT

考虑基于RB的模拟器粒度、控制和参考
因此,必须考虑这种约束来对信令进行建模。 根据
标准[TS36211],下行控制帧从每个子帧的开头开始
并且在整个系统带宽上最多持续三个符号,其中实际
持续时间由物理控制格式指示信道 (PCFICH) 提供。 这
然后将分配信息映射到剩余资源中,直到
由 PCFICH 定义的持续时间,在所谓的物理下行链路控制信道中
(PDCCH)。 PDCCH 传输称为下行链路控制信息 (DCI) 的单个消息
来自 MAC 层,其中调度程序指示资源分配
特定用户。 PCFICH 和 PDCCH 被建模为控制传输
固定持续时间为 3/14 毫秒的帧,跨越整个可用
带宽,因为调度器不估计控制区域的大小。 这个
意味着单个传输块以固定的方式对整个控制帧进行建模
所有可用 RB 的功率(即用于 PDSCH 的功率)。 根据这个
功能,这种传输也代表了对参考信号的宝贵支持
(RS)。 这允许让每个 TTI 评估干扰场景,因为
所有 eNB 都在各自的节点上(同时)传输控制帧
可用带宽。 我们注意到,该模型不包括功率提升,因为
它没有反映所实施的信道估计模型的任何改进。

探测参考信号 (SRS) 的建模类似于下行链路控制帧。
SRS周期性地放置在整个系统中子帧的最后一个符号中
带宽。 RRC 模块已经包含一个算法,用于动态分配
根据连接到 eNB 的实际 UE 数量的函数的周期性
UE 特定程序(参见 [TS8.2] 的第 36213 节)。

MAC 频道 延迟
为了模拟实际 MAC 和 PHY 实现的延迟,PHY 模型模拟了一个
多个 TTI (1ms) 中的 MAC 到通道延迟。 数据和控制的传输
数据包延迟了这个数量。

CQI 反馈
CQI 反馈的生成根据 [FFAPI] 中的规定进行。 在
详细地,我们考虑了周期性宽带 CQI 的生成(即,单个值
被认为代表所有正在使用的 RB 的信道状态)和带内 CQI(即
表示每个 RB 的信道状态的一组值)。

要上报的 CQI 索引是先得到一个 SINR 测量值,然后
将此 SINR 测量传递给自适应调制和编码,将其映射到
CQI 指数。

在下行链路中,用于生成 CQI 反馈的 SINR 可以用两种不同的方式计算
方法:

1. 按Ctrl 方法:结合参考信号功率计算 SINR
信号(在模拟中相当于 PDCCH)和干扰
来自 PDCCH 的功率。 这种方法导致将任何相邻的 eNB 视为
干扰源,无论此 eNB 是否实际执行任何 PDSCH
传输,并且无论用于最终干扰的功率和 RB
PDSCH 传输。

2. 混合 方法:结合参考信号功率计算 SINR
信号(在模拟中相当于 PDCCH)和干扰
来自 PDSCH 的电源。 这种方法导致仅将那些
在 PDSCH 上主动传输数据的相邻 eNB,并允许
生成带内 CQI,这些 CQI 说明了不同的干扰量
RBs 根据实际干扰水平。 在没有 PDSCH 的情况下
传输由任何 eNB 执行,这种方法认为干扰是
零,即,SINR 将仅计算为信噪比。

要在这两种 CQI 生成方法之间切换, LteHelper::UsePdschForCqiGeneration
需要配置:第一种方法为false,第二种方法为true(true为
默认值):

Config::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration", BooleanValue (true));

在上行链路中,实现了两种类型的 CQI:

· 基于 SRS,由 UE 定期发送。

· 基于PUSCH,根据实际传输的数据计算。

调度程序接口包括一个属性系统调用 UlCqi过滤器 用于管理
根据 CQI 的性质过滤 CQI,具体如下:

· SRS_UL_CQI 仅用于存储基于 SRS 的 CQI。

· PUSCH_UL_CQI 用于仅存储基于 PUSCH 的 CQI。

· ALL_UL_CQI 用于存储所有接收到的 CQI。

必须指出的是, FfMac调度程序 只提供接口,这很重要
的实际调度程序实现以包含用于管理这些属性的代码
(有关此问题的更多信息,请参阅调度程序相关部分)。

干扰 型号
PHY模型基于著名的高斯干扰模型,根据该模型
将干扰信号的功率(以线性单位)相加以确定
总干扰功率。

图的时序图 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 PHY 干扰 计算
程序 显示如何处理干扰信号以计算 SINR,以及如何 SINR
然后用于生成 CQI 反馈。
[图片] PHY干扰计算过程的时序图。UNIDENT

LTE的 光谱 型号
[TS36101] 中描述了 LTE 中 eNB 和 UE 对无线电频谱的使用。 在里面
模拟器,无线电频谱使用建模如下。 让 f_c 表示 LTE Absolute
射频频道号,用于标识 100 kHz 上的载波频率
光栅; 此外,设 B 为传输带宽配置,以数量为单位
资源块。 对于模拟中使用的每一对 (f_c,B),我们定义一个对应的
SpectrumModel 使用 sec-spectrum-module 提供的功能。 模型使用
[Baldo2009] 中描述的 Spectrum 框架。 f_c 和 B 可以为每个配置
在模拟中实例化的 eNB; 因此,每个 eNB 可以使用不同的频谱模型。
每个 UE 都会自动使用它所连接的 eNB 的频谱模型。 使用
[Baldo2009] 中描述的 MultiModelSpectrumChannel,使用的 eNB 之间的干扰
适当地考虑了不同的频谱模型。 这允许模拟动态
频谱访问政策,例如频谱许可政策
在 [Ofcom2600MHz] 中讨论。

时间 PHY 误差 型号
模拟器包括数据平面的错误模型(即PDSCH和PUSCH),根据
到标准的链接到系统映射 (LSM) 技术。 选择与
OFDMA无线电传输技术的标准系统仿真方法。 谢谢
LSM 我们能够保持良好的准确性,同时限制
计算复杂度增加。 它基于单链路层的映射
通过到系统的链路级模拟器获得的性能(在我们的例子中是网络)
模拟器。 特别是链接层模拟器用于生成性能
从 PHY 层的角度来看单个链路,通常在码块错误率方面
(BLER),在特定的静态条件下。 LSM 允许更多地使用这些参数
复杂的场景,典型的系统/网络模拟器,我们有更多的链接,
干扰和“有色”信道传播现象(例如,频率选择性
衰退)。

为此,Vienna LTE 模拟器 [ViennaLteSim] 已用于解决
提取链路层性能和基于互信息的有效 SINR
(MIESM) 作为 LSM 映射函数,使用 Signet 最近发布的部分工作
帕多瓦大学小组 [PaduaPEM]。

米斯曼
具体采用的LSM方法是基于互信息的使用
度量,通常称为每编码比特的互信息(MIB 或 MMIB,当
涉及多个 MIB 的平均值)。 另一种选择将由
指数 ESM (EESM); 然而,最近的研究表明,MIESM 在
准确性方面 [LozanoCost]。
[图片] MIESM 计算程序图。UNIDENT

互信息 (MI) 取决于星座映射,可以是
通过评估符号上的 MI 和
副载波。 但是,这对于网络模拟器来说太复杂了。 因此,在我们的
已考虑在 RB 内实现平坦的信道响应; 因此
TB 的整体 MI 是通过对 TB 中使用的每个 RB 评估的 MI 进行平均计算得出的。
详细地,实现的方案如图所示 米斯曼 计算 程序
图表,我们看到模型从评估每个 RB 的 MI 值开始,
图中用 SINR 样本表示。 然后计算等效 MI
TB 基础通过平均 MI 值。 最后,必须采取进一步措施,因为
链路级模拟器以块错误率的形式返回链路的性能
(BLER) 在加性高斯白噪声 (AWGN) 通道中,其中块是代码
块 (CB) 由 Turbo 编码器独立编码/解码。 在这件事上
标准 3GPP 分割方案已用于估计实际 CB 大小
(在 [TS5.1.2] 的第 36212 节中描述)。 该方案将 TB 划分为 N_{K_-}
大小为 K_- 的块和大小为 K_+ 的 N_{K+} 个块。 因此总体 TB BLER (TBLER)
可以表示为

其中CBLER_i是根据链路级模拟器得到的CB i的BLER
CB BLER 曲线。 为了估计 CBLER_i,已实施 MI 评估
根据 [wimaxEmd] 中定义的数值近似。 此外,为了减少
计算的复杂度,近似值已转换为查找
表。 详细地,高斯累积模型已用于逼近 AWGN
具有三个参数的 BLER 曲线,可提供与标准 AWGN 的紧密拟合
性能,公式:

其中 x 是 TB 的 MI,b_{ECR} 表示“过渡中心”,c_{ECR} 是
与每个高斯累积分布的“过渡宽度”有关
有效码率 (ECR),即根据信道的实际传输速率
编码和 MCS。 为了限制我们考虑的模型的计算复杂度
只有可能的 ECR 的一个子集,事实上我们可能有 5076 个可能的 ECR
(即 27 个 MCS 和 188 个 CB 尺寸)。 在这方面,我们将 CB 大小限制为
代表值(即 40、140、160、256、512、1024、2048、4032、6144),而对于
其他的将使用近似真实的最差的(即,较小的 CB
相对于真实的可用大小值)。 这个选择与典型的一致
turbo 码的性能,其中 CB 大小对 BLER 的影响不大。
但是,需要注意的是,对于小于 1000 位的 CB 大小,效果可能是
相关(即,直到 2 dB); 因此,我们采用这种不平衡的采样间隔
在必要的地方有更高的精度。 数字证实了这种行为
介绍在 Annes 部分。

误码率 曲线
在这方面,我们重用了在 [PaduaPEM] 中获得的部分曲线。 详细来说,我们
在开发人员的支持下,将 CB 尺寸依赖性引入 CB BLER 曲线
[PaduaPEM] 和 LTE 维也纳模拟器。 事实上,发布的模块提供了
链路层性能仅针对与 MCS 相关的内容(即,具有给定的固定 ECR)。 在
详细说明每个已通过模拟活动评估的新错误率曲线
使用具有 AWGN 噪声且 CB 大小为 104 的单个链路的链路层模拟器,
140、256、512、1024、2048、4032 和 6144。这些曲线已用高斯
上面给出的累积模型公式,用于获得对应的 b_{ECR} 和
c_{ECR} 参数。

使用链路级模拟器获得的所有 MCS 的 BLER 性能绘制在
以下数字(蓝线)及其对应的高斯映射
累积分布(红色虚线)。
[图像] MCS 1、2、3 和 4 的 BLER..UNINDENT
[图像] MCS 5、6、7 和 8 的 BLER..UNINDENT
[图像] MCS 9、10、11 和 12 的 BLER..UNINDENT
[图像] MCS 13、14、15 和 16 的 BLER..UNINDENT
[图像] MCS 17、17、19 和 20 的 BLER..UNINDENT
[图像] MCS 21、22、23 和 24 的 BLER..UNINDENT
[图像] MCS 25、26、27 和 28 的 BLER..UNINDENT
[图片] MCS 29 的 BLER..UNINDENT

之路 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 误码率 曲线 in 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 ns-3 LTE的 模块
实现的模型使用最近的 LTE PHY 错误模型的 LSM 曲线
由 Signet Group [PaduaPEM] 在 ns3 社区发布并生成新的
适用于不同的 CB 尺寸。 这 LTE频谱物理学 班级负责评估 TB BLER
感谢提供的方法 LteMiError模型 班级,负责
根据每个 RB 的感知 SINR 向量评估 TB BLER、MCS 和
大小以便正确模拟 CB 中的 TB 分段。 为了得到
感知 SINR 的向量 两个实例 LtePemSinrChunk 处理器 (孩子的
LteChunk处理器 专用于评估 SINR 以获得物理错误性能)
已连接到 UE 下行链路和 eNB 上行链路 LTE频谱物理学 评估模块
PDSCH(UE侧)和ULSCH(eNB侧)的误差模型分布。

该模型可以通过设置禁用零损耗通道 Pem启用
的属性 LTE频谱物理学 类(默认情况下是活动的)。 这可以按照
到标准的ns3属性系统程序,即:

Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

通过积极争取让商标与其相匹配的域名优先注册来维护 频道 PHY 误差 型号
该模拟器包括下行链路控制信道(PCFICH 和 PDCCH)的误差模型,
而在上行链路中,它被假定为理想的无差错信道。 该模型基于
之前介绍的 MIESM 方法用于考虑频率选择性的影响
通道,因为大多数控制通道跨越整个可用带宽。

PCFICH + 数据中心信道 误差 型号
这些通道的误差分布所采用的模型是基于一个评估
在 4GPP 的 RAN3 中进行的研究,其中不同的供应商调查了
PCFICH与PDCCH联合的解调性能。 这是因为
PCFICH 是负责向 UE 传达实际维度的通道
PDCCH(跨越 1 到 3 个符号); 因此正确的解码
DCI 取决于对两者的正确解释。 在 3GPP 中有这个问题
被评估为提高单元边缘性能 [FujitsuWhitePaper],其中
由于信号劣化,相邻小区之间的干扰可能相对较高。 一个
类似的问题已经在 femto-cell 场景中出现,更一般地说,在 HetNet 中
主要检测到瓶颈的场景是 PCFICH 通道 [Bharucha2011],
如果多个 eNB 部署在同一个服务区域,则该信道可能会发生冲突
在频率上,也无法正确检测PDCCH信道。

在模拟器中,接收期间感知的 SINR 已根据
上述 MIESM 模型以评估 PCFICH 的误差分布和
PDCCH。 详细地,所有RB的SINR样本都包含在MI的评估中
与控制帧相关联,根据该值,有效 SINR (eSINR)
通过反转 MI 评估过程获得。 需要注意的是,如果发生
MIMO 传输,PCFICH 和 PDCCH 始终使用传输分集模式作为
由标准定义。 根据 eSINR 感知到的解码错误
概率可以估计为 [R4-081920] 中给出的结果的函数。 如果
发生错误,DCI 被丢弃,因此 UE 将无法接收
对应的Tbs,因此导致丢失。

多输入多输出 型号
在发射器和接收器端都使用多个天线,称为
多输入多输出 (MIMO) 是一个在文献中得到充分研究的问题
过去几年。 大部分工作集中在分析评估
不同的 MIMO 方案在容量方面可能有; 但是也有人提供
接收功率方面的增益信息 [CatreuxMIMO]。

根据上述考虑,可以得到一个更灵活的模型,考虑到
从统计的角度来看,MIMO 方案为系统带来的增益。 作为
之前重点介绍,[CatreuxMIMO] 展示了几种 MIMO 解决方案的统计增益
在天线之间没有相关性的情况下,关于 SISO 之一。 在工作中
增益表示为输出 SINR 的累积分布函数 (CDF)
关注 SISO、MIMO-Alamouti、MIMO-MMSE、MIMO-OSIC-MMSE 和 MIMO-ZF 方案。
详细说明结果,输出 SINR 分布可以近似为
作为所考虑方案的函数,具有不同均值和方差的对数正态。
然而,方差并没有太大的不同,它们大致等于
SISO 模式的阴影部分已经包含
建筑物传播损失模型, 详细地:

· SISO: = 13.5 和 ma = 20 [dB]。

· MIMO-Alamouti:= 17.7 和 ma = 11.1 [dB]。

· MIMO-MMSE:= 10.7 和 ma = 16.6 [dB]。

· MIMO-OSIC-MMSE:= 12.6 和 ma = 15.5 [dB]。

· MIMO-ZF:= 10.3 和 ma = 12.6 [dB]。

因此,PHY 层将 MIMO 模型实现为接收器感知的增益
当使用 MIMO 方案时,相对于使用 SISO 获得的方案。 我们注意到,这些
增益指的是 MIMO 中天线之间没有相关性的情况
方案; 因此,不要对由于路径相关性导致的退化进行建模。

UE PHY 测量 型号
根据 [TS36214],UE 必须报告 eNB 的一组测量值,
设备能够感知:参考信号接收功率 (RSRP) 和
参考信号接收质量(RSRQ)。 前者是接收功率的量度
一个特定的 eNB,而后者还包括信道干扰和热噪声。
UE 必须与物理小区标识 (PCI) 一起报告测量结果
细胞。 RSRP 和 RSRQ 测量都是在接收 RS 期间执行的,
而 PCI 是通过主同步信号 (PSS) 获得的。 PSS 已发送
由 eNB 每 5 个子帧,并在子帧 1 和 6 中详细说明。在实际系统中,只有
504 个不同的 PCI 可用,因此可能会出现两个附近的 eNB 使用
相同的 PCI; 然而,在模拟器中,我们使用模拟元数据对 PCI 进行建模,并且我们允许
多达 65535 个不同的 PCI,从而避免 PCI 冲突,前提是少于 65535
在相同的场景中模拟 eNB。

根据 [TS36133] 第 9.1.4 和 9.1.7 节,物理层以 dBm 报告 RSRP
而 RSRQ 以 dB 为单位。 RSRP 和 RSRQ 的值通过
C-PHY SAP(通过 Ue测量参数 struct) 每 200 毫秒定义一次
[TS36331]。 第 1 层过滤是通过对收集的所有测量值进行平均来执行的
在最后一个窗口时段。 可根据研究调整报告周期
目的是通过 LteUePhy::UeMeasurementsFilterPeriod 属性。

考虑到 PHY 的假设,RSRP 和 RSRQ 的公式可以简化
层表示通道在 RB 内是平坦的,精度最高。 事实上,这
意味着 RB 内的所有 RE 具有相同的功率,因此:

其中 P(k,m) 表示 RB k 内 RE m 的信号功率,如观察到的那样
之前,在同一个 RB 内是常数,等于 P(k),M 是承载的 RE 的数量
一个RB中的RS,K是RB的个数。 需要注意的是,P(k),通常所有
本节中定义的功率是在模拟器中从 RB 的 PSD 获得的
(由 LteInterferencePowerChunk处理器), 详细地:

其中 PSD_{RB}(k) 是 RB k 的功率谱密度,180000 是以 Hz 为单位的带宽
RB 和 12 是 OFDM 符号中每个 RB 的 RE 数。 同样,对于 RSSI,我们
它们在许多情况下都能提供类似的结果。

其中 S 是 RB 中携带 RS 的 OFDM 符号的数量,R 是 RE 的数量
在 OFDM 符号中携带 RS(固定为 2),而 P(k,s,r), I(k,s,r) 和 N(k,s,r)
分别表示服务小区的感知功率、干扰功率和
符号 s 中 RE r 的噪声功率。 对于 RSRP,RB 内的测量值是
根据 PHY 模型,彼此之间总是相等; 因此 P(k,s,r) = P(k),
I(k,s,r) = I(k) 和 N(k,s,r) = N(k),这意味着 RSSI 可以计算为:

考虑到 PHY 接收链实现的约束,并且为了
保持较低的计算复杂度,只有RSRP可以直接得到
所有的细胞。 这是因为 LTE频谱物理学 旨在评估
干扰仅与服务 eNB 的信号有关。 这意味着 PHY
层被优化用于以服务 eNB 作为管理功率信号信息
参考。 然而,相邻小区 i 的 RSRP 和 RSRQ 可以通过当前的
服务小区 j 的可用信息如下所述:

其中 RSRP_i 是相邻小区 i 的 RSRP,P_i(k) 是任何 RE 感知的功率
在RB k内,K为RB总数,RSSI_i为邻区i的RSSI
当 UE 连接到小区 j 时(因为它是所有接收功率的总和,
与 RSSI_j 一致,I_j(k) 是 UE 在 RB k 的任何 RE 中感知到的总干扰
当连接到单元格 i 时(由 LteInterferencePowerChunk处理器), P_j(k) 是
RB k 和 N 的任何 RE 中小区 j 的感知功率是功率噪声谱
任何 RE 中的密度。 如果评估的 RSRQ 是,则该样本被认为是有效的
上方的 LtelEPhy::RsrqUeMeasThreshold 属性。

自动重传
所实施的 HARQ 方案是基于增量冗余 (IR) 解决方案相结合的
具有多个停止和等待过程,以实现连续的数据流。 详细来说,
采用的解决方案是 结合 混合 IR 增量 冗余 (也叫
IR Type II),这意味着重传仅包含新信息方面
到以前的。 HARQ的资​​源分配算法已经实现
在各自的调度程序类中(即, RrFfMac调度程序PfFfMac调度程序,
有关更多信息,请参阅他们的相应部分),而
HARQ 已在 LTE频谱物理学LTEHarqPhy 课程将是
本节详述。

根据标准,UL 重传是同步的,因此是
在原始传输后 7 ms 分配。 另一方面,对于 DL,它们是
异步,因此可以从 7 ms 开始以更灵活的方式分配,并且
这是特定调度程序实现的问题。 HARQ 处理行为是
如图所示:参考:fig-harq 进程方案.

在 MAC 层,驻留在调度器中的 HARQ 实体负责控制
用于生成新数据包和管理重传的 8 个 HARQ 进程
DL 和 UL。 调度器从 eNB 和 UE PHY 层收集 HARQ 反馈
(分别用于 UL 和 DL 连接)通过 FF API 原语
计划触发请求计划触发请求. 根据 HARQ 反馈和 RLC
缓冲状态,调度程序生成一组 DCI,包括重传
HARQ 块接收到错误的和新的传输,一般来说,优先于
以前的。 在这个问题上,调度器必须考虑一个约束,当
为 HARQ 重传分配资源时,它必须使用相同的调制阶数
第一次传输尝试(即,[0..9] 中 MCS 的 QPSK,[16..10] 中 MCS 的 16QAM
和 [64..17] 中用于 MCS 的 28QAM)。 此限制来自速率的规范
3GPP 标准 [TS36212] 中的匹配器,其中算法固定调制阶数
生成冗余版本的不同块。

PHY 错误模型模型(即, LteMiError模型 之前已经介绍过的课程)有
根据 [wimaxEmd] 扩展以考虑 IR HARQ,其中参数
重传情况下 MIESM 映射的 AWGN 曲线映射由下式给出:

其中 X 是原始信息位数,C_i 是编码位数,M_i 是
在 q 次重传总数上接收到的每个 HARQ 块的互信息。
因此,为了能够用错误模型返回错误概率
在模拟器中实现评估 R_{eff} 和 MI_{I eff} 并返回值
具有最接近较低速率的相同调制的 ECR 的错误概率
R_{eff}。 为了考虑 HARQ 重传的影响,一组新的曲线
已根据用于原始 MCS 的标准进行了集成。 新曲线
旨在涵盖使用调制的最保守 MCS 的情况
这意味着 R_{eff} 的生成低于标准 MCS 之一。 在这
重要的是,已针对 1 和 2 评估了 3、10 和 17 次重传的曲线。对于
MCS 0 我们只考虑了第一次重传,因为生成的码率已经
非常保守(即 0.04)并返回对接收足够稳健的错误率
(即,BLER 的下降以-18 dB 为中心)。 需要注意的是,
假设第一个 TB 传输的大小包含所有信息位
被编码; 因此 X 等于 HARQ 进程发送的第一个 TB 的大小。 这
模型假设码字中最终存在的奇偶校验位已经
在链路层曲线中考虑。 这意味着只要最小 R_{eff} 是
达到模型不包括由于传输进一步平价而获得的增益
位。
[图片] HARQ 处理 LTE.UNIDENT 中的行为

HARQ 中专门用于管理 HARQ 块解码的部分已
在实施 LTEHarqPhyLTE频谱物理学 类。 前者负责
维护每个活动进程的 HARQ 信息。 后者与
LteMiError模型 用于评估接收到的块的正确性的类,包括
负责与调度程序中的 HARQ 实体通信的消息传递算法
解码的结果。 这些消息被封装在
dlInfoListElement 对于深度学习和 ulInfoList元素 用于 UL 并通过 PUCCH 和
根据他们的假设,PHICH 分别具有理想的无误差模型
执行。 HARQ和LTE协议栈迭代示意图
如图所示:参考:fig-harq-架构.

最后,HARQ 引擎在 MAC 和 PHY 层始终处于活动状态; 但是,如果
调度程序不支持 HARQ 系统将继续使用 HARQ
功能被禁止(即,缓冲区已填充但未使用)。 这个实现
特性提供了与在 HARQ 之前实现的调度程序的向后兼容性
积分。
[图片] HARQ 和 LTE 协议栈之间的交互。UNIINDENT

MAC
更多相关资源 分配 型号
我们现在简要描述在 LTE 中如何处理资源分配,阐明它是如何处理的
在模拟器中建模。 调度器负责生成特定的结构
被称为 时间 通过积极争取让商标与其相匹配的域名优先注册来维护 迹象 (DCI) 然后由 eNB 的 PHY 发送到
连接的 UE,以便通知它们每个子帧上的资源分配
基础。 在下行链路方向执行此操作时,调度程序必须填充一些特定的
DCI 结构的所有信息字段,例如:调制和编码
要使用的方案 (MCS)、MAC 传输块 (TB) 大小和分配位图
它标识哪些 RB 将包含 eNB 发送给每个用户的数据。

对于资源到物理 RB 的映射,我们采用 本地化 制图 方法(见
[Sesia2009],第 9.2.2.1 节); 因此在给定的子帧中,每个 RB 总是分配给
两个插槽中的同一用户。 分配位图可以用不同的格式编码; 在
在这个实现中,我们考虑了 分配 类型 0 在 [TS36213] 中定义,根据
RB被分组到不同大小的资源块组(RBG)中
作为正在使用的传输带宽配置的函数。

对于某些带宽值,并非所有 RB 都可用,因为组大小不是
群的公约数。 例如,当带宽等于
25 个 RB,导致 RBG 大小为 2 个 RB,因此 1 个 RB 不会导致
可寻址的。 在上行链路中,DCI 的格式不同,因为只有相邻的 RB 可以
由于 SC-FDMA 调制而被使用。 因此,所有 RB 都可以通过
eNB 与带宽配置无关。

自适应 调制 编码
该模拟器提供了两种自适应调制和编码 (AMC) 模型:一种基于
GSoC 模型 [Piro2011] 和一个基于物理误差模型(在
以下部分)。

前一个模型是 [Piro2011] 中描述的模型的修改版本,而后者反过来
灵感来自 [Seo2004]。 我们的版本如下所述。 让我表示
普通用户,让 mma_i 为其 SINR。 我们得到用户 i 的频谱效率 \ta_i
使用以下等式:

[R1-081483] 中描述的过程用于获得相应的 MCS 方案。 这
频谱效率根据信道质量指标 (CQI) 进行量化,四舍五入为
最低值,并映射到相应的 MCS 方案。

最后,我们注意到 [R1-081483] 中的 MCS 索引之间存在一些差异
并且由标准表明:[TS36213]表7.1.7.1-1表示MCS索引
从 0 到 31,0 似乎是有效的 MCS 方案(TB 大小不是 0),但在
[R1-081483] 第一个有用的 MCS 索引是 1。因此要获得预期的值
标准我们需要从 [R1-1] 中报告的索引中减去 081483。

替代模型基于为此模拟器开发的物理误差模型
并在以下小节中解释。 该方案能够适应 MCS 选择
根据具体的 CQI 报告来确定实际的 PHY 层性能。 根据
根据它们的定义,当单个 PDSCH TB 具有调制
[TS7.2.3]表1-36213中该CQI索引对应的编码方案和码率
可以以小于 0.1 的错误概率接收。 在宽带 CQI 的情况下,
参考 TB 包括所有可用的 RBG,以便根据
全部可用资源; 而对于子带 CQI,参考 TB 的大小与 RBG 相同。

Transport / 运输 阻止 模型
模拟器提供的 MAC 传输块 (TB) 模型简化为
符合 3GPP 规范。 特别是一个模拟器特定的类
(PacketBurst) 用于聚合 MAC SDU,以实现模拟器的等效
TB,没有相应的实现复杂性。 多路复用
使用专用数据包执行往返 RLC 层的不同逻辑信道
标签(LteRadioBearerTag),它执行的功能部分等同于
由 3GPP 指定的 MAC 报头。

- 毫微微论坛 MAC 调度 接口
本节介绍 ns-3 特定版本的 LTE MAC 调度程序接口
FemtoForum [FFAPI] 发布的规范。

我们实现了 ns-3 特定版本的 FemtoForum MAC 调度程序接口 [FFAPI]
作为一组 C++ 抽象类; 特别是,每个原语都被翻译成 C++
给定类的方法。 期限 实施 这里使用的含义相同
在 [FFAPI] 中,因此指的是翻译逻辑接口的过程
特定编程语言的规范。 [FFAPI] 中的原语被分组
分为两组:处理调度程序配置的 CSCHED 原语和
SCHED原语,处理调度程序的执行。 此外,[FFAPI]
定义了两种不同类型的原语:REQ 类型的原语从 MAC 到
调度器,IND/CNF 类型的从调度器到 MAC。 翻译这些
特性到 C++ 中,我们定义了以下实现 Service 的抽象类
用于发布原语的接入点 (SAP):

· 这 FfMacSchedSapProvider 类定义了与 SCHED 对应的所有 C++ 方法
REQ 类型的原语;

· 这 FfMacSchedSap用户 类定义了与 SCHED 对应的所有 C++ 方法
CNF/IND 类型的原语;

· 这 FfMacCschedSapProvider 类定义了所有对应的 C++ 方法
REQ 类型的 CSCHED 原语;

· 这 FfMacCschedSap用户 类定义了与 CSCHED 对应的所有 C++ 方法
CNF/IND 类型的原语;

MAC调度器接口涉及3个块:控制块,子帧块
和调度程序块。 这些块中的每一个都提供了 MAC 调度程序接口的一部分。
下图显示了我们定义的块和 SAP 之间的关系
MAC调度程序接口的实现。
[图片]

除上述原则外,还采取了以下设计选择:

· MAC调度器接口类的定义遵循命名约定
ns-3 编码风格。 特别是,我们遵循 CamelCase 约定
原始名称。 例如,原语 CSCHED_CELL_CONFIG_REQ 被翻译成
CschedCellConfigReq ,在 ns-3 码。

· 原始参数遵循相同的命名约定。 作为
原始参数是类的成员变量,它们也带有前缀
m_.

· 关于在数据结构中使用向量和列表,我们注意到 [FFAPI] 是
几乎是面向 C 的 API。 但是,考虑到 ns-3 中使用了 C++,并且
不鼓励使用 C 数组,我们使用 STL 向量 (性病::矢量) 为了
MAC调度程序接口的实现,而不是使用C数组作为
[FFAPI] 的编写方式隐含地建议。

· 在 C++ 中,不允许有构造函数和析构函数的成员 工会. 因此所有
那些数据结构被称为 工会 在 [FFAPI] 中被定义为
结构 在我们的代码中。

下图显示了 MAC 调度器接口如何在 eNB 中使用。
[图片]

CSCHED SAP 和 SCHED SAP 的用户侧都在 eNB MAC 内实现,
即,在文件中 lte-enb-mac.cc. eNB MAC 可以与不同的调度器一起使用
无需修改即可实现。 同一张图还举例说明了
Round Robin Scheduler 实现:与 eNB 的 MAC 交互,Round Robin
调度程序实现了 SCHED SAP 和 CSCHED SAP 接口的 Provider 端。 一个
类似的方法也可用于实现其他调度程序。 每个的描述
作为 LTE 模拟模块的一部分,我们提供的调度器实现是
在以下小节中提供。

圆形 知更鸟 (RR) 调度
Round Robin (RR) 调度器可能是文献中发现的最简单的调度器。
它通过在活动流之间划分可用资源来工作,即那些逻辑流
具有非空 RLC 队列的通道。 如果 RBG 的数量大于
活动流的数量,所有流可以分配在同一个子帧中。 否则,如果
活动流的数量大于 RBG 的数量,不是所有的流都可以
在给定的子帧中调度; 然后,在下一个子帧中,分配将从
最后一个未分配的流。 为每个用户采用的 MCS 已完成
根据接收到的宽带 CQI。

对于 HARQ,RR 实现了非自适应版本,这意味着在
分配重传尝试 RR 使用相同的分配配置
原始块,这意味着保持相同的 RBG 和 MCS。 分配给的 UE
新数据的传输不考虑 HARQ 重传,以防它们有
在同一 TTI 中可用的传输机会。 最后,可以使用以下命令禁用 HARQ
ns3 属性系统,用于保持与旧测试用例和代码的向后兼容性,
详细:

Config::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled", BooleanValue (false));

调度器根据上行链路 CQI 的性质对上行链路 CQI 进行过滤
UlCqi过滤器 属性,详细:

· SRS_UL_CQI:内部属性中仅存储基于 SRS 的 CQI。

· PUSCH_UL_CQI:内部属性中仅存储基于PUSCH的CQI。

· ALL_UL_CQI:所有 CQI 存储在同一个内部属性中(即最后一个 CQI
收到的存储独立于其性质)。

成比例的 展会 (FP) 调度
Proportional Fair (PF) 调度器 [Sesia2009] 通过调度用户何时使用
瞬时信道质量相对于其自身的平均信道条件而言是高的
时间。 令 i,j 表示一般用户; 令 t 为子帧索引,k 为资源
块索引; 让 M_{i,k}(t) 成为用户 i 在资源块 k 上可用的 MCS,根据什么
由 AMC 模型报告(见 自适应 调制 编码); 最后,令 S(M, B) 为
在 [TS36213] 中定义的 TB 大小(以比特为单位),用于资源数量为 B 的情况
块被使用。 资源块组上用户 i 的可实现速率 R_{i}(k,t)(bit/s)
子帧 t 处的 k 定义为

其中 au 是 TTI 持续时间。 在每个子帧 t 的开始,每个 RBG 被分配给一个
某个用户。 详细地说,在时间 t 分配了 RBG k 的索引 144}_{k}(t) 是
确定为

其中 T_{j}(t) 是用户 j 感知到的过去吞吐量性能。 根据
上述调度算法,一个用户可以被分配到不同的RBG,可以是
是否相邻,取决于通道的当前状况和过去
吞吐量性能 T_{j}(t)。 后者在子帧 t 结束时确定
使用以下指数移动平均方法:

其中 lpha 是指数移动的时间常数(以子帧数计)
平均,用户 i 在子帧 t 中实现的实际吞吐量为 384s。 360是
按照以下程序进行测量。 首先我们确定 MCS 840 j:

然后我们确定总数 936 j:

在哪里

对于 HARQ,PF 实现了非自适应版本,这意味着在
分配重传尝试调度程序使用相同的分配
原始块的配置,这意味着保持相同的 RBG 和 MCS。 用户设备
分配给 HARQ 重传的不考虑用于新的传输
数据,以防它们在同一 TTI 中有可用的传输机会。 最后,HARQ
可以使用 ns3 属性系统禁用以保持与旧的向后兼容性
测试用例和代码,详细:

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

最大 生产能力 (MT) 调度
最大吞吐量 (MT) 调度程序 [FCapo2012] 旨在最大化整体吞吐量
的 eNB。 它将每个 RB 分配给能够达到最大可实现速率的用户
当前的 TTI。 目前,NS-3中的MT调度器有两个版本:频域
(FDMT) 和时域 (TDMT)。 在 FDMT 中,每个 TTI,MAC 调度器都会为 UE 分配 RBG
由子带 CQI 计算的最高可实现速率。 在 TDMT 中,每个 TTI、MAC
调度器选择一个由宽带 CQI 计算的具有最高可实现速率的 UE。
然后 MAC 调度器在当前 TTI 中将所有 RBG 分配给这个 UE。 的计算
FDMT 和 TDMT 中的可实现速率与 PF 中的相同。 令 i,j 表示泛型
用户; 设t为子帧索引,k为资源块索引; 让 M_{i,k}(t) 为
根据 AMC 模型报告的内容,用户 i 在资源块 k 上可以使用的 MCS(参见
自适应 调制 编码); 最后,令 S(M, B) 为 TB 大小(以位为单位),如
[TS36213] 用于使用 B 个资源块的情况。 可达到的比率
用户 i 在子帧 t 的资源块 k 上的 R_{i}(k,t)(bit/s)定义为

其中 au 是 TTI 持续时间。 在每个子帧 t 的开始,每个 RB 被分配给一个
某个用户。 详细地说,在时间 t 分配了 RB k 的索引 144}_{k}(t) 是
确定为

当有多个 UE 具有相同的可实现速率时,当前的实现总是
选择在脚本中创建的第一个 UE。 虽然 MT 可以最大化细胞吞吐量,但它
不能为信道条件差的 UE 提供公平性。

生产能力 一般 (电讯报) 调度
吞吐量到平均 (TTA) 调度程序 [FCapo2012] 可以被认为是一个中间
MT和PF之间。 TTA 中使用的度量计算如下:

这里,R_{i}(k,t) in bit/s 表示用户 i 在资源块 k 上可达到的速率
子帧 t。 计算方法已在 MT 和 PF 中显示。 同时,R_{i}(t) 在
bit/s 代表 i 在子帧 t 的可实现速率。 这两者的区别
可实现的费率是如何获得 MCS。 对于 R_{i}(k,t),MCS 由子带 CQI 计算,而
R_{i}(t) 由宽带 CQI 计算得出。 TTA调度器只能在频率上实现
域(FD),因为特定 RBG 的可实现速率仅与 FD 有关
调度。

一般 生产能力 调度
盲平均吞吐量调度程序 [FCapo2012] 旨在为所有
eNB 下的 UE。 TTA 中使用的度量计算如下:

其中 T_{j}(t) 是用户 j 感知到的过去吞吐量性能,可以是
在 PF 调度器中通过相同的方法计算。 时域盲平均吞吐量
(TD-BET),调度器选择具有最大优先级度量的UE并分配所有RBG
到这个 UE。 另一方面,在频域盲平均吞吐量(FD-BET)中,
每个 TTI,调度器首先选择一个过去平均吞吐量最低的 UE(最大
优先级指标)。 然后调度器分配一个RBG给这个UE,它计算期望
该 UE 的吞吐量,并使用它与过去的平均吞吐量 T_{j}(t) 进行比较
其他 UE。 调度器继续为这个 UE 分配 RBG,直到它预期的
吞吐量不是所有 UE 过去平均吞吐量 T_{j}(t) 中最小的一个。 然后
调度器将使用相同的方式为过去最低的新 UE 分配 RBG
平均吞吐量 T_{j}(t),直到所有 RBG 都分配给 UE。 这背后的原理
就是,在每个 TTI 中,调度器都尽最大努力在
所有 UE。

Token 银行 展会 队列 调度
Token Bank Fair Queue (TBFQ) 是一个 QoS 感知调度器,它源自漏桶
机制。 在 TBFQ 中,用户 i 的流量由以下参数表征:

· t_{i}:数据包到达率(字节/秒)

· r_{i}:令牌生成速率(字节/秒)

· p_{i}:令牌池大小(字节)

· E_{i}: 记录借用或给予token的token数量的计数器
按流量 i 银行; E_{i} 可以小于零

每个 K 字节数据消耗 k 个令牌。 此外,TBFQ 维护一个共享令牌库 (B),以便
平衡不同流之间的流量。 如果令牌生成率 r_{i} 大于
数据包到达率 t_{i},然后将令牌池溢出的令牌添加到令牌中
银行,并且 E_{i} 增加了相同的数量。 否则,流程 i 需要退出
基于优先级度量 frac{E_{i}}{r_{i}} 来自令牌库的令牌,并且 E_{i} 是
减少。 显然,用户在代币银行上贡献的越多,对代币银行的优先级越高
借代币; 另一方面,用户从银行借入的代币越多,获得的代币越少
优先继续提取代币。 因此,如果多个用户拥有
相同的代币生成率、流量率和代币池大小,用户遭受的损失更大
干扰有更多机会从银行借到代币。 此外,TBFQ 可以警察
通过设置令牌生成速率来限制吞吐量。 此外,
TBFQ 还为每个流维护以下三个参数:

· 债务限额 d_{i}:如果 E_{i} 低于此阈值,用户 i 无法进一步借入代币
从银行。 这是为了防止恶意 UE 借用过多的代币。

· 信用额度c_{i}:UE i 一次可以从银行借入的最大代币数量
时间。

· 信用阈值 C:一旦 E_{i} 达到债务限额,UE i 必须将 C 代币存入银行
为了进一步从银行借到代币。

NS-3中的LTE有两个版本的TBFQ调度器:频域TBFQ(FD-TBFQ)和时间
域 TBFQ (TD-TBFQ)。 在 FD-TBFQ 中,调度器总是选择具有最高度量的 UE,并且
分配具有最高子带 CQI 的 RBG,直到 UE 的 RLC 缓冲区内没有数据包
或分配所有 RBG [FABokhari2009]。 在 TD-TBFQ 中,选择 UE 最大
度量,它通过使用宽带 CQI [WKWong2004] 将所有 RBG 分配给该 UE。

优先 选择 调度
优先级集调度器 (PSS) 是一种 QoS 感知调度器,它结合了时域 (TD) 和
频域 (FD) 数据包调度操作集成到一个调度程序中 [GMonghal2008]。 它
通过指定的目标比特率 (TBR) 控制 UE 之间的公平性。

在 TD scheduler 部分,PSS 首先选择 RLC 缓冲区非空的 UE,然后划分它们
根据 TBR 分为两组:

· set 1:过去平均吞吐量小于TBR的UE; TD调度器计算
他们在盲等吞吐量 (BET) 样式中的优先级指标:

· set 2:过去平均吞吐量大于(或等于)TBR的UE; TD调度器
以比例公平 (PF) 方式计算它们的优先级度量:

属于 set 1 的 UE 比 set 2 中的 UE 具有更高的优先级。然后 PSS 将选择
N_{mux} 个 UE 在两组中具有最高度量,并将这些 UE 转发到 FD 调度器。 在 PSS 中,
FD 调度器将 RBG k 分配给 UE n,使所选度量最大化。 两个 PF 调度器
在 PF 调度程序中使用:

· 预定的比例公平(PFsch)

· 载波对平均值的干扰 (CoIta)

其中 Tsch_{j}(t) 与用户 j 感知的过去吞吐量性能相似,其中
区别在于它仅在实际服务第 i 个用户时才更新。 CoI[j,k] 是一个
UE j 的 RBG k 上的 SINR 估计。 PFsch 和 CoIta 都用于解耦 FD
来自 TD 调度程序的指标。 此外,PSS FD 调度器还提供了一个权重度量 W[n]
用于在 UE 数量较少的情况下帮助控制公平性。

其中 T_{j}(t) 是用户 j 感知到的过去吞吐量性能。 因此,在
RBG k,FD调度器选择频率乘积最大的UE j
权重 W[n] 的域度量 (Msch, MCoI)。 该策略将保证
较低质量的 UE 倾向于 TBR。

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

调度器根据上行链路 CQI 的性质对上行链路 CQI 进行过滤
UlCqi过滤器 属性,详细:

· SRS_UL_CQI:内部属性中仅存储基于 SRS 的 CQI。

· PUSCH_UL_CQI:内部属性中仅存储基于PUSCH的CQI。

· ALL_UL_CQI:所有 CQI 存储在同一个内部属性中(即最后一个 CQI
收到的存储独立于其性质)。

频道 服务质量 知道的 调度
Channel and QoS Aware (CQA) Scheduler [Bbojovic2014] 是一种 LTE MAC 下行链路调度
考虑行首 (HOL) 延迟、GBR 参数和通道的算法
不同子带的质量。 CQA 调度器基于联合 TD 和 FD 调度。

在 TD(在每个 TTI)中,CQA 调度程序按优先级对用户进行分组。 的目的
分组是强制FD调度首先考虑具有最高HOL的流
延迟。 用户 j=1,...,N 的分组度量 m_{td} 定义如下:

其中d_{hol}^{j}(t)是流j的HOL延迟的当前值,g是一个分组
确定组粒度的参数,即流的数量
将在 FD 调度迭代中考虑。

TD迭代中选择的流组转发给FD调度
从具有最高 m_{td} 度量值的流开始,直到所有 RBG
在相应的 TTI 中分配。 在 FD 中,对于每个 RBG k=1,...,K,CQA 调度器
将当前 RBG 分配给用户 j,该用户 j 具有我们的 FD 度量的最大值
通过以下方式定义:

其中 m_{GBR}^j(t) 计算如下:

其中 GBR^j 是流 j 的 EPS 承载中指定的比特率, rie R j ( ) shps
用移动平均值计算,r^{j}(t) 是在时间 t 实现的吞吐量,
并且 lpha 是一个系数,使得 0 lpha ..sp 对于 m_{ca}^{(k,j)}(t) 我们考虑两个
不同的指标:m_{pf}^{(k,j)}(t) 和 m_{ff}^{(k,j)}(t)。 m_{pf} 是比例
公平指标定义如下:

其中 R_e^{(k,j)}(t) 是用户 j 在 RBG k 上的估计可实现吞吐量
由映射信道的自适应调制和编码 (AMC) 方案计算得出
质量指示符 (CQI) 值以比特为单位的传输块大小。

我们考虑的另一个频道感知度量是 m_{ff},它在
[GMonghal2008] 它表示用户在 RBG k 上的频率选择性衰落增益
j 并按以下方式计算:

其中 CQI^{(k,j)}(t) 是用户 j 最后报告的第 k 个 RBG 的 CQI 值。

用户可以通过设置属性来选择是使用m_{pf}还是m_{ff}
ns3::CqaFfMacScheduler::CqaMetric 分别到 “CqaPf” or “CqaF”.

随机 Access
LTE模型包括基于一些简化的随机接入过程模型
假设,下面对每个消息和信号进行详细说明
在规范 [TS36321] 中描述。

· 随机 Access (青蛙) 前言:在真正的 LTE 系统中,这对应于 Zadoff-Chu
(ZC) 序列使用几种可用格式之一,并在 PRACH 时隙中发送
原则上可以与 PUSCH 重叠。 PRACH 配置索引 14 是
假设,即可以在任何系统帧号和子帧号上发送前导码。
RA 前导码使用 LteControlMessage 类建模,即作为理想的
不消耗任何无线电资源的消息。 序言的碰撞
同一小区中多个 UE 的传输使用协议建模
干扰模型,即,每当两个或多个相同的前导码在
在相同 TTI 的相同小区,这些相同的前导码中的任何一个都不会被接收到
基站。 除了这个碰撞模型,没有错误模型与
接收 RA 前导。

· 随机 Access 响应 (压缩包):在真正的 LTE 系统中,这是一个特殊的 MAC PDU
DL-SCH。 由于 MAC 控制元素没有在模拟器中准确建模
(只有 RLC 及以上的 PDU 是),RAR 被建模为一个 LteControlMessage
不消耗任何无线电资源。 尽管如此,在 RA 过程中,LteEnbMac 仍将
使用 FF MAC 向调度程序请求为 RAR 分配资源
调度程序原语 SCHED_DL_RACH_INFO_REQ。 因此,增强的调度程序
实施(目前不可用)可以为
RAR,从而对无线电资源的消耗进行建模以传输
RAR。

· 留言信息 3:在实际 LTE 系统中,这是通过指定资源发送的 RLC TM SDU
在 RAR 中的 UL 授权中。 在模拟器中,这被建模为真实的 RLC TM RLC
其 UL 资源由调度程序在调用时分配的 PDU
SCHED_DL_RACH_INFO_REQ。

· 争夺 分辨率 (CR):在实际的LTE系统中,需要CR阶段来解决
两个或多个 UE 在同一个 TTI 中发送同一个 RA 前导码的情况,并且 eNB 是
尽管发生冲突,仍能够检测到此前导码。 由于本次活动不
由于用于接收 RA 前导码的协议干扰模型而发生,
CR 阶段未在模拟器中建模,即 CR MAC CE 从未由
eNB 和 UE 在收到 RAR 时认为 RA 成功。 作为一个
因此,传输 CR MAC CE 所消耗的无线资源为
没有建模。

数字 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基于竞争 MAC 随机 Access 程序序列
图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 非基于竞争的 MAC 随机 Access 程序 显示顺序
基于竞争和非基于竞争的 MAC 随机接入示意图
过程,突出 MAC 和其他实体之间的交互。
[图片] 基于竞争的 MAC 随机访问过程的序列图。 UNINDENT
[image] 基于非竞争的 MAC 随机接入的时序图
程序.UNIDENT

RLC
概述
RLC 实体在 3GPP 技术规范 [TS36322] 中规定,包括
三种不同类型的 RLC:透明模式 (TM)、未确认模式 (UM) 和
确认模式 (AM)。 模拟器包括每个实体的一个模型

RLC 实体为上层 PDCP 层和 MAC 提供 RLC 服务接口
到较低 MAC 层的服务接口。 RLC 实体使用 PDCP 服务接口
来自上层 PDCP 层和来自下层 MAC 层的 MAC 服务接口。

数字 实施 型号 of 聚二氯乙烯, RLC MAC 实体 SAP 显示
RLC实体的实现模型及其与所有其他实体的关系
和协议栈中的服务。
[图片] PDCP、RLC 和 MAC 实体和 SAPs.UNIDENT 的实现模型

服务 接口
RLC 服务 接口
RLC服务接口分为两部分:

· 这 RlcSap提供者 部分由 RLC 层提供,由上层 PDCP 层使用


· 这 RlcSap用户 部分由上 PDCP 层提供并由 RLC 层使用。

UM 和 AM RLC 实体都向上层提供相同的 RLC 服务接口
PDCP层。

RLC 服务 基元
以下列表指定 RLC 服务提供哪些服务原语
接口:

· RlcSapProvider::TransmitPdcpPdu

· PDCP 实体使用该原语将 PDCP PDU 发送到较低的 RLC 实体
在发射器对等体中

· RlcSapUser::ReceivePdcpPdu

· RLC实体使用这个原语发送一个PDCP PDU给上层PDCP实体
在接收方对等方

MAC 服务 接口
MAC服务接口分为两部分:

· 这 MacSap提供商 部分由 MAC 层提供,由上层 RLC 层使用


· 这 MacSap用户 部分由上层 RLC 层提供并由 MAC 层使用。

MAC 服务 基元
以下列表指定 MAC 服务提供哪些服务原语
接口:

· MacSapProvider::TransmitPdu

· RLC 实体使用这个原语发送一个 RLC PDU 到较低的 MAC 实体
发射器对等体

· MacSapProvider::ReportBufferStatus

· RLC 实体使用该原语向 MAC 实体报告待处理的大小
发送器对等体中的缓冲区

· MacSapUser::NotifyTxOpportunity

· MAC实体使用这个原语通知RLC实体一个传输
机遇中发展

· MacSapUser::ReceivePdu

· MAC 实体使用该原语向上层 RLC 实体发送 RLC PDU
在接收方对等方

AM RLC
解释了确认模式 (AM) RLC 实体中的数据传输处理
在 [TS5.1.3] 的第 36322 节中。 在本节中,我们将描述
RLC 实体的实现。

缓冲区 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 发送 操作
我们对 AM RLC 实体的实现为传输操作维护了 3 个缓冲区:

· 传输 缓冲区:是RLC SDU队列。 当 AM RLC 实体收到一个 SDU
在来自上层 PDCP 实体的 TransmitPdcpPdu 服务原语中,它将其入队
在传输缓冲区。 我们对 RLC 缓冲区大小进行了限制,并且只是默默地
当缓冲区已满时丢弃 SDU。

· 发送 的PDU 缓冲区:它是发送的 RLC PDU 队列
ACK/NACK 尚未收到。 当 AM RLC 实体向 MAC 发送 PDU
实体,它还将传输的 PDU 的副本放在传输的 PDU 缓冲区中。

· 重播 缓冲区:它是 RLC PDU 的队列,被考虑用于
重传(即,它们已被 NACKed)。 AM RLC 实体将此 PDU 移动到
重传缓冲区,当它从已传输缓冲区重传 PDU 时。

发送 操作 in 下行
下面的序列图显示了不同实体之间的交互(RRC,
下行链路中eNB的PDCP、AM RLC、MAC和MAC调度器)执行数据
通信。

数字 序列 图表 of data PDU 传输 in 下行 显示上层如何
发送数据 PDU 以及不同实体/服务如何处理数据流
LTE 协议栈。
[图片] 下行数据PDU传输时序图.UNIDENT

PDCP 实体调用 发送_PDCP_PDU 服务 原始 为了发送数据
PDU。 AM RLC 实体根据 AM 数据处理该服务原语
[TS5.1.3] 第 36322 节中定义的传输程序。

当。。。的时候 发送_PDCP_PDU 调用服务原语时,AM RLC 实体执行
以下操作:

· 将数据 SDU 放入传输缓冲区。

· 计算缓冲区的大小(如何计算缓冲区的大小将是
后解释)。

· 打电话给 报告_缓冲区_状态 eNB MAC 实体的服务原语,以便
向 eNB MAC 实体通知 AM RLC 实体的缓冲区大小。 然后,
eNB MAC 实体使用
FF MAC 调度程序 API 的 SchedDlRlcBufferReq 服务原语。

之后,当 MAC 调度器决定可以发送一些数据时,MAC 实体
通知 RLC 实体,即它调用 通知_Tx_机会 服务原语,
然后 AM RLC 实体执行以下操作:

· 通过分段和/或连接 SDU 中的 SDU 创建单个数据 PDU
传输缓冲器。

· 将数据 PDU 从传输缓冲区移动到传输的 PDUs 缓冲区。

· 根据 [TS5.1.3.1.1] 的第 36322 节更新状态变量。

· 打电话给 发送_PDU 原语,以便将数据 PDU 发送到 MAC 实体。

重播 in 下行
图的时序图 序列 图表 of data PDU 重播 in 下行
显示了不同实体(AM RLC、MAC 和 MAC 调度器)之间的交互
当数据 PDU 必须由 AM RLC 实体重传时,eNB 处于下行链路。
[图片] 下行数据PDU重传时序图.UNIDENT

发送 AM RLC 实体可以从对等 AM RLC 实体接收 STATUS PDU。
STATUS PDU 是根据 [TS5.3.2] 的 36322 节和处理
根据 [TS5.2.1] 的第 36322 节进行接收。

当一个数据 PDUs 从 Transmitted PDUs Buffer 重传时,它也被移动到
重传缓冲区。

发送 操作 in 上行
图的时序图 序列 图表 of data PDU 传输 in 上行 节目
UE的不同实体(RRC、PDCP、RLC和MAC)之间的交互和
当上层发送数据 PDU 时,上行链路中的 eNB(MAC 和调度器)。
[图片]上行数据PDU传输时序图。UNIDENT

类似于下行的时序图; 主要区别在于,在这个
如果 Report_Buffer_Status 从 UE MAC 发送到 eNB 中的 MAC 调度程序
使用控制信道在空中。

重播 in 上行
图的时序图 序列 图表 of data PDU 重播 in 上行 节目
UE的不同实体(AM RLC和MAC)和eNB之间的交互
(MAC) 在上行链路中,当数据 PDU 必须由 AM RLC 实体重传时。
[图片] 上行链路中数据 PDU 重传的时序图。UNIDENT

计算 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 缓冲 尺寸
传输缓冲区包含 RLC SDU。 一个 RLC PDU 是一个或多个 SDU 段加上一个
RLC 标头。 一个 RLC PDU 的 RLC 头的大小取决于 SDU 的数量
PDU 包含的段。

3GPP 标准([TS6.1.3.1] 的第 36321 节)明确指出,对于上行链路,
RLC 和 MAC 标头不考虑在要报告的缓冲区大小中作为
缓冲区状态报告。 对于下行链路,未指定行为。 两者都不
[FFAPI] 指定如何做。 我们的 RLC 模型通过假设计算
下行链路的缓冲区大小与上行链路完全相同,即不考虑
RLC 和 MAC 报头大小。

我们注意到这个选择会影响与 MAC 调度器的互操作,因为在
回应 通知_Tx_机会 服务原语,RLC 预计将创建一个
PDU 不超过 MAC 请求的大小,包括 RLC 开销。 因此,不需要
如果(例如)MAC 通知传输正好等于
RLC 先前报告的缓冲区大小。 我们假设它留给调度器
实施智能策略以选择变速器的尺寸
机会,以最终避免不必要的碎片化的低效率。

级联 用户分类
AM RLC 实体为每次传输生成并发送一个 RLC PDU
即使它小于传输机会报告的大小。
例如,如果要发送一个 STATUS PDU,那么只有这个 PDU 会在那个
传播机会。

AM RLC 实体的 SDU 队列的分段和串联遵循相同的
哲学与 UM RLC 实体的过程相同,但有新的状态变量
(参见 [TS36322] 第 7.1 节)仅存在于 AM RLC 实体中。

请注意,根据 3GPP 规范,没有连接
重传缓冲区。

重新细分
AM RLC 实体的当前模型不支持重新分割
重传缓冲区。 相反,AM RLC 实体只是等待接收足够大的
传播机会。

不支持 功能
我们不支持 [TS36322] 的以下程序:

· “发送成功交付 RLC SDU 的指示”(参见第 5.1.3.1.1 节)

· “向上层指示已达到最大重传”(参见章节
5.2.1)

· “SDU 丢弃程序”(见第 5.3 节)

· “重建程序”(见第 5.4 节)

对于 AM RLC 实体,我们不支持 RLC SAP 的任何附加原语。 在
特定:

· 无 PDCP 通知的 SDU 丢弃

· 没有 AM RLC 实体向 PDCP 实体发送成功/失败的通知

UM RLC
在本节中,我们描述了 Unacknowledge Mode (UM) RLC 实体的实现。

发送 操作 in 下行
UM RLC 的发送操作与之前的 AM RLC 类似
节中描述 发送 操作 in 下行, 不同的是, 以下
[TS36322]的规范,不进行重传,也没有STATUS
PDU。

发送 操作 in 上行
上行链路的传输操作与下行链路的传输操作类似,主要是
Report_Buffer_Status 从 UE MAC 发送到 MAC 调度器的区别在于
eNB 使用控制信道进行空中传输。

计算 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 缓冲 尺寸
UM RLC 的缓冲区大小的计算是使用与
AM RLC,请参阅章节 计算 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 缓冲 尺寸 对于相应的
描述。

TM RLC
在本节中,我们描述了透明模式 (TM) RLC 实体的实现。

发送 操作 in 下行
在模拟器中,TM RLC 仍然为上层提供相同的服务接口
由 AM 和 UM RLC 实体提供给 PDCP 层; 实际上,这个接口是
由 RRC 实体(不是 PDCP 实体)用于传输 RLC SDU。 这个选择是
由于 TM RLC 向上层提供的服务,
根据 [TS36322],是 UM 和 AM RLC 实体提供给
PDCP层; 因此,为了简单起见,我们重用了相同的接口。

下行链路中的发送操作如下执行。 当。。。的时候
发送_PDCP_PDU 服务 原始 由上层调用,TM RLC 执行
在以下:

· 将 SDU 放入传输缓冲区

· 计算传输缓冲区的大小

· 打电话给 报告_缓冲区_状态 eNB MAC实体的服务原语

之后,当 MAC 调度器决定某些数据可以由逻辑
TM RLC实体所属的信道,MAC实体通知TM RLC
通过调用实体 通知_Tx_机会 服务原语。 收到此消息后
原语中,TM RLC 实体执行以下操作:

· 如果 TX 机会的大小大于或等于
传输缓冲区中的线头 SDU

· 从传输缓冲区中取出行头 SDU

· 创建一个完全包含该 SDU 的 RLC PDU,没有任何 RLC 标头

· 打电话给 发送_PDU 原语,以便将 RLC PDU 发送到 MAC 实体。

发送 操作 in 上行
上行链路的传输操作与下行链路的传输操作类似,主要是
传输机会也可能来自 UL 的分配的差异
GRANT 作为随机访问过程的一部分,没有明确的缓冲区状态报告
由 TM RLC 实体发布。

计算 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 缓冲 尺寸
根据规范 [TS36322],TM RLC 不会将任何 RLC 标头添加到 PDU
被传送。 因此,报告给 MAC 层的缓冲区大小为
简单地通过将传输缓冲区中所有数据包的大小相加来计算,因此
通知 MAC 确切的缓冲区大小。

SM RLC
除了以 3GPP 为模型的 AM、UM 和 TM 实现之外
规范中,提供了一个简化的 RLC 模型,称为饱和模式 (SM)
RLC。 此 RLC 模型不接受来自任何上述层(例如 PDCP)的 PDU; 相反,
SM RLC 负责生成 RLC PDU 以响应通知
MAC 通知的传输机会。 换句话说,SM RLC 模拟
饱和条件,即它假设 RLC 缓冲区总是满的,并且可以
每当调度程序通知时生成一个新的 PDU。

SM RLC 用于简化的仿真场景,其中只有 LTE Radio 模型
使用,没有 EPC,因此没有任何 IP 网络支持。 我们注意到,
虽然 SM RLC 是一个不切实际的流量模型,但它仍然允许正确的
具有属于不同(非实时)QoS 的多个流的场景模拟
类,以测试不同调度程序获得的 QoS 性能。 这个可以
因为调度器的任务是分配传输资源
每个无线承载的特性(例如,保证比特率),它们被指定
根据模拟程序中每个承载的定义。

至于设计用于处理具有延迟限制的实时 QoS 流量的调度程序,
SM RLC 可能不是一个合适的选择。 这是因为没有实际
RLC SDU(由人工生成的 Buffer Status Reports 代替)使其不
可以为调度程序提供有意义的线头延迟信息,即
通常是实时调度策略实施的首选指标
交通流量。 对于此类调度程序的模拟和测试,建议使用
UM 或 AM RLC 模型。

聚二甲基硅氧烷
聚二甲基硅氧烷 型号 概述
PDCP 实体规范的参考文档是[TS36323]。 尊重地
根据本规范,在模拟器中实现的 PDCP 模型仅支持
具有以下特点:

· 数据传输(用户平面或控制平面);

· PDCP SN 的维护;

· SN状态转移(切换时使用);

当前不支持以下功能:

· 使用ROHC协议对IP数据流进行报头压缩和解压;

· 在重建下层时按顺序传递上层PDU;

· 在重建低层时重复消除低层 SDU
映射在 RLC AM 上的无线电承载;

· 用户面数据和控制面数据的加密和解密;

· 控制平面数据的完整性保护和完整性验证;

· 基于定时器的丢弃;

·重复丢弃。

聚二甲基硅氧烷 服务 接口
PDCP服务接口分为两部分:

· 这 PdcpSapProvider 部分由PDCP层提供,上层使用


· 这 PdcpSap用户 部分由上层提供,由PDCP层使用。

聚二甲基硅氧烷 服务 基元
以下列表指定了 PDCP 服务提供了哪些服务原语
接口:

· PdcpSapProvider::传输PdcpSdu

· RRC 实体使用这个原语发送一个 RRC PDU 到较低的 PDCP 实体
在发射器对等体中

· PdcpSapUser::ReceivePdcpSdu

· PDCP实体使用该原语向上层RRC实体发送一个RR​​C PDU
在接收方对等方

RRC
特性
模拟器中实现的 RRC 模型提供以下功能:

· 系统信息的生成(在 eNB)和解释(在 UE)(在
特别是主信息块,在撰写本文时,只有系统
信息块类型 1 和 2)

· 初始单元格选择

· RRC连接建立流程

· RRC 重新配置过程,支持以下用例: + 重新配置
SRS 配置索引 + PHY TX 模式 (MIMO) 的重新配置 +
UE测量重配置+数据无线电承载建立+切换

· RRC连接重建,支持以下用例:+切换

卓越
RRC模型分为以下几部分:

· RRC实体 LTELteEnbrrc,它实现的状态机
分别在 UE 和 eNB 的 RRC 实体;

· RRC SAPs LTERrcSapProvider, LTERRCSAP用户, LteEnbRrcSapProvider,
LteEnbRrcSap用户,它允许 RRC 实体发送和接收 RRC 消息和
信息元素;

· RRC 协议类 LTEUERRC协议理想, LteEnbRrc协议理想,
LTEUERRC协议真实, LteEnbRrc协议Real, 它实现了两种不同的模型
RRC 消息的传输。

此外,RRC 组件使用各种其他 SAP 来与其他 SAP 交互
的协议栈。 使用的所有 SAP 的表示形式在
数字 LTE的 无线电电路 协议 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 data 平面, LTE的 无线电电路
协议 架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 控制 平面, LTE的 无线电电路 协议
架构 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基站 on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 data 平面LTE的 无线电电路 协议 架构
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基站 on 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 控制 平面.

UE RRC 包装机械
在图中 UE RRC 包装机械 我们表示在 RRC UE 中实现的状态机
实体。
[图片] UE RRC 状态机.UNIDENT

需要注意的是,大多数状态都是瞬态的,即一旦 UE 进入一个
在 CONNECTED 状态中,它永远不会切换回任何 IDLE 状态。 这个选择
这样做的原因如下:

· 如本节所述 工艺设计 标准,LTE-EPC仿真的重点
模型处于连接模式

· 无线电链路故障目前没有建模,如第 XNUMX 节中讨论的那样 广播电台 链接
失败,因此 UE 不能因为无线链路故障而进入 IDLE

· RRC 连接释放当前从未被 EPC 或 NAS 触发

尽管如此,我们还是选择显式建模 IDLE 状态,因为:

· 切换需要一个真实的 UE RRC 配置,这是一个必需的特性,
为了实现更简洁的实现,使用相同的 UE RRC 是有意义的
配置也用于初始连接建立

· 将来更容易实现空闲模式小区选择,这是一个
非常理想的功能

ENB RRC 包装机械
eNB RRC 为每个连接到小区的 UE 维护状态。 从一个
从实现的角度来看,每个 UE 的状态都包含在
UeManager 类。 状态机如图所示 ENB RRC 包装机械
UE.
[image] 每个 UE.UNIDENT 的 ENB RRC 状态机

初始 手机 选择
初始小区选择是一个空闲模式过程,由 UE 在尚未完成时执行
驻留或连接到 eNodeB。 该过程的目的是找到一个合适的细胞
并附加到它以访问蜂窝网络。

它通常在仿真开始时完成,如图所示 样本 运行 of
初始 细胞 选择 in UE 定时 of 有关 事件 以下。 上的时间图
左侧说明了第一次尝试初始小区选择成功的情况,
而右侧的图表是针对第一次尝试失败的情况
第二次尝试成功。 时序假设使用真实的 RRC 协议模型(见 RRC
协议 模型) 并且没有传输错误。
[图片] UE 中初始小区选择的示例运行和相关时间
事件.UNINDENT

该功能基于 3GPP IDLE 模式规范,例如在 [TS36300] 中,
[TS36304] 和 [TS36331]。 但是,仍然缺少 IDLE 模式的正确实现
在模拟器中,所以我们保留几个简化假设:

· 不支持多载频;

· 多个公共陆地移动网络 (PLMN) 身份(即多个网络
运算符)不受支持;

· 不使用 RSRQ 测量;

· 不支持存储信息小区选择;

· 不支持“任意小区选择”状态和驻留到可接受小区;

· 不支持将单元格标记为禁止或保留;

· 不支持小区重选,因此 UE 无法预占
放置初始营地后的不同单元; 和

· UE的封闭用户组(CSG)白名单只包含一个CSG身份。

另请注意,初始单元选择仅适用于启用 EPC 的模拟。
仅限 LTE 的模拟必须使用手动连接方法。 见部分
用户文档的 sec-network-attachment 以获取有关它们之间差异的更多信息
在使用中。

接下来的小节涵盖了初始细胞选择的不同部分,即 细胞 搜索、,
播放 of 系统 信息细胞 选择 评估.

手机 搜索
小区搜索旨在检测周围的小区并测量接收信号的强度
从这些细胞中的每一个。 其中一个小区将成为 UE 的入口点以加入
蜂窝网络。

测量基于接收到的 PSS 的 RSRP,由第 1 层过滤平均,
并由 PHY 层执行,如前面部分中更详细描述的那样 UE PHY
测量 型号. PSS 由 eNodeB 在其中心的 72 个子载波上传输
DL 信道(第 5.1.7.3 节 [TS36300]),因此我们对小区搜索进行建模以使用 DL 进行操作
6个RB的带宽。 请注意,目前无法测量 RSRQ
在模拟中。 因此, LtelEPhy::RsrqUeMeasThreshold 属性不
在小区搜索期间应用。

通过使用测量的 RSRP,PHY 实体能够生成检测到的小区列表,
每个都有其对应的小区 ID 和平均 RSRP。 此列表会定期推送
通过 CPHY SAP 到 RRC 实体作为测量报告。

RRC 实体检查报告并简单地选择具有最强 RSRP 的小区,如
[TS5.2.3.1] 的第 36304 节中也有说明。 然后它指示 PHY 实体返回
同步到这个特定的单元格。 小区实际工作带宽仍为
此时未知,因此 PHY 实体仅侦听 6 个 RB 的最小带宽。
然而,PHY 实体将能够从这个接收系统广播消息
特定的 eNodeB,这是下一小节的主题。

广播 Broadcast of 系统 资讯
eNodeB 以预定义的时间间隔向 UE 广播系统信息块,
改编自 [TS5.2.1.2] 的第 36331 节。 支持的系统信息块有:

·

总音量 资讯 阻止 (MIB)
包含与 PHY 层相关的参数,在 cell 期间生成
配置并在无线电帧开始时每 10 ms 广播一次
控制消息。

·

系统 资讯 阻止 类型 1 (SIB1)
包含有关网络访问的信息,每 20 毫秒广播一次
无线电帧的中间作为控制消息。 不用于手动附件
方法。 UE 在接收 SIB1 之前必须已解码 MIB。

·

系统 资讯 阻止 类型 2 (SIB2)
包含 UL 和 RACH 相关设置,计划通过 RRC 协议传输
在小区配置后 16 毫秒,然后每 80 毫秒重复一次(可配置
通过 LteEnbRrc::系统信息周期性 属性。 UE 必须驻留
到一个小区,以便能够接收其 SIB2。

系统信息的接收是 UE 在其生命周期中前进的基础。 MIB
使 UE 能够将 6 个 RB 的初始 DL 带宽增加到实际操作
网络带宽。 SIB1 提供小区选择所需的信息
评估(在下一节中解释)。 最后在 UE 运行之前需要 SIB2
允许切换到 CONNECTED 状态。

手机 选择 评价
UE RRC 审查生成的测量报告 手机 搜索 和小区访问
SIB1 提供的信息。 一旦两个信息都可用于特定单元格,
UE触发评估过程。 此过程的目的是确定是否
该小区是一个适合露营的小区。

评估过程是 [TS5.2.3.2] 第 36304 节的略微简化版本。
它由以下标准组成:

· Rx 水平标准; 和

· 封闭用户组(CSG)标准。

第一个标准,Rx 水平,基于小区测量的 RSRP Q_{rxlevmeas},它
必须高于所需的最小值 Q_{rxlevmin} 才能通过标准:

其中 Q_{rxlevmin} 由每个 eNodeB 确定并且可由 UE 从 SIB1 获得。

最后一个标准 CSG 是一个真或假参数的组合,称为 南玻
迹象 和一个简单的数字 南玻 身分. 基本规则是 UE 不应预占
具有不同 CSG 身份的 eNodeB。 但此规则仅在 CSG 指示时执行
被认为是真实的。 用户的 sec-network-attachment 部分提供了更多详细信息
文档。

当单元格通过上述所有条件时,该单元格被认为是 合适的. 然后UE
扎营(正常空闲状态 状态)。

在此之后,上层可以请求 UE 进入 CONNECTED 模式。 请参阅章节
RRC 地都 编制 有关详细信息。

另一方面,当小区没有通过 CSG 准则时,则该小区被标记
as 可接受 (第 10.1.1.1 节 [TS36300])。 在这种情况下,RRC 实体会告诉 PHY
实体同步到第二强的小区并重复初始小区选择
使用该单元格的过程。 只要没有找到合适的小区,UE就会重复这些
步骤,同时避免已被确定为可接受的单元格。

广播电台 入学咨询 通过积极争取让商标与其相匹配的域名优先注册来维护
通过让 eNB RRC 回复 RRC CONNECTION 来支持无线电准入控制
由 UE 发送的 REQUEST 消息,带有 RRC CONNECTION SETUP 消息或 RRC
CONNECTION REJECT 消息,取决于新 UE 是否被接纳。 在
当前实现,行为由布尔属性决定
ns3::LteEnbRrc::AdmitRrcConnectionRequest. 目前没有无线电准入控制
动态决定是否允许新连接的算法。

广播电台 持票人 配置
在 RRC 中已经做出了一些关于无线电设置的实施选择
持票人:

· 三个逻辑信道组(四个可用)被配置为上行缓冲区
状态报告目的,根据以下政策:

· LCG 0 用于信令无线电承载

· LCG 1 用于 GBR 数据无线电承载

· LCG 2 用于非 GBR 数据无线电承载

广播电台 链接 失败
由于在此阶段 RRC 仅支持 CONNECTED 模式,因此无线链路故障 (RLF) 是
不处理。 原因是 RLF 的可能结果之一(当 RRC
re-establishment is unsuccessful) 是离开 RRC CONNECTED 通知 RRC 的 NAS
连接失败。 为了正确建模 RLF,应支持 RRC IDLE 模式,
尤其包括空闲模式小区(重新)选择。

使用当前模型,UE 的链路质量较差且性能不佳
切换(因为,例如,没有相邻小区,切换禁用,切换阈值
配置错误)只会与同一个 eNB 保持关联,并且调度程序将停止
分配资源给它进行通信。

UE RRC 测量 型号
UE RRC 测量 支持
UE RRC 实体为 UE 测量提供支持; 特别是,它实现了
[TS5.5] 第 36331 节中描述的程序,以下简化
假设:

· 仅支持 E-UTRA 同频测量,这意味着:

· 模拟过程中只使用一个测量对象;

· 执行测量不需要测量间隙;

· 事件B1和B2没有执行;

· 只要 报告最强细胞 目的得到支持,而 报告CGI
报告SON的最强细胞 不支持用途;

· s-测量 不支持;

· 由于LTE模块不支持载波聚合,以下
UE 测量中的假设成立:

· 没有二次电池的概念(细胞);

· 原细胞 (细胞) 仅表示服务小区;

· 事件A6未执行;

· 触发时间的速度相关缩放([TS5.5.6.2] 的第 36331 节)不是
支持的。

整体 设计
该模型基于以下概念 UE 测量 消费者,这是一个实体,可以
请求 eNodeB RRC 实体提供 UE 测量报告。 消费者是,因为
例, 交出 算法,它基于 UE 测量计算切换决策
报告。 测试用例和用户的程序也可能成为消费者。 数字 关系
之间 UE 测量 它的 消费者 描述了这些实体之间的关系。
[图片] UE 测量值与其消费者之间的关系。 UNINDENT

RRC 级别的整个 UE 测量功能分为 4 个主要部分:

1. 测量配置(由 LteUeRrc::ApplyMeasConfig)

2. 执行测量(由 LteUeRrc::DoReportUeMeasurements)

3. 测量报告触发(由 LteUeRrc::测量报告触发)

4. 测量报告(由 LteUeRrc::发送测量报告)

以下部分将描述上述每个部分。

多维数据监测 配置
eNodeB RRC 实体通过将配置参数发送到
UE RRC 实体。 这组参数定义在 测量配置 资讯
RRC 连接重配置消息的元素 (IE) (RRC 地都
重新设置).

eNodeB RRC 实体实现配置参数和过程中描述的
[TS5.5.2] 的第 36331 节,具有以下简化假设:

· 配置(即添加、修改和删除)只能在
模拟开始;

· 连接到 eNodeB 的所有 UE 都将以相同的方式配置,即没有
支持为特定UE配置特定测量; 和

· 假设 PCI 和 E-UTRAN 之间存在一对一的映射
全球小区标识符 (EGCI)。 这与 PCI 建模假设一致
描述于 UE PHY 测量 型号.

eNodeB RRC 实例在此充当消费者和终端之间的中介。
附加的 UE。 在模拟开始时,每个消费者提供 eNodeB RRC
实例与它需要的 UE 测量配置。 之后,eNodeB
RRC 将配置分发给连接的 UE。

用户可以使用多种方法自定义测量配置。 请参阅
用户文档的部分 sec-configure-ue-measurements 用于描述
这些方法。

表演 测量
UE RRC 定期从 UE PHY 接收 RSRP 和 RSRQ 测量结果,如
描述于 UE PHY 测量 型号. 3 过滤 将应用于这些
收到的测量值。 过滤的实现遵循第 5.5.3.2 节
[TS36331]:

其中:

· M_n 是最新收到的物理层测量结果;

· F_n 为更新后的滤波测量结果;

· F_{n-1}是旧的过滤测量结果,其中F_0 = M_1(即第一个
测量未过滤); 和

· a = (ac{1}{2})^{ac{k}{4}},其中 k 是可配置的 过滤系数 提供
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 数量配置;

k = 4 是默认值,但可以通过设置 Rsrp过滤系数
Rsrq过滤系数 属性在 LteEnbrrc.

因此 k = 0 将禁用第 3 层过滤。 另一方面,过去的测量可以
使用较大的 k 值可以对过滤结果产生更大的影响。

多维数据监测 报告 触发
在这一部分中,UE RRC 将遍历活动测量配置列表和
根据第 5.5.4 节检查触发条件是否满足
[TS36331]。 当所有活动测量中至少有一个触发条件
配置完成后,测量报告程序(在接下来的描述
小节)将启动。

3GPP 定义了两种 触发器类型: 期刊基于事件。 目前,只有
支持基于事件的标准。 有多种事件可供选择,其中
下表简要说明:

列表 of 支持的 基于事件 触发 标准
┌──────────┬──────────────────────────────────┐
│名称 │ 说明 │
├──────────┼──────────────────────────────────┤
│事件A1 │服务小区变得优于│
│ │ 门槛
├──────────┼──────────────────────────────────┤
│事件 A2 │ 服务小区变得比 │
│ │ 门槛
├──────────┼──────────────────────────────────┤
│事件A3 │邻居变成 抵消 分贝│
│ │ 比服务小区好 │
├──────────┼──────────────────────────────────┤
│Event A4 │邻居变比 │
│ │ 门槛
└──────────┴──────────────────────────────────┘

│事件A5 │服务变得比不上│
│ │ 阈值1 AND 邻居变成了│
│ │ 优于 阈值2
└──────────┴──────────────────────────────────┘

在基于事件的触发器中要检查的两个主要条件是 进入 流程条件
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 离开 流程条件. 有关这两者的更多详细信息,请参见第 5.5.4 节
[TS36331]。

基于事件的触发器可以通过引入滞后和进一步配置
触发时间。 滞后 (Hys) 定义进入和离开之间的距离
以 dB 为单位的条件。 相似地, 触发时间 延迟进入和离开
条件,但以时间为单位。

- 期刊 不支持报告触发器类型,但其行为可以很容易地
通过使用基于事件的触发器获得。 这可以通过配置测量来完成
以始终满足输入条件的方式,例如,通过设置
事件 A1 的阈值为零(最低级别)。 结果,测量报告
将始终在每个特定时间间隔触发,由 报告间隔
场内 LterRrcSap::ReportConfigEutra,因此产生与
定期报告。

作为对 3GPP 规范的限制,当前模型不支持
任何特定于单元的配置。 这些配置参数在测量中定义
目的。 因此,将黑细胞列表合并到触发过程中
不支持。 此外,特定于小区的偏移量(即事件 A3、A4 中的 O_{cn} 和 O_{cp},
和 A5) 也不支持。 始终假定等于零的值代替
他们。

多维数据监测 报告
这部分处理从 UE RRC 实体提交测量报告到
通过 RRC 协议服务 eNodeB 实体。 采用了几个简化假设:

· 报告金额 is 而不去 适用(即始终假定为无限);

· 在测量报告中, 报告数量 总是假定为 ,即,两者
始终报告 RSRP 和 RSRQ,无论 触发数量.

交出
RRC 模型通过调用基于 X2 的切换来支持 CONNECTED 模式下的 UE 移动性
程序。 该模型基于第 10.1.2.1 节的 EUTRAN 内和频率内
[TS36300]。

本节重点介绍触发切换的过程。 交接执行
程序本身包含在第 X2.

有两种方法可以触发切换过程:

· 明确地 (或手动)由模拟程序通过调度一个
方法的执行 LteEnbRrc::发送切换请求或;

· 自动 由 eNodeB RRC 实体基于 ​​UE 测量和触发
根据选择的切换算法。

用户文档的 sec-x2-based-handover 部分提供了一些使用示例
模拟中的显式和自动切换触发。 下一小节将
仔细研究自动方法,通过描述设计方面
切换算法接口和可用的切换算法。

交出 算法
3GPP LTE 中的切换具有以下特性:

·

UE辅助
UE 以测量报告的形式向网络提供输入。 这个
UE RRC 测量 型号.

·

网络控制
网络(即源 eNodeB 和目标 eNodeB)决定何时
触发移交并监督其执行。

- 交出 算法 运行在源eNodeB,负责切换
以“自动”方式做出决定。 它通过
交出 管理 树液 界面。 这些关系如图所示
关系 之间 UE 测量 它的 消费者 从上一节。

切换算法接口由以下方法组成:

·

添加 UeMeasReportConfigForHandover
(Handover Algorithm -> eNodeB RRC) 切换算法用来请求
来自 eNodeB RRC 实体的测量报告,通过传递所需的
报告配置。 该配置将应用于所有未来
附加的UE。

·

报告UeMeas
(eNodeB RRC -> 切换算法)基于配置的 UE 测量
早些时候 添加 UeMeasReportConfigForHandover, UE可以提交测量报告
到 eNodeB。 eNodeB RRC 实体使用 报告UeMeas 接口
将这些测量报告转发给切换算法。

·

触发切换
(切换算法 -> eNodeB RRC)检查测量报告后
(但不一定),切换算法可以声明切换。 这个
方法用于将此决定通知 eNodeB RRC 实体,这将
然后开始交接程序。

一张纸条 添加 UeMeasReportConfigForHandover. 该方法将返回 测量ID
(测量标识)新创建的测量配置。 通常一个
切换算法将存储此唯一编号。 它可能在 报告UeMeas
方法,例如,当请求了多个配置和切换时
算法需要根据配置区分传入报告
触发了他们。

切换算法是通过编写一个子类来实现的 LTE切换算法
抽象超类并实现上述每个 SAP 接口方法。
用户可以通过这种方式开发自己的切换算法,然后在任何模拟中使用它
按照 sec-x2-based-handover of the User 部分中概述的步骤进行操作
文档。

或者,用户可以选择使用提供的 3 种内置切换算法之一
LTE模块:no-op、A2-A4-RSRQ、最强小区切换算法。 他们是
准备用于模拟或可以作为实现切换的示例
算法。 这些内置算法中的每一个都包含在以下每一个中
小节。

空操作 交出 算法
- 无操作 交出 算法 (NoOp切换算法 类)是最简单的
切换算法的实现。 它基本上什么也不做,即不调用任何
切换管理 SAP 接口方法。 用户可以选择这种切换算法
如果他们希望在模拟中禁用自动切换触发器。

A2-A4-RSRQ 交出 算法
- A2-A4-RSRQ 交出 算法 提供默认切换的功能
最初包含在 LENA M6 (ns-3.18) 中的算法,移植到 Handover Management SAP
界面作为 A2A4Rsrq切换算法 类。

顾名思义,该算法利用参考信号接收质量 (RSRQ)
从事件 A2 和事件 A4 获得的测量值。 因此,该算法将添加 2
测量配置到相应的 eNodeB RRC 实例。 他们的预期用途是
描述如下:

· 创建 A2 (服务小区的 RSRQ 变得比 门槛) 被用来表示
UE 正在经历较差的信号质量并且可能受益于切换。

· 创建 A4 (邻居小区的 RSRQ 变得比 门槛) 用于检测
相邻小区并从每个附着的 UE 获取相应的 RSRQ,这
然后由算法内部存储。 默认情况下,算法配置
事件 A4 具有非常低的阈值,从而使触发条件始终为真。

数字 A2-A4-RSRQ 交出 算法 下面总结了这个过程。
[图片] A2-A4-RSRQ切换算法.UNINDENT

可以设置两个属性来调整算法行为:

·

服务小区阈值
- 门槛 对于事件 A2,即 UE 必须具有低于此的 RSRQ
考虑切换的阈值。

·

相邻单元格偏移量
- 抵消 旨在确保UE将接收到更好的信号质量
交接后。 相邻小区被视为目标小区
仅当其 RSRQ 高于服务小区的 RSRQ 数量时才切换
这个的 抵消.

这两个属性的值都表示为 RSRQ 范围([TS9.1.7] 的第 36133 节),
这是一个介于 0 和 34 之间的整数,其中 0 是最低的 RSRQ。

最强 细胞 交出 算法
- 最强 细胞 交出 算法,或者有时也被称为 传统 功率
预算 (PBGT) 算法, 是使用 [Dimou2009] 作为参考开发的。 这个想法是
为每个 UE 提供最佳参考信号接收功率 (RSRP)。 这是
通过在更好的小区(即具有更强的 RSRP)出现时立即执行切换来完成
检测到。

创建 A3 (相邻小区的 RSRP 变得比服务小区的 RSRP 更好)被选择为
实现这个概念。 这 A3Rsrp切换算法 类是的结果
执行。 触发UE切换到测量中的最佳小区
报告。

使用此算法的模拟通常更容易受到乒乓切换的影响
(短时间内连续切换到之前的源eNodeB),
特别是当 衰退 型号 已启用。 这个问题通常由
给切换引入一定的延迟。 该算法通过包括
迟滞和触发时间参数([TS6.3.5] 的第 36331 节)到 UE
测量配置。

滞后 (又名切换裕度)延迟关于 RSRP 的切换。 价值是
以 dB 表示,范围在 0 到 15 dB 之间,精度为 0.5 dB,例如,输入
2.7 dB 的值四舍五入为 2.5 dB。

另一方面, 触发时间 在时间上延误交接。 3GPP定义16
触发时间的有效值(均以毫秒为单位):0、40、64、80、100、128、160、256、
320、480、512、640、1024、1280、2560和5120。

迟滞和触发时间之间的区别如图所示 影响 of
磁滞现象 触发时间 in 最强 细胞 交出 算法 下面,这是采取
来自 lena-x2-移交措施 例子。 它描述了服务小区的感知 RSRP
移动通过小区边界的UE的相邻小区。
[图片] 最强小区切换中滞后和触发时间的影响
算法.UNINDENT

默认情况下,该算法使用 3.0 dB 的迟滞和 256 ms 的触发时间。
这些值可以通过调整 滞后触发时间 的属性
A3Rsrp切换算法 类。

邻居 关系
LTE模块支持简化 自动表 邻居 关系 (ANR) 功能。 这是
由处理 莱特安尔 类,它通过 ANR 与 eNodeB RRC 实例交互
SAP 接口。

邻居 关系
ANR 持有 邻居 关系 (NRT),类似于Section中的描述
[TS22.3.2] 的 36300a。 表中的每个条目称为 邻居 关系 (天然橡胶)和
表示检测到的相邻小区,它包含以下布尔字段:

·

没有 删除
表示 NR 应 而不去 从 NRT 中删除。 这是 true by
默认为用户提供的 NR 和 false 除此以外。

·

没有 X2 表示 NR 应 而不去 使用 X2 接口来启动
向 eNodeB 管理目标小区的过程。 这是 false by
用户提供的 NR 的默认值,以及 true 除此以外。

·

没有 HO 表示 NR 应 而不去 由 eNodeB 出于切换原因使用。
这是 true 在大多数情况下,除非 NR 既是用户提供的又是
网络检测。

每个 NR 条目可能至少具有以下属性之一:

·

用户提供
这种类型的 NR 是按照模拟用户的指示创建的。 例如,
在用户启动 X2 的建立时自动创建 NR
2 个 eNodeB 之间的连接,例如第
基于 sec-x2 的切换。 另一种创建用户提供的 NR 的方法是调用
添加邻居关系 明确地发挥作用。

·

网络检测
这种类型的 NR 是在模拟过程中自动创建的,因为
附近小区的发现。

为了自动创建网络检测到的 NR,ANR 使用 UE 测量。 在
换句话说,ANR 是 UE 测量的消费者,如图所示 关系
之间 UE 测量 它的 消费者. RSRQ 和事件 A4(邻居变得更好
门槛) 用于报告配置。 默认事件 A4 门槛
设置为最低可能,即最大检测能力,但可以通过更改
设置 的属性 莱特安尔 班级。 注意 A2-A4-RSRQ 切换
算法也使用类似的报告配置。 尽管有相似之处,但当
ANR 和这种切换算法都在 eNodeB 中处于活动状态,它们使用单​​独的报告
组态。

另请注意,不支持 X2 接口的自动设置。 这就是为什么
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 没有 X2没有 HO 字段在网络检测到但用户检测到的 NR 中为真。

角色 of ANR in 教学帖子
ANR SAP 接口提供了 ANR 和 eNodeB RRC 之间的通信方式。 一些
eNodeB RRC使用接口函数与NRT进行交互,如下图:

·

添加邻居关系
(eNodeB RRC -> ANR) 添加一个新的用户提供的 NR 条目到 NRT 中。

·

不删除
(eNodeB RRC -> ANR) 获取值 没有 删除 NR条目的字段
给定的小区ID。

·

无所事事
(eNodeB RRC -> ANR) 获取值 没有 HO 给定的 NR 条目的字段
单元 ID。

·

获取NoX2
(eNodeB RRC -> ANR) 获取值 没有 X2 给定的 NR 条目的字段
单元 ID。

存在其他接口功能以支持 ANR 作为 UE 测量消费者的角色,
如下所示:

·

添加 UeMeasReportConfigForAnr
(ANR -> eNodeB RRC) ANR 使用它来请求来自基站的测量报告
eNodeB RRC 实体,通过传递所需的报告配置。 这
配置将应用于所有未来连接的 UE。

·

报告UeMeas
(eNodeB RRC -> ANR) 基于之前配置的 UE 测量
添加 UeMeasReportConfigForAnr,UE可以向eNodeB提交测量报告。
eNodeB RRC 实体使用 报告UeMeas 转发这些的接口
测量报告给 ANR。

请参考相应的API文档 LTEAnrSap 上课了解更多详情
关于用法和所需的参数。

eNodeB RRC 实例使用 ANR 作为数据结构来跟踪
附近相邻小区的情况。 ANR 还有助于 eNodeB RRC 实例
确定是否可以执行到相邻小区的切换过程。
这是通过以下事实实现的:eNodeB RRC 将只允许切换过程
如果目标单元格的 NR 条目同时具有 没有 HO没有 X2 字段设置为 false.

模拟中的每个 eNodeB 实例默认启用 ANR。 它可以被禁用
通过设置 Anr启用 归因于 莱特助手 上课到 false.

RRC 序列
在本节中,我们提供了一些序列图来解释最重要的 RRC
正在建模的程序。

RRC 地都 编制
数字 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 RRC 连接升级包 建立 程序 展示了 RRC 如何
连接建立过程被建模,突出了 RRC 层在
UE 和 eNB,以及与其他层的交互。
[image] RRC Connection Establishment procedure.UNINDENT 序列图

有几个与此过程相关的超时,列在下面
定时器 in RRC 地都 编制 程序. 如果这些计时器中的任何一个超时,
RRC连接建立过程失败终止。 在这种情况下,
上层(UE NAS)将立即尝试重试该过程,直到它完成
成功。

定时器 in RRC 地都 编制 程序
┌────────────────┬────────────┬────────────────┬──── ──────────────┬──────────┬────────────────┐
│名称 │ 位置 │ 定时器开始 │ 定时器停止 │ 默认值 │ 当定时器 │
│ │ │ │ │ 持续时间 │ 过期 │
├────────────────┼────────────┼────────────────┼──── ──────────────┼──────────┼──────────────┤
│连接 │ eNodeB RRC │ 新 UE 上下文 │ 接收 RRC │ 15 ms │ 移除 UE │
│ 请求 │ │ 添加 │ 连接 │ │ 上下文 │
│超时 │ │ │ 请求 │ │ │
├────────────────┼────────────┼────────────────┼──── ──────────────┼──────────┼──────────────┤
│连接 │ UE RRC │ 发送 RRC │ 接收 RRC │ 100 ms │ 重置 UE MAC │
│超时(T300 │ │ 连接 │ 连接 │ │ │
│定时器)│ │ 请求 │ 设置 或 │ │ │
│ │ │ │ 拒绝 │ │ │
├────────────────┼────────────┼────────────────┼──── ──────────────┼──────────┼──────────────┤
│连接 │ eNodeB RRC │ 发送 RRC │ 接收 RRC │ 100 ms │ 移除 UE │
│ 设置超时 │ │ 连接 │ 连接 │ │ 上下文 │
│ │ │ 设置 │ 设置完成 │ │ │
├────────────────┼────────────┼────────────────┼──── ──────────────┼──────────┼──────────────┤
│连接 │ eNodeB RRC │ 发送 RRC │ 从不 │ 30 ms │ 移除 UE │
│被拒绝 │ │ 连接 │ │ │ 上下文 │
│超时 │ │ 拒绝 │ │ │ │
└────────────────┴────────────┴────────────────┴──── ──────────────┴──────────┴────────────────┘

RRC 地都 重新设置
数字 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 RRC 连接升级包 重构 程序 展示了 RRC 如何
连接重新配置过程是为 MobilityControlInfo 的情况建模的
不提供,即不执行切换。
[image] RRC Connection Reconfiguration procedure.UNINDENT 序列图

数字 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 RRC 连接升级包 重构 程序 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 交出
案件 展示了 RRC 连接重新配置过程是如何为这种情况建模的
其中提供了MobilityControlInfo,即要进行切换。 作为指定
在 [TS36331] 中, 接收 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 交出 信息, 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE 尝试 ACCESS 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 目标
细胞 at 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 第一 可使用 随机存取存储器 场合 根据 随机 Access 资源 选择
定义 in [TS36321]_, 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 交出 is 异步。 所以, ,尤其是 分配
a 专用 前言 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 随机 ACCESS in 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 目标 细胞, 欧洲UTRA 确保 it is
可使用 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 第一 随机存取存储器 场合 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE 五月 使用。 乳铁蛋白 完成 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。
交出, 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE 发送 a 消息 用过的 确认 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 交出。 请注意,随机
这种情况下的接入过程是基于非竞争的,因此在真实的 LTE 系统中它
与建立的 RRC 连接中使用的略有不同。 另请注意,RA
Preamble ID 通过包含在 X2 切换请求中的切换命令发出信号
目标eNB发送给源eNB的ACK消息; 特别是,序言是
包含在 RACH-ConfigDedicated IE 中,它是 MobilityControlInfo 的一部分。
[image] RRC Connection Reconfiguration 过程的序列图
交接案.UNINDENT

RRC 协议 模型
如前所述,我们提供了两种不同的传输模型和
RRC消息的接收: 理想真实成功. 它们中的每一个都在其中一个中进行了描述
以下小节。

理想 RRC 协议 模型
根据这个模型,在类和 LTEUERRC协议理想
LteEnbRrc协议理想,所有的 RRC 消息和信息元素之间传输
eNB 和 UE 以一种理想的方式,不消耗无线电资源并且没有
错误。 从实现的角度来看,这是通过传递RRC数据来实现的
直接在 UE 和 eNB RRC 实体之间构建,不涉及较低层
(PDCP、RLC、MAC、调度程序)。

真实成功 RRC 协议 模型
该模型在类中实现 LTEUERRC协议真实LteEnbRrc协议Real
旨在模拟真实 LTE 中通常执行的 RRC PDU 传输
系统。 尤其是:

· 对于发送的每个 RRC 消息,都会在 ASN.1 之后创建一个真正的 RRC PDU
[TS36331] 中指定的 RRC PDU 和信息元素 (IE) 的编码。 一些
对包含在 PDU 中的 IE 进行了简化,即只有那些
包括用于模拟目的的 IE。 如需详细清单,请
请参阅中定义的 IE lte-rrc-sap.h 并与 [TS36331] 进行比较。

· 编码的 RRC PDU 在信令无线电承载上发送,并受相同的约束
用于数据通信的传输建模,因此包括调度、无线电
资源消耗、信道错误、延迟、重传等。

发信号 广播电台 持票人 模型
我们现在描述用于 真实成功 RRC协议
模型。

· SRB0 消息(通过 CCCH):

· Rrc连接请求: 在真实的 LTE 系统中,这是一个 RLC TM SDU
RAR 中 UL Grant 中指定的资源(不在 UL DCI 中); 原因是
C-RNTI 在这个阶段还不知道。 在模拟器中,这被建模为真实的
RLC TM RLC PDU,其 UL 资源由调度程序分配给
SCHED_DL_RACH_INFO_REQ。

· Rrc连接设置:在模拟器中,这是在真实的 LTE 系统中实现的,
即,通过常规 UL DCI 指示的资源发送 RLC TM SDU,
分配了由 RLC TM 实例触发的 SCHED_DL_RLC_BUFFER_REQ
映射到 LCID 0(CCCH)。

· SRB1 消息(通过 DCCH):

· 在模拟器中建模的所有 SRB1 消息(例如, RrcConnection完成) 是
在真实的 LTE 系统中实现,即通过 RLC AM 发送真实的 RLC SDU
使用通过缓冲区状态报告分配的 DL 资源。 查看 RLC 模型
有关详细信息的文档。

· SRB2 消息(通过 DCCH):

· 根据 [TS36331],“SRB1 is RRC 条未读消息 (哪一个 五月 包括 a
捎带 NAS 信息) as as NAS 条未读消息 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 编制
of SRB2, 所有 运用 直流信道 合乎逻辑的 渠道“, 然而 ”SRB2 is NAS 消息,
运用 直流信道 合乎逻辑的 渠道“和”SRB2 具有 a 低优先级 SRB1 is
时刻 配置 by 通用陆地无线网络 after 安全 激活".建模
安全相关方面不是 LTE 仿真模型的要求,
因此我们总是使用 SRB1 而从不激活 SRB2。

ASN.1 编码 of RRC IE的
RRC SAP 中定义的消息,对所有 Ue/Enb SAP 用户/提供商通用,被传输
在透明容器中往返于 Ue/Enb。 编码格式不同
信息元素在 [TS36331] 中指定,使用未对齐的 ASN.1 规则
变种。 Ns3/Lte 中的实现分为以下几类:

· Asn1Header : 包含基本ASN类型的编码/解码

· RrcAsn1Header : 继承Asn1Header,包含common的编码/解码
[TS36331] 中定义的 IE

· Rrc specific messages/IEs classes:RRC 中定义的每个消息的类
SAP 标头

Asn1 头文件 - 实施 of 基地 ASN.1 类型
此类实现序列化/反序列化正在使用的 ASN.1 类型的方法
[TS36331],根据 ITU-T X.691 中的打包编码规则。 考虑的类型
是:

· 布尔值:布尔值使用单个位(1=true,0=false)。

· 整数:一个受约束的整数(定义了最小值和最大值)使用最小值
对其范围进行编码的位数 (max-min+1)。

· Bitstring:一个双串将被一点一点地复制到序列化缓冲区。

· Octetstring:当前未使用。

· 序列:序列生成一个前导码,指示可选和
默认字段。 它还添加了一个位来指示扩展标记的存在。

· Sequence...Of : sequence...of 类型对序列的元素个数进行编码
作为一个整数(随后的元素将需要在之后进行编码)。

· Choice:表示选择集中的元素中的哪个元素被编码。

· 枚举:被序列化为一个整数,表示使用哪个值,其中
枚举中的个数,枚举中的元素个数为upper
边界。

· null :空值没有被编码,虽然它的序列化函数被定义了
在规范和实现之间提供更清晰的映射。

该类继承自 ns-3 Header,但 Deserialize() 函数被声明为纯虚函数,
因此继承类必须实现它。 原因是反序列化会
检索 RRC 消息中的元素,每个元素包含不同的信息
元素。

此外,必须注意特定类型/消息的结果字节长度
根据可选字段的存在以及优化的编码,可能会有所不同。
因此,将使用 PreSerialize() 函数处理序列化位,从而节省
结果在 m_serializationResult 缓冲区中。 由于在 ns3 缓冲区中读/写的方法是
以字节为基础定义,序列化位存储到 m_serializationPendingBits
属性,直到 8 位被设置并且可以写入缓冲区迭代器。 最后,当
调用 Serialize(),将复制 m_serializationResult 属性的内容
到 Buffer::Iterator 参数

RrcAsn1标头 : 相当常见 IE
由于一些信息元素被用于多个 RRC 消息,因此此类
实现以下常见的 IE:

· SrbToAddModList

· DrbToAddModList

· 逻辑通道配置

· RadioResourceConfigDedicated

· 物理配置专用

· 系统信息块类型1

· 系统信息块类型2

· RadioResourceConfigCommonSIB

电阻率 具体的 消息/IE
已实施以下 RRC SAP:

· Rrc连接请求

· Rrc连接设置

· RrcConnectionSetupComplete完成

· Rrc连接重配置

· RrcConnectionReconfiguration完成

· 交接准备信息

· Rrc连接重建请求

· RrcConnection重建

· RrcConnection重建完成

· Rrc连接重建拒绝

· Rrc连接释放

NAS
LTE-EPC模型的重点是NAS Active状态,对应EMM
已注册,ECM 已连接,RRC 已连接。 正因为如此,以下
进行了简化:

· EMM 和 ECM 没有明确建模; 相反,UE 的 NAS 实体将
直接与 MME 交互以执行等效的操作(总计
简化)使 UE 进入 EMM Connected 和 ECM Connected 状态;

· NAS 还负责多路复用来自上层的上行数据包
通过使用流量流模板分类器将层放入适当的 EPS 承载中
(Tft 分类器)。

· NAS不支持PLMN和CSG选择

· NAS 在空闲模式下不支持任何位置更新/寻呼程序

数字 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 连接 程序 显示简化的 NAS 模型
实现附加过程。 请注意,默认和最终的专用 EPS
作为此过程的一部分,承载被激活。
[image] attach procedure.UNINDENT 的时序图

S1
S1-U
S1-U 接口通过封装数据包以逼真的方式建模
GTP/UDP/IP,就像在真正的 LTE-EPC 系统中所做的那样。 对应的协议栈如图
数字 LTE-EPC data 平面 协议 . 如图所示,有两种不同的
IP网络层。 第一个是端到端层,它提供端到端的
与用户的连接; 该层涉及 UE、PGW 和远程主机
(包括最终的互联网路由器和中间的主机),但不涉及 eNB。
UE默认在4/7.0.0.0网络中分配一个公网IPv8地址,PGW
获取地址 7.0.0.1,所有 UE 都使用该地址作为到达互联网的网关。

IP网络的第二层是EPC局域网。 这涉及所有 eNB
节点和 SGW/PGW 节点。 该网络是作为一组点对点链接实现的
将每个 eNB 与 SGW/PGW 节点连接起来; 因此,SGW/PGW 有一组
点对点设备,每个设备都提供与不同 eNB 的连接。 默认情况下,一个
10.xyz/30 子网分配给每个点对点链接(/30 子网是最小的
允许两个不同主机地址的子网)。

按照 3GPP 的规定,端到端 IP 通信通过本地 EPC IP 隧道传输
使用 GTP/UDP/IP 的网络。 下面,我们解释一下这个隧道是如何实现的
在 EPC 模型中。 通过讨论端到端的数据流来完成解释
包。
[图片] 互联网和 UE.UNINDENT 之间下行链路中的数据流

首先,我们考虑下行链路的情况,如图所示 时间
in 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 下行 之间 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE. 下行链路 Ipv4 数据包是
从通用远程主机生成,并寻址到其中一个 UE 设备。 互联网
路由将负责将数据包转发到 SGW/PGW 的通用 NetDevice
连接到互联网的节点(根据 3GPP,这是 Gi 接口
术语)。 SGW/PGW 有一个分配了网关 IP 的 VirtualNetDevice
UE子网地址; 因此,静态路由规则将导致传入数据包
从 Internet 通过此 VirtualNetDevice 进行路由。 这样的设备启动
GTP/UDP/IP 隧道程序,通过将数据包转发到专用应用程序
称为 EpcSgwPgwApplication 的 SGW/PGW 节点。 这个应用程序做
以下操作:

1. 它通过查看 IP 确定 UE 连接到的 eNB 节点
目的地址(UE的地址);

2. 它使用流量模板 (TFT) 对数据包进行分类,以识别到哪个
它属于EPS Bearer。 EPS 承载具有到 S1-U 承载的一对一映射,因此
此操作返回 GTP-U 隧道端点标识符 (TEID),
数据包所属;

3、在数据包中加入相应的GTP-U协议头;

4. 最后,它通过 UDP 套接字将数据包发送到 S1-U 点对点
NetDevice,寻址到 UE 所连接的 eNB。

因此,带有新添加的 IP、UDP 和 GTP 标头的端到端 IP 数据包是
通过 S1 链路之一发送到 eNB,在 eNB 本地接收和传送
(因为最外层 IP 标头的目标地址与 eNB IP 地址相匹配)。 这
本地传递进程将通过 UDP 套接字将数据包转发到专用的
名为 EpcEnbApplication 的应用程序。 该应用程序然后执行以下操作
操作:

1. 它删除 GTP 标头并检索包含在其中的 TEID;

2. 利用 S1-U 承载和无线电承载之间的一对一映射(这
是 3GPP 要求),它确定数据包发送到的承载 ID (BID)
属于;

3. 它将 BID 记录在名​​为 EpsBearerTag 的专用标签中,该标签添加到
包;

4. 它通过原始数据包将数据包转发到 eNB 节点的 LteEnbNetDevice
插座

注意,此时数据包最外层的头部是端到端的IP头部,
因为 S1 协议栈的 IP/UDP/GTP 标头已经被剥离。 之上
从 EpcEnbApplication 接收数据包,LteEnbNetDevice 将检索
BID来自EpsBearerTag,并根据BID确定Radio Bearer实例
(以及相应的 PDCP 和 RLC 协议实例),然后用于转发
通过 LTE 无线电接口向 UE 发送数据包。 最后,UE的LteUeNetDevice会
接收数据包,并在本地将其传送到 IP 协议栈,IP 协议栈将依次
下发给UE的应用,也就是下行的终点
通信。
[图片] UE 和互联网之间上行链路中的数据流。UNINDENT

上行链路的情况如图所示 时间 in 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 上行 之间 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 UE
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 . 上行链路 IP 数据包由 UE 内部的通用应用程序生成,
由本地TCP/IP协议栈转发给UE的LteUeNetDevice。 这
LteUeNetDevice 然后执行以下操作:

1. 它使用 TFT 对数据包进行分类并确定无线承载
数据包所属(以及对应的RBID);

2. 标识对应的PDCP协议实例,为入口点
此数据包的 LTE 无线电协议堆栈;

3. 它通过 LTE 无线电协议栈将数据包发送到 eNB。

eNB 通过其 LteEnbNetDevice 接收数据包。 由于只有一个 PDCP 和 RLC
每个无线电承载的协议实例,LteEnbNetDevice 能够确定 BID
的数据包。 这个 BID 然后被记录到一个 EpsBearerTag 上,它被添加到
包。 LteEnbNetDevice 然后通过原始数据包将数据包转发给 EpcEnbApplication
包套接字。

收到数据包后,EpcEnbApplication 执行以下操作:

1. 它从数据包中的 EpsBearerTag 中检索 BID;

2. 决定对应的EPS Bearer instance和GTP-U TEID
S1-U承载和无线承载之间的一对一映射;

3、在数据包上添加GTP-U头,包括之前确定的TEID;

4. 它通过连接到 S1-U 的 UDP 套接字将数据包发送到 SGW/PGW 节点
点对点网络设备。

此时,数据包包含 S1-U IP、UDP 和 GTP 标头以及
原始的端到端 IP 标头。 当数据包被相应的S1-U接收到
SGW/PGW节点的点对点NetDevice,在本地下发(作为目的地
最外层 IP 报头的地址匹配点对点网络设备的地址)。
本地投递进程将数据包通过
相应的 UDP 套接字。 EpcSgwPgwApplication 然后删除 GTP 标头并转发
数据包到 VirtualNetDevice。 此时,数据包的最外层头是
端到端 IP 报头。 因此,如果此标头中的目标地址是远程
互联网上的主机,数据包通过相应的 NetDevice 发送到互联网
SGW/PGW 的。 如果数据包被寻址到另一个 UE,IP 堆栈
SGW/PGW 将数据包再次重定向到 VirtualNetDevice,数据包将去
通过下行链路传递过程以到达其目标UE。

请注意,EPS Bearer QoS 并未在 S1-U 链路上强制执行,假设
链路带宽的过度供应足以满足所有的 QoS 要求
承担者。

S1AP
S1-AP接口提供eNB和MME之间的控制面交互。 在里面
模拟器,这个界面以理想的方式建模,之间有直接的交互
eNB 和 MME 对象,实际上没有实现 S1AP 消息的编码
和 [TS36413] 中指定的信息元素,并且没有实际传输任何 PDU
在任何链接上。

建模的 S1-AP 原语是:

· 初始UE消息

· 初始上下文设置请求

·初始上下文设置响应

· 路径切换请求

· 路径切换请求确认

X2
X2 接口互连两个 eNB [TS36420]。 从逻辑的角度来看,X2
接口是两个eNB之间的点对点接口。 在真实的 E-UTRAN 中,
即使没有物理接口,逻辑点对点接口也应该是可行的
两个 eNB 之间的直接连接。 在模拟器中实现的 X2 模型中,
X2 接口是两个 eNB 之间的点对点链路。 点对点设备是
在两个 eNB 中创建并且两个点对点设备连接到点对点
链接。

展示 X2 接口如何融入 LENA 的整体架构
仿真模型,读者参考图 概述 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 LTE-EPC 模拟
模型.

模拟器中实现的 X2 接口提供了详细的实现
遵循移动性管理功能 [TS36423] 的基本过程:

· 移交请求程序

· 移交请求确认程序

· SN状态转移程序

· UE上下文释放流程

这些过程涉及基于X2的切换。 你可以找到详细的
[TS10.1.2.1] 第 36300 节中对切换的描述。 我们注意到模拟器
模型目前仅支持 无缝的 交出 如第 2.6.3.1 节所定义
[Sesia2009]; 尤其是, 无损 交出 如第 2.6.3.2 节所述
[Sesia2009] 在撰写本文时不受支持。

数字 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 基于X2 交出 下面显示了交互
模拟器中 X2 模型的实体。 阴影标签表示
UE 或 eNodeB 转换到另一个 RRC 状态。
[image] X2-based handover.UNINDENT 时序图

该图还显示了切换过程中的两个计时器: 交出 离开
计时器 由源 eNodeB 维护,而 交出 加盟 计时器 由目标
基站。 定时器的持续时间可以在
切换离开超时持续时间切换加入超时持续时间 的属性
那些 LteEnbrrc 实例。 当这些定时器之一到期时,切换过程
被视为失败。

但是目前的LTE版本并没有对切换失败进行适当的处​​理
模块。 用户应适当调整模拟以避免切换失败,
否则可能会发生意外行为。 请参阅章节
用户文档的 sec-tuning-handover-simulation 以获取有关此的一些提示
物。

X2 模型是使用以下服务的实体:

· X2接口,

· 它们被实现为点对点设备之上的套接字。

· 它们用于通过 X2-C 和 X2-U 接口发送/接收 X2 消息
(即连接到点对点链路的点对点设备)朝向
对端 eNB。

· S1 应用程序。

· 目前是EpcEnbApplication。

· 用于获取X2基本程序所需的一些信息
消息。

它为以下方面提供服务:

· RRC实体(X2 SAP)

·发送/接收RRC消息。 X2 实体以透明方式发送 RRC 消息
X2 消息中的容器。 该 RRC 消息被发送到 UE。

数字 实施 型号 of X2 实体 SAP 展示了X2的实现模型
实体及其与协议中所有其他实体和服务的关系
叠加。
[图片] X2 实体和 SAPs.UNINDENT 的实现模型

RRC 实体管理切换过程的启动。 这是在
eNB RRC实体的切换管理子模块。 目标 eNB 可以执行一些
准入控制程序。 这是在准入控制子模块中完成的。
最初,该子模块将接受任何切换请求。

X2 接口
X2 模型包含两个接口:

· X2-C接口。 它是控制接口,用于发送 X2-AP PDU
(即基本程序)。

· X2-U接口。 它用于发送承载数据时有 DL 转发.

数字 X2 接口 协议 显示了 X2-U 接口的协议栈和
在模拟器中建模的 X2-C 接口。
[图片] X2 接口协议栈.UNINDENT

X2-C
X2-C接口是X2接口的控制部分,用于发送
X2-AP PDU(即基本程序)。

在原来的X2接口控制平面协议栈中,使用SCTP作为传输层
协议,但目前,SCTP 协议未在 ns-3 模拟器及其模型中建模
实施超出了项目范围。 UDP协议用作数据报
面向协议而不是 SCTP 协议。

X2-U
X2-U接口用于发送承载数据,当有 DL 转发
执行基于 X2 的切换过程。 类似于为 S1-U 所做的
接口,数据包在通过此发送时通过 GTP/UDP/IP 封装
界面。 请注意,EPS Bearer QoS 并未在 X2-U 链路上强制执行,假设
链路带宽的过度供应足以满足 QoS 要求
所有承载者。

X2 服务 接口
X2服务接口用于RRC实体发送和接收X2的消息
程序。 它分为两部分:

· 这 EpcX2SapProvider 部分由 X2 实体提供并由 RRC 实体使用,并且

· 这 EpcX2Sap用户 部分由RRC实体提供,由RRC实体使用。

我们的 X2-C 模型中支持的原语描述如下
小节。

X2-C 原语 交出 执行
以下原语用于基于 X2 的切换:

· 移交请求

· 移交请求确认

· 交接准备失败

· SN 身份转移

· UE上下文发布

以上所有原语都被当前实现的 RRC 模型在
交接程序的准备和执行。 它们的使用与 RRC 交互
状态机; 因此,它们不打算用于代码定制,至少
除非需要修改 RRC 状态机。

X2-C 原语
以下原语可用于实现自组织网络 (SON)
功能:

· 加载信息

· 资源状态更新

请注意,当前的 RRC 模型实际上并没有使用这些原语,它们被包括在内
在模型中只是为了能够开发包含在 RRC 逻辑中的 SON 算法
利用它们。

作为第一个例子,我们在这里展示了如何使用负载信息原语。 我们猜测
LteEnbRrc 已被修改为包含以下新成员变量:

std::向量
m_currentUlInterferenceOverloadInductionList;
std::向量
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

对于这些变量的类型的详细描述,我们建议查阅文件
epc-x2-sap.h,相应的 doxygen 文档,以及其中对
3GPP TS 36.423 的相关章节。 现在,假设在运行时这些变量有
已按照刚才提到的规范设置为有意义的值。 那么你也能
在 LteEnbRrc 类实现中添加以下代码以发送负载
信息原语:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndicateList = m_currentUlInterferenceOverloadIndicateList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

EpcX2Sap::LoadInformationParams 参数;
params.targetCellId = cellId;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation(参数);

上面的代码允许源 eNB 发送消息。 方法
LteEnbRrc::DoRecvLoadInformation 将在目标 eNB 收到消息时调用。
因此,负载信息的所需处理应该在
方法。

在下面的第二个示例中,我们展示了如何使用资源状态更新原语。
我们假设 LteEnbRrc 已被修改为包含以下新成员
变量:

EpcX2Sap::CellMeasurementResultItem m_cmri;

与之前类似,我们参考 epc-x2-sap.h 以及其中的详细参考资料
有关此变量类型的信息。 同样,我们假设变量已经
设置为有意义的值。 然后,您可以添加以下代码以发送
资源状态更新:

EpcX2Sap::ResourceStatusUpdateParams 参数;
params.targetCellId = cellId;
参数.cellMeasurementResultList.push_back (m_cmri);
m_x2SapProvider->SendResourceStatusUpdate(参数);

该方法 eEnbRrc::DoRecvResourceStatusUpdate 将在目标 eNB 收到时调用
资源状态更新消息。 此消息的所需处理应该
因此在该方法中实现。

最后,我们注意到适当值的设置和处理
传递给上述原语的变量被认为是特定于 SON 的
正在实施的算法,因此不在本文档中。

不支持 原语
移动稳健性优化原语,例如无线电链路故障指示和
此阶段不支持移交报告。

(S11)
S11 接口提供 SGW 和 MME 之间的控制平面交互,使用
[TS2] 中指定的 GTPv29274-C 协议。 在模拟器中,这个界面被建模为
理想的时尚,在 SGW 和 MME 对象之间直接交互,没有
实际上实现了消息的编码而不实际传输任何
任何链路上的 PDU。

建模的 S11 基元是:

· 创建会话请求

· 创建会话响应

· 修改承载请求

· 修改承载响应

在这些原语中,前两个在初始 UE 连接时使用
S1-U承载的建立; 另外两个在切换期间使用以切换
作为接收的结果,从源 eNB 到目标 eNB 的 S1-U 承载
PATH SWITCH REQUEST S1-AP 消息的 MME。

电力 通过积极争取让商标与其相匹配的域名优先注册来维护
本节描述下行链路和上行链路功率控制的 ns-3 实现。

下行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护
由于某些频率复用算法需要下行链路功率控制,因此该功能被
也在 ns-3 中实现。
[图片] 下行功率控制时序图.UNINDENT

数字 序列 图表 of 下行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护 显示设置时序图
UE的下行链路P_A值,突出了RRC和其他之间的交互
实体。 FR算法触发RRC改变UE的P_A值。 然后RRC开始
RrcConnectionReconfiguration 函数通知 UE 新的配置。 后
RrcConnectionReconfiguration成功,RRC可以通过调用为UE设置P_A值
来自 CphySap 的函数 SetPa,值保存在包含 P_A 值的新映射 m_paMap 中
对于 eNb 服务的每个 UE。

当 LteEnbPhy 开始新的子帧时,处理 DCI 控制消息以获得矢量
用过的RB。 现在还有 GeneratePowerAllocationMap(uint16_t rnti, int rbId) 函数也是
叫。 此函数检查 UE 的 P_A 值,为每个 RB 生成功率并将其存储在
m_dlPowerAllocationMap。 然后这张地图被使用
创建 Ptr 的 CreateTxPowerSpectralDensityWithPowerAllocation 函数
txPsd。

PdschConfigDedicated (TS 36.331, 6.3.2 PDSCH-Config) 添加到
LteRrcSap::PhysicalConfigDedicated 结构体,用于 RrcConnectionReconfiguration
的过程。

上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护
上行链路功率控制控制不同上行链路物理层的发射功率
渠道。 此功能在 3GPP TS 36.213 第 5 节中进行了描述。

上行链路功率控制默认启用,可以通过属性系统禁用:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (false));

实现了两种上行链路功率控制机制:

· 开环上行链路功率控制:UE 传输功率取决于对
下行链路路径损耗和信道配置

· 闭环上行链路功率控制:与开环一样,另外 eNB 可以控制 UE
通过显式传输功率控制 TPC 命令传输功率
在下行传输。

要在这两种机制类型之间切换,应该更改参数:

Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));

默认情况下,闭环功率控制处于启用状态。

模式 of 不营业 循环 上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护 旨在 可供选择:

· 绝对模式:TxPower 是用绝对 TPC 值计算的

· 累积模式:TxPower 是用累积的 TPC 值计算的

要在这两种模式之间切换,应该更改参数:

Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

默认情况下,累积模式启用,DL-DCI 中的 TPC 命令由所有设置
调度程序为 1,在累积模式中映射到值 0。

上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护 普施
物理上行链路共享信道 (PUSCH) 的 UE 传输功率设置
传输定义如下:

· 如果 UE 为服务小区 c 发送 PUSCH 而没有同步的 PUCCH,则
UE 在子帧 i 中用于 PUSCH 传输的发射功率 P_{PUSCH,c}(i)
服务小区 c 由下式给出:

·如果UE同时为服务小区c发送PUSCH和PUCCH,则UE
子帧 i 中 PUSCH 传输的发射功率 P_{PUSCH,c}(i)
服务小区 c 由下式给出:

由于未实现 PUCCH 的上行链路功率控制,因此未实现这种情况
以及。

· 如果 UE 没有为服务小区 c 传输 PUSCH,则用于累积
为 PUSCH 接收到带有 DCI 格式 3/3A 的 TPC 命令,UE 应假定 UE
子帧 i 中 PUSCH 传输的发射功率 P_{PUSCH,c}(i)
服务小区 c 由下式计算

其中:

· P_{CMAX,c}(i) 是 3GPP 36.101 中定义的配置的 UE 发射功率。 桌子
6.2.2-1在服务小区c的子帧i中,{P}_{CMAX,c}(i)为线性值
P_{CMAX,c}(i)。 P_{CMAX,c}(i) 的默认值为 23 dBm

· M_{PUSCH,c}(i)是PUSCH资源分配的带宽,表示为
对子帧 i 和服务小区 c 有效的资源块数。

· P_{O_PUSCH,c}(j)是由一个分量的和组成的参数
P_{O_NOMINAL_PUSCH,c}(j) 从高层为 j={0,1} 和一个组件提供
P_{O_UE_PUSCH,c}(j) 由更高层为 j={0,1} 为服务小区 c 提供。
SIB2消息需要扩展携带这两个组件,但目前
它们可以通过属性系统设置:

Config::SetDefault ("ns3::LteUePowerControl::PoNominalPusch", IntegerValue (-90));
Config::SetDefault ("ns3::LteUePowerControl::PoUePusch", IntegerValue (7));

· lpha_{c} (j) 是上层提供的 3 位参数,当 ightinForelj=2 时,
对于 j=0,1, lpha_c 在 t 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1
lpha_{c} (j) = 1。该参数可由属性系统配置:

Config::SetDefault ("ns3::LteUePowerControl::Alpha", DoubleValue (0.8));

· PL_{c}是UE为服务小区c计算的下行链路路径损耗估计
以 dB 为单位,PL_{c} = referenceSignalPower – 更高层过滤的 RSRP,其中
referenceSignalPower 由高层和 RSRP 提供。 参考信号功率
在 SIB2 消息中提供

· cond case 被执行。

· f_{c}(i) 是闭环功率控制的组成部分。 是当前的PUSCH功率
服务小区c的控制调整状态。

如果启用累积模式,f_{c}(i) 由下式给出:

其中: elta_{PUSCH,c} 为校正值,也称为 TPC 命令
与DCI一起包含在PDCCH中; elta_{PUSCH,c}(i - K_{PUSCH}) 已发出信号
PDCCH/EPDCCH,在子帧 (i - K_{PUSCH}) 上具有用于服务小区 c 的 DCI; K_{PUSCH} =
4 为 FDD。

如果 UE 已达到服务小区 c 的 P_{CMAX,c}(i),则针对
服务小区c不被累积。 如果 UE 已达到最小功率,则为负
不累积 TPC 命令。 最小 UE 功率在 TS36.101 中定义
第 6.2.3 节。 默认值为 -40 dBm。

如果未启用累积模式,则 f_{c}(i) 由下式给出:

其中: elta_{PUSCH,c} 为校正值,也称为 TPC 命令
与DCI一起包含在PDCCH中; elta_{PUSCH,c}(i - K_{PUSCH}) 已发出信号
PDCCH/EPDCCH,在子帧 (i - K_{PUSCH}) 上具有用于服务小区 c 的 DCI; K_{PUSCH} =
4 为 FDD。

将 DCI 格式 0/3/4 中的 TPC 命令字段映射到绝对和累积
elta_{PUSCH,c} 值在 TS36.231 第 5.1.1.1 节表 5.1.1.1-2 中定义

上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护 公共信道信道
由于所有上行链路控制消息都是理想消息并且不消耗任何无线电
资源,不需要PUCCH的上行链路功率控制,也没有实现。

上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护 SRS
在子帧 i 上传输的 SRS 的 UE 传输功率 P_{SRS} 的设置
服务小区 c 定义为

其中:

· P_{CMAX,c}(i) 是 3GPP 36.101 中定义的配置的 UE 发射功率。 桌子
6.2.2-1。 P_{CMAX,c}(i) 的默认值为 23 dBm

· P_{SRS_OFFSET,c}(m) 由高层半静态配置,m=0,1
服务小区 c . 对于给定触发类型 0 的 SRS 传输,则 m=0,1 并且对于 SRS
传输给定触发类型 1 然后 m=1。 对于 K_{s} = 0 P_Srs_Offset_Value 是
用等式计算:

此参数可由属性系统配置:

Config::SetDefault ("ns3::LteUePowerControl::PsrsOffset", IntegerValue (7));

· M_{SRS,c}为服务小区在子帧i的SRS传输带宽
c 以资源块的数量表示。 在当前实现中发送 SRS
在整个 UL 带宽。

· f_{c}(i)为服务小区c当前PUSCH功控调整状态,
如定义 上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护 普施

· P_{O_PUSCH,c}(j) 和 lpha_{c}(j) 是定义在 上行 电力
通过积极争取让商标与其相匹配的域名优先注册来维护 普施, 其中 j = 1 。

分数 频率 重用
概述
本节描述了 ns-3 对分数频率重用算法的支持。 全部
[ASHamza2013] 中描述了实现的算法。 目前有7种FR算法
已实施:

· ns3::LteFrNoOp算法

· ns3::LteFrHard算法

· ns3::LteFrStrict算法

· ns3::LteFrSoft算法

· ns3::LteFFrSoft算法

· ns3::LteFfr增强算法

· ns3::LteFfr分布式算法

创建了新的 LteFfrAlgorithm 类,它是频率重用的抽象类
算法实现。 此外,还添加了 FR-Scheduler 和 FR-RRC 之间的两个新 SAP。
[image] FR算法调度时序图.UNINDENT

数字 序列 图表 of 调度 - FR 算法 显示时序图
用FR算法调度进程。 在调度过程开始时,调度器
向 FR 实体询问可用的 RBG。 根据实施 FR 返回所有 RBG
在单元格中可用或根据其策略过滤它们。 然后当尝试分配一些
RBG 到 UE,调度程序询问 FR 实体是否允许此 RBG 用于此 UE。 当FR回来时
true,调度程序可以将此 RBG 分配给此 UE,如果不是,则调度程序正在检查另一个 RBG
对于这个UE。 同样,FR 响应取决于应用到 UE 的实现和策略。

支持 FR 算法
没有 频率 重用
NoOp FR 算法(LteFrNoOpAlgorithm 类)是 Full Frequency Reuse 的实现
方案,这意味着同一网络的 eNB 之间不执行频率分区
(频率复用因子,FRF 等于 1)。 eNB 使用整个系统带宽并传输
对所有 RBG 具有统一的权力。 是最简单的方案,也是最基本的方式
运营 LTE 网络。 该方案允许实现高峰值数据速率。 但
另一方面,由于来自相邻小区的严重干扰电平,小区边缘
用户性能受到很大限制。

数字 频率 重用 方案 下面介绍了完整的频率和功率计划
频率重用方案。
[image] 全频复用方案.UNINDENT

在 ns-3 中,NoOp FR 算法总是允许调度器使用全带宽并允许
所有 UE 使用任何 RBG。 它只是没有做任何新的事情(即它不限制 eNB
带宽,禁用 FR 算法),它是 FrAlgorithm 的最简单实现
类,默认安装在 eNb 中。

频率 重用
硬频率重用算法提供了最简单的方案,可以减少
小区间干扰电平。 在该方案中,整个频率带宽被划分为
几个(通常是 3、4 或 7)个不相交的子带。 相邻的eNB分配不同的
子带。 频率复用因子等于子带的数量。 该方案允许
显着降低小区边缘的ICI,从而提高小区用户的性能。
但由于每个 eNB 只使用整个带宽的一部分,即峰值数据速率
level 也减少了等于重用因子的因子。

数字 频率 重用 方案 下面介绍了 Hard 的频率和功率计划
频率重用方案。
[图片] 硬频率重用方案.UNINDENT

在我们的实现中,Hard FR 算法只有 RBG 向量可用于 eNB
并在调度功能期间将其传递给 MAC 调度程序。 当调度程序询问时,RBG 是否
允许特定的 UE,它总是返回 true。

监督 频率 重用
严格频率复用方案是全频率复用方案和硬频率复用方案的组合。 它
包括将系统带宽分成两部分,这将有不同的
频率复用。 每个小区内部使用系统带宽的一个公共子带
(频率重用-1),而带宽的另一部分被分配给
相邻的eNB,如硬频率复用(frequency reuse-N, N>1),为了创建
每个扇区中一个具有低小区间干扰电平的子带。 中心 UE 将是
授予完全重用的频率块,而小区边缘 UE 具有正交块。
这意味着来自一个小区的内部 UE 不与来自一个小区的边缘 UE 共享任何频谱
第二个小区,这减少了对两者的干扰。 可以注意到,严格的 FR 需要
总共 N + 1 个子带,并允许在 1 和 3 之间的中间实现 RFR。

数字 监督 频率 重用 方案 下面介绍了 Strict 的频率和功率计划
小区边缘复用因子 N = 3 的频率复用方案。
[图片] 严格的频率重用方案.UNINDENT

在我们的实现中,严格 FR 算法有两个映射,每个子带一个。 如果UE
可以在专用子带内提供服务,其 RNTI 被添加到 m_privateSubBandUe 映射。 如果
UE 可以在公共子带内得到服务,其 RNTI 被添加到 m_commonSubBandUe 映射中。
严格的 FR 算法需要决定应该在哪个子带内为 UE 提供服务。 它用
RRB 提供的 UE 测量结果与信号质量阈值(本
参数可以很容易地通过属性机制进行调整)。 阈值有影响
内部与小区半径之比。

频率 重用
在软频率复用 (SFR) 方案中,每个 eNb 在整个系统带宽上传输,
但是有两个子带,在 UE 内以不同的功率级别提供服务。 自从
小区中心UE与相邻小区共享带宽,它们通常以较低的速率传输
功率水平低于小区边缘 UE。 SFR 比 Strict FR 的带宽效率更高,
因为它使用了整个系统带宽,但也会对两者造成更多干扰
小区内部和边缘用户。

SFR 方案有两种可能的版本:

· 在第一个版本中,专用于小区边缘 UE 的子带也可以被使用
小区中心 UE,但功率水平降低且仅当它未被占用时
小区边缘UE。 小区中心子带仅可用于中心 UE。 数字
频率 重用 方案 版本 1 下面介绍了频率和功率计划
这个版本的软频率重用方案。
[图片] Soft Frequency Reuse scheme version 1.UNINDENT

· 在第二个版本中,小区中心UE 无法访问小区边缘子带。 在
这样,每个小区都可以使用整个系统带宽,同时减少
对相邻小区的干扰。 另一方面,较低的 ICI 水平
小区边缘是以较低的频谱利用率为代价实现的。 数字
频率 重用 方案 版本 2 下面介绍了这个的频率和功率计划
软频率重用方案的版本。
[图片] Soft Frequency Reuse scheme version 2.UNINDENT

SFR 算法维护两个映射。 如果 UE 应以较低的功率电平提供服务,则其
RNTI 被添加到 m_lowPowerSubBandUe 映射。 如果UE应该以更高的功率服务
级别,其 RNTI 被添加到 m_highPowerSubBandUe 映射。 决定使用哪个功率级别
应该为 UE 提供服务 SFR 算法利用 UE 测量值,并将它们与
临界点。 inner的信号质量阈值和PdschConfigDedicated(即P_A值)
外部区域可以通过属性系统进行配置。 SFR 利用下行链路功率
此处描述控制。

分数 频率 重用
软分数频率复用 (SFFR) 是严格频率和软频率的组合
重用方案。 虽然 Strict FR 不使用分配给外部区域的子带
相邻小区,软 FFR 将这些子带用于具有低发射功率的内部 UE。 作为
因此,SFFR 与 SFR 一样,使用发射功率电平高且发射功率低的子带
发射功率电平。 与 Soft FR 和 Strict FR 不同,Soft FFR 使用常见的
可以提高内部用户吞吐量的子带。

数字 分数 分数 频率 重用 方案 下面介绍频率和
软分数频率重用的电源计划。
[图片] 软分数分数频率重用方案.UNINDENT

品牌影响力提升 分数 频率 重用
[ZXie2009] 中描述的增强型分数频率复用 (EFFR) 定义了 3 种细胞类型
对于蜂窝系统中直接相邻的小区,并为每个小区类型保留一个
整个频段的一部分命名为 分割, 在不同类型的细胞中
应该是正交的。 其余子通道构成 二次 分割。 该
分割 细胞类型的同时是 二次 业务领域
属于另外两种细胞类型。 每个小区可以占用其所有子信道
分割 随意,而只有一部分子通道在 二次 分割 可以使用
由这个小区以干扰感知的方式。 分割 每个细胞被分割
分为 reuse-3 部分和 reuse-1 部分。 reuse-1部分可以被所有类型的cell复用
在系统中,而 reuse-3 部分只能被其他相同类型独占重用
小区(即 reuse-3 子信道不能被直接相邻的小区重新使用)。 上
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 二次 分割 小区作为客人,占用次要子信道是
实际上重用属于直接相邻小区的主要子信道,因此
重用 二次 分割 每个单元格应符合两个规则:

· 使用前监测

· 基于SINR估计的资源复用

每个小区始终监听每个辅助子信道。 在占领之前,它
根据收集到的信道质量信息(CQI)进行SINR评估,
选择具有最佳估计值的资源进行重用。 如果 RBG 的 CQI 值高于
为某些用户配置的阈值,可以使用此执行此用户的传输
红绿蓝。

[ZXie2009]中描述了调度过程,它包括三个步骤和两个
调度策略。 由于当前实现的调度程序都不允许这样做
行为,应用了一些简化。 在我们的实现中,reuse-1 子通道可以
仅供手机中心用户使用。 Reuse-3 子信道可以被边缘用户使用,并且只有
如果没有边缘用户,可以在reuse-3中为小区中心用户传输
子频道。

数字 品牌影响力提升 分数 分数 频率 重用 方案 下面介绍频率和
增强型部分频率复用的电源计划。
[图片] 增强型分数频率重用方案.UNINDENT

分布式 分数 频率 重用
这种分布式分数频率重用算法在 [DKimura2012] 中提出。 它
通过关注用户分布自动优化小区边缘子带(在
特别是接收功率分配)。 该算法自适应地选择 RBs
基于来自相邻小区的协调信息的小区边缘子带并通知
相邻小区的基站,其选择在边缘子带中使用哪些RB。
每个小区的基站使用接收到的信息和以下等式来
计算每个 RB 的小区边缘带度量 A_{k}。

其中 J 是一组相邻小区,X_{j,k}=0,1 是来自第 j 个相邻小区的 RNTP。
当第j个邻区的第k个RB作为cell-edge时取值为1
子带,否则为 0。 符号 w_{j} 表示相对于相邻单元格 j 的权重,
也就是说,信号功率之间的差异的用户数量
从服务小区 i 接收到的信号功率和从相邻小区接收到的信号功率
小区 j 小于阈值(即小区边缘附近的用户数
服务单元)。 较大的接收功率差异意味着第 i 个小区边缘用户
小区受到第j个小区的强干扰。

度量 A_{k} 最小的 RB 被认为受以下因素影响最小
来自另一个小区的干扰。 服务小区选择配置数量的RB作为
以 A_{k} 升序排列的小区边缘子带。 结果,其中一个小的 RB
小区边缘用户的数量受到相邻基站的高干扰
选择。

然后将更新后的 RNTP 发送到所有相邻小区。 为了避免无意义的
小区边缘频带选择的振荡,基站忽略来自另一个基站的 RNTP
cell ID 大于基站的基站。

在所有小区中重复此过程可以将 RB 分配到小区边缘区域
在整个系统中进行优化,并随着用户分布的变化进行调整。

数字 序列 图表 of 分布式 频率 重用 方案 下面呈现顺序
分布式部分频率复用方案图。
[image] 分布式频率复用方案时序图.UNINDENT

助手
两个辅助对象用于设置模拟和配置各种组件。
这些对象是:

· 莱特助手,它负责 LTE 无线电接入网络的配置,如
以及协调 EPS 承载的设置和释放。 这 莱特助手
提供 API 定义及其实现。

· Epc助手,它负责演进分组核心的配置。 这
Epc助手 class是一个抽象基类,只提供API定义; 这
实现被委托给子类以允许不同的 EPC
网络模型。

可以通过使用创建一个简单的纯 LTE 模拟 莱特助手 独自一人,或
通过使用两者创建完整的 LTE-EPC 模拟 莱特助手Epc助手. 当两个
使用助手,他们以主从方式交互,与 莱特助手 做主人
直接与用户程序交互,以及 Epc助手 在“引擎盖下”工作
根据调用的显式方法配置 EPC 莱特助手. 确切的相互作用是
如图所示 序列 图表 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 ,增强互动体验。 之间 莱特助手
Epc助手.
[图片] LteHelper与EpcHelper.UNINDENT交互时序图

用户 文件记录
背景
我们假设读者已经熟悉如何使用 ns-3 模拟器来运行通用
模拟程序。 如果不是这种情况,我们强烈建议读者咨询
[ns3教程]。

用法 概述
ns-3 LTE 模型是一个允许模拟 LTE 网络的软件库,
可选地包括演进分组核心 (EPC)。 执行这样的过程
模拟通常包括以下步骤:

1. 确定 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 脚本 被模拟

2. 填写 a 模拟 程序 重新创建所需的场景
拓扑/架构。 这是通过使用访问 ns-3 LTE 模型库完成的
ns3::LteHelper API定义于 src/lte/helper/lte-helper.h.

3. 指定 配置 参数 正在用于的对象的
模拟。 这可以使用输入文件(通过 ns3::配置库),或
直接在模拟程序中。

4. 配置 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 期望 产量 由模拟器产生

5. 运行 模拟。

所有这些方面都将在以下各节中通过实际操作进行解释
例子。

基础版 模拟 程序
这是进行仅 LTE 模拟所需的最小模拟程序
(没有 EPC)。

1.初始样板:

#包括
#包括
#包括
#包括

使用命名空间 ns3;

int main (int argc, char *argv[])
{
// 模拟程序的其余部分如下

2。 创建一个 莱特助手 宾语:

指针lteHelper = CreateObject ();

这将实例化一些通用对象(例如 Channel 对象)并提供
添加 eNB 和 UE 并配置它们的方法。

3。 创建 Node eNB 和 UE 的对象:

节点容器 enbNodes;
enbNodes.Create(1);
节点容器ueNodes;
ueNodes.Create(2);

请注意,此时上述 Node 实例仍然没有 LTE 协议
堆叠安装; 它们只是空节点。

4. 为所有节点配置移动模型:

MobilityHelper 移动性;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
移动性。安装(enbNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
移动性.安装(ueNodes);

以上将把所有节点放在坐标 (0,0,0) 处。 请参阅
有关如何设置自己的位置或配置的 ns-3 移动模型的文档
节点运动。

5. 在 eNB 上安装 LTE 协议栈:

NetDeviceContainer enbDevs;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6、在UE上安装LTE协议栈:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. 将 UE 连接到 eNB。 这将根据 eNB 配置每个 UE
配置,并在它们之间创建 RRC 连接:

lteHelper->Attach (ueDevs, enbDevs.Get (0));

8. 激活每个 UE 和它所连接的 eNB 之间的数据无线承载:

枚举 EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
EpsBearer 承载(q);
lteHelper->ActivateDataRadioBearer (ueDevs, bearer);

此方法还将为该承载激活两个饱和流量生成器,一个
在上行链路和一个在下行链路。

9.设置停止时间:

模拟器::停止(秒(0.005));

这是必需的,否则模拟将永远持续下去,因为(除其他外)
start-of-subframe 事件被重复调度,ns-3 模拟器调度器将
因此永远不会用完事件。

10. 运行模拟:

模拟器::运行();

11.清理退出:

模拟器::销毁();
0返回;
}

如何编译和运行仿真程序,请参考[ns3tutorial]。

配置 of LTE的 模型 参数
所有相关的 LTE 模型参数都通过 ns-3 属性系统进行管理。
请参考 [ns3tutorial] 和 [ns3manual] 以获得所有的详细信息
可能的方法(环境变量、C++ API、GtkConfigStore...)。

在下文中,我们只是简要总结了如何使用输入文件以及
ns-3 配置库。 首先,您需要将以下内容放入您的模拟中
程序,紧随其后 () 开始:

命令行 cmd;
cmd.Parse(argc, argv);
ConfigStore 输入配置;
inputConfig.ConfigureDefaults();
// 再次解析,以便您可以从命令行覆盖默认值
cmd.Parse(argc, argv);

为了使上述工作正常,请确保您也 的#include “ns3/config-store.h”. 现在创建一个
命名的文本文件(例如) 输入-defaults.txt 指定新的默认值
你想用于某些属性:

默认 ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
默认 ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
默认 ns3::LteEnbNetDevice::UlBandwidth "25"
默认 ns3::LteEnbNetDevice::DlBandwidth "25"
默认 ns3::LteEnbNetDevice::DlEarfcn "100"
默认 ns3::LteEnbNetDevice::UlEarfcn "18100"
默认 ns3::LteUePhy::TxPower "10"
默认 ns3::LteUePhy::NoiseFigure "9"
默认 ns3::LteEnbPhy::TxPower "30"
默认 ns3::LteEnbPhy::NoiseFigure "5"

假设你的模拟程序被调用 src/lte/示例/lte-sim-with-input,你可以直接在这个页面上
现在通过以下方式将这些设置传递给模拟程序:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --运行 src/lte/examples/lte-sim-with-input

此外,您可以使用以下命令生成模板输入文件:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --运行 src/lte/examples/lte-sim-with-input

请注意,上面将放入文件 输入-defaults.txt 所有 默认值
已在您的特定模拟器版本中注册,包括许多非 LTE
属性。

配置 LTE的 MAC 调度
用户可以在此处选择多种类型的 LTE MAC 调度程序。 用户可以使用以下
定义调度程序类型的代码:

指针lteHelper = CreateObject ();
lteHelper->SetSchedulerType ("ns3::FdMtFfMacScheduler"); // FD-MT调度器
lteHelper->SetSchedulerType ("ns3::TdMtFfMacScheduler"); // TD-MT调度器
lteHelper->SetSchedulerType ("ns3::TtaFfMacScheduler"); // TTA调度器
lteHelper->SetSchedulerType ("ns3::FdBetFfMacScheduler"); // FD-BET 调度器
lteHelper->SetSchedulerType ("ns3::TdBetFfMacScheduler"); // TD-BET 调度器
lteHelper->SetSchedulerType ("ns3::FdTbfqFfMacScheduler"); // FD-TBFQ 调度器
lteHelper->SetSchedulerType ("ns3::TdTbfqFfMacScheduler"); // TD-TBFQ 调度器
lteHelper->SetSchedulerType ("ns3::PssFfMacScheduler"); //PSS调度器

TBFQ 和 PSS 比其他调度器有更多的参数。 用户可以定义那些参数
通过以下方式:

* TBFQ 调度器::

指针lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("DebtLimit", IntegerValue(yourvalue)); // 默认值 -625000 字节 (-5Mb)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(yourvalue)); // 默认值 625000 字节 (5Mb)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(yourvalue)); // 默认值 1 字节
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(yourvalue)); // 默认值 0

* PSS 调度器::

指针lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("nMux", UIntegerValue(yourvalue)); // TD调度器选择的最大UE数
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // PSS 中的 PF 调度器类型

在 TBFQ 中,debt limit 和 credit limit 的默认值设置为 -5Mb 和 5Mb
分别基于论文 [FABokhari2009]。 当前实现不考虑
信用阈值(C = 0)。 在 PSS 中,如果用户没有定义 nMux,PSS 将把这个值设置为
UE总数的一半。 默认的 FD 调度器是 PFsch。

此外,TBFQ 中的令牌生成速率和 PSS 中的目标比特率需要
通过 epc 承载 QoS 中的保证比特率 (GBR) 或最大比特率 (MBR) 配置
参数。 用户可以使用以下代码在下行链路和链路中定义 GBR 和 MBR
上行链路:

指针lteHelper = CreateObject ();
枚举 EpsBearer::Qci q = EpsBearer::yourvalue; //定义Qci类型
GbrQos信息qos;
qos.gbrDl = 你的价值; // 下行GBR
qos.gbrUl = 你的值; // 上行GBR
qos.mbrDl = 你的价值; // 下行MBR
qos.mbrUl = 你的价值; // 上行MBR
EpsBearer 承载(q,qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, bearer, EpcTft::Default ());

在 PSS 中,TBR 是从承载级 QoS 参数中的 GBR 获得的。 在 TBFQ 中,代币生成
速率是从承载级别 QoS 参数中的 MBR 设置获得的,因此
需要一致地配置。 对于恒定比特率 (CBR) 流量,建议
将 MBR 设置为 GBR。 对于方差比特率(VBR)流量,建议设置MBR k次
大于 GBR 以覆盖峰值流量速率。 在当前的实现中,k 是
根据论文 [FABokhari2009] 设置为 XNUMX。 此外,当前版本的 TBFQ 不
考虑 MBR 和 GBR 中的 RLC 标头和 PDCP 标头长度。 TBFQ 中的另一个参数是
数据包到达率。 该参数在scheduler内部计算,等于过去
PF 调度器中使用的平均吞吐量。

下面将描述 LTE-EPC 模型的许多有用属性
小节。 尽管如此,仍有许多属性未在规范中明确提及
设计或用户文档,但使用 ns-3 属性明确记录
系统。 您可以轻松地打印给定对象的属性列表以及
他们的描述和默认值传递 --打印属性= 模拟程序,
喜欢这个:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

您也可以尝试使用其他 LTE 和 EPC 对象,如下所示:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"

教学帖子 输出
ns-3 LTE模型目前支持PHY、MAC、RLC和PDCP级别的输出到文件
关键绩效指标 (KPI)。 您可以通过以下方式启用它:

指针lteHelper = CreateObject ();

// 在这里配置所有的模拟场景...

lteHelper->EnablePhyTraces();
lteHelper->EnableMacTraces();
lteHelper->EnableRlcTraces();
lteHelper->EnablePdcpTraces();

模拟器::运行();

RLC 和 PDCP KPI 在一定时间间隔内计算并存储在 ASCII 文件中,其中两个用于
RLC KPI 和两个用于 PDCP KPI,在每种情况下一个用于上行链路,一个用于下行链路。 时间
可以使用属性控制间隔持续时间
ns3::RadioBearerStatsCalculator::EpochDuration.

RLC KPI 文件的列如下(上行和下行相同):

1. 模拟开始后测量间隔的开始时间,以秒为单位

2. 模拟开始后测量间隔的结束时间,以秒为单位

3. 小区标识

4.唯一UE ID(IMSI)

5.小区特定UE ID(RNTI)

6.逻辑频道ID

7. 传输的RLC PDU数

8. 传输的总字节数。

9.接收到的RLC PDU数量

10. 接收到的总字节数

11. 以秒为单位的平均 RLC PDU 延迟

12. RLC PDU延迟的标准偏差

13. RLC PDU延迟的最小值

14. RLC PDU延迟的最大值

15. 平均 RLC PDU 大小,以字节为单位

16. RLC PDU大小的标准偏差

17. 最小 RLC PDU 大小

18. 最大 RLC PDU 大小

同样,PDCP KPI 文件的列如下(同样,上行链路相同
和下行):

1. 模拟开始后测量间隔的开始时间,以秒为单位

2. 模拟开始后测量间隔的结束时间,以秒为单位

3. 小区标识

4.唯一UE ID(IMSI)

5.小区特定UE ID(RNTI)

6.逻辑频道ID

7. 发送的PDCP PDU数

8. 传输的总字节数。

9.接收到的PDCP PDU数

10. 接收到的总字节数

11. 以秒为单位的平均 PDCP PDU 延迟

12. PDCP PDU延迟的标准偏差

13. PDCP PDU延迟的最小值

14. PDCP PDU延迟的最大值

15. 平均 PDCP PDU 大小,以字节为单位

16. PDCP PDU大小的标准偏差

17. 最小 PDCP PDU 大小

18.最大PDCP PDU大小

MAC KPI 基本上是调度程序报告的资源分配跟踪
每个子帧的开始。 它们存储在 ASCII 文件中。 对于下行链路 MAC KPI,
格式如下:

1. 调度程序指示分配的模拟时间(以秒为单位)

2. 小区标识

3.唯一UE ID(IMSI)

4.车架号

5.子帧号

6.小区特定UE ID(RNTI)

7. TB 1 的 MCS

8. TB 1 的大小

9. TB 2 的 MCS(如果不存在则为 0)

10. TB 2 的大小(如果不存在则为 0)

而对于上行链路 MAC KPI,格式为:

1. 调度程序指示分配的模拟时间(以秒为单位)

2. 小区标识

3.唯一UE ID(IMSI)

4.车架号

5.子帧号

6.小区特定UE ID(RNTI)

7. 结核病的 MCS

8.结核大小

用于 MAC KPI 输出的文件名可以通过 ns-3 属性自定义
ns3::MacStatsCalculator::DlOutputFilenamens3::MacStatsCalculator::UlOutputFilename.

PHY KPI 分布在七个不同的文件中,可通过属性进行配置

1. ns3::PhyStatsCalculator::DlRsrpSinrFilename

2. ns3::PhyStatsCalculator::UeSinrFilename

3. ns3::PhyStatsCalculator::InterferenceFilename

4. ns3::PhyStatsCalculator::DlTxOutputFilename

5. ns3::PhyStatsCalculator::UlTxOutputFilename

6. ns3::PhyStatsCalculator::DlRxOutputFilename

7. ns3::PhyStatsCalculator::UlRxOutputFilename

在 RSRP/SINR 文件中,提供以下内容:

1. 调度程序指示分配的模拟时间(以秒为单位)

2. 小区标识

3.唯一UE ID(IMSI)

4. 建议零售价

5. 线性单位下行链路 SINR 的所有 RB 的线性平均

UE SINR文件中的内容为:

1. 调度程序指示分配的模拟时间(以秒为单位)

2. 小区标识

3.唯一UE ID(IMSI)

4. UE 的线性单位的上行链路 SINR

在干扰文件名中的内容是:

1. 调度程序指示分配的模拟时间(以秒为单位)

2. 小区标识

3.每个RB的干扰值列表

在 UL 和 DL 传输文件中,包含的参数是:

1. 以毫秒为单位的模拟时间

2. 小区标识

3.唯一UE ID(IMSI)

4.RNTI

5.传输层

6.多维控制系统

7. TB的大小

8.冗余版本

9. 新数据指标标志

最后,在 UL 和 DL 接收文件中,包含的参数是:

1. 以毫秒为单位的模拟时间

2. 小区标识

3.唯一UE ID(IMSI)

4.RNTI

5.传输方式

6.传输层

7.多维控制系统

8. TB的大小

9.冗余版本

10. 新数据指标标志

11. TB接收的正确性

衰退 追踪 用法
在本节中,我们将描述如何在 LTE 模拟中使用衰落轨迹。

衰退 痕迹
可以使用随附的专用 matlab 脚本生成衰落轨迹
代码 (/lte/model/fading-trace/fading-trace-generator.m). 这个脚本已经包含
三种 3GPP 场景(即行人、车辆和
[TS2] 的附件 B.36104 中定义的城市); 但是用户也可以介绍他们的
具体配置。 可配置参数的列表在
在以下:

· fc :使用的频率(它影响多普勒速度的计算)。

· v_公里_小时 : 用户的速度

· 跟踪持续时间 :跟踪总长度的持续时间(以秒为单位)。

· 数量RBs :要评估的资源块的编号。

· 行李牌 :要应用于生成的文件的标记。

生成的文件包含以矩阵方式组织的 ASCII 格式实数值:
每一行对应一个不同的RB,每一列对应一个不同的RB
时间衰落跟踪样本。

必须注意的是,ns-3 LTE 模块能够处理任何衰落跟踪文件
符合上述 ASCII 格式。 因此,其他外部工具可以
用于生成自定义衰落轨迹,例如其他模拟器或
实验装置。

衰退 痕迹 用法
使用衰落轨迹时,正确指定轨迹至关重要
模拟中的参数,以便衰落模型可以正确加载和使用它。 这
需要配置的参数有:

· 跟踪文件名 :要加载的迹线名称(绝对路径,或相对路径
wrt 模拟程序执行的路径);

· 轨迹长度 : 以秒为单位的跟踪持续时间;

· 样本数 : 样本数;

· 窗口大小 : 衰落采样窗口的大小,以秒为单位;

重要的是要强调衰落轨迹的采样间隔必须为 1 ms
或更大,在后一种情况下,它必须是 1 毫秒的整数倍才能
由衰落模块正确处理。

matlab 脚本的默认配置提供了一个 10 秒长的跟踪,由
10,000 个样本(即,每个 TTI = 1 毫秒 1 个样本)并使用 0.5 秒的窗口大小
振幅。 这些也是上面使用的参数的默认值
模拟器; 因此,如果褪色痕迹尊重它们,则可以避免它们的设置。

为了激活衰落模块(默认情况下未激活)以下代码
应包含在模拟程序中:

指针lteHelper = CreateObject ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

并设置参数:

lteHelper->SetFadingModelAttribute ("TraceFilename", StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute ("TraceLength", TimeValue (Seconds (10.0)));
lteHelper->SetFadingModelAttribute ("SamplesNum", UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("WindowSize", TimeValue (Seconds (0.5)));
lteHelper->SetFadingModelAttribute ("RbNum", UintegerValue (100));

需要注意的是, 跟踪文件名 没有默认值,因此必须
始终明确设置。

模拟器本身提供了三个根据生成的衰落轨迹
[TS2] 的附件 B.36104 中定义的配置。 这些痕迹可在
src/lte/模型/衰落痕迹/). 这些痕迹的摘录显示在
以下数字。
[图片:衰落痕迹 3 kmph] [图片] 衰落痕迹的摘录包含在
行人场景模拟器(时速 3 公里)..UNINDENT
[图片:衰落痕迹 60 kmph] [图片] 衰落痕迹的摘录包含在
车辆场景模拟器(时速 60 公里)..UNINDENT
[图片:衰落痕迹 3 kmph] [图片] 衰落痕迹的摘录包含在
城市场景模拟器(时速 3 公里)..UNINDENT

流动性 型号 - Buildings
我们现在通过示例解释如何使用建筑物模型(特别是
移动建筑信息建立传播模型 ns-3 模拟中的类)
用于设置包括建筑物和室内节点的 LTE 模拟场景的程序。

1.需要包含的头文件:

#包括
#包括
#包括

2. Pathloss模型选择:

指针lteHelper = CreateObject ();

lteHelper->SetAttribute ("PathlossModel", StringValue ("ns3::BuildingsPropagationLossModel"));

3. EUTRA频段选择

传播模型的工作频率的选择必须与
标准 ns-3 属性系统,如相应部分所述(“配置
LTE模型参数”)通过DlEarfcn和UlEarfcn参数,例如:

lteHelper->SetEnbDeviceAttribute("DlEarfcn", UintegerValue (100));
lteHelper->SetEnbDeviceAttribute("UlEarfcn", UintegerValue (18100));

需要注意的是,使用其他方式来配置所使用的频率
传播模型(即配置相应的 BuildingsPropagationLossModel
直接属性)可能会在频率定义中产生冲突
模拟期间的模块,因此不建议。

1.移动模型选择:

MobilityHelper 移动性;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");

需要注意的是,可以使用任何移动模型。

2. 建筑创作:

双 x_min = 0.0;
双 x_max = 10.0;
双 y_min = 0.0;
双 y_max = 20.0;
双 z_min = 0.0;
双 z_max = 10.0;
点b = 创建对象();
b->SetBoundaries (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Building::Residential);
b->SetExtWallsType (Building::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNroomsX (3);
b->SetNroomsY (2);

这将实例化一座住宅建筑,其底部为 10 x 20 米,高度为
10米,外墙为混凝土,有窗; 该建筑有三个
楼层,并有一个内部 3 x 2 大小相同的房间网格。

3、节点创建与定位:

ueNodes.Create(2);
移动性.安装(ueNodes);
BuildingsHelper::安装(ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
点mm0 = enbNodes.Get (0)->GetObject ();
点mm1 = enbNodes.Get (1)->GetObject ();
mm0->SetPosition (Vector (5.0, 5.0, 1.5));
mm1->SetPosition (Vector (30.0, 40.0, 1.5));

4.完成构建和移动模型配置:

BuildingsHelper::使移动模型一致 ();

请参阅文档 建筑物 模块以获得更详细的信息。

PHY 误差 型号
物理错误模型由数据错误模型和下行链路控制错误组成
模型,默认情况下它们都处于活动状态。 可以使用 ns3 停用它们
属性系统,详细:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

多输入多输出 型号
本小节我们将说明如何配置 MIMO 参数。 LTE定义了7种类型
传输模式:

·传输模式1:SISO。

· 传输模式 2:MIMO Tx 分集。

· 传输模式 3:MIMO 空间复用开环。

·传输模式4:MIMO空间复用闭环。

·传输模式5:MIMO多用户。

· 传输方式6:闭环单层预编码。

· 传输方式7:单天线端口5。

根据实现的模型,模拟器包括前三种传输模式
类型。 默认的是传输模式 1 (SISO)。 为了改变默认
要使用的传输模式,属性 默认传输模式LteEnbrrc 能够
可以使用,如下图:

Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (0)); // 单声道
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (1)); // MIMO Tx 分集(1 层)
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (2)); // MIMO 空间复用(2 层)

用于在模拟特定用户期间更改特定用户的传输模式
接口已在两个标准调度程序中实现:

void TransmissionModeConfigurationUpdate (uint16_t rnti, uint8_t txMode);

该方法既可用于开发传输模式决策引擎(即,用于
根据信道条件和/或用户的优化传输模式
要求)和从模拟脚本手动切换。 在后一种情况下,
可以如下所示进行切换:

指针lteEnbDev = enbDevs.Get (0)->GetObject ();
指针值 ptrval;
enbNetDev->GetAttribute ("FfMacScheduler", ptrval);
指针rrsched = ptrval.Get ();
Simulator::Schedule (Seconds (0.2), &RrFfMacScheduler::TransmissionModeConfigurationUpdate, rrsched, rnti, 1);

最后,所实现的模型可以根据不同的 MIMO 模型进行重新配置
更新增益值(唯一的限制是增益必须在
仿真运行时和图层通用)。 每个传输模式的增益可以是
根据标准的ns3属性系统更改,其中属性为:
TxMode1增益, TxMode2增益, TxMode3增益, TxMode4增益, TxMode5增益, TxMode6增益
TxMode7增益. 仅默认 TxMode1增益, TxMode2增益TxMode3增益 有一个有意义的
值,即由 _[CatreuxMIMO] 导出的值(即分别为 0.0、4.2 和 -2.8
D b)。

使用 VHDL 语言编写 of 天线型号
我们现在展示如何将特定的 AntennaModel 与 eNB 设备相关联,以便对
宏 eNB 的扇区。 为此,使用 余弦天线模型
由 ns-3 天线模块提供。 eNB 的配置将通过
莱特助手 创建之前的实例 启用网络设备,如图所示
在以下:

lteHelper->SetEnbAntennaModelType ("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute("方向", DoubleValue (0));
lteHelper->SetEnbAntennaModelAttribute ("波束宽度", DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute("MaxGain", DoubleValue (0.0));

上面的代码将生成一个具有 60 度波束宽度指向的天线模型
X 轴。 方向以 X 轴的度数为单位进行测量,例如,方向
90 的方向将指向 Y 轴,-90 的方向将指向负方向
沿 Y 轴的方向。 波束宽度是 -3 dB 波束宽度,例如,对于 60 度
beamwidth 角度为 m 的天线增益
与定向方向成 30 度为 -3 dB。

创建多扇区站点,需要创建不同的ns-3节点放置在同一个位置
位置,并单独配置 启用网络设备 具有不同的天线方向
安装在每个节点上。

广播电台 环境 地图
通过使用类 无线电环境地图助手 可以将无线电输出到文件
环境地图 (REM),即代表环境的统一二维值网格
相对于具有最强 eNB 的下行链路信噪比
在每个点发出信号。 可以指定是否应为数据生成 REM 或
控制通道。 用户还可以设置 RbId,将为其生成 REM。 默认 RbId
是 -1,这意味着 REM 将生成所有的平均信噪比
RB。

为此,您只需将以下代码添加到您的模拟程序中
结束,就在调用 Simulator::Run () 之前:

指针remHelper = 创建对象();
remHelper->SetAttribute("ChannelPath", StringValue("/ChannelList/0"));
remHelper->SetAttribute("OutputFile", StringValue("rem.out"));
remHelper->SetAttribute("XMin", DoubleValue (-400.0));
remHelper->SetAttribute("XMax", DoubleValue (400.0));
remHelper->SetAttribute("XRes", UintegerValue (100));
remHelper->SetAttribute("YMin", DoubleValue (-300.0));
remHelper->SetAttribute("YMax", DoubleValue (300.0));
remHelper->SetAttribute ("YRes", UintegerValue (75));
remHelper->SetAttribute("Z", DoubleValue (0.0));
remHelper->SetAttribute ("UseDataChannel", BooleanValue (true));
remHelper->SetAttribute("RbId", IntegerValue (10));
remHelper->安装();

通过配置属性 无线电环境地图助手 如上所示的对象,你
可以调整要生成的 REM 的参数。 请注意,每个
无线电环境地图助手 实例只能生成一个 REM; 如果你想产生更多
REM,您需要为每个 REM 创建一个单独的实例。

请注意,REM 生成要求非常高,特别是:

· 运行时内存消耗约为每个像素 5KB。 例如,REM
分辨率为 500x500 需要大约 1.25 GB 内存,分辨率为
1000x1000 需要大约 5 GB(此时对于普通 PC 来说太多了
写作)。 为了克服这个问题,REM 是在连续的步骤中生成的,每个
步骤最多评估由 the 的值确定的多个像素
属性 RadioEnvironmentMapHelper::MaxPointsPerIteration.

· 如果在模拟开始时生成 REM,它会减慢
执行其余的模拟。 如果要为程序生成 REM
并使用相同的程序来获得模拟结果,建议添加一个
允许生成 REM 或运行完整的命令行开关
模拟。 为此,请注意有一个属性
RadioEnvironmentMapHelper::StopWhenDone (默认值:true)这将强制
模拟在 REM 生成后立即停止。

REM 以下列格式存储在 ASCII 文件中:

·第1列是x坐标

·第2列是y坐标

·第3列是z坐标

· 第 4 列是以线性单位表示的 SINR

下面给出了一个允许您绘制 REM 的最小 gnuplot 脚本:

设置视图地图;
设置 xlabel "X"
设置标签“Y”
设置 cblabel "SINR (dB)"
取消设置键
使用 ($1):($2):(10*log10($4)) 和图像绘制“rem.out”

作为示例,这是可以通过示例程序获得的 REM
lena-dual-stripe,显示同信道部署中的三扇区 LTE 宏蜂窝
一些住宅 femtocell 随机部署在两个公寓楼中。
[图片] 从 lena-dual-stripe example.UNINDENT 获得的 REM

请注意,lena-dual-stripe 示例程序还会生成与 gnuplot 兼容的输出
包含有关 UE 和 eNB 节点位置以及
建筑物,分别在文件中 文件.txt, enbs.txt建筑物.txt。 这些可以
使用 gnuplot 时很容易包含在内。 例如,假设您的 gnuplot 脚本
(例如,上面描述的最小 gnuplot 脚本)保存在一个名为
我的剧情脚本,运行以下命令将绘制 UE、eNB 和
REM顶部的建筑物:

gnuplot -p enbs.txt ues.txtbuildings.txt my_plot_script

资产管理公司 型号 CQI 计算
模拟器针对 MCS 的选择提供了两种可能的方案
并相应地生成 CQI。 第一个是基于GSoC模块
[Piro2011] 并按 RB 为基础工作。 这个模型可以用 ns3 属性激活
系统,如下所示:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));

同时,基于物理误差模型的解决方案可以通过以下方式控制:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::MiErrorModel));

最后,所需的效率 皮罗EW2010 AMC 模块可以调谐感谢
小檗碱 属性(),例如:

Config::SetDefault ("ns3::LteAmc::Ber", DoubleValue (0.00005));

进化 小包装 核心科目 (EPC)
我们现在解释如何编写允许模拟 EPC 的模拟程序
除了 LTE 无线电接入网络。 使用 EPC 允许使用 IPv4 网络
与 LTE 设备。 换句话说,你将能够使用常规的 ns-3 应用程序
LTE 上的 IPv4 和套接字,以及将 LTE 网络连接到任何其他 IPv4
您在模拟中可能拥有的网络。

首先,除了 莱特助手 我们已经介绍过 基础版 模拟
程序,您需要使用额外的 Epc助手 类,它将负责创建
EPC实体和网络拓扑。 请注意,您不能使用 Epc助手 直接地,因为它
是抽象基类; 相反,您需要使用它的一个子类,它
提供不同的 EPC 拓扑实现。 在这个例子中,我们将考虑
点对点EpcHelper,它实现了基于点对点链路的 EPC。 要使用它,
您首先需要将此代码插入您的模拟程序中:

指针lteHelper = CreateObject ();
指针epcHelper = CreateObject ();

然后,您需要告诉 LTE 助手将使用 EPC:

lteHelper->SetEpcHelper(epcHelper);

上述步骤是必要的,以便 LTE 助手将触发适当的 EPC
与一些重要配置相对应的配置,例如当一个新的 eNB
或 UE 添加到模拟中,或创建 EPS 承载。 EPC助手将
自动处理必要的设置,例如 S1 链接创建和 S1 承载
设置。 所有这些都将在没有用户干预的情况下完成。

调用 lteHelper->SetEpcHelper (epc 助手) 启用 EPC 的使用,并具有侧
影响任何新的 LteEnbrrc 创建的将具有 EpsBearerToRlc映射
属性设置为 RLC_UM_ALWAYS 而不是 RLC_SM_ALWAYS 如果后者是默认值;
否则,该属性不会更改(例如,如果您将默认值更改为
RLC_AM_ALWAYS,它不会被触及)。

要注意的是 Epc助手 也会自动创建PGW节点和
配置它,以便它可以正确处理来自/到 LTE 无线电接入网络的流量。
尽管如此,您仍需要添加一些显式代码以将 PGW 连接到其他 IPv4 网络(例如,
互联网)。 这是一个关于如何将单个远程主机连接到的非常简单的示例
通过点对点链路的 PGW:

指针pgw = epcHelper->GetPgwNode();

// 创建一个 RemoteHost
节点容器远程主机容器;
RemoteHostContainer.Create(1);
指针remoteHost = remoteHostContainer.Get (0);
InternetStackHelper 互联网;
互联网安装(remoteHostContainer);

// 创建互联网
点对点助手 p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("延迟", TimeValue (秒 (0.010)));
NetDeviceContainer internetDevices = p2ph.Install(pgw,remoteHost);
Ipv4AddressHelper ipv4h;
ipv4h.SetBase("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetDevices);
// 接口 0 是本地主机,1 是 p2p 设备
Ipv4Address RemoteHostAddr = internetIpIfaces.GetAddress (1);

指定路由很重要,这样远程主机才能到达 LTE UE。 一种方式
这样做是通过利用以下事实 点对点EpcHelper 将默认分配
LTE UE 7.0.0.0 网络中的 IP 地址。 考虑到这一点,这样做就足够了:

Ipv4静态路由助手 ipv4路由助手;
指针remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask ("255.0.0.0"), 1);

现在,您应该继续创建 LTE eNB 和 UE,如前几节所述。
您当然可以配置其他 LTE 方面,例如路径损耗和衰落模型。 正确的
创建 UE 后,还应该为 IP 网络配置它们。 这个做完了
如下。 我们假设您有一个用于 UE 和 eNodeB 节点的容器,如下所示:

节点容器ueNodes;
节点容器 enbNodes;

要配置仅 LTE 模拟,您通常会执行以下操作:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Attach (ueLteDevs, enbLteDevs.Get (0));

为了为 IP 网络配置 UE,您只需要另外执行以下操作
这个:

// 我们在 UE 上安装 IP 栈
InternetStackHelper 互联网;
互联网安装(ueNodes);

//给UE分配IP地址
对于 (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
指针ue = ueNodes.Get (u);
指针ueLteDevice = ueLteDevs.Get (u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
//设置UE的默认网关
指针ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute(epcHelper->GetUeDefaultGatewayAddress(), 1);
}

承载的激活与完成的方式略有不同
用于仅 LTE 模拟。 首先,不使用 ActivateDataRadioBearer 方法
使用 EPC 时。 二、使用EPC时,会激活默认的EPS承载
当你调用 LteHelper::Attach () 时自动。 第三,如果你想设置专用
EPS 承载,您可以使用方法 LteHelper::ActivateDedicatedEpsBearer () 来实现。 这个
方法将流量流模板 (TFT) 作为参数,它是一个结构
标识将映射到专用 EPS 承载的流量类型。 这是一个
关于如何在 UE 上通信的应用程序设置专用承载的示例
端口 1234:

指针tft = 创建();
EpcTft::PacketFilter pf;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft-> 添加 (pf);
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs, EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT), tft);

你当然可以使用自定义 EpsBearer 和 EpcTft 配置,请参考
有关如何操作的 doxygen 文档。

最后,您可以在与远程通信的 LTE UE 节点上安装应用程序
互联网上的应用程序。 这是按照通常的 ns-3 程序完成的。
按照我们使用单个 remoteHost 的简单示例,这里是如何设置下行链路
通信,与远程主机上的 UdpClient 应用程序和 PacketSink
LTE UE(使用与之前代码片段相同的变量名)

uint16_t dlPort = 1234;
PacketSinkHelper packetSinkHelper ("ns3::UdpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny(), dlPort));
ApplicationContainer serverApps = packetSinkHelper.Install(ue);
serverApps.Start(秒(0.01));
UdpClientHelper 客户端(ueIpIface.GetAddress(0), dlPort);
ApplicationContainer clientApps = client.Install(remoteHost);
clientApps.Start(秒(0.01));

就这样! 您现在可以像往常一样开始模拟:

模拟器::停止(秒(10.0));
模拟器::运行();

运用 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 EPC - 仿真 模式
在上一节中,我们使用点对点链接来连接 eNB 和
SGW(S1-U 接口)和 eNB 之间(X2-U 和 X2-C 接口)。 LTE模块
支持使用模拟链接而不是 PointToPoint 链接。 这是通过仅
取代创造 莱特助手Epc助手 使用以下代码:

指针lteHelper = CreateObject ();
指针epcHelper = CreateObject ();
lteHelper->SetEpcHelper(epcHelper);
epcHelper->初始化();

属性 ns3::EmuEpcHelper::sgwDeviceNamens3::EmuEpcHelper::enbDeviceName 旨在
用于设置用于传输S1-U、X2-U和X2-C的设备名称
分别在 SGW 和 eNB 的接口。 我们现在将展示这是如何在一个
我们执行示例程序的示例 lena-简单-epc-emu 使用两个虚拟
以太网接口。

首先,我们适当地构建 ns-3:

# 配置
./waf 配置 --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# 建造
./waff

然后我们设置两个虚拟以太网接口,并启动 wireshark 查看流量
经历:

# 注意:你需要是 root

# 创建两个配对的 veth 设备
ip 链接添加名称 veth0 类型 veth 对等名称 veth1
ip链接显示

# 启用混杂模式
ip 链接设置 veth0 promisc on
ip 链接设置 veth1 promisc on

# 启动接口
ip链接设置veth0
ip链接设置veth1

# 启动 wireshark 并在 veth0 上捕获
线鲨 &

我们现在可以使用模拟时钟运行示例程序:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

使用 wireshark,您应该首先看到 ARP 解析,然后一些 GTP 数据包交换了两者
在上行链路和下行链路。

示例程序默认设置为1个eNB和1个UE。 你可以通过改变这个
命令行参数,例如:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

要获取可用参数的列表:

./waf --run lena-simple-epc-emu --command="%s --PrintHelp"

使用实时时钟运行:事实证明默认的调试版本太慢了
即时的。 用 BestEffort 模式软化实时约束不是一个好主意:
可能会出现问题(例如,ARP 可能会失败),如果是这样,您将不会收到任何数据包
出去。 所以你需要一个像样的硬件和静态链接的优化构建
模块:

./waf 配置-d 优化 --enable-static --enable-modules=lte --enable-examples --enable-sudo

然后像这样运行示例程序:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImpl --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

注意 HardLimit 设置,如果跟不上将导致程序终止
实时。

本节中描述的方法可用于任何类型的网络设备。 为了
例如,[Baldo2014] 描述了如何使用它在一个网络上运行模拟的 LTE-EPC 网络
真正的多层分组光传输网络。

网络 附件
如部分中的基本示例所示 基础版 模拟 程序, 将 UE 附加到
eNodeB是通过调用 LteHelper::附加 功能。

有两种可能的网络连接方式。 第一种方法是 “手动的” 一,
而第二个有更多 “自动的” 感觉上。 他们每个人都将在
这个部分。

用户手册 gehechtheid
此方法使用 LteHelper::附加 上面提到的功能。 它一直是唯一
LTE 模块早期版本中可用的网络连接方法。 它通常是
在模拟开始之前调用:

lteHelper->Attach (ueDevs, enbDev); // 将一个或多个 UE 附加到单个 eNodeB

LteHelper::InstallEnbDeviceLteHelper::安装UeDevice 函数必须被调用
在附加之前。 在启用 EPC 的模拟中,还需要正确具有 IPv4
预装在UE中。

这个方法很简单,但是需要你明确知道哪个UE属于哪个
仿真开始前的 eNodeB。 当 UE 初始位置是
由模拟脚本随机确定。

可以选择UE和eNodeB之间的距离作为选择基站的标准。
适当的细胞。 它非常简单(至少从模拟器的角度来看)并且
有时实用。 但需要注意的是,有时距离并不重要
单一正确的标准。 例如,eNodeB 天线方向性应为
也考虑了。 除此之外,还应该考虑信道条件,
如果有褪色或阴影效果,这可能会波动。 在这些
在这种情况下,网络依恋不应仅基于距离。

在现实生活中,UE会自动评估某些标准并选择最佳小区
附加到,无需用户手动干预。 显然情况并非如此
Free Introduction LteHelper::附加 功能。 另一种网络连接方式使用较多 “自动的”
网络依附的方法,如下所述。

自动表 gehechtheid 运用 空闲 模式 细胞 选择 程序
接收信号的强度是用于选择最佳信号的标准准则
要附加到的单元格。 该标准的使用在 初始 细胞 选择
进程,可以通过调用另一个版本的 LteHelper::附加
函数,如下图:

lteHelper->附加(ueDevs); // 将一个或多个 UE 连接到最强的小区

与手工方式不同的是不指定目的基站。 这
程序将根据几个标准为 UE 找到最佳小区,包括
接收信号强度 (RSRP)。

调用该方法后,UE会花一些时间测量邻区,
然后尝试连接到最好的那个。 更多详细信息,请参阅部分
设计文档的 sec-initial-cell-selection。

请务必注意,此方法仅适用于支持 EPC 的仿真。 仅限 LTE
模拟必须采用手动连接方法。

不营业 订户 团队
初始单元格选择过程的一个有趣用例是设置模拟
封闭用户组 (CSG) 的环境。

例如,某个 eNodeB,通常是 femtocell 等较小的版本,可能属于
私人所有者(例如家庭或企业),仅允许访问某些 UE
之前已由所有者注册。 eNodeB和注册UE一共
组成一个CSG。

可以通过用相同的CSG“标记”CSG成员来模拟访问限制
ID。 这是通过 eNodeB 和 UE 中的属性完成的,例如使用
以下 莱特助手 职能:

// 将以下 eNodeB 标记为 CSG 身份 1 并启用 CSG 指示
lteHelper->SetEnbDeviceAttribute("CsgId", UintegerValue (1));
lteHelper->SetEnbDeviceAttribute ("CsgIndication", BooleanValue (true));

// 标记一个或多个 CSG 标识为 1 的 UE
lteHelper->SetUeDeviceAttribute("CsgId", UintegerValue (1));

// 安装 eNodeB 和 UE
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

然后在 UE 上启用初始小区选择过程:

lteHelper->附加(csgUeDevs);

这是必要的,因为 CSG 限制仅适用于网络自动方法
附件,但不是在手动方法中。

请注意,将 eNodeB 的 CSG 指示设置为 false(默认值)将
禁用限制,即任何 UE 都可以连接到该 eNodeB。

配置 UE 测量
模拟中的活动 UE 测量配置由所选的 so 决定
称为“消费者”,如切换算法。 用户可以将自己的配置添加到
行动,有几种方法可以做到这一点:

1.在eNodeB RRC实体中直接配置;

2、配置现有的切换算法; 和

3.开发新的切换算法。

本节将仅介绍第一种方法。 第二种方法包含在 自动表
交出 触发, 而第三种方法在章节中有详细解释
设计文档的sec-handover-algorithm。

eNodeB RRC 中的直接配置工作如下。 用户首先创建一个新的
LterRrcSap::ReportConfigEutra 实例并将其传递给 LteEnbRrc::AddUeMeasReportConfig
功能。 该函数将返回 测量ID (测量标识)这是唯一的
eNodeB 实例中配置的引用。 这个函数必须在之前调用
模拟开始。 测量配置将在连接到的所有 UE 中激活
eNodeB 在整个模拟过程中。 在模拟过程中,用户可以
通过收听现有的,捕获 UE 生成的测量报告
LteEnbRrc::接收测量报告 跟踪源。

结构 报告配置Eutra 符合3GPP规范。 的定义
结构和每个成员字段可以在 [TS6.3.5] 的第 36331 节中找到。

下面的代码示例将事件 A1 RSRP 测量配置到网络中的每个 eNodeB
容器 开发者:

LteRrcSap::ReportConfigEutra 配置;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::ThresholdEutra::THRESHOLD_RSRP;
配置.threshold1.range = 41;
config.triggerQuantity = LteRrcSap::ReportConfigEutra::RSRP;
config.reportInterval = LteRrcSap::ReportConfigEutra::MS480;

std::向量测量标识符列表;

NetDeviceContainer::Iterator 它;
for (it = devs.Begin (); it != devs.End (); it++)
{
指针dev = *它;
指针enbDev = dev->GetObject ();
指针enbRrc = enbDev->GetRrc();

uint8_t measId = enbRrc->AddUeMeasReportConfig (config);
measIdList.push_back (measId); // 记住创建的measId

enbRrc->TraceConnect ("RecvMeasurementReport",
“语境”,
MakeCallback (&​​RecvMeasurementReportCallback));
}

请注意,阈值表示为范围。 在上面的示例中,RSRP 的范围 41
对应于 -100 dBm。 范围格式的转换是由于 Section
[TS9.1.4] 的 9.1.7 和 36133。 这 欧特兰测绘公司 类有几个静态
可用于此目的的功能。

相应的回调函数将具有类似于以下的定义:

无效
RecvMeasurementReportCallback(std::string 上下文,
uint64_t imsi,
uint16_t 小区 ID,
uint16_t rnti,
LteRrcSap::测量报告 measReport);

此方法会将回调函数注册为 UE 测量值的消费者。 在里面
模拟中有多个消费者的情况(例如切换算法),
用于其他消费者的测量值也将被此回调捕获
功能。 用户可以利用 测量ID 字段,包含在
LteRrcSap::测量报告 回调函数的参数,告诉哪个测量
配置已触发报告。

一般来说,这种机制可以防止一个消费者在不知不觉中干预另一个消费者
消费者的报告配置。

请注意,只有报告配置部分(即 LterRrcSap::ReportConfigEutra)的
UE测量参数开放供消费者配置,其他部分
被隐藏起来。 同频限制是这个 API 背后的主要动机
执行决定:

· 只有一个,明确且确定 数据监测 对象,因此不存在
需要配置它;

· 数据监测 身份 被隐藏是因为存在一对一的事实
报告配置和测量身份之间的映射,因此是一个新的
当一个新的报告配置是自动设置测量身份
创建;

· 数量 配置 在别处配置,请参阅 sec-performing-measurements; 和

· 数据监测 差距 不支持,因为它只适用于异频
设置;

基于X2 交出
根据 3GPP 的定义,切换是一个改变 UE 服务小区的过程。
连接模式。 该过程中涉及的两个 eNodeB 通常称为 资源
基站目标 基站.

为了能够在仿真中执行基于 X2 的切换,有两个
必须满足的要求。 首先,必须在仿真中启用 EPC(请参阅 进化
小包装 核心科目 (EPC)).

其次,两个eNodeB之间必须配置一个X2接口,需要
在模拟程序中明确完成:

lteHelper->AddX2Interface (enbNodes);

哪里 enb节点 是一个 节点容器 包含两个 eNodeB,X2 之间
接口是要配置的。 如果容器有两个以上的 eNodeB,函数
将在容器中的每对 eNodeB 之间创建一个 X2 接口。

最后,目标 eNodeB 必须配置为对 X2 切换请求“开放”。 每一个
eNodeB默认是开启的,所以大多数情况下不需要额外的指令。 然而,用户
可以通过设置布尔属性将 eNodeB 设置为“关闭”
LteEnbRrc::AdmitHandoverRequestfalse. 例如,您可以运行 lena-x2-移交
编程并以这种方式设置属性:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

满足以上三个要求后,即可触发切换流程
手动或自动。 每个都将在以下小节中介绍。

用户手册 交出 触发
切换事件可以通过安排一个模拟程序“手动”触发
显式切换事件。 这 莱特助手 对象提供了一个方便的方法
切换事件的调度。 例如,让我们假设 UELTE开发者 是一个
网络设备容器 包含要移交的 UE,并且 赋能开发者 is
另一个 网络设备容器 包含源和目标 eNB。 然后,交接
在 0.1s 可以这样安排:

lteHelper->HandoverRequest(秒(0.100),
ueLteDevs.Get (0),
enbLteDevs.Get (0),
enbLteDevs.Get (1));

注意UE需要已经连接到源eNB,否则模拟
将以错误消息终止。

有关完整源代码的示例,请参阅 lena-x2-移交 例子
程序。

自动表 交出 触发
切换过程也可以由 UE 的服务 eNodeB“自动”触发。
触发器背后的逻辑取决于当前处于活动状态的切换算法
eNodeB RRC 实体。 用户可以选择和配置将要使用的切换算法
在模拟中,这将在本节中简要说明。 用户也可以选择
编写自己的切换算法实现,如第
设计文档的sec-handover-algorithm。

选择切换算法是通过 莱特助手 对象及其
设置切换算法类型 方法如下图:

指针lteHelper = CreateObject ();
lteHelper->SetHandoverAlgorithmType ("ns3::A2A4RsrqHandoverAlgorithm");

选定的切换算法还可以提供几个可配置的属性,这些属性
可以设置如下:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold",
整数值(30));
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset",
整数值(1));

LTE 模块中包含三种切换算法选项。 这 A2-A4-RSRQ
切换算法(命名为 ns3::A2A4Rsrq切换算法) 是默认选项,并且
上面已经显示了用法。

另一种选择是 最强 细胞 切换算法(命名为
ns3::A3RsrpH切换算法), 可以通过以下代码选择和配置:

lteHelper->SetHandoverAlgorithmType ("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute("迟滞",
双值 (3.0));
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger",
时间值(毫秒(256)));

最后一个选项是一个特殊的选项,称为 无操作 切换算法,基本上
禁用自动切换触发器。 这在手动操作的情况下很有用
切换触发器需要独占控制所有切换决策。 它没有任何
可配置的属性。 用法如下:

lteHelper->SetHandoverAlgorithmType ("ns3::NoOpHandoverAlgorithm");

有关每个切换算法的决策策略及其属性的更多信息,
请参阅 Section sec-handover-algorithm 中各自的小节
设计文档。

最后,该 安装EnbDevice 功能 莱特助手 将实例化一个实例
为每个 eNodeB 设备选择切换算法。 换句话说,确保选择
在以下代码行中完成之前的正确切换算法:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

使用自动切换触发器的完整源代码示例可以在
lena-x2-移交措施 示例程序。

调音 模拟 - 交出
如设计文档中所述,当前切换模型的实现可能
当发生切换失败时产生不可预测的行为。 本小节将重点关注
如果用户计划在他们的应用程序中使用切换,则用户应考虑的步骤
模拟。

我们要解决的切换失败的主要原因是传输错误
在执行切换过程期间与切换相关的信令消息。 作为
从设计文档中的图 fig-x2-based-handover-seq-diagram 可以看出,
它们有很多,它们使用不同的接口和协议。 为了
为简单起见,我们可以安全地假设 X2 接口(在源 eNodeB 和
target eNodeB)和S1接口(在target eNodeB和SGW/PGW之间)相当
稳定的。 因此,我们将关注 RRC 协议(在 UE 和
eNodeBs)和随机接入程序,通常通过空中传输
并且容易受到信道条件退化的影响。

减少传输错误的一般技巧是 确保 更多 信噪比 每个水平
UE。 这可以通过适当规划网络拓扑来完成 最小化 网络
覆盖 . 如果拓扑有一个已知的覆盖空洞,那么 UE 应该被配置
不要冒险去那个地区。

要记住的另一种方法是 避免 为时已晚 移交. 换句话说,交接
应该在 UE 的 SINR 变得太低之前发生,否则 UE 可能无法接收
来自源基站的切换命令。 切换算法有控制的手段
做出移交决定的时间有多早或多晚。 例如A2-A4-RSRQ切换算法
可以配置更高的门限,使其更早决定切换。 相似地,
最强小区切换算法中更小的滞后和/或更短的触发时间
通常会导致更早的切换。 为了找到这些正确的值
参数,应该考虑的因素之一是UE移动速度。
通常,移动速度较快的UE需要较早执行切换。 有些研究
工作提出了推荐值,例如 [Lee2010]。

以上提示在正常的模拟使用中应该足够了,但在一些特殊的情况下
出现需求时,可以考虑采取极端措施。 例如,用户
可以考虑 禁用 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 渠道 错误 模型. 这将确保所有
与切换相关的信令消息将被成功传输,无论
距离和信道条件。 但是,它也会影响所有其他数据或控制
与切换无关的数据包,这可能是不希望的副作用。 否则,它可以
如下进行:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

通过使用上面的代码,我们禁用了控制和数据通道中的错误模型,并且
在两个方向上(下行链路和上行链路)。 这是必要的,因为切换相关
使用这些信道传输信令消息。 一个例外是当
模拟使用理想的 RRC 协议。 在这种情况下,只有随机接入程序是
留待考虑。 该过程由控制消息组成,因此我们只需要
禁用控制通道的错误模型。

交出 步伐
RRC模型,特别是 LteEnbrrcLTE 对象,提供一些有用的
可以连接到一些自定义函数的跟踪,以便在启动时调用它们
UE 和 eNB 侧的切换执行阶段结束。 例如,在
您的模拟程序可以声明以下方法:

无效
NotifyHandoverStartUe(std::string 上下文,
uint64_t imsi,
uint16_t 小区 ID,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << 上下文
<<“UE IMSI”<<IMSI
<< ": 之前连接的CellId " << cellId
<< “与 RNTI” << rnti
<< ", 正在切换到 CellId " << targetCellId
<< 标准::结束;
}

无效
NotifyHandoverEndOkUe(std::string 上下文,
uint64_t imsi,
uint16_t 小区 ID,
uint16_trnti)
{
std::cout << Simulator::Now ().GetSeconds () << " " << 上下文
<<“UE IMSI”<<IMSI
<< ": 成功切换到 CellId " << cellId
<< “与 RNTI” << rnti
<< 标准::结束;
}

无效
NotifyHandoverStartEnb(std::string 上下文,
uint64_t imsi,
uint16_t 小区 ID,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << 上下文
<< “eNB CellId” << cellId
<< ": 使用 IMSI 开始 UE 的切换 " << imsi
<< “RNTI” << RNTI
<< “到 CellId” << targetCellId
<< 标准::结束;
}

无效
NotifyHandoverEndOkEnb(std::string 上下文,
uint64_t imsi,
uint16_t 小区 ID,
uint16_trnti)
{
std::cout << Simulator::Now ().GetSeconds () << " " << 上下文
<< “eNB CellId” << cellId
<< ": 完成UE与IMSI的切换" << imsi
<< “RNTI” << RNTI
<< 标准::结束;
}

然后,您可以像这样将这些方法连接到相应的跟踪源:

Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverStart",
MakeCallback (&​​NotifyHandoverStartEnb));
配置::连接(“/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart”,
MakeCallback (&​​NotifyHandoverStartUe));
Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverEndOk",
MakeCallback (&​​NotifyHandoverEndOkEnb));
配置::连接(“/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk”,
MakeCallback (&​​NotifyHandoverEndOkUe));

示例程序 src/lte/examples/lena-x2-handover.cc 说明了以上所有内容
指令可以集成在模拟程序中。 您可以像这样运行程序:

./waf --运行 lena-x2-handover

它将输出自定义切换跟踪钩子打印的消息。 为了
另外可视化一些有意义的日志信息,你可以像这样运行程序
这个:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --run lena-x2-handover

频率 重用 算法
在本节中,我们将描述如何在 LTE 中的 eNb 中使用频率复用算法
模拟。 有两种可能的配置方式。 第一种方法是
“手动”一种,需要配置更多参数,但允许用户配置FR
他/她需要的算法。 第二种方法更“自动”。 很方便,
因为每个 FR 算法都是一样的,所以用户可以通过以下方式快速切换 FR 算法
仅更改 FR 算法的类型。 一个缺点是“自动”方法只使用
每个算法的配置集有限,这使得它不太灵活,但是
对于大多数情况来说已经足够了。

这两种方法将在下面的小节中详细介绍。

如果用户不配置Frequency Reuse算法,默认一个(即LteFrNoOpAlgorithm)
安装在 eNb 中。 它就像禁用了 FR 算法一样。

应该提到的一件事是,大多数已实现的 FR 算法都与
小区带宽大于或等于 15 个 RB。 此限制是由以下要求引起的
至少必须分配三个连续的RB给UE进行传输。

用户手册 配置
频率重用算法可以在模拟程序中“手动”配置
设置 FR 算法的类型及其所有属性。 目前,有 XNUMX 种 FR 算法
已实施:

· ns3::LteFrNoOp算法

· ns3::LteFrHard算法

· ns3::LteFrStrict算法

· ns3::LteFrSoft算法

· ns3::LteFFrSoft算法

· ns3::LteFfr增强算法

· ns3::LteFfr分布式算法

选择 FR 算法是通过 莱特助手 对象及其 设置算法类型
方法如下图:

指针lteHelper = CreateObject ();
lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");

每个实现的 FR 算法都提供了几个可配置的属性。 用户没有
关心 UL 和 DL 带宽配置,因为它是在期间自动完成的
细胞配置。 要更改 FR 算法的带宽,请为
LTEEnbNetDevice:

uint8_t 带宽 = 100;
lteHelper->SetEnbDeviceAttribute("DlBandwidth", UintegerValue(带宽));
lteHelper->SetEnbDeviceAttribute("UlBandwidth", UintegerValue(带宽));

现在,将描述每个FR算法配置。

频率 重用 算法
如设计文档的 sec-fr-hard-algorithm 部分所述
ns3::LteFrHard算法 使用一个子带。 要配置此子带用户需要指定
DL 和 UL 的偏移量和带宽,以 RB 的数量表示。

硬频率重用算法提供以下属性:

· Dl子带偏移量: 资源块组数量中的下行链路偏移量

· 下行带宽:下行链路传输子带宽配置数量
资源块组

· Ul子带偏移量:资源块组数量中的上行链路偏移

· Ul子带宽: 资源数量中的上行链路传输子带宽配置
块组

LteFrHardAlgorithm 的示例配置可以通过以下方式完成:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("DlSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlSubBandwidth", UintegerValue (8));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

以上示例允许 eNB 在 DL 和 UL 中仅使用 8 到 16 的 RB,而整个小区
带宽为25。

监督 频率 重用 算法
严格频率复用算法使用两个子带:一个为每个小区公用,一个为
私人的。 还有RSRQ门限,需要用到它来决定UE在哪个子带内
应该送达。 此外,这些子带中的功率传输可以不同。

严格频率重用算法提供以下属性:

· UlCommonSubBandwidth:资源数量中的上行链路公共子带宽配置
块组

· UlEdgeSubBandOffset:资源块组数量中的上行链路边缘子带偏移

· UlEdge子带宽:资源数量中的上行链路边缘子带宽配置
块组

· DlCommonSubBandwidth:下行链路公共子带宽配置的数量
资源块组

· DlEdgeSubBand偏移量:资源块组数量中的下行链路边缘子带偏移

· DlEdge子带宽:资源数量中的下行链路边缘子带宽配置
块组

· 请求阈值: 如果 RSRQ 比这个阈值差,UE 应该被服务
边缘子带

· 中心功率偏移: PdschConfigDedicated::中心子带的Pa值,默认值
dB0

· 边缘功率偏移: PdschConfigDedicated::边缘子带的Pa值,默认值dB0

· 中心区Tpc: TPC value 将在 DL-DCI 中为中心区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

· 边缘区域Tpc: TPC value 将在 DL-DCI 中为边缘区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

下面的示例允许 eNB 使用从 0 到 6 的 RB 作为公共子带,从 12 到 18 作为公共子带
下行和上行私有子带,RSRQ门限为20 dB,中心区域功率等于
LteEnbPhy::TxPower - 3dB, 边缘区域的功率等于 LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrStrictAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
lteHelper->SetFfrAlgorithmAttribute ("CenterAreaTpc", UintegerValue (1));
lteHelper->SetFfrAlgorithmAttribute ("EdgeAreaTpc", UintegerValue (2));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

频率 重用 算法
使用软频率复用算法,eNb 使用整个小区带宽,但有两个
UE 内的子带以不同的功率级别提供服务。

软频率重用算法提供以下属性:

· UlEdgeSubBandOffset:资源块组数量中的上行链路边缘子带偏移

· UlEdge子带宽:资源数量中的上行链路边缘子带宽配置
块组

· DlEdgeSubBand偏移量:资源块组数量中的下行链路边缘子带偏移

· DlEdge子带宽:资源数量中的下行链路边缘子带宽配置
块组

· 允许中心使用边缘子带:如果真正的中心 UE 可以在边缘子带 RBG 上接收,
否则边缘子带仅允许用于边缘 UE,默认值为 true

· 请求阈值: 如果 RSRQ 比这个阈值差,UE 应该被服务
边缘子带

· 中心功率偏移: PdschConfigDedicated::中心子带的Pa值,默认值
dB0

· 边缘功率偏移: PdschConfigDedicated::边缘子带的Pa值,默认值dB0

· 中心区Tpc: TPC value 将在 DL-DCI 中为中心区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

· 边缘区域Tpc: TPC value 将在 DL-DCI 中为边缘区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

下面的示例配置从 8 到 16 的 RB 供小区边缘 UE 使用,并且该子带是
不适用于手机中心用户。 RSRQ 阈值为 20 dB,中心区域的功率等于
LteEnbPhy::TxPower, 边缘区域的功率等于 LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("AllowCenterUeUseEdgeSubBand", BooleanValue (false));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

分数 频率 重用 算法
软分数频率复用 (SFFR) 使用三个子带:中心、中等(普通)和
边缘。 用户只需配置其中两个:common 和 edge。 中心子带将是
由剩余带宽组成。 每个子带可以服务于不同的
传输功率。 由于存在三个子带,因此需要设置两个 RSRQ 阈值
配置。

软分数频率重用算法提供以下属性:

· UlCommonSubBandwidth:资源数量中的上行链路公共子带宽配置
块组

· UlEdgeSubBandOffset:资源块组数量中的上行链路边缘子带偏移

· UlEdge子带宽:资源数量中的上行链路边缘子带宽配置
块组

· DlCommonSubBandwidth:下行链路公共子带宽配置的数量
资源块组

· DlEdgeSubBand偏移量:资源块组数量中的下行链路边缘子带偏移

· DlEdge子带宽:资源数量中的下行链路边缘子带宽配置
块组

· 中心请求阈值: 如果 RSRQ 比这个阈值差,UE 应该被服务
在中子带

· 边缘Rsrq阈值: 如果 RSRQ 比这个阈值差,UE 应该被服务
在边缘子带

· 中心区域功率偏移: PdschConfigDedicated::Pa 中心子带的值,默认
值 dB0

· 中等区域功率偏移: PdschConfigDedicated::中子带的Pa值,默认
值 dB0

· 边缘区域功率偏移: PdschConfigDedicated::边缘子带的Pa值,默认值
dB0

· 中心区Tpc: TPC value 将在 DL-DCI 中为中心区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

· 中等面积Tpc: TPC value 将在 DL-DCI 中为中等区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

· 边缘区域Tpc: TPC value 将在 DL-DCI 中为边缘区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

在下面的示例中,从 0 到 6 的 RB 将用作普通(中)子带,从 6 到 XNUMX 的 RB
12 将用作边缘子带,12 到 24 的 RB 将用作中心子带(它
由剩余的 RB 组成)。 中心和中等区域之间的 RSRQ 阈值为 28 dB,
中间区域和边缘区域之间的 RSRQ 阈值为 18 dB。 中心区域的功率等于
LteEnbPhy::TxPower - 3dB, 中等面积的功率等于 LteEnbPhy::TxPower + 3dB, 上电
边缘面积等于 LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("CenterRsrqThreshold", UintegerValue (28));
lteHelper->SetFfrAlgorithmAttribute ("EdgeRsrqThreshold", UintegerValue (18));
lteHelper->SetFfrAlgorithmAttribute ("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute ("MediumAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

品牌影响力提升 分数 频率 重用 算法
Enhanced Fractional Frequency Reuse (EFFR) 为每个小区预留部分系统带宽
(通常有 3 种小区类型,每一种都获得 1/3 的系统带宽)。 然后一部分
这个子带宽用作 分割 具有重用因子 3 和作为 二次 分割
重用因子为 1。用户必须配置(对于 DL 和 UL)小区子带宽的偏移量
in number of RB, 将用作RB的数量 分割 和 RB 的数量
将用作 二次 分割. 分割 由细胞随意使用,但 RBs 来自
二次 分割 只能分配给 UE 是来自该 UE 的 CQI 反馈具有更高
值超过配置的 CQI 阈值。 当 UE 的 RSRQ 较低时,UE 被认为是边缘 UE
请求阈值.

由于每个 eNb 都需要知道其他细胞类型的主要和次要位置,它会
计算它们假设每个小区的配置相同并且只有子带宽
偏移量不同。 因此,重要的是将可用系统带宽平均分配给
每个单元格并将相同的主要和次要段配置应用于它们。

增强的分数频率重用算法提供以下属性:

· Ul子带偏移量:资源块数量中此小区的上行链路子带偏移


· UlReuse3SubBandwidth:上行链路复用 3 个子带宽配置(资源数量)
块组

· UlReuse1SubBandwidth:上行链路复用 1 个子带宽配置(资源数量)
块组

· Dl子带偏移量:资源块数量中此小区的下行链路子带偏移


· DlReuse3SubBandwidth: 下行复用 3 SubBandwidth Configuration in number of
资源块组

· DlReuse1SubBandwidth: 下行复用 1 SubBandwidth Configuration in number of
资源块组

· 请求阈值: 如果 RSRQ 比这个阈值差,UE 应该被服务
边缘子带

· 中心区域功率偏移: PdschConfigDedicated::Pa 中心子带的值,默认
值 dB0

· 边缘区域功率偏移: PdschConfigDedicated::边缘子带的Pa值,默认值
dB0

· DlCqi阈值:如果 RBG 的 DL-CQI 高于此阈值,传输
在 RBG 上是可能的

· UlCqi阈值:如果 RBG 的 UL-CQI 高于此阈值,传输
在 RBG 上是可能的

· 中心区Tpc: TPC value 将在 DL-DCI 中为中心区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

· 边缘区域Tpc: TPC value 将在 DL-DCI 中为边缘区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

在下面的示例中,DL 和 UL 中的偏移量为 0 RB,将使用 4 RB 分割
二次 分割. 中心和边缘区域之间的 RSRQ 阈值为 25 dB。 DL 和 UL CQI
阈值设置为 10。中心区域的功率等于 LteEnbPhy::TxPower - 6dB,
边缘区域的功率等于 LteEnbPhy::TxPower + 0dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrEnhancedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute("DlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("UlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_6));
lteHelper->SetFfrAlgorithmAttribute("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("UlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("UlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("UlReuse1SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("DlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlReuse1SubBandwidth", UintegerValue (4));

分布式 分数 频率 重用 算法
分布式部分频率复用要求所有 eNB 之间的 X2 接口是
安装。 X2接口只有配置了EPC才能安装,所以这个FFR方案
只能与 EPC 场景一起使用。

借助分布式分数频率复用算法,eNb 使用整个小区带宽和
可以有两个子带:中心子带和边缘子带。 在这些子带内
可以提供不同的功率级别。 算法自适应地为小区边缘选择 RB
基于来自相邻小区的协调信息(即 RNTP)的子带并通知
相邻小区的基站,其选择在边缘子带中使用哪些RB。 如果
小区中没有分类为边缘UE的UE,eNB不会使用任何RB作为边缘子带。

分布式分数频率重用算法提供以下属性:

· 计算间隔: 边缘子带计算的时间间隔,默认
值 1 秒

· 请求阈值: 如果 RSRQ 比这个阈值差,UE 应该被服务
边缘子带

· Rsrp 差异阈值:如果接收到的信号的功率之间的差异
UE 从服务小区接收到的信号功率
单元格小于 RsrpDifferenceThreshold 值,单元格权重递增

· 中心功率偏移: PdschConfigDedicated::边缘子带的Pa值,默认值
dB0

· 边缘功率偏移: PdschConfigDedicated::边缘子带的Pa值,默认值dB0

· 边缘Rb编号: 边缘子带可使用的RB数

· 中心区Tpc: TPC value 将在 DL-DCI 中为中心区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

· 边缘区域Tpc: TPC value 将在 DL-DCI 中为边缘区域的 UEs 设置,Absolute
使用模式,默认值 1 根据 TS1 表 36.213-5.1.1.1 映射到 -2

在下面的示例中,计算间隔为 500 毫秒。 中心和边缘之间的 RSRQ 阈值
区域为 25。RSRP 差异阈值设置为 5。在 DL 和 UL 中,6 RB 将被使用
边缘子带中的每个小区。 中心区域的功率等于 LteEnbPhy::TxPower - 0dB, 力量
在边缘面积等于 LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrDistributedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("CalculationInterval", TimeValue(毫秒(500)));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute ("RsrpDifferenceThreshold", UintegerValue (5));
lteHelper->SetFfrAlgorithmAttribute ("EdgeRbNum", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));

自动表 配置
频率重用算法也可以通过设置以更“自动”的方式配置
带宽和 FrCellTypeId。 在 FR 实例初始化期间,配置为
设置带宽和 FrCellTypeId 将从配置表中获取。 这很重要
只有子带将被配置,阈值和传输功率将被设置为
默认值。 如果有人愿意,他/她可以更改阈值和传输功率,如图所示
在前面的小节中。

一共有三个 FrCellTypeId : 1, 2, 3, 分别对应三种不同的配置
对于每个带宽。 三种配置允许在
六边形 eNB 布局中的相邻小区。 如果用户需要有更多不同
相邻小区的配置,他/她需要使用手动配置。

下面的示例显示了自动 FR 算法配置:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("FrCellTypeId", UintegerValue (1));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

上行 电力 通过积极争取让商标与其相匹配的域名优先注册来维护
默认情况下启用上行链路功率控制功能。 用户可以通过设置禁用它
布尔属性 ns3::LteUePhy::启用上行链路功率控制 真实。

用户可以在开环功率控制和闭环功率控制机制之间切换
通过设置布尔属性 ns3::LteUePowerControl::闭环. 默认关闭
使能带累加模式的环路功率控制。

路径损耗是上行链路功率控制的关键组成部分。 它被计算为之间的差异
过滤后的 RSRP 和 ReferenceSignalPower 参数。 ReferenceSignalPower 与 SIB2 一起发送。

上行链路功率控制中可用的属性:

· 闭环:如果启用闭环上行链路功率控制模式并且开环
电源控制 否则,默认值为 false

· 启用累积:如果启用了 true 累积模式和绝对模式
否则,默认值为 false

· 阿尔法:路径损耗补偿因子,默认值为1.0

· 皮克敏: 最小 UE TxPower,默认值为 -40 dBm

· 最大压力: 最大 UE TxPower,默认值为 23 dBm

· Po标称压力:该参数应该由高层设置,但目前需要
由属性系统配置,可能的值是范围内的整数(-126 ...
24), 默认值为-80

· 极点:这个参数应该由高层来设置,但目前需要
由属性系统配置,可能的值是范围内的整数(-8 ... 7),
默认值为 0

· 偏移量:这个参数应该由高层来设置,但目前需要
由属性系统配置,可能的值是范围 (0 ... 15) 内的整数,
默认值为 7,P_Srs_Offset_Value = 0

究其根源 价值观 in 上行 电力 控制:

· 报告PuschTxPower:PUSCH 的当前 UE TxPower

· ReportPuchTxPower:PUCCH 的当前 UE TxPower

· 报告SrsTxPower:SRS的当前UE TxPower

示例配置如下所示:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (true));
Config::SetDefault ("ns3::LteEnbPhy::TxPower", DoubleValue (30));
Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));
Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

例如,用户可以查看并运行 lena-uplink-power-control 程序。

例子 计划部
目录 src/lte/例子/ 包含一些示例模拟程序,展示如何
模拟不同的 LTE 场景。

参考法案 情景
有大量的参考 LTE 模拟场景可以在
文学。 在这里,我们列出了其中的一些:

· [TR2] 的 A.36814 节中提到的系统仿真场景。

· 双条纹模型 [R4-092042],在示例中部分实现
程序 src/lte/examples/lena-dual-stripe.cc. 这个示例程序有很多特点
可配置参数,可以通过改变相应的全局来定制
变量。 要获取所有这些全局变量的列表,您可以运行以下命令:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

以下小节介绍了使用运行模拟活动的示例
这个示例程序。

交出 模拟 运动
在本小节中,我们将演示使用运行模拟活动的示例
的LTE模块 ns-3. 该活动的目的是比较每个活动的效果
LTE模块内置切换算法。

该活动将使用 lena 双条纹 示例程序。 首先,我们必须修改
生成我们需要的输出的示例程序。 在这种情况下,我们要生产
切换次数、用户平均吞吐量和平均 SINR。

切换的次数可以通过计算切换的次数得到 交接结束Ok
交出 步伐 被解雇了。 然后可以通过启用获得用户平均吞吐量
RLC 教学帖子 输出. 最后,可以通过启用PHY仿真来获得SINR
输出。 以下示例代码片段显示了获取上述内容的一种可能方法:

无效
NotifyHandoverEndOkUe(std::string 上下文,uint64_t imsi,
uint16_t cellId、uint16_t rnti)
{
std::cout << "移交 IMSI " << imsi << std::endl;
}

INT
主要(int argc,char *argv[])
{
/*** 剪辑 ***/

配置::连接(“/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk”,
MakeCallback (&​​NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces();
lteHelper->EnableRlcTraces();
指针rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute("开始时间", TimeValue(秒(0)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (Seconds (simTime)));

模拟器::运行();
模拟器::销毁();
0返回;
}

然后我们必须配置程序的参数以满足我们的模拟需要。 我们
在我们的模拟中寻找以下假设:

· 7个三扇形宏基站站点(即21个宏蜂窝)呈六角形部署
站点间距离为 500 m 的布局。

· 虽然 lena 双条纹 最初用于两层(宏蜂窝和
femtocell)模拟,我们将模拟简化为一层(宏蜂窝)
仅限模拟。

· UE随机分布在站点周围,自动接入网络
使用空闲模式单元格选择。 之后UE会在模拟环境中漫游
以 60 kmph 的移动速度。

· 50 秒的模拟持续时间,因此 UE 会走得足够远以触发一些
移交。

· 46 dBm 宏蜂窝 Tx 功率和 10 dBm UE Tx 功率。

· 将使用 EPC 模式,因为 X2 切换过程需要启用它。

· 全缓冲下行链路和上行链路流量,均为 5 MHz 带宽,使用 TCP 协议
和比例公平调度程序。

·理想的RRC协议。

lena 双条纹 参数 配置 交出 运动 下面展示了我们如何
配置参数 lena 双条纹 实现上述假设。

lena 双条纹 参数 配置 交出 运动
┌────────────────────┬────────┬────────────────── ────────┐
│参数名称 │ 值 │ 说明 │
├──────────────────┼────────┼────────────────── ────────┤
│simTime │ 50 │ 50秒模拟 │
│ │ │ 持续时间 │
├──────────────────┼────────┼────────────────── ────────┤
│nBlocks │ 0 │ 残疾公寓 │
│ │ │ 建筑物和家庭基站 │
├──────────────────┼────────┼────────────────── ────────┤
│nMacroEnbSites │ 7 │ 宏蜂窝数量 │
│ │ │ 站点(每个站点有 3 │
│ │ │ 细胞) │
├──────────────────┼────────┼────────────────── ────────┤
│nMacroEnbSitesX │ 2 │ 宏蜂窝站点将 │
│ │ │ 定位为 2-3-2 │
│ │ │ 编队 │
├──────────────────┼────────┼────────────────── ────────┤
│interSiteDistance │ 500 │ 500 m 之间的距离 │
│ │ │ 相邻的宏蜂窝站点 │
├──────────────────┼────────┼────────────────── ────────┤
│macroEnbTxPowerDbm │ 46 │ 每个 46 dBm Tx 功率 │
│ │ │ 宏蜂窝 │
├──────────────────┼────────┼────────────────── ────────┤
│epc │ 1 │ 启用 EPC 模式 │
└────────────────────┴────────┴────────────────── ────────┘

│epcDl │ 1 │ 启用全缓冲区DL │
│ │ │ 交通 │
├──────────────────┼────────┼────────────────── ────────┤
│epcUl │ 1 │ 启用全缓冲区 UL │
│ │ │ 交通 │
├──────────────────┼────────┼────────────────── ────────┤
│useUdp │ 0 │ 禁用 UDP 流量和 │
│ │ │ 改为启用 TCP │
├──────────────────┼────────┼────────────────── ────────┤
│macroUeDensity │ 0.00002 │ 确定UE的数量│
│ │ │(在 │ 中转换为 48 个 UE
│ │ │ 我们的模拟) │
├──────────────────┼────────┼────────────────── ────────┤
│outdoorUeMinSpeed │ 16.6667 │ 最小 UE 移动 │
│ │ │ 速度,以米/秒(60 公里/小时)为单位 │
├──────────────────┼────────┼────────────────── ────────┤
│outdoorUeMaxSpeed │ 16.6667 │ 最大 UE 移动 │
│ │ │ 速度,以米/秒(60 公里/小时)为单位 │
├──────────────────┼────────┼────────────────── ────────┤
│macroEnbBandwidth │ 25 │ 5 MHz DL 和 UL │
│ │ │ 带宽 │
├──────────────────┼────────┼────────────────── ────────┤
│generateRem │ 1 │ (可选)用于绘图 │
│ │ │ 无线电环境 │
│ │ │ 地图 │
└────────────────────┴────────┴────────────────── ────────┘

一些必需的假设不能作为参数使用 lena 双条纹。在
在这种情况下,我们覆盖默认属性,如表所示 覆写 默认
属性 交出 运动 联络一位教师

覆写 默认 属性 交出 运动
┌──────────────────────────────────────────────── ──────┬────────────────────────────────┬──────────── ────────────────┐
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
│ns3::LteHelper::切换算法│ ns3::NoOpHandover 算法, │ 交接选择 │
│ │ ns3::A3RsrpH切换算法, │ 算法 │
│ │ ns3::A2A4Rsrq切换算法 │ │
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
│ns3::LteHelper::调度器│ ns3::PfFfMacScheduler │ 比例公平 │
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ DL RLC 的文件名 │
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ UL RLC 的文件名 │
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrFilename │ -DlRsrpSinrStats.txt │ DL PHY 的文件名 │
├────────────────────────────────────────────── ──────┼────────────────────────────────┼──────────── ────────────────┤
│ns3::PhyStatsCalculator::UlSinrFilename │ -UlSinrStats.txt │ UL PHY 的文件名 │
└────────────────────────────────────────────── ──────┴──────────────────────────────────┴──────────── ────────────────┘

ns-3 提供了许多将配置值传递到模拟中的方法。 在这个
例如,我们将使用命令行参数。 它基本上是通过附加
参数及其值 WAF 在开始每个单独的模拟时调用。 所以
这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 WAF 调用我们的 3 个模拟的调用如下所示:

$ ./waf --run="lena-双条纹
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

$ ./waf --run="lena-双条纹
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::切换算法=ns3::A3RsrpH切换算法
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a3-rsrp-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a3-rsrp-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a3-rsrp-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
--RngRun=1" > a3-rsrp.txt

$ ./waf --run="lena-双条纹
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A2A4RsrqHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a2-a4-rsrq-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a2-a4-rsrq-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a2-a4-rsrq-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a2-a4-rsrq-UlSinrStats.txt
--RngRun=1" > a2-a4-rsrq.txt

关于执行的一些注意事项:

· 请注意,某些参数未指定,因为它们已经与
默认值。 我们还将切换算法保留在每个自己的默认设置上。

· 注意仿真输出的文件名,例如 RLC traces 和 PHY traces,因为我们
必须确保它们不会被下一次模拟运行覆盖。 在这个
例如,我们使用命令行参数一一指定名称。

· --RngRun=1 最后的参数用于设置使用的运行号
模拟中使用的随机数生成器。 我们重新运行相同的模拟
不同 荣润 值,因此创建相同的多个独立复制
模拟。 然后我们对从这些复制中获得的结果进行平均,以实现
一些统计信心。

· 我们可以添加一个 --generateRem=1 生成生成所需文件的参数
模拟的无线电环境图 (REM)。 结果如图 快速眼动 获得
a 模拟 in 交出 运动 下面,可以通过以下方式产生
节中描述的步骤 广播电台 环境 地图. 该图还显示了
eNodeB 和 UE 在模拟开始时的位置 荣润 = 1。 其他
的值 荣润 可能会产生不同的 UE 位置。
[图片] 从交接活动中的模拟中获得的 REM。UNINDENT

经过几个小时的运行,模拟活动最终将结束。 接下来我们将
对生成的模拟输出执行一些后处理以获得有意义的
从中获取信息。

在这个例子中,我们使用GNU Octave来辅助处理吞吐量和SINR数据,
如下面的示例 GNU Octave 脚本所示:

% RxBytes 是第 10 列
DlRxBytes = load ("no-op-DlRlcStats.txt") (:,10);
DlAverageThroughputKbps = 总和 (DlRxBytes) * 8 / 1000 / 50

% RxBytes 是第 10 列
UlRxBytes = load ("no-op-UlRlcStats.txt") (:,10);
UlAverageThroughputKbps = 总和 (UlRxBytes) * 8 / 1000 / 50

% Sinr 是第 6 列
DlSinr = load ("no-op-DlRsrpSinrStats.txt") (:,6);
% 消除 NaN 值
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (mean (DlSinr)) % 转换为 dB

% Sinr 是第 5 列
UlSinr = load ("no-op-UlSinrStats.txt") (:,5);
% 消除 NaN 值
idx = isnan(UlSinr);
UlSinr(idx) = 0;
UlAverageSinrDb = 10 * log10 (mean (UlSinr)) % 转换为 dB

至于切换的次数,我们可以用简单的shell脚本统计一下
日志文件中字符串“Handover”的出现次数:

$ grep "移交" no-op.txt | wc -l

结果演示 of 交出 运动 下面显示了我们完成后的完整统计信息
对每个单独的模拟运行进行后处理。 显示的值是平均值
从中获得的结果 荣润 1、2、3 和 4。

结果演示 of 交出 运动
┌────────────────────┬────────────┬──────────────┬── ────────────────┐
│统计 │ 无操作 │ A2-A4-RSRQ │ 最强细胞 │
├──────────────────┼──────────┼────────────┼── ────────────────┤
│平均 DL 系统 │ 6 615 kbps │ 20 509 kbps │ 19 709 kbps │
│吞吐量 │ │ │ │
├──────────────────┼──────────┼────────────┼── ────────────────┤
│平均 UL 系统 │ 4 095 kbps │ 5 705 kbps │ 6 627 kbps │
│吞吐量 │ │ │ │
├──────────────────┼──────────┼────────────┼── ────────────────┤
│平均 DL SINR │ -0.10 dB │ 5.19 dB │ 5.24 dB │
├──────────────────┼──────────┼────────────┼── ────────────────┤
│平均 UL SINR │ 9.54 dB │ 81.57 dB │ 79.65 dB │
├──────────────────┼──────────┼────────────┼── ────────────────┤
│交接次数│ 0 │ 0.05694 │ 0.04771 │
│ 每 UE 每秒 │ │ │ │
└────────────────────┴────────────┴──────────────┴── ──────────────────┘

结果表明,在移动性模拟中使用切换算法可以改善两者
用户吞吐量和 SINR 显着。 两者差别不大
此活动场景中的切换算法。 看到他们的会很有趣
不同场景下的性能,例如家庭基站部署的场景。

频率 重用 例子
有两个示例显示了频率重用算法的功能。

lena频率再利用 是 3 个 eNB 呈三角形布局的简单示例。 有3个细胞
位于该三角形中心的边缘 UE 和 3 个小区中心 UE(一个靠近
每个 eNB)。 用户还可以指定随机定位的 UE 的数量。 FR算法是
安装在 eNB 中,每个 eNB 都有不同的 FrCellTypeId,每个 eNB 使用什么意思
不同的帧中继配置。 用户可以运行 lena频率再利用 有 6 种不同的 FR
算法:NoOp、Hard FR、Strict FR、Soft FR、Soft FFR 和 Enhanced FFR。 运行场景
使用分布式 FFR 算法,用户应使用 lena-分布式-ffr. 这两个例子
非常相似,但由于 Distributed FFR 需要使用 EPC,所以将它们分开,
而其他算法则没有。

跑步 lena频率再利用 使用不同的频率复用算法,用户需要
通过覆盖默认属性指定 FR 算法 ns3::LteHelper::Ffr算法.
要运行的示例命令 lena频率再利用 下面介绍了 Soft FR 算法:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

在这些示例中,添加了生成 REM 和频谱分析仪迹线的功能。
用户可以通过设置启用它的生成 生成Rem生成频谱跟踪
属性。

用于在数据通道中为 RB 1 生成 REM 的命令 lena频率再利用 情景与
Soft FR算法如下:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

软 FR 的无线电环境图如图所示 快速眼动 RB 1 获得
lena频率再利用 例子 - FR 算法 启用.
[图片] RB 1 的 REM 从 lena频率再利用 Soft FR 算法示例
启用.UNINDENT

从中生成频谱轨迹的命令 lena频率再利用 软 FFR 场景
算法如下所示(频谱分析仪位置需要在内部配置
脚本):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=真”

示例频谱分析仪轨迹如图所示 光谱 分析仪 追踪 获得
lena频率再利用 例子 - FFR 算法 启用。 光谱 分析仪
位于 需要 基站 - FrCell类型Id 2.. 可以看出,不同的数据信道子带
以不同的功率电平(根据配置)发送,而控制通道是
沿整个系统带宽以统一功率传输。
[图片] 频谱分析仪迹线获得自 lena频率再利用 软 FFR 示例
算法启用。 Spectrum Analyzer was located need eNB with FrCellTypeId 2..UNINDENT

lena 双条纹 也可以使用安装在所有宏中的频率重用算法运行
基站。 用户需要通过覆盖默认属性来指定 FR 算法
ns3::LteHelper::Ffr算法. 要运行的示例命令 lena 双条纹 硬 FR
算法如下:

$ ./waf --run="lena-双条纹
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

在数据通道中为 RB 1 生成 REM 的示例命令 lena 双条纹 脚本
Hard FR 算法如下:

$ ./waf --run="lena-双条纹
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=0 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > no-op.txt

RB 1、10 和 20 的无线电环境图生成自 lena 双条纹 情景与
硬频率重用算法如下图所示。 这些RB被选中
因为每一个都被不同的 FR 细胞类型使用。
[图片] RB 1 的 REM 从 lena 双条纹 使用 Hard FR 算法进行仿真
启用.UNINDENT
[图片] RB 10 的 REM 从 lena 双条纹 使用 Hard FR 算法进行仿真
启用.UNINDENT
[图片] RB 20 的 REM 从 lena 双条纹 使用 Hard FR 算法进行仿真
启用.UNINDENT

故障排除 调试 秘诀
许多用户在 ns-3-users 邮件列表上发帖询问,例如,为什么他们没有收到任何
他们模拟中的流量,或者可能只有上行链路但没有下行链路流量等。在大多数情况下
在这种情况下,这是用户模拟程序中的错误。 这里有一些调试技巧
程序并找出问题的原因。

一般的方法是有选择地和增量地启用相关的日志记录
LTE 模块组件,在每次激活时确认输出符合预期。 在
detail:

· 首先检查控制平面,特别是 RRC 连接建立
过程,通过启用日志组件 LteUeRrc 和 LteEnbRrc

· 然后检查数据平面上的数据包传输,首先启用日志
组件 LteUeNetDevice 和 EpcSgwPgwApplication,然后是 EpcEnbApplication,然后
向下移动 LTE 无线电堆栈(PDCP、RLC、MAC,最后是 PHY)。 这一切直到你
找到停止处理/转发数据包的位置。

测试 文件记录
概述
为了测试和验证 ns-3 LTE 模块,提供了几个测试套件,它们是
与 ns-3 测试框架集成。 要运行它们,您需要配置
以这种方式构建模拟器:

$ ./waf configure --enable-tests --enable-modules=lte --enable-examples
$ ./测试.py

以上不仅会运行属于 LTE 模块的测试套件,还会运行那些
属于 LTE 模块所依赖的所有其他 ns-3 模块。 见 ns-3
有关测试框架的通用信息手册。

您可以通过以下方式获得更详细的 HTML 格式报告:

$ ./test.py -w 结果.html

上述命令运行后,您可以通过打开查看每个测试的详细结果
文件 结果.html 使用网络浏览器。

您可以使用以下命令分别运行每个测试套件:

$ ./test.py -s 测试套件名称

有关的更多详细信息 测试文件 和 ns-3 测试框架,请参考 ns-3
手册。

描述 of 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 测试 套房
单位 检测
信噪比 计算 in 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 下行
测试套件 LTE-下行链路-sinr 检查下行链路中的 SINR 计算是否已执行
正确。 为分配给数据的每个 RB 计算下行链路中的 SINR
通过将来自所考虑的 eNB 的预期信号的功率除以
噪声功率的总和加上同一 RB 上来自其他 eNB 的所有传输
(干扰信号):

通常,不同的信号可以在不同的时间段期间处于活动状态。 我们定义一个
作为开始或结束类型的任意两个事件之间的时间间隔
波形。 换句话说,一个块标识了一个时间间隔,在此期间
活动波形不会改变。 让我成为通用块,T_i 它的持续时间和
thrm{SINR_i} 它的 SINR,用上面的等式计算。 平均值的计算
信噪比me
测试套件检查上述计算是否在模拟器中正确执行。
测试向量是通过实现上述内容的 Octave 脚本离线获得的
等式,并重新创建一些随机传输信号和干扰
模拟 UE 试图解码来自 eNB 的信号的场景的信号,同时
面临来自其他 eNB 的干扰。 如果计算值等于则测试通过
测试向量在 10^{-7} 的公差范围内。 公差是为了考虑
浮点运算的典型近似误差。

信噪比 计算 in 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 上行
测试套件 LTE-上行链路-sinr 检查上行链路中的 SINR 计算是否已执行
正确。 该测试套件与 LTE-下行链路-sinr 前面描述过
部分,与信号和干扰的区别现在指的是
UE 发送,eNB 接收。 这个测试套件
重新创建一些随机传输信号和干扰信号来模拟
eNB 尝试同时解码来自多个 UE 的信号的场景(
eNB 小区中的那些)同时面临来自其他 UE 的干扰(那些属于
到其他细胞)。

测试向量是通过专用的 Octave 脚本获得的。 测试通过,如果
计算值在 10^{-7} 的公差范围内等于测试向量,至于
下行链路 SINR 测试处理浮点算术逼近问题。

欧洲UTRA 绝对 广播电台 频率 频道 联系电话 (EARFCN)
测试套件 LTE-earfcn 检查所使用的载波频率
LteSpectrumValueHelper 类(实现 LTE 频谱模型)是在
符合 [TS36101],其中 E-UTRA 绝对射频信道号
(EARFCN) 被定义。 该测试套件的测试向量包含一组 EARFCN 值
以及按照规范手动计算的相应载波频率
[TS36101]。 如果 LteSpectrumValueHelper 返回的载波频率为
与测试向量中每个元素的已知值相同。

系统 检测
专注 持票人 停用 检测
测试套件“lte-test-deactivate-bearer”使用单个 EnodeB 和三个创建测试用例
UE的。 每个UE由一个Default和一个具有相同承载的Dedicated EPS承载组成
规范,但具有不同的 ARP。 测试用例流程如下:Attach UE -> Create
默认+专用承载 -> 停用其中一个专用承载

测试用例进一步停用具有承载 ID 2(LCID=BearerId+2) 的专用承载
第一个 UE (UE_ID=1) 用户可以在特定时间延迟后使用
Simulator::Schedule() 方法。

一旦测试用例执行结束,它将创建 DlRlcStats.txt 和 UlRlcStats.txt。 钥匙
统计中需要检查的字段有:

|
开始| 结束 | 小区编号 | IMSI | RNTI| 液晶识别码 | 发送字节 | 接收字节 |

测试用例在三个时期执行。 1) 在第一个纪元 (0.04s-1.04s) 所有 UE 和
相应的承载被附加
和数据包流过激活的专用承载。

2.在第二个Epoch(1.04s-2.04s),bearer deactivation被实例化,因此用户可以看到
与其他承载相比,UE_ID=1 和 LCID=4 上的 TxByte 数量相对较少。

3. 在第三个时期(2.04s-3.04s),因为 UE_ID=1 和 LCID=4 的承载停用是
完成后,用户将看不到任何与 LCID=4 相关的日志记录。

测试用例通过当且仅当 1) IMSI=1 和 LCID=4 在第三个时期完全移除 2)
在对应于 IMSI=1 和 LCID=4 的 TxBytes 和 RxBytes 中没有看到数据包 如果以上
标准与被认为失败的测试用例不匹配

自适应 调制 编码 检测
测试套件 LTE链路适配 提供系统测试以重新创建场景
单个 eNB 和单个 UE。 对应不同的创建不同的测试用例
UE感知的SNR值。 测试的目的是检查每个测试用例中的
选择的 MCS 对应于一些已知的参考值。 得到这些参考值
通过在 Octave 中重新实现(参见 src/lte/测试/参考/lte_amc.m) 中描述的模型
sec-lte-amc 部分用于计算频谱效率,并确定
通过手动查找 [R1-081483] 中的表来获取相应的 MCS 索引。 所结果的
测试向量如图所示 测试 向量 自适应 调制 编码.

模拟器使用的 MCS 是通过获取跟踪输出来测量的
由调度程序在 4 毫秒后生成(这是需要考虑初始延迟
CQI 报告)。 模拟器计算的 SINR 也可以使用
LteChunk处理器 界面。 如果满足以下两个条件,则测试通过
使满意:

1.模拟器计算出来的SINR对应测试向量的SNR在
10^{-7} 的绝对公差;

2.模拟器使用的MCS指标与测试中的完全对应
向量。
[图片] 自适应调制和编码的测试向量.UNINDENT

小区间 干扰 检测
测试套件 干扰 提供系统测试重建一个inter-cell
具有两个 eNB 的干扰场景,每个 eNB 都有一个 UE 连接到它并采用
下行链路和上行链路中的自适应调制和编码。 的拓扑结构
场景如图所示 拓扑 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 细胞间 干扰 测试. d_1
参数表示每个 UE 到它所连接的 eNB 的距离,而 d_2
参数表示干扰距离。 我们注意到场景拓扑是这样的
上行链路和下行链路的干扰距离相同; 仍然,实际
由于传播损耗不同,感知到的干扰功率会不同
在上行链路和下行链路频段。 通过改变 d_1 和
d_2 参数。
[图片] 小区间干扰测试的拓扑结构。UNINDENT

测试向量是通过使用专用的八度脚本(可在
src/lte/test/reference/lte_link_budget_interference.m), 它做链路预算
与每个测试用例的拓扑对应的计算(包括干扰),
并输出由此产生的 SINR 和频谱效率。 后者用于
确定(使用与 自适应 调制 编码 检测。 我们
请注意,测试向量包含上行链路和下行链路的单独值。

UE 测量 检测
测试套件 LTE测量 提供系统测试重建一个inter-cell
干扰场景与定义的相同 干扰 测试套件。
但是,在此测试中,要测试的数量由 RSRP 和 RSRQ 表示
UE 在堆栈的两个不同点执行的测量:源、
是UE PHY层,目的地是eNB RRC。

测试向量是通过使用专用的八度脚本(可在
src/lte/test/reference/lte-ue-measurements.m), 它进行链路预算计算
(包括干扰)对应于每个测试用例的拓扑结构,并输出
由此产生的 RSRP 和 RSRQ。 然后将获得的值用于检查的正确性
PHY 层的 UE 测量。 之后,他们必须根据 3GPP 进行转换
格式化以检查它们在 eNB RRC 级别的正确性。

UE 数据监测 配置 测试
除了前面提到的测试套件外,还有其他3个用于测试UE的测试套件
测量: LTE-UE-测量-分段-1, LTE-UE-测量-分段-2
LTE-UE测量切换. 这些测试套件更侧重于报告触发器
程序,即基于事件的触发实施的正确性
标准在这里得到验证。

更具体地说,测试验证了 定时内容 每个测量报告
eNodeB 收到。 每个测试用例都是一个独立的 LTE 模拟,测试用例将
如果测量报告仅在规定时间出现并显示正确,则通过
RSRP 级别(RSRQ 目前未验证)。

逐段 配置
分段配置旨在测试特定的 UE 测量配置。 这
仿真脚本会为UE设置相应的测量配置,这
将在整个模拟过程中处于活动状态。

由于参考值是手动预先计算的,因此做出了几个假设
简化模拟。 首先,信道只受路径损耗模型的影响(在这个
情况下,使用 Friis 模型)。 其次,使用ideal RRC协议,layer 3
过滤被禁用。 最后,UE 以预定义的运动模式在 4
不同的斑点,如图所示 UE 运动 追踪 始终 这些因素包括原料奶的可用性以及达到必要粉末质量水平所需的工艺。 模拟 in
分段地 配置 以下。 因此,测量的 RSRP 的波动可以是
更容易确定。
[图片] 分段配置中整个模拟的 UE 移动轨迹。UNINDENT

背后的动机 “传送” 在预定义点之间是引入
RSRP 电平的剧烈变化,将保证触发进入或离开
测试事件的条件。 通过执行重大更改,测试可以在
更短的时间。

数字 测量 回复 追踪 of an 例子 创建 A1 测试 案件 in 分段地 配置
下面显示了在 PHY 层进行第 1 层过滤后测得的 RSRP
具有分段配置的模拟。 因为禁用了第 3 层过滤,所以这些
是 UE RRC 实例用于评估报告触发的确切值
程序。 请注意,这些值每 200 毫秒刷新一次,这是默认值
PHY 层测量报告的过滤周期。 该图还显示了时间
事件 A1 示例实例的进入和离开条件(服务单元变为
优于阈值)发生在模拟过程中。
[图片] 分段测量的示例事件 A1 测试用例的 RSRP 轨迹
配置.UNINDENT

每个报告标准都使用不同的阈值/偏移量进行多次测试
参数。 一些测试场景还考虑了迟滞和触发时间。
数字 测量 回复 追踪 of an 例子 创建 A1 - 磁滞现象 测试 案件 in 分段地
配置 描述了事件 A1 测试的另一个示例中滞后的影响。
[图片] 带有迟滞测试用例的示例事件 A1 的测量 RSRP 迹线
分段配置.UNINDENT

分段配置用于 UE 测量的两个测试套件。 第一个是
LTE-UE-测量-分段-1,此后分段测试#1,模拟 1 个 UE 和
1 个基站。 另一个是 LTE-UE-测量-分段-2,它有 1 个 UE 和 2 个 eNodeB
在模拟中。

分段测试 #1 旨在测试不相关的基于事件的标准
关于相邻小区的存在。 这些标准包括事件 A1 和 A2。 这
还对其他事件进行了简短测试,以验证它们是否仍在正常工作
(虽然没有报告任何东西)在没有任何相邻小区的情况下。 桌子 UE
测量 测试 情景 运用 分段地 配置 #1 下面列出了场景
在分段测试 #1 中测试。

UE 测量 测试 情景 运用 分段地 配置 #1
┌────────┬────────────┬──────────────────┬────────── ──┬──────────────────┐
│测试 # │ 报告 │ 阈值/偏移 │ 迟滞 │ 触发时间 │
│ │ 标准 │ │ │ │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│1 │ 事件 A1 │ 低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│2 │ 事件 A1 │ 正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│3 │ 事件 A1 │ 正常 │ 否 │ 空头 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│4 │ 事件 A1 │ 正常 │ 否 │ 长 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│5 │ 事件A1 │ 普通 │ 否 │ 超级 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│6 │ 事件 A1 │ 正常 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│7 │ 事件 A1 │ 高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│8 │ 事件 A2 │ 低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│9 │ 事件 A2 │ 正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│10 │ 事件 A2 │ 正常 │ 否 │ 空头 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│11 │ 事件 A2 │ 正常 │ 否 │ 长 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│12 │ 事件A2 │ 普通 │ 否 │ 超级 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│13 │ 事件 A2 │ 正常 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│14 │ 事件 A2 │ 高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│15 │ 事件 A3 │ 零 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│16 │ 事件 A4 │ 正常 │ 否 │ 否 │
└────────┴────────────┴──────────────────┴────────── ──┴──────────────────┘

│17 │ 事件 A5 │ 正常-正常 │ 否 │ 否 │
└────────┴────────────┴──────────────────┴────────── ──┴──────────────────┘

事件 A3、A4 和 A5 等其他事件取决于相邻小区的测量,因此
它们在 Piecewise test #2 中进行了更彻底的测试。 模拟将节点放在
直线并指示UE “跳” 以与分段测试 #1 类似的方式。
切换在模拟中被禁用,因此服务小区和相邻小区的角色
模拟过程中不切换。 桌子 UE 测量 测试 情景 运用 分段地
配置 #2 下面列出了在分段测试#2 中测试的场景。

UE 测量 测试 情景 运用 分段地 配置 #2
┌────────┬────────────┬──────────────────┬────────── ──┬──────────────────┐
│测试 # │ 报告 │ 阈值/偏移 │ 迟滞 │ 触发时间 │
│ │ 标准 │ │ │ │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│1 │ 事件 A1 │ 低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│2 │ 事件 A1 │ 正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│3 │ 事件 A1 │ 正常 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│4 │ 事件 A1 │ 高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│5 │ 事件 A2 │ 低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│6 │ 事件 A2 │ 正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│7 │ 事件 A2 │ 正常 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│8 │ 事件 A2 │ 高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│9 │ 事件 A3 │ 正 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│10 │ 事件 A3 │ 零 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│11 │ 事件 A3 │ 零 │ 没有 │ 短 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│12 │ 事件A3 │ 零 │ 否 │ 超级 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│13 │ 事件 A3 │ 零 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│14 │ 事件 A3 │ 否定 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│15 │ 事件 A4 │ 低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│16 │ 事件 A4 │ 正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│17 │ 事件 A4 │ 正常 │ 否 │ 空头 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│18 │ 事件A4 │ 普通 │ 否 │ 超级 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│19 │ 事件 A4 │ 正常 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│20 │ 事件 A4 │ 高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│21 │ 事件 A5 │ 低-低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│22 │ 事件 A5 │ 低-正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│23 │ 事件 A5 │ 低-高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│24 │ 事件 A5 │ 正常-低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│25 │ 事件 A5 │ 正常-正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│26 │ 事件A5 │ 正常-正常 │ 没有 │ 空头 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│27 │ 事件A5 │ 正常-正常 │ 否 │ 超级 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│28 │ 事件 A5 │ 正常-正常 │ 是 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│29 │ 事件 A5 │ 正常高 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│30 │ 事件 A5 │ 高-低 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│31 │ 事件 A5 │ 高-正常 │ 否 │ 否 │
├────────┼────────────┼──────────────────┼────────── ──┼──────────────────┤
│32 │ 事件 A5 │ 高-高 │ 否 │ 否 │
└────────┴────────────┴──────────────────┴────────── ──┴──────────────────┘

关于触发时间测试的注意事项,它们使用 3 个不同的值进行测试
触发时间: (短于报告间隔), (比过滤器短
200毫秒的测量周期),和 (超过 200 毫秒)。 前两个确保
触发时间评估始终使用从 PHY 收到的最新测量报告
层。 最后一个负责验证触发取消时间,因为
当 PHY 的测量报告显示进入/离开条件为 no 时的示例
在触发第一个触发器之前不再为真。

交出 配置
切换配置的目的是验证UE测量是否
配置在成功切换后正确更新。 为了这
目的,仿真将构建 2 个具有不同 UE 测量的 eNodeB
配置,UE将执行从一个小区到另一个小区的切换。 UE将是
位于2个eNodeB之间的直线上,将调用切换
手动。 每次模拟的持续时间为 2 秒(最后一个测试用例除外),并且
切换恰好在仿真进行到一半时触发。

- LTE-UE测量切换 测试套件涵盖各种类型的配置
差异。 第一个是报告间隔的差异,例如第一个 eNodeB 是
配置为 480 ms 报告间隔,而第二个 eNodeB 配置为 240 ms
报告间隔。 因此,当UE切换到第二小区时,新的
报告间隔必须生效。 与分段配置一样,时序和
eNodeB收到的每份测量报告的内容都会被校验。

测试套件涵盖的其他类型的差异是事件和
阈值/偏移量的差异。 桌子 UE 测量 测试 情景 运用 交出
配置 下面列出了经过测试的场景。

UE 测量 测试 情景 运用 交出 配置
────────────────────────────────────────────────────── ────────────────────────
测试# 测试对象初始交接后
配置 配置
────────────────────────────────────────────────────── ────────────────────────
1 报告间隔 480 毫秒 240 毫秒
────────────────────────────────────────────────────── ────────────────────────
2 报告间隔 120 毫秒 640 毫秒
────────────────────────────────────────────────────── ────────────────────────
3 事件 事件 A1 事件 A2
────────────────────────────────────────────────────── ────────────────────────
4 事件 事件 A2 事件 A1
────────────────────────────────────────────────────── ────────────────────────
5 事件 事件 A3 事件 A4
────────────────────────────────────────────────────── ────────────────────────
6 事件 事件 A4 事件 A3
────────────────────────────────────────────────────── ────────────────────────
7 事件 事件 A2 事件 A3
────────────────────────────────────────────────────── ────────────────────────
8 事件 事件 A3 事件 A2
────────────────────────────────────────────────────── ────────────────────────
9 事件 事件 A4 事件 A5
────────────────────────────────────────────────────── ────────────────────────
10 事件 事件 A5 事件 A4
────────────────────────────────────────────────────── ────────────────────────
11 阈值/偏移 RSRP 范围 52 RSRP 范围 56
(活动A1) (活动A1)
────────────────────────────────────────────────────── ────────────────────────
12 阈值/偏移 RSRP 范围 52 RSRP 范围 56
(活动A2) (活动A2)
────────────────────────────────────────────────────── ────────────────────────
13 阈值/偏移量 A3 偏移量 -30 A3 偏移量 +30
(活动A3) (活动A3)
────────────────────────────────────────────────────── ────────────────────────
14 阈值/偏移 RSRP 范围 52 RSRP 范围 56
(活动A4) (活动A4)
────────────────────────────────────────────────────── ────────────────────────
15 阈值/偏移 RSRP 范围 52-52 RSRP 范围 56-56
(活动A5) (活动A5)
────────────────────────────────────────────────────── ────────────────────────
16 触发时间 1024 毫秒 100 毫秒
────────────────────────────────────────────────────── ────────────────────────
17 触发时间 1024 毫秒 640 毫秒
┌────────┬──────────────────┬────────────────────┬ ──────────────────────┐
│ │ │ │ │
二进制文件(标准输入)匹配

使用 onworks.net 服务在线使用 ns-3-model-library


免费服务器和工作站

下载 Windows 和 Linux 应用程序

Linux 命令

Ad




×
广告
❤️在这里购物、预订或购买——免费,有助于保持服务免费。