当前位置:文档之家› H.248协议

H.248协议

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
目 录
目 录
第 2 章 H.248 协议 ..................................................................................................................2-1
2.1 概述.................................................................................................................................... 2-1 2.1.1 基本概念 .................................................................................................................. 2-1 2.1.2 相关术语 .................................................................................................................. 2-1 2.1.3 协议栈结构 .............................................................................................................. 2-6 2.1.4 H.248 协议的应用 .................................................................................................... 2-7 2.2 协议消息............................................................................................................................. 2-8 2.2.1 消息类型 .................................................................................................................. 2-8 2.2.2 消息结构 .................................................................................................................. 2-9 2.3 基本控制流程 ................................................................................................................... 2-24 2.3.1 网关注册流程......................................................................................................... 2-24 2.3.2 网关注销流程......................................................................................................... 2-25 2.3.3 网关初始化流程 ..................................................................................................... 2-26 2.3.4 成功的终端呼叫流程.............................................................................................. 2-27 2.3.5 成功的中继呼叫流程.............................................................................................. 2-38
i

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
第2章 H.248 协议
2.1 概述
2.1.1 基本概念
H.248 协议, 也叫 MeGaCo 协议, 是媒体网关控制器 (MGC) 与媒体网关 (MG) 之间的一种媒体网关控制协议,这个协议是一项 ITU-T 与 IETF 合作结果的新 标准。目前 ITU-T、IETF、软交换论坛等标准化组织正在加紧对 H.248 协议 进行完善,各大电信设备制造商也在 H.248 协议的研发和应用上加大了投入。 与 MGCP 协议相比,H.248 协议可以支持更多类型的接入技术并支持终端的 移动性, 除此之外, H.248 协议最显著之处在于能够支持更大规模的网络应用, 而且更便于对协议进行扩充,因而灵活性更强,已逐渐取代 MGCP 发展成为 媒体网关控制协议的标准。
2.1.2 相关术语
1. 终端 终端 (Termination) MG 的一个逻辑实体, 是 可以发送 (接收) 媒体流和 (或) 控制流,终端可用特性来进行描述,在终端中,封装了媒体流参数、modem 和承载能力参数,这些特性可以组成一系列描述符而包含在命令中。终端有 唯一的标志 Termination ID,它由 MG 在创建终端时分配。 2. 终端类型 终端类型分为半永久性终端和临时性终端两类。半永久性终端可以代表物理 实体,例如一个 TDM 信道,此时,只要 MG 存在这个信道,这个终端就存在。 临时性终端可以代表临时性的信息流,例如 RTP 流,此时,只有当 MG 使用 这些信息流时,这个终端才存在。 临时性终端可由 Add 命令来创建、Subtract 命令来删除。而半永久终端不同, 当使用 Add 命令向一个关联添加物理终端时,这个物理终端来自空关联,当 使用 Subtract 命令从一个关联中删除物理终端时,这个物理终端将转移到空 关联中。
2-1

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
3. 终端功能 终端可支持信号, 这些信号可以是 MG 产生的媒体流 (如信号音和录音通知) , 也可以是信路信号(如 Hook Flash)。 通过编程可以设置终端对事件进行检测,一旦检测到这些事件发生,MG 就向 MGC 发送 Notify 消息进行报告或由 MG 采取相应的操作。 终端可以对数据进行统计,当 MGC 发出 AuditValue 命令进行统计请求时, 或者当终端从它所在的关联被删除时,终端就将这些统计数据报告给 MGC。 4. 终端 ID 终端可用 Termination ID 进行标识, Termination ID 由 MG 分配。 Termination ID 可以使用通配值“ALL”和“CHOOSE”。通配值“ALL”用来规定多个 终端,当命令中的 Termination ID 是通配值“ALL”时,则对每一个匹配的终 端重复该命令;“CHOOSE”则用来指示 MG 必须选择符合条件的终端,例 如 MGC 可以指示 MG 选择一个中继群中的一条中继点电路。 例如,在协议的文本格式编码中,有 R13/3/1, R13/3/2, R13/3/3 三个终端, 则 R13/3/*将匹配所有这三个终端。一些特殊场合必须引用所有终端,这时 “ * ”就可满足要求。当需要引用一个 Termination ID,但不能确定该终端是 否存在,则可以选用“CHOOSE”,即“ $ ”,则 R13/3/$将匹配三个终端 中的其中一个。 5. 描述符 描述符(Descriptor) 是协议中的一种语法元素,用来描述一组相互联系的特 性。例如:通过在一个命令中包含适当的描述符控制器能够设置 MG 中的媒 体流特性。 6. 终端特性 终端可用特性进行描述,每个特性由一个 PropertyID 标识,由这些特性可以 组成一系列描述符。 终端具有一些公共特性以及与特定媒体流相关的非公共特性。公共特性与特 定媒体流无关,也称为终端状态(TerminationState)特性。与特定媒体流相 关的特性包括本地(Local)特性和接收/发送流特性。终端的非公共特性由包 进行定义,这些特性可由包名(PackageName)和特性标识符(PropertyID) 来标识。特性具有只读(ReadOnly)和可读写(Read/Write)两种属性,对 于可读写的特性,MGC 可以设置它们的值。 当使用 Add 命令将一个终端添加到一个关联时,可以通过加入适当的描述符 作为命令输入参数来设置可读写的特性值,Add 命令中未设置的特性值将保
2-2

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
持它们以前的值。类似的,使用 Modify 命令可以改变一个关联中的终端的特 性值,Modify 命令中未设置的特性值将保持它们以前的值。使用 Move 命令 将一个终端从一个关联转移到另一个关联时,也可以改变终端的特性值。 7. 根终端 根终端(Root)是特殊的终端,代表整个 MG。当 root 作为命令的输入参数 时,命令可以作用于整个网关,而不是一个终端。 8. 关联 关联(Context)为一组终端之间的联系。如果一个关联中超过两个终端,那 么关联就对终端之间的拓扑结构和媒体混合和(或)交换参数进行描述。空 关联是一种特殊的关联,它包含所有那些与其它终端没有联系的终端,例如, 在一个中继网关中,所有的空闲线路被作为终端包括在“空”关联当中。 图 2-1给出了终端和关联的例子,但不包括所有类型。
Media Gateway Context Context
Termination RTP Stream Termination SCN Bearer Channel Termination SCN Bearer Channel
* * *
图2-1 关联模型示例
Context
Termination RTP Stream
Null Context
Termination SCN Bearer Channel
Context
Termination RTP Stream Termination SCN Bearer Channel
关联中的最大终端数是媒体网关的一个特性。仅支持点到点连接的媒体网关 在每个关联中仅允许两个终端存在。支持会议呼叫的媒体网关可以允许三个 或更多的终端同时存在于一个关联中。 9. 关联特性 关联具有以下特性: ContextID:关联标识,一个由媒体网关(MG)选择的 32 位整数,在 MG 范 围内是独一无二的。特殊关联编码对照如表 2-1所示:
2-3

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册 表2-1 特殊关联编码对照表 关联 空关联 CHOOSE 关联 ALL 关联 0 0xFFFFFFFE 0xFFFFFFFF 二进制编码 文本编码 “_” “$” “*”
第 2 章 H.248 协议
含义 表示在网关中所有与其它任何终端都 没有关联的终端 表示请求 MG 创建一个新的关联 表示 MG 的所有关联
Topology:拓扑结构,关联的拓扑结构描述关联中终端之间的媒体的流向。 终端的 Send/Receive 方式指示媒体在媒体网关的流入或流出方向。 有三种连 接值:单向,双向,隔离 。单向是指两个终端之间的单向媒体流。 双向是指 的两个终端之间的双向媒体流。隔离是指两个终端之间没有媒体流。拓扑结 构只用于描述关联。它可在“Add”或“Modify”命令中使用。 优先权:表示 MG 处理关联的先后次序。“0”为最低优先级,“15”为最高 优先级。 紧急呼叫的标识符: 用于关联向 MG 提供紧急呼叫关联的信息。 MG 优先处理 使用紧急呼叫标识符的呼叫。 10. 包 不同类型的网关可以支持不同类型的终端,本协议通过允许终端具有可选的 特性、事件、信号和统计来实现不同类型的终端。为了实现 MG 和 MGC 之间 的互操作,本协议将这些可选项组合成包(Packages), MGC 可以通过审 计命令 Audit 来确定终端实现了哪一种类型的包。 终端具有可选的特性、事件、信号和统计,这些可选项组合成包。这些项以 及包含的参数分别由标识符 ID 进行标识。 包的定义特性、事件、信号、统计和程序五个部分。表 2-2列出了几类常用的 包:
表2-2 包分类列表 包名 Generic Base Root Package 中文名 通用包 基础根包 g root 包 ID 含义 常见项目里都会用到通用包 该包定义了网关范围内的属性
2-4

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
包名
中文名
包 ID
含义 该包定义了生成放音的各种信号。基于扩 展性的考虑,该包没有指定参数值。放音 一般定义成单个的信号,信号包含一个参 数 ind 、 一 个 放 音 ID 。参数 ind 表 示 interdigit 时延,放音 ID 用于放音。放音 ID 对于任何相同的语音来说都应该与语 音生成保持一致。MG 应提供其所在国家 支持的各种放音的特性。 该包定义了用于音检测的各种事件。各种 音通过其名称(放音 ID)来选择。MG 应 提供其所在国家支持的各种放音的特性。 该包将基本的 DTMF 音定义成各种信号, 并扩展了 tonegen 中 playtone 的参数 tl 的允许取值。 该包定义了基本的 DTMF 音检测。 该包扩 展了“start tone detected”、“end tone detected”和“long tone detected”事件 中放音 ID 的可能的取值。 该包将基本的呼叫进展音定义成各种信 号, 并扩展了 tonegen 中 playtone 的参数 tl 的允许取值。 该包定义了基本呼叫进展检测音。该包扩 展了“start tone detected”、“end tone detected”和“long tone detected”事件 中放音 ID 的可能的取值。 该包定义了模拟线的各种事件和信号。 该包定义了用于导通测试的各种事件和 信号。导通测试包括提供环回或收发器功 能。 该包定义了与网络类型无关的网络终端 的属性。 该包用于支持通过实时传输协议 RTP 方 式的分组多媒体数据传输。 该包用于支持 TDM 电路终结点。
Tone Generator Package
音生成器包
tonegen
Tone Detection Package Basic DTMF Generator Package DTMF detection Package Call Progress Tones Generator Package Call Progress Tones Detection Package Analog Line Supervision Package Basic Continuity Package Network Package RTP Package TDM Circuit Package
音检测包
tonedet
基 本 DTMF 生成器包
dg
DTMF 检 测 包
dd
呼叫进展音 生成器包
cg
呼叫进展音 检测包
cd
模拟线监控 包
al
基本导通包
ct
网络包 RTP 包 TDM 电路包
nt rtp tdmc
表 2-3列出了包中常用的特性名、事件名和信号等。其通常为包名/特性名、 包名/事件名和包名/信号的格式。
2-5

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册 表2-3 特性名、事件名和信号举例 事件名 al/fl al/of al/on al/ri cg/bt cg/ct cg/cw cg/dt cg/rt dd/ce nt/jit tdmc/ec tdmc/gain 模拟线包中的拍叉事件 模拟线包中的摘机事件 模拟线包中的挂机事件 模拟线包中的振铃音信号 呼叫音包中的忙音信号 呼叫音包中的拥塞音信号 呼叫音包中的呼叫等待音信号 呼叫音包中的拨号音信号 呼叫音包中的回铃音信号 DTMF 检测包中的 DigitMap Completion 事件 含义
第 2 章 H.248 协议
Network Package 中的抖动缓存最大值,单位为毫秒 TDM 电路包中的回声取消特性 TDM 电路包中的增益控制特性
2.1.3 协议栈结构
H.248 消息可基于 UDP/IP 传输,此外还可基于其它多种传输协议传输,如承 载在 IP 网络上的 TCP、SCTP 和 M3UA,承载在 ATM 上的 MTP3-B 等。 SoftX3000 H.248 协议传输层可以是承载在 IP 上的 UDP/TCP/SCTP 和承载 在 ATM 上的 MTP3-B,如图 2-2所示:
H.248 UDP/TCP/SCTP IP MAC
图2-2 SoftX3000 H.248 协议栈
H.248 协议假设其下层的传输网络是不可靠的, 因此事务的状态和可靠性由协 议本身实现。
2-6

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
2.1.4 H.248 协议的应用
H.248 在 NGN 中的典型应用如图 2-3所示,目前主要应用在软交换系统 (SoftSwitch)与中继媒体网关(TMG)之间的通信、软交换设备与接入媒体 网关(AMG/IAD)之间的通信。
SoftX3000
H.248 IP城域网
No.7中继电路
PSTN 交换机
TMG8010 / UMG8900
H.248
图2-3 H.248 在 NGN 中的典型应用
SoftX3000 通过 H.248 协议与中继网关通信。Soft Switch 提供 H.248 MGC 功能以控制中继网关中的 ISUP 中继,H.248 MGC 提供以下功能: (1) 出口网关和入口网关的 RTP 容量协商
可以配置每个 H.248 MG 的 RTP 发送和接受容量。 SoftX3000 要确保两个 MG 之间设定的匹配容量被用于建立呼叫。 (2) 通过 H.248 协议管理 TMG 中的 PSTN ISUP 中继 支持 TMG 上的中继预留 支持 TMG 上的中继释放 支持 TMG 上的中继回流型连接 支持中继参数的修改 在中继上加上信号音 支持中继(或中继组)暂停业务和恢复业务 (3) 通过 H.248 协议管理 TMG 中的临时 RTP 终止 支持临时终端的创建 支持临时终端的取消
2-7

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
支持有关临时终端的 RTP 参数的修改
2.2 协议消息
2.2.1 消息类型
1. 命令 H.248 定义了 8 个命令,用于对协议连接模型中的逻辑实体(关联和终端) 进行操作和管理,命令提供了实现对关联和终端进行完全控制的机制。 H.248 规定的命令大部分用于 MGC 实现对 MG 的控制。通常 MGC 作为命令 起始者,MG 作为命令响应者接收。但是, Notify 和 ServiceChange 命令除 外。Notify 命令由 MG 发送给 MGC, 而 ServiceChange 既可以由 MG 发起, 也可以由 MGC 发起。 H.248 命令及其含义参见表 2-4:
表2-4 H.248 命令 命令名称 Add Modify Subtract Move AuditValue AuditCapa bilities Notify 命令代码 ADD MOD SUB MOV AUD_VAL AUD_CAP NTFY 描述 MGC→MG , 增 加 一 个 终 端 到 一 个 关 联 中 , 当 不 指 明 ContextID 时,将生成一个关联,然后再将终端加入到该 关联中。 MGC→MG,修改一个终端的属性、事件和信号参数。 MGC→MG,从一个关联中删除一个终端,同时返回终端 的统计状态。如关联中再没有其它的终端将删除此关联。 MGC→MG,将一个终端从一个关联移到另一个关联。 MGC→MG,获取有关终端的当前特性,事件、信号和统 计信息。 MGC→MG,获取 MG 所允许的终端的特性、事件和信号 的所有可能值的信息。 MG→MGC ,MG 将检测到的事件通知给 MGC。 MGC?MG 或 MG→MGC, MG 使用 ServiceChange 命 令向 MGC 报告一个终端或者一组终端将要退出服务或者 刚刚进入服务。MG 也可以使用 ServiceChange 命令向 MGC 进行注册,并且向 MGC 报告 MG 将要开始或者已 经 完 成 了 重 新 启 动 工 作 。 同 时 , MGC 可 以 使 用 ServiceChange 命令通知 MG 将一个终端或者一组终端 进入服务或者退出服务。
ServiceCh ange
SVC_CHG
2-8

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
2. 响应 所有的 H.248 命令都要接收者回送响应。命令和响应的结构基本相同,命令 和响应之间由事务 ID 相关联。 响应有两种:“Reply”和“Pending”。“Reply”表示已经完成了命令执行, 返回执行成功或失败信息; “Pending”指示命令正在处理, 但仍然没有完成。 当命令处理时间较长时,可以防止发送者重发事务请求。
2.2.2 消息结构
1. 命令格式 (1) 命令的封装格式
H.248 协议发送或接收的信息单元称为消息。在 H.248 协议中,一个或多个 命令被封装成一个消息进行发送或接收。 H.248 消息可以是二进制格式和文本格式编码。 采用二进制编码时, 使用 ITU-T X.680 (ASN.1)定义的规范描述,使用 X.690 定义的 BER 规则编码;采用 文本方式编码时, 遵循 RFC 2234 ABNF 规范。 MGC 必须支持两种编码格式, MG 可能支持其中任何一种或两种方式。H.248 消息都有相同的结构,一个 H.248 消息的结构如图 2-4所示。
Megaco/H.248 message ....
Header
Transaction Req or Reply
Transaction Req or Reply
Transaction Req or Reply
Trans Hdr
Action
....
Action
Ctx Hdr
Ctx Properties
Command
....
Command
Trans Hdr
Descriptor
....
Descriptor
图2-4 H.248 消息结构
消息 消息从消息头(Header)开始,后面是若干个事务。消息头中包含消息标识 符(MID,Message Identifier)和版本字段:MID 标识消息的发送者,可以
2-9

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
是域地址、域名或设备名,一般采用域名;版本字段用于标识消息遵守的协 议版本,版本字段有 1 位或 2 位数,目前版本为 1。 事务 一个消息(Message)包含一个或多个事务(Transaction),消息内的事务 是相互独立的,当多个被独立处理时,消息没有规定处理的先后次序。 事务包括请 求和响应两 种类型,而 响应也有两 种:TransactionReply 和 TransactionPending。由于命令封装在 Transaction Request 事务中,我们在 此仅对请求事务结构进行介绍。响应事务结构我们将在下一节介绍。 每个 Transaction Request 请求激发一个事务。 一个事务包含一个到多个动作, 每个动作包含一系列与同一个 Context 相关的一个到多个命令。其结构如下:
TransactionRequest(TransactionId { ContextID {Command ... Command}, ... ContextID {Command ... Command } })
动作 动作与关联(Context)是密切相关的,动作由 ContextID 进行标识。在一个 动作内,命令需要顺序执行。 一个动作从关联头部(CtxHdr)开始,在 CtxHdr 包含 ContextID,用于标识 该动作对应的关联。ContextID 由 MG 指定,在 MG 范围内是唯一的。MGC 必须在以后的与此关联相关的事务中使用相同的 ContextID。 在 CtxHdr 后面是若干命令,这些命令都与 ContextID 标识的关联相关。 命令 命令是 H.248 消息的主要内容,实现对关联和终端属性的控制,包括指定终 端报告检测到的事件,通知终端使用什么信号和动作,以及指定关联的拓扑 结构等,命令由命令头部(CMDHdr)与命令参数构成,在 H.248 协议中, 命令参数被组织成“描述符”(Descriptor)。 由此,H.248 消息构成机制如图 2-5所示。
2-10

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
消息 事务 关联 命令 描述符
Message TransactionI ContextID1
CMD1 Des-1 Des-n
...CMDn
ContextIDn
...
TransactionIDn
图2-5 消息机制
(2)
命令描述符
一个命令的参数被定义为描述符。 描述符是由 Name 和 item 组成(item 可以携 带 Value)。一些命令可以共享一个或几个描述符。描述符可以作为一个命令 的输出返回值。在很多情况下描述符作为返回值,只有 Name 没有其它 item。 通常,描述符的形式如下:
DescriptorName=
{ parm = value, parm = value ...... }
H.248 协议定义了 19 种描述符,下面我们对常用的一些描述符进行介绍。 Modem 描述符(MD) 标识 Modem 的类型和其它参数等信息。Modem 描述符包含以下调制解调器 类型: V.18、 V.22、V.22bis 、 V.32、 V32bis 、 V.34、 V.90、V.91、 同步 ISDN, 并且允许进行扩充。缺省情况下,终端中不包含 Modem 描述符。 Mux 描述符(MX) 多媒体呼叫时,媒体流是在一群承载通道上进行传输的。复用描述符将媒体 和对应的承载通道联系起来。 复用描述符支持的复用类型包括: H.221、 H.223、 H.226、V. 7 6 以及一些扩展复用类型。复用描述符的定义由复用类型以及被 复用的输入终端的 TerminationID 集合组成,例如: Mux=H.221{ MyT3/1/2,MyT3/2/3,MyT3/3/6,MyT3/21/22}。 Media 描述符(M) 媒体描述符是用于描述所有媒体流特性的参数。媒体流特性参数可用终端状 态描述符(TerminationState)和若干个流描述符(Stream)来描述。其中,
2-11

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
TerminationState 描述符与特定媒体流无关, 用于描述终端的特性; Stream 描 述符描述媒体流。 本协议规定 Stream 描述符由 StreamID 进行标识。Stream 描述符可分为本 地控制描述符 (LocalControl ) 本地描述符 、 (Local)和远端描述符 (Remote) 三种。为简便起见,本协议规定 LocalControl、 Local 和 Remote 可以在一个 Media 描述符中进行定义,当这三种描述符在一个 Media 描述符中描述时, Stream 描述符的 StreamID 通常假定为 1。 这几种描述符之间的关系如下所示: Media Descriptor TerminationStateDescriptor Stream Descriptor LocalControl Descriptor Local Descriptor Remote Descriptor Termination State 描述符(TS) TerminationState 描述符包括业务状态(ServiceStates)特性、事件缓存控 制(EventBufferControl)特性以及在包中定义的与特定流无关的终端特性。 其中,ServiceStates(SI)特性描述了终端的状态,本协议规定终端状态有 以下三种:“test(TE)”、“out of service(OS)”和“in service(IV)”。 “test”用于指示一个终端正在处于被检测的状态;“out of service”用于指 示一个终端处于退出服务的状态;“in service”用于指示一个终端正处于服 务状态。TerminationState 描述符的缺省值为“in service”。 EventBufferControl(EB)特性描述了检测到 Events 描述符中指定的事件后 的处理方式。本协议规定处理方式有两种:一种是立即对事件进行处理;另 一种是先对事件进行缓存再处理。 Stream 描述符(ST) Stream 描 述 符 用 于 指 定 一 个 双 向 流 的 参 数 。 Stream 描 述 符 可 分 为 LocalControl、Local 和 Remote 描述符三种。本协议规定 Stream 描述符可 用 StreamID 进行标识,通过在关联中的一个终端上指定一个新的 StreamID 可以创建一个新的流。而删除一个存在的流则需要对该流原先所在的关联中 的所有终端设置:LocalControl 描述符中 ReserveGroup 和 ReserveValue 参 数为“false”;Local 和 Remote 描述符为空。 H.248 规定 StreamID 由 MGC 分配,StreamID 是 MGC 和 MG 之间的局部 参数。一个关联中具有相同 StreamID 的流是相互连接。
2-12

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
LocalControl 描述符(O) LocalControl 描述符包含模式属性 Mode(MO)、预留组属性 ReserveGroup (RG)、预留值属性 ReserveValue(RV)和包中定义的某些与特定媒体流 有关的终端属性。 Mode 可分为 Sendonly(SO)、Receiveonly(RC)、Send/Receive(SR)、 Inactive(IN)和 Loopback(LB)几种。其中 Send 和 Receive 与关联中媒 体流的流向有关。例如,如果某个媒体流的模式为 Sendonly ,则此流并不将 接收到的媒体传送给关联。信号和事件均不受模式的影响。 预留属性 Reserve 决定了 MG 在收到 Local 和/或 Remote 描述符后的处理动 作。Reserve 属性包括 ReserveValue 和 ReserveGroup 两种属性,属性值为 布尔函数,缺省值均为“False”。 Local 描述符(L)和 Remote 描述符(R) Local 描述符针对 MG 接收到的媒体进行定义,Remote 描述符对 MG 发出的 媒体进行定义。 利用 Local 和 Remote 描述符,MGC 为 MG 预留和承接用于信息流和终端的 媒体编解码所需的资源, 则在响应中通过这些描述符返回它实际预留的资 MG 源。如果一些必选属性未在 MGC 发出的请求中给出,那么 MG 要在响应中 添加这些属性。 如果采用文本方式编码,则 Local 和 Remote 描述符由 RFC 2327 所定义的 SDP 的会话描述来构造。 Events 描述符(E) Events 描述符包含 RequestID 属性以及 MG 要求检测和报告的一组事件。通 过 RequestID 可以将事件请求命令和事件发生通知(Notify) 命令关联起来。 请求事件包括传真音、摘机/挂机和 Hook Flash 等。 描述符的每个事件包含事件名、可选动作、可选参数。事件名包括包名和事 件名,格式描述为包名/事件名(例如:al/on 表示模拟线包中的摘机事件)。 事件有参数,参数在包中定义和命名。动作参数指示在事件发生时采取的一 个或多个可能的动作。 EventBuffer 描述符(EB) 当 Events 缓冲区被激活后,用来描述 MG 中检测到的事件。 Signals 描述符(SG) Signals 描述符包含向媒体网关请求应用于终端的信号集合。Signals 描述符 包含多个信号、信号序列或空信号。信号由包名与 SignalID 组成,格式描述 为包名/信号名。
2-13

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
例如,SG{SL=0{cg/dt}} “SL”为信号序列“SignalList”的简写,“cg/dt”表示呼叫音包中的拨号音 信号。 有三类信号: 开/关:信号持续直到设置为关; 超时:信号持续直到设置为关或超时; 短暂:信号持续时间很短,它会自动终止,除非新的信号产生使它终止。不 需超时设置。 Audit 描述符(AT) Audit 命令(AuditValue 和 AuditCapabilities 命令)可以指定什么信息可以审 计。下列是可能的项目: Modem、Mux、Events、Media、Signals、ObservedEvents、DigitMap、 Statistics、Packages、EventBuffer。 ServiceChange 描述符(SC) ServiceChange 描述符描述 ServiceChange 发生的原因,包含下列参数: ServiceChangeMethod ( MT ) 参 数 指 示 将 要 发 生 或 已 经 发 生 的 ServiceChange 的类型,该参数规定 MG 发生业务改变的 6 种方式: Graceful :指示终端将在延迟 ServiceChangeDelay 之后离开服务;已经建 立的连接暂不影响,但 MGC 将避免新建连接并试图文明关闭已存在连接。 Forced :指示终端突然中断服务,已建立的连接丢失。 Restart:指示指定终端在延迟 ServiceChangeDelay 之后重起。 Disconnected:拆线方式适用于根终端。用来指示 MG 曾中断与 MGC 的通 信连接但是随后连接又重新恢复。因为 MG 的状态发生改变,所以 MGC 可 以审计命令来使 MG 与 MGC 重新同步。 Handoff:当该参数由 MGC 发送给 MG ,用于指示 MGC 将退出服务,MG 必 须与一个新的 MGC 建立新的连接;当该参数从 MG 发送给 MGC 时,指示 MG 试图与新的 MGC 建立新的连接 。 Failover:该参数从 MG 发送给 MGC, 指示主控 MG 将退出服务,备用的 MG 将开启服务。
2-14

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
ServiceChangeReason(RE)指定已发生或将要发生的 ServiceChange 命 令的原因。它由数字字母令牌(IANA 注册)和解释性文字组成。 其参数值如 表 2-5所示:
表2-5 业务改变原因值 业务改变原因值 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 业务恢复 冷启动 热启动 直接的 MGC 改变 终端故障 终端退出服务 更低层连接丢失 传输故障 MG 临近故障 MGC 临近故障 媒体能力故障 Modem 能力故障 Mux 能力故障 信号能力故障 事件能力故障 状态丢失 包类型改变 能力改变 含义
ServiceChangeAddress 参数为任选项,规定了用于后续通信的地址(例如 IP 网的端口号)。 ServiceChangeDelay 参数为可选项,单位为秒。 ServiceChangeProfile 参数任选项, 规定协议的框架。 ServiceChangeProfile 包括支持的框架版本。 ServiceChangeVersion 参数为任选项,包含所支持的协议版本,进行协议 协商版本时使用。
2-15

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
ServiceChangeMGCId 参数可以由 MGC 返回 MG,用于指示 MG 应该优先 选择的 MGC。此时,MG 可以向新的 MGC 重新发送 ServiceChange 请求命 令。ServiceChangeMgcId 参数中规定的 MGC 的优先级比其他 MGC 高。当 MGC 向 MG 发送的 ServiceChange 命令中 ServiceChangeMethod 参数为 HandOff 时 ,ServiceChangeMgcId 参数中指示的 MGC 将代替原有 MGC 而 进入服务。 TimeStamp 参数为任选项,表示发送方当前的实际时间。接收方可用此参数 来确定在时间的含义方面与接收方的不同。 Extension 参数为 MG 和 MGC 之间的内部参数。 DigitMap 描述符(DM) DigitMap 是驻留在媒体网关的拨号方案,用于检测和报告终端接收的数字事 件。DigitMap 描述符包含 DigitMap 名字和指定的 DigitMap 方案。 按照 DigitMap 方案,H.248 协议规定数字的收集可有三个时钟保证:起始定 时器(T)、短定时器(S)和长定时器(L)。DigitMap 中的定时器为可配 置参数,DigitMap 使用初期默认定时器为起始定时器 T ,但起始定时器 T 可 以被短定时器 S 和长定时器 L 取代。 起始定时器 T 用于任何号码开始拨之前。 如果媒体网关检测到至少还需要一个数字来匹配 Digit Map 的模式,则数字间 的定时器值应设置为长定时器 L(例如 16 秒)。 若号码串能够匹配 DigitMap 中的某一拨号方案,但同时有可能收到多位号码 而导致匹配其它不同的拨号方案,则不应立即报告匹配情况。MG 必须使用短 定时器 S(例如 8 秒)等待接收更多位数的号码。 关于 Digit Map 的其它解释请参考本手册 MGCP 协议。 Statistics 描述符(SA) 统计描述符用于描述一个特定关联中的终端状态和使用信息。终端的特定统 计属性由终端实现的包决定。一般在缺省情况下,在关联中删除终端时,会 报 告 其 统 计 信 息 。 统 计 参 数 还 可 以 通 过 Audit 命 令 中 返 回 , 或 者 通 过 Add/Move/Modify 命令中的 Audit 描述符中返回。 Packages 描述符(PG) 仅用在 AuditValue 命令中,返回端点能识别的一系列包。 ObservedEvents 描述符(OE) ObservedEvents 在 Notify 命令中通知 MGC 检测到那些事件。当 Auditvalue 命令中使用了 ObservedEvents 描述符,则该命令的返回响应中将返回在
2-16

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
Notify 命令中未报告的 EventBuffer 中的事件。ObservedEvents 描述符包含 触发 Notify 命令的 Events 描述符的 RequestID 和被检测的事件和检测时间。 报告的检测时间可以精确到 10 毫秒。 Topology 描述符(TP) Topology 描述符用于描述关联中终端之间的流方向。Topology 描述符适用于 关联而不是终端。关联的缺省拓扑是所有终端可以接收到其它任何终端的媒 体流。在命令中 Topology 描述符为任选项。 Topology 描述符的格式为(T1,T2,Association)。T1 和 T2 规定关联中 的关联,可以使用通配值“ALL”或“CHOOSE”。Association 参数规定两 个关联间的媒体流流向: (T1 T2 Isolate) 表示终端 T2 不能从终端 T1 接收到媒体流。 (T1 T2 Oneway) 表示终端 T2 可以从终端 T1 单向接收媒体流而不能反向接 收。 (T1 T2 Bothway)表示终端 T2 可以从终端 T1 双向接收媒体流。 图 2-6是拓扑的示例:
Context 1 T2 Context 1 T2 Context 1 T2
T1
T3
T1 2. T1, T2 Isolate Context 1
T3
T1 3. T3, T2 One way Context 1
T3
1. No topology descriptors Context 1 T2
T2
T2
T1 4. T2, T3 One way
T3
T1 5. T2,T3 Bothway
T3
T1 6. T1,T2 Bothway
T3
Note: the direction of the arrow indicates the direction of flow
图2-6 拓扑举例
表 2-6对图 2-6的拓扑图进行了说明:
2-17

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册 表2-6 拓扑说明 拓扑 1 无 Topology 描述符 说明
第 2 章 H.248 协议
当未包含 Topology 描述符时所有终端间都具有双向连接 T1,T2,Isolate 去掉 T1 与 T2 的连接
2
T3 与 T1 和 T2 具有双向连接 T1 与 T3 具有双向连接 T3, T2, Oneway
3
从 T3 到 T2 单向连接 (即 T2 从 T3 接收媒体流) 。T1 与 T3 之间双向连 接 T2, T3, Oneway T2 与 T3 之间单向连接。T1 与 T3 保持双向连接 T2, T3 Bothway T2 双向连接到 T3,结果见 2 T1, T2, Bothway
4
5
6
(T2, T3 双向和 T1,T3 双向可以是暗示或明确方式).。终端与所有其它终 端具有双向连接
Error 描述符(ER) 当处理 Transaction 出错时, 则命令响应 Reply 中应包含 Error 描述符。 Notify 命令也可以包含 Error 描述符。Error 描述符由注册的 IANA 错误代码和错误 文本描述组成,可以选择发送说明文字。
表2-7 错误码列表 错误码 400 401 402 403 406 410 411 412 421 错误请求 协议错误 未授权 事物交互语法错误 协议版本不支持 标识符错误 事物交互指向未知的关联 关联不可用 Action 未知或 Action 组不合法 含义
2-18

U-SYS SoftX3000 软交换系统 技术手册 信令与协议分册
第 2 章 H.248 协议
错误码 422 430 431 432 433 434 440 441 442 443 444 445 446 447 448 450 451 452 453 454 455 456 457 471 500 501 502 503 504 505 510 512 动作语法错误 终端未知 不存在匹配的终端 终端不可用或没有足够的终端 终端已存在于一个关联中 关联中的终端数目超过了最大值 协议不支持的包或未知的包 Remote 描述符丢失 命令语法错误 命令类型不支持或命令类型未知
含义
描述符类型不支持或描述符类型未知 特性类型不支持或特性类型未知 参数类型不支持或参数类型未知 命令中描述符非法类型 同一描述符在命令中重复两次 包中不存在的特性 包中不存在的事件 包中不存在的信号 包中不存在的统计数据 包中不存在的参数 描述符中的参数非法 同一描述符中参数或特征重复两次 信号或事件参数丢失 添加复用描述符终端失败 内部网关错误 未执行 未准备就绪 业务不可用 命令发起方未授权 接收 Restart 响应前接收到命令 没足够资源可用 MG 不能进行对要求检测的事件的检测
2-19

Ns2.34上leach协议的完美移植

Ns2.34上leach协议的完美移植 经过几天的不断实验,以及网上各位前辈的帮助,终于成功将leach协议完美移植到ns2.34上,下面是我的安装笔记。 Step1 在ns-2.34的目录下新建一个leach文件夹,将leach.tar.gz放入这个文件夹 Step2 在终端中进入这个目录下,键入tar zxf leach.tar.gz Step3 ①将leach/mit整个目录复制到ns-allinone-2.34/ns-2.34中 ②将leach/mac目录下的https://www.doczj.com/doc/9f8591807.html,, mac-sensor.h, https://www.doczj.com/doc/9f8591807.html,, mac-sensor-timers.h四个文件复制到ns-allinone-2.34/ns-2.34/mac中 ③将leach/tcl/mobility目录下的四个文件复制到ns-allinone-2.34/ns-2.34/tcl/mobility中 ④将ns-allinone-2.34/ns-2.34/tcl/ex目录下的wireless.tcl重命名为wireless_1.tcl,再将leach/tcl/ex目录下的wireless.tcl复制到ns-allinone-2.34/ns-2.34/tcl/ex中⑤将leach目录下的test,leach_test,package_up三个文件复制到ns-allinone-2.34/ ns-2.34中 Step3 修改文件 ①需要修改的文件有: ns-allinone-2.34/ns-2.34/apps/https://www.doczj.com/doc/9f8591807.html,,app.h ns-allinone-2.34/ns-2.34/trace/https://www.doczj.com/doc/9f8591807.html,,cmu-trace.h ns-allinone-2.34/ns-2.34/common/https://www.doczj.com/doc/9f8591807.html,,https://www.doczj.com/doc/9f8591807.html,,packet.h ns-allinone-2.34/ns-2.34/mac/https://www.doczj.com/doc/9f8591807.html,,ll.h,https://www.doczj.com/doc/9f8591807.html,,https://www.doczj.com/doc/9f8591807.html,,phy.h,wireless-phy.c c,wireless-phy.h ②修改方法: 对于leach目录下相应的文件(即刚才未复制的文件),将代码中以“#ifdef MIT_uAMPS”开始,并以“#endif”结束的部分复制到以上文件对应的位置 这个过此要小心核对修改,否则前功尽弃 ③特殊情况 <1> ns-allinone-2.34/ns-2.34/common/packet.h中大约185行,根据其他变量的格式将代码更改为 #ifdef MIT_uAMPS static const packet_t PT_RCA = 61; #endif 并将最后一个枚举值改为62 这个过程可以随情况改变,还要注意的是packet.h文件并不是只改这一部分,前面的修改依然要。 <2> ns-allinone-2.34/ns-2.34/mac/wireless-phy.h,给类WirelessPhy添加public变量,大约105行 #ifdef MIT_uAMPS MobileNode * node_;

LEACH协议的算法结构及最新研究进展

LEACH协议的算法结构及最新研究进展 1 LEACH协议算法结构 LEACH这个协议的解释是:低功耗自适应集簇分层型协议。通过名字,我们就能想到这个协议的大概作用了。那么在这之中,我们先来研究一下它的算法。 该算法基本思想是:以循环的方式随机选择蔟首节点,将整个网络的能量负载平均分配到每个传感器节点中,从而达到降低网络能源消耗、提高网络整体生存时间的目的。仿真表明,与一般的平面多跳路由协议和静态分层算法相比,LEACH协议可以将网络生命周期延长15%。LEACH在运行过程中不断的循环执行蔟的重构过程,每个蔟重构过程可以用回合的概念来描述。每个回合可以分成两个阶段:蔟的建立阶段和传输数据的稳定阶段。为了节省资源开销,稳定阶段的持续时间要大于建立阶段的持续时间。蔟的建立过程可分成4个阶段:蔟首节点的选择、蔟首节点的广播、蔟首节点的建立和调度机制的生成。 蔟首节点的选择依据网络中所需要的蔟首节点总数和迄今为止每个节点已成为蔟首节点的次数来决定。具体的选择办法是:每个传感器节点随机选择0-1之间的一个值。如果选定的值小于某一个阀值,那么这个节点成为蔟首节点。 选定蔟首节点后,通过广播告知整个网络。网络中的其他节点根据接收信息的信号强度决定从属的蔟,并通知相应的蔟首节点,完成蔟的建立。最后,蔟首节点采用TDMA方式为蔟中每个节点分配向其传递数据的时间点。 稳定阶段中,传感器节点将采集的数据传送到蔟首节点。蔟首节点对蔟中所有节点所采集的数据进行信息融合后再传送给汇聚节点,这是一种叫少通信业务量的合理工作模型。稳定阶段持续一段时间后,网络重新进入蔟的建立阶段,进行下一回合的蔟重构,不断循环,每个蔟采用不同的CDMA代码进行通信来减少其他蔟内节点的干扰。 LEACH协议主要分为两个阶段:即簇建立阶段(setup phase)和稳定运行阶段(ready phase)。簇建立阶段和稳定运行阶段所持续的时间总和为一轮(round)。为减少协议开销,稳定运行阶段的持续时间要长于簇建立阶段。 在簇建立阶段,传感器节点随机生成一个0,1之间的随机数,并且与阈值T(n)做比较,如果小于该阈值,则该节点就会当选为簇头。在稳定阶段,传感器节点将采集的数据传送到簇首节点。簇首节点对采集的数据进行数据融合后再将信息传送给汇聚中心,汇聚中心将数据传送给监控中心来进行数据的处理。稳定阶段持续一段时间后,网络重新进行簇的建立阶段,进行下一轮的簇重建,不断循环。 2 LEACH协议的特点 1 为了减少传送到汇聚节点的信息数量,蔟首节点负责融合来自蔟内不同源节点所产生的数据,并将融合后的数据发送到汇聚点。 2 LEACH采用基于TDMA/CDMA的MAC层机制来减少蔟内和蔟间的冲突。 3 由于数据采集是集中的和周期性的,因此该协议非常适合于要求连续监控的应用系统。 4 对于终端使用者来说,由于它并不需要立即得到所有的数据,因此协议不需要周期性的传输数据,这样可以达到限制传感器节点能量消耗的目的。 5 在给定的时间间隔后,协议重新选举蔟首节点,以保证无线传感器网络获取同意的能量分布。

WSN中LEACH协议源码分析报告

WSN中LEACH协议源码分析 分析(一) 首先对wireless.tcl进行分析,先对默认的脚本选项进行初始化: set opt(chan)Channel/\VirelessChannel set opt(prop) Propagatioii/TwoRayGround set opt(netif)PhyAVirelessPhy set opt(mac) Mac/802_l 1 set opt(ifq) Qucuc/DropTail/PriQueue set opt(ll) LL set opt(ant) Antenna/OmniAntenna set opt(x) 0 。# X dimension of the topography set opt(y) 0。# Y dimension of the topography set opt(cp),H, set opt(sc) N../mobility/scene/scen-670x670-50-600-20-2u。# scenario file set opt(ifqlen)50o # max packet in if set opt(nn) 51。# number of nodes set opt(secd) 0.0 set opt(stop) 10.0 o # simulation time set opt(tr) out.tr。# trace file set opt(rp) dsdv 。 # routing protocol script set opt(lm) M on H。# log movement 在这个wireless.tcl中设置了一些全局变呈:: # #Initialize Global Variables # set ns_ [new Simulator] set chan [new $opt(chan)] set prop [new $opt(prop)] set topo [newTopography] set tracefd [open Sopt(tr) w] Stopo Ioad_flatgrid $opt(x) $opt(y) Sprop topography Stopo 这些初始化将在后而的使用中用到,该文件最重要的是创建leach 17点:创建方法如下: } elseif { [string compare Sopt(rp) M leach,,]==0} { for {set i 0} {$i < $opt(nn) } {incr i} { leach-create-mobile-node $i } 如果路由协议是leach协议,则在Uamps.tcl中调用leach-create-mobile-node方法创建leach节点。将在第二小节讲如何创建leach节点。 for {set i 0} {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop).000000001 M Snode_($i) reset”。〃完成后,重宜右点的应用

无线传感器网络LEACH协议研究

无线传感器网络LEACH协议的研究 摘要:无线传感器网络因其在军事、经济、民生等方面广阔的应用前景成为21世纪的前沿热点研究领域[1]。在传感器节点能量有限的情况下,提高路由效率,延长网络寿命成为无线传感器网络需考虑的问题。由于采取分簇,数据融合的思想,LEACH协议有着较高的路由效率,但在实际应用,尤其是大规模网络中,仍存在负载不均衡等问题。本文主要分析了LEACH协议的基本思想及优缺点,随后针对大规模的网络环境对其分簇算法进行改进。前人提出一种有效的方法计算最优簇首个数,本文推算出适合本文中网络环境的公式并加以应用。本文用NS2进行仿真,仿真后的结果表明,改进后的分簇算法更为有效,延长了网络寿命,增大了网络传送数据量。 关键词:无线传感器网络;路由协议;LEACH;分簇思想 Research on Routing Protocol of LEACH in WSN Shen Y uanyi Dept. of Information and Telecommunication,NUPT ABSTRACT:Nowadays, wireless sensor network has become a hot spot of 21st century because of its wide application on military, economy and human life. On the condition that the energy of a sensor node is limited, how to improve the routing efficiency and expand the network’s lifespan has been an important issue to consider. LEACH maintains quite high routing efficiency for its idea of clustering and data gathering. But in practical, it still has problems such as load unbalance especially in large scale network. The article mainly analyses the basic idea of LEACH, the benefits and drawbacks of it and later introduce an improvement on clustering algorithm according to large scale network. Key words:WSN;routing protocol; LEACH; clustering 1LEACH协议介绍与分析 1.1 LEACH算法思想 算法基本思想[2]是:以循环的方式随机选择簇头节点,将整个网络的能量负载平均分配到每个传感器节点中,从而达到降低网络能源消耗、提高网络整体生存时间的目的。LEACH在运行过程中不断的循环执行簇的重构过程,每个簇重构过程可以用回合的概念来描述[3]。每个回合可以分成两个阶段:簇的建立阶段和传输数据的稳定阶段。 1.2 LEACH算法的分析 LEACH协议的优点[4]有: (1)LEACH 通过减少参与路由计算的节点数目,减少了路由表尺寸。(2)LEACH协议是一种分簇路由协议,降低了非簇首节点的任务复杂度,不必对通信路由进行维护。(3)协议不需要周期性的传输数据。(4)在给定的时间间隔后,协议重新选举簇首节点,以保证无线传感器网络获取同意的能量分布。 由于LEACH算法是建立在一些假设上,所以在实际应用中LEACH协议存在一些问题:(1)在LEACH协议中,簇头的选举是随机产生的,这样的随机性可能会导致簇头

LEACH协议簇头

《单片机原理与接口技术》期中论文 论文题目 LEACH协议簇头 选择算法的改进 姓名 学号 学院电气工程学院 专业班级 2008级通信工程

目录 引言................................. 错误!未定义书签。 1 LEACH协议 .......................... 错误!未定义书签。 LEACH 协议介绍.................... 错误!未定义书签。 LEACH 协议的能量损耗模型.......... 错误!未定义书签。 LEACH 的不足在于:................ 错误!未定义书签。 LEACH 协议的优化.................. 错误!未定义书签。 基本思想....................... 错误!未定义书签。 改进细节........................ 错误!未定义书签。 2 簇头选择算法的改进LEACH-H ........... 错误!未定义书签。 簇头初选........................... 错误!未定义书签。 簇头调整过程....................... 错误!未定义书签。 3仿真结果 ............................ 错误!未定义书签。 4仿真分析 ............................ 错误!未定义书签。 5结束语 .............................. 错误!未定义书签。参考文献 ............................. 错误!未定义书签。

Ubuntu安装ns-2.35及leach协议安装

Ubuntu 13.10下安装ns-2.35及leach协议安装 powered by Hong Sheng , Jiangsu university ,Zhenjiang 583301743@https://www.doczj.com/doc/9f8591807.html, Tue Nov 25 , 2013 之所以选择基于linux的操作系统ubuntu来安装ns2,是因为我个人特别讨厌Microsoft 开发的基于windows的cygwin软件,此软件安装的时候不仅有各种错误,UI也不够友好。而,有关ubuntu的安装,大家可以自行baidu或google之。下面只讲解ns-2.35和leach协议的安装过程。 1. Ubuntu 13.10下ns- 2.35安装 step 1:下载ns2.35,https://www.doczj.com/doc/9f8591807.html,/s/1h8rj0#dir/path=%2FNS解压,放在home/xx下,xx是你的用户名 step 2:更新源包,终端输入:sudo apt-get update step 3:安装依赖包 sudo apt-get install tcl8.5-dev tk8.5-dev sudo apt-get install build-essential autoconf automake sudo apt-get install perl xgraph libxt-dev libx11-dev libxmu-dev step 4:修改ns-allinone-2.35中ls.h文件的代码 将void eraseAll() { erase(baseMap::begin(), baseMap::end()); } 改为: void eraseAll() { this->erase(baseMap::begin(), baseMap::end()); } step 5:sudo ls /usr/bin/gcc* //查看系统已经安装的gcc版本。Ubuntu 13.10默认安装了gcc-4.8 //和gcc-4.8版本的,如果是其他版本的linux操作系统且没有安装 //高于4.0版本的gcc/g++。则需要手动安装gcc/g++-4.8 sudo apt-get install gcc-4.8 g++-4.8 // 对于Ubuntu 13.10,此项是非必须的 sudo export CC=gcc-4.8 sudo export CXX=g++-4.8 //CC和CXX是全局变量,用来指定make将会用哪个版本的gcc/g++编译器生成 //makefile文件。如果没有这一步,保证你会makefile失败!!!因为,在ns-2.35文件夹//下的makefile.in 中要求配置全局变量。 echo $CC echo $CXX //查看全局变量导入成功了没有,如果成功,则执行 sudo ./install //开始进行安装,大概等5分钟左右。 ....... 出现以下的内容,每个人的/home/xx/不同,我的用户名是nan,所以,显示了以下信息。 Ns-allinone package has been installed successfully. Here are the installation places: tcl8.5.10: /home/nan/ns-allinone-2.35/{bin,include,lib} tk8.5.10: /home/nan/ns-allinone-2.35/{bin,include,lib} otcl: /home/nan/ns-allinone-2.35/otcl-1.14 tclcl: /home/nan/ns-allinone-2.35/tclcl-1.20 ns: /home/nan/ns-allinone-2.35/ns-2.35/ns nam:/home/nan/ns-allinone-2.35/nam-1.15/nam xgraph: /home/nan/ns-allinone-2.35/xgraph-12.2 gt-itm: /home/nan/ns-allinone-2.35/itm, edriver, sgb2alt, sgb2ns, sgb2comns, sgb2hierns

LEACH协议的MATLAIB仿真代码

Matlab Code for LEACH NodeNums = 100; % the num of node AreaR = 100 ; % the area of simulate NodeTranR=10; % the transit Radius Elec=50 * 10^(-9); % Eamp=100*10^(-12); Bx=50; % The Postion of Baseation By=175; MaxInteral =700; % the leach simulate time Pch=0.05; % the desired percentage of cluster heads InitEn=0.5; % the init energy of all node Tr=30; TDMA=100; Kbit=2000; % the bits of a node transmiting a packet every time BandWitch = 1*10.^(6); % Channel Bandwitch TOS_LOCAL_ADDRESS = 0; for i=1:(MaxInteral) AliveNode(i)=NodeNums; AmountData(i)=0; end sym alldata; alldata=0; LAECH = zeros(1,MaxInteral); LAENO = zeros(1,MaxInteral); for i=1:1:NodeNums EnNode(i)=InitEn; % the init energy of all node StateNode(i)=1; % the State of all node 1: alive 0:dead ClusterHeads(i)=0; % the Set of Cluster Head ,1: cluster head 0 :node Rounds=0; % the round end Threshold=0; % the threshold of node becoming a cluster-head Node.x=AreaR*rand(1,NodeNums); % the position of node Node.y=AreaR*rand(1,NodeNums); Node.c=zeros(1,NodeNums); Node.d=zeros(1,NodeNums); Node.l=zeros(1,NodeNums); Node.csize=zeros(1,NodeNums); Node.initclEn=zeros(1,NodeNums); % for i=1:NodeNums % Node.c(i)=0; % the Cluster head of node

SEP协议

1 SEP:A Stable Election Protocol for clustered heterogeneous wireless sensor networks G EORGIOS S MARAGDAKIS I BRAHIM M ATTA A ZER B ESTAVROS Computer Science Department Boston University gsmaragd,matta,best@https://www.doczj.com/doc/9f8591807.html, Abstract—We study the impact of heterogeneity of nodes, in terms of their energy,in wireless sensor networks that are hierarchically clustered.In these networks some of the nodes become cluster heads,aggregate the data of their cluster members and transmit it to the sink.We assume that a percentage of the population of sensor nodes is equipped with additional energy resources—this is a source of heterogeneity which may result from the initial setting or as the operation of the network evolves. We also assume that the sensors are randomly(uniformly) distributed and are not mobile,the coordinates of the sink and the dimensions of the sensor?eld are known.We show that the behavior of such sensor networks becomes very unstable once the?rst node dies,especially in the presence of node heterogeneity.Classical clustering protocols assume that all the nodes are equipped with the same amount of energy and as a result,they can not take full advantage of the presence of node heterogeneity.We propose SEP,a heterogeneous-aware protocol to prolong the time interval before the death of the?rst node(we refer to as stability period),which is crucial for many applications where the feedback from the sensor network must be reliable. SEP is based on weighted election probabilities of each node to become cluster head according to the remaining energy in each node.We show by simulation that SEP always prolongs the stability period compared to(and that the average throughput is greater than)the one obtained using current clustering protocols. We conclude by studying the sensitivity of our SEP protocol to heterogeneity parameters capturing energy imbalance in the network.We found that SEP yields longer stability region for higher values of extra energy brought by more powerful nodes. I.I NTRODUCTION Motivation:Wireless Sensor Networks are networks of tiny, battery powered sensor nodes with limited on-board process-ing,storage and radio capabilities[1].Nodes sense and send their reports toward a processing center which is called“sink.”The design of protocols and applications for such networks has to be energy aware in order to prolong the lifetime of the network,because the replacement of the embedded batteries is a very dif?cult process once these nodes have been deployed.Classical approaches like Direct Transmission and Minimum Transmission Energy[2]do not guarantee well balanced distribution of the energy load among nodes of the sensor https://www.doczj.com/doc/9f8591807.html,ing Direct Transmission(DT),sensor nodes transmit directly to the sink,as a result nodes that are far away from the sink would die?rst[3].On the other hand, using Minimum Transmission Energy(MTE),data is routed This work was supported in part by NSF grants ITR ANI-0205294,EIA-0202067,ANI-0095988,and ANI-9986397.over minimum-cost routes,where cost re?ects the transmission power expended.Under MTE,nodes that are near the sink act as relays with higher probability than nodes that are far from the sink.Thus nodes near the sink tend to die fast.Under both DT and MTE,a part of the?eld will not be monitored for a signi?cant part of the lifetime of the network,and as a result the sensing process of the?eld will be biased.A solution proposed in[4],called LEACH,guarantees that the energy load is well distributed by dynamically created clusters,using cluster heads dynamically elected according to a priori optimal probability.Cluster heads aggregate reports from their cluster members before forwarding them to the sink.By rotating the cluster-head role uniformly among all nodes,each node tends to expend the same energy over time. Most of the analytical results for LEACH-type schemes are obtained assuming that the nodes of the sensor network are equipped with the same amount of energy—this is the case of homogeneous sensor networks.In this paper we study the impact of heterogeneity in terms of node energy.We assume that a percentage of the node population is equipped with more energy than the rest of the nodes in the same network—this is the case of heterogeneous sensor networks.We are motivated by the fact that there are a lot of applications that would highly bene?t from understanding the impact of such heterogeneity.One of these applications could be the re-energization of sensor networks.As the lifetime of sensor networks is limited there is a need to re-energize the sensor network by adding more nodes.These nodes will be equipped with more energy than the nodes that are already in use,which creates heterogeneity in terms of node energy.Note that due to practical/cost constraints it is not always possible to satisfy the constraints for optimal distribution between different types of nodes as proposed in[5]. There are also applications where the spatial density of sen-sors is a constraint.Assuming that with the current technology the cost of a sensor is tens of times greater than the cost of embedded batteries,it will be valuable to examine whether the lifetime of the network could be increased by simply distribut-ing extra energy to some existing nodes without introducing new nodes.1 1We also study the case of uniformly distributing such extra energy over all nodes.In practice,however,it maybe dif?cult to achieve such uniform distribution because extra energy could be expressed only in terms of discrete battery units.Even if this is possible,we show in this paper that such fair distribution of extra energy is not always bene?cial.

Leach协议

目录 一、Leach协议与NS的关系 (2) 二、算法设计思想 (3) 三、簇头建立算法流程图 (4) 四、难点解决 (6) 五、算法运行结果分析 (9) 参考文献 (9)

一、Leach协议与NS的关系 为了实现leach 协议,对ns进行扩展。在ns中增加了一个事件驱动模拟器支持模拟无线传感器网络协议。这些扩展包括MAC协议,用于计算和交互的能量分配模型和leach协议的体系结构。 网络拓扑结构可以通过简单的Nodes, Links, Agents和Applications 描述。Nodes相当于网络中的终端主机, Links 是用于Nodes交互的连接器, Agent用来实现不同网络协议,是支持分组产生和丢弃的节点。Applications 用来产生数据和实现不同的应用函数。一旦网络拓扑结构建立起来后,模拟通过启动节点上的Applications运行。 为了在ns中支持无线传感器网络,在ns中增加了 mobile nodes, MAC 协议和信道传播模型Channel 。 Applications类的头文件用Tcl语言写的,节点中的其他函数功能用C++语言写成的。 数据包的发送过程: Applications创建数据包(data packets),然后发送给Agent. Agent执行协议栈中运输层和网络层的功能,将数据包发送给CMUTrace,。 CMUTrace将packets的统计数据写到trace 文件,然后将packets发至Connector。Connector将数据包传送给用于数据链路处理的链路层(LL).经过一小段时间的延迟后,数据包由LL发送给Queue缓冲队列。如果是还没有传送过的数据包,Queue将以队列进行存储。然后Queue将数据包出队列,发送到MAC层。然后开始运行MAC(媒体访问控制)协议。最终,packets被发送到网络接口层(Network Interface),网络接口层将packets加上正确的传输能量,然后将packets发送到Channel. Channel将packets进行拷贝,并发往连接信道的每一个节点。 发送过程可参考如下图1 数据包的接收过程: 数据包被节点的网络接口接收,并被向上传送至MAC层,Link-Layer, Connector, CMUTrace, 和Agent 函数. Agent 对数据包进行判定,并将数据包到达的信息通知给Application. 接收过程与发送过程传输的路径相反。

相关主题
文本预览
相关文档 最新文档