ns-3中的数据跟踪与采集——Tracing系统的配置

ns-3中的数据跟踪与采集——Tracing系统的配置

在文章ns-3中的数据跟踪与采集——Tracing系统综述及fourth脚本中学习的函数TraceConnectWithoutContext在实际编写中很少用到。通常使用“Config path”子系统从系统中选取用户所要使用的Trace Source。这里使用在ns-3脚本初识——WIFI无线网络:third脚本中学过的third.cc作为基本代码,然后通过定义一个Trace Sink来输出移动节点的位置变化信息。

下面的函数CourseChange就是要定义的Trace Sink,和定义普通函数没有太大区别,在主函数前声明定义就行。

void
CourseChange (std::string context, Ptr<const MobilityModel> model)
{
  Vector position = model->GetPosition ();
  NS_LOG_UNCOND (context <<
    " x = " << position.x << ", y = " << position.y);
}

下面的代码就是使上面的Trace Sink和Trace Source相关联的代码。放在 Simulator::Run ();前面即可。

std::ostringstream oss;
oss << "/NodeList/"
    << wifiStaNodes.Get (nWifi - 1)->GetId ()
    << "/$ns3::MobilityModel/CourseChange";

Config::Connect (oss.str (), MakeCallback (&CourseChange));

使用类Config的第一个静态成员函数Connect将二者关联在一起。这个函数有两个参数。其中,第二个参数MakeCallback (&CourseChange)的功能是使函数CourseChange成为一个回调函数。第一个参数oss.str ()是一个由各种字符组成的字符串,下面来分析这个作为路径的字符串所代表的含义:

为了便于讨论,假设getid()返回的节点号是“7”。在这种情况下,上面的路径是

"/NodeList/7/$ns3::MobilityModel/CourseChange"

第一个“/”符号代表后面要紧跟的是命名空间,后面所跟的“/”符号可以像目录与子目录一样来理解。这里用到的命名空间为NodeList。而NodeList是一个仿真中使用的节点的一个列表,紧随其后的是这个列表的一个索引,这里是通过Get函数来获取该节点,再通过GetId函数来得到该节点的索引。下一段字符串的第一个字符为“$”,当程序遇到这个符号时,就会调用函数GetObject来返回一个对象,因为在实际仿真中使用的对象聚合技术已经把许多对象全都集成在这个节点中。因为节点中集成了所需要的对象,所以后面就要给出返回对象的类型,此处要返回的对象类型是MobilityModel。而类MobilityModel有一个CourseChange属性,也就是我们要跟踪的Trace Sources。

如何确定“Config path”?
只要进入API文档,进入所需要的类,就会看到一个标题Config Paths,如下图所示:
API文档截图下面对比更改前的程序third.cc和更改后的mythird.cc运行结果对比。可以看到,后者的结果中不仅包含了前者的结果,还有后来通过Tracing系统定义的一些相关输出结果,即节点7(如下所示)的位置坐标变化信息。
节点7示意图

third.cc的运行结果:
third.cc运行结果
mythird.cc的运行结果:
mythird.cc运行结果
在本例中已经研究了系统中可能有任意数量的跟踪源对应于具有移动模型的任意数量的节点。需要有某种方法来确定哪个跟踪源实际上是触发回调的跟踪源。简单的方法是使用Config::Connect连接,而不是使用Config::ConnectWithoutContext。

猜你喜欢

转载自blog.csdn.net/qq_31676673/article/details/88794600