移动管理分布式部署

移动管理分布式部署（精选5篇）

移动管理分布式部署 篇1

随着日益增多的个人设备逐渐融入企业办公环境, 员工在享受移动办公所带来的高效率的同时, 企业也面临着众多移动设备与企业网络对接时的安全挑战。另一方面, 尽管“统一通信”概念已被大多数企业接受并认可, 但其移动性拓展却是因为近两年智能终端的飞速发展才开始提及。作为统一通信大系统中的一个增值应用, 移动统一通信部署在逐渐成为热点的同时, 作为一个新兴产物, 也为企业及员工带来了不同的难题。

更灵活的移动办公

目前, 在企业的业务开展和IT投资重点中, 许多都与移动通信及协作功能提升效率有关。对于移动统一通信的兴起, 西门子中国区统一通信产品经理陆秀锦表示, 这一方面来自技术力量的驱动—智能通信、无线通信技术的快速发展为之奠定了技术基础;另一方面, 企业及员工对移动性需求的不断增长是促进其发展的内在动力。

对于企业而言, 移动统一通信部署类似于云部署, 可以使企业在全国、全球范围内更快地部署, 并且其灵活性较高, 可以很好地配合企业业务发展需要, 业务覆盖也可以得到更快扩张。同时对于企业员工而言, 可以方便员工在任意地点接入统一通信系统, 并提高工作效率, 增强了移动性。例如, 国外部分企业通过统一通信系统的移动性拓展, 已可以使得员工在家便能接入统一通信系统, 打破了传统办公的地域限制。

并且诸如“软终端”的功能, 使得员工在离开办公室时, 可以通过企业内部Wi-Fi网络, 实现移动终端与桌面的联动及切换。而在移动终端上实现在线状态、日志、IM、会议管理等信息管理功能和文档共享等协同应用, 将进一步提升员工的办公效率。

“移动统一通信带来的是以人为本的解放, 而非时刻工作、可联系的束缚。”陆秀锦说道。

安全挑战值得注意

在移动统一通信的实际部署过程中, 陆秀锦提醒到, 安全性的考虑将是企业面临的重要挑战, 这主要来自于两方面:一是网络本身的安全性;一是信息数据交互的安全性。

为实现统一通信系统的移动性拓展, 企业自身的网络是否已经准备充分, 部署后系统安全是否能得到保障, 无线网络的安全管理是否已得到完善, 这些问题都是企业需要积极思考的。同时移动性拓展, 带来了内外网穿越的问题, 但大多数企业出于对信息安全、保密的考虑, 并不喜欢与外网进行重要文档的共享。如何保障数据在服务器、移动终端上不残留, 保障数据传输过程中, 信息交互安全, 不仅是企业的重要考虑, 也为服务提供商提出了挑战。

“尽管移动统一通信仍处于市场培育期, 但经过2～3年用户的逐渐适应, 将为市场发展指出新的方向。同时移动统一通信对于企业而言, 只是一个增值应用, 但却可以大大提升办公效率。”陆秀锦表示。

分布式移动性管理协议研究 篇2

我们已经进入到后PC时代, 互联网移动流量激增, 移动通信网络发挥着越来越重要的作用。目前移动终端设备产生的流量远远大于PC终端设备产生的流量, 更多的实时娱乐流量都被发送到了平板电脑或者智能手机而不是台式机[1]。

在制定IP移动性支持协议时, 移动互联网架构是集中分层的形式, 故最初设计时采用集中的移动性管理锚点[2]。IETF提出的移动性管理协议均基于集中式的层次网络架构, 引入集中的移动性管理锚点确保来自/去往移动设备的数据的可达性, 使移动设备未连接到其家乡域时仍然可达, 是集中式移动性管理 (CMM, Centralized Mobility Management) 方法。例如, 基于终端侧的移动性支持协议MIPv6[3]采用HA作为移动性管理锚点, 基于网络侧的移动性支持协议PMIPv6[4]采用LMA作为移动性管理锚点。这些集中的移动性管理锚点在控制平面负责维护管理域内MNs的移动性上下文, 同时也在数据平面负责处理来自或发往域内MNs的数据包的路由。

CMM最初是为语音通话设计的, 随着移动设备数量的增加和移动互联网流量的激增, 采用集中的移动性管理方式成为限制网络规模增长的瓶颈[5]。传统集中式的网络架构存在扩展性问题 (网络带宽瓶颈) 、安全问题 (单点失败) 及性能问题 (次优路由) , 不能够适应移动流量激增的形式。当流量需求超过可用容量时, 服务提供商需要实现新的策略, 如通过其他接入网进行选择性流量卸载。另外, 内容提供商选择将内容服务器部署在位置更加接近移动/固定服务提供商网络的本地网络中从而提高内容获取速度并减少内容交付对核心网带宽的消耗[6]。移动互联网流量激增加速了移动网络架构后向兼容的扁平化演进, 卸载和内容分发网络 (CDN, Content Delivery Network) 技术都能够从路由层次更少的移动架构中获益。

为了应对移动互联网流量激增, 移动网络架构向扁平化演进, 移动性管理协议需要适应这样的网络架构。IETF于2012年3月成立了分布式移动性管理 (DMM, Distributed Mobility Management) 工作组研究可适应移动网络架构扁平化发展趋势的分布式移动性管理方法。

1 移动性管理概述

1.1 移动性管理的概念

网络层移动性管理方案通过将会话标识和路由地址解耦的方式保证移动节点移动过程中的通信连续性。数据包根据路由位置路由并根据会话标识交付, 会话标识与路由位置的转换点为映射系统。移动性管理解决方案在本质上涉及如下3项内容[7]:

会话标识 (session identifier) :移动接收端固定不变的会话标识符, 可为IP地址的形式

路由位置 (route locator) :代表移动节点当前网络拓扑接入点的IP地址

映射系统 (mapping system) :维护会话标识和路由位置之间的映射信息

依据移动性管理是否需要修改移动终端的网络协议栈, 可将移动性管理分为基于终端侧的 (host-based) 移动性管理方案和基于网络侧的 (network-based) 移动性管理方案。在基于终端侧的移动性管理方案中, 移动终端需要参与移动性管理相关信令。当移动终端改变其网络接入点时, 数据包首先被路由到MN的家乡代理 (HA) , 然后通过查询MN的家乡地址到其当前网络接入位置的映射对发往MN的数据包进行封装和转发。基于网络侧的移动性管理方案引入网络侧功能实体代替MN进行移动性管理相关的信令交互, 无需MN的参与即可将数据包透明地由MN原网络接入点转发至其当前网络接入点。

从移动性支持范围的角度来看, 在基于终端侧的移动性管理协议中, MN移动过程中会参与移动性相关信令以及数据包的封装与解封装操作, 因此是一种全局移动性支持协议。从协议部署的角度来看, 基于终端侧的移动性管理协议需要修改终端主机协议栈以支持移动性管理。现有的大量用户的设备都缺乏移动性支持能力, 这成为其广泛部署的最大障碍。基于网络侧的方案便于广泛部署, 更能够吸引运营商。

1.2 移动性管理的方法

1.2.1 移动性管理的逻辑功能

当前移动性管理功能可以划分为数据平面功能和控制平面功能如图1所示[8]。数据平面功能负责数据包的封装/解封装和地址转换操作。控制平面功能负责所有与移动性管理相关的信令的处理。控制平面功能可以进一步划分为切换管理功能和位置管理功能。将控制平面逻辑功能进一步划分可以提高网络架构部署的灵活性, 不同的控制平面功能可以在不同的网络实体上执行。切换管理功能用于保障移动终端移动并改变网络接入点时正在进行的会话的连续性。位置管理功能用于保障移动终端移动过程中的持续可达性。本节对移动性管理的逻辑功能进行了详细的划分和描述。

位置管理:管理和跟踪MN的网络位置信息, 当MN移动并改变网络接入点时, 保障其在线持续可达性。位置管理功能需要借助位置服务数据库来实现, 该数据库负责维护MN的会话标识到其当前路由位置的映射。应用会话可以以MN的会话标识为关键字, 通过查询位置服务数据库获取MN当前的路由位置。当MN位置发生改变时, 切换管理功能以MN的会话标识为关键字更新其位置服务数据库的路由位置信息。

数据管理:数据管理功能通过地址转换的方式进行数据包封装, 根据位置管理提供的信息更新路由表。数据管理功能截获到数据包, 必要时对数据包进行封装或解封装操作。数据管理功能可以根据地址转换规则以新的IP头对数据包进行封装转发。数据管理功能不提供任何信令, 仅能能够接收和处理来自切换管理功能的信令。

切换管理:切换管理功能负责保证MN改变网络接入点时移动会话的连续性, 在IP层提供切换检测和协商机制。当MN发生IP切换时, 切换管理功能需要与位置管理功能和数据管理功能进行信令交互。切换管理功能负责维护MN的与位置管理功能相关的移动性上下文信息和与数据管理功能相关的路由位置信息。

1.2.2 移动性管理的形式划分

在对移动性管理的功能进行上述逻辑分解后, 所有的移动性管理协议的网络架构中的实体都可以由不同的移动性管理逻辑功能的组合来表示。根据数据平面和控制平面在部署时的耦合程度, 可以将移动性管理划分为集中式移动性管理方法和分布式移动性管理方法。

集中式移动性管理方法采用一个集中的移动性锚点 (MA, Mobility Anchor) 负责数据、切换和位置管理。所有会话都通过集中的MA路由, 并且必要时由MA进行封装并转发至MN当前网络接入位置。集中的MA需要为每个MN维护隧道信息, 以便当MN切换后将数据包转发至MN当前接入的网络。即使通信节点双方的距离很近, 通信会话依然要经过集中的MA进行路由转发。因此, 集中的MA成为网络性能提升的瓶颈。

分布式移动性管理方法将集中式的移动性管理方法中MA的数据平面和控制平面分散开以缓解MA的负担, 通常将数据管理平面分布在接入网水平, 理想情况下与第一跳接入路由器并列。根据位置管理平面的分布方式, 可以进一步将分布式的移动性管理方法划分为部分分布式移动性管理方法和完全分布式移动性管理方法。

2 分布式移动性管理的产生及发展

2.1 需求分析

移动IP协议需要适应网络架构扁平化的发展趋势, 在扁平化的网络架构中采用CMM进行移动性管理存在如下几点问题[9]:

(1) 非最优路由

在CMM中, 所有的流量都通过一个集中锚点路由通常会导致更长的路由路径。若MN和CN相互邻近但是同时远离移动性管理锚点, 则由CN发往MN的数据包需要经由移动锚进行路由, 这并不是最短的路由路径。

(2) 不适应网络架构扁平化的发展趋势

移动性管理的发展是与蜂窝网层次架构相适应的。无线网络数据通信量的指数增长要求集中式网络花费巨资来提升集中的移动性管理锚点的处理能力。减少网络分层可以减少网络中不同物理网络元素的数量, 有助于简化系统维护和降低开销, 集中式的移动性管理方法不能够适应这样的趋势。

(3) 可扩展性差

在CMM中, 集中的移动性管理锚点需要管理和维护所有MNs的移动性上下文和路由。随着接入MN数量的增加, 需要维护的移动性上下文和需要处理路由转发所需要的资源呈指数增长趋势。采用的集中锚点需要提供更多的资源, 可扩展性差。此外, 若集中的锚点发生故障或被攻击, 将会影响域内所有移动节点的正常工作。

(4) 存在不必要的资源浪费

现有移动支持协议盲目地为所有MN提供移动性支持, 浪费网络资源并且随着无线使用增加带来可扩展性问题[14,15]。随着无线连接的普遍应用, 无线连接并不仅用于移动性, 有时仅仅是为了避免使用有线连接。研究表明, 一个用户超过三分之二的无线接入时间是固定的。许多数据业务如网页浏览并不需要固定的IP地址, 有些应用程序可以不需要网络的帮助通过用自身的能力进行自身的移动性管理。

2.2 研究现状

为应对移动互联网流量激增的压力及网络架构扁平化的发展趋势, IETF于2012年3月成立DMM工作组研究分布式移动性管理方法。根据方案设计思路的不同, 可以将DMM的研究可划分为“演进性”的方法和“革命性”的方法。“演进性”的方法基于现有的移动IP协议进行改进和完善, 可与现有网络兼容, 短期内可部署性强。“演进性”的设计方案主要围绕基于终端侧的移动性管理方法[10]和基于网络侧的移动性管理方法[11]两个大方向展开研究。“革命性”的设计方案如基于路由的方案[12]和基于SDN的方案[13], 采用重新设计的思想避免传统CMM方案的局限性。在IETF DMM工作组的主导下, 目前“革命性”的方案进入起步阶段, 而“演进性”的设计方案的研究已取得显著进展。

3 分布式移动性管理架构

3.1“演进性”方案

3.1.1 基于终端侧的DMM方案

MIPv6采用集中的移动性管理锚点HA为管理域内注册的MNs维护移动上下文和路由状态信息, HA成为网络性能的瓶颈[16]。基于终端侧的DMM方案从MIPv6演进而来, MN向网络侧的移动性管理实体提供自身的当前位置、IP会话信息和相关移动性管理锚点信息等移动性上下文信息, 需要修改MN协议栈。该方案将接入移动性锚点 (AMA, Access Mobility Anchor) 下放到接入网水平, 重用MIPv6协议概念如MN处的绑定更新列表 (binding update list) 、移动性管理锚点处的绑定缓存 (binding cache entity) 、相关移动锚点间的双向转发隧道等, 并对MIPv6协议的移动性管理信令进行了扩展。

基于终端侧的DMM方案的网络架构如图2所示。移动性管理锚点AMA部署在位于接入网水平的接入路由器上。MN根据其当前所接入的AMA提供的网络前缀配置地址, 并通过绑定更新 (BU, Binding Update) 消息向该AMA注册配置的地址, 最新配置的地址优先级最高。当MN改变接入位置连接到新的AMA时根据新的网络前缀配置新的地址, 仍然保留之前的地址并降低之前地址的优先级。MN通过BU消息向新的接入网注册时不仅注册最新配置的地址, 还携带它之前的有效地址 (使用中的IP地址) 。当前接入的AMA通过BU获取之前的地址后向相关AMA发送接入绑定更新 (ABU, Access BU) 消息更新MN移动上下文和路由状态并建立双向隧道。通过在相关的AMAs之间建立双向隧道保证与MN锚定在之前AMA上的地址相关的通信会话的连续性。

3.1.2 基于网络侧的DMM方案

PMIPv6采用集中的移动性管理锚点LMA为所有注册的MNs维护移动上下文和路由状态信息, LMA成为网络性能的瓶颈。基于网络侧的DMM方案从PMIPv6演进而来, 可以通过向位置管理实体查询获取MN移动性上下文信息, 无需MN参与与移动性管理相关的信令。完全分布式移动性管理架构即数据平面和管理平面均采用分布式部署形式的架构, 这种方式中切换后如何获取MN的移动性上下文信息仍面临挑战。为解决上述问题, IETF提出了一种基于网络侧的部分分布式移动性管理方法。部分分布式模式将数据平面 (data plane) 分布到接入网水平, 但仍然采用集中的控制平面进行位置管理 (location management) , 因此称之为基于网络侧的部分分布式移动性管理方法。

基于网络侧的部分分布式DMM方案的网络架构如图3所示, 由位集中的中心移动性数据库 (CMD, Central Mobility Database) 和一系列分布在接入网水平的移动接入锚点 (MAR, Mobile Access Anchor) 组成。CMD是负责移动性会话注册的控制平面功能实体, 采用绑定缓存实体 (BCE, Binding Cache Entity) 为所在BDMM域内的MNs维护移动性上下文信息。MAR既是控制平面实体又是数据平面实体。作为控制平面实体, MAR负责追踪MN移动并代替MN向CMD执行移动性相关信令。每个MAR都有一个全球唯一的网络前缀用于MAR所在接入网络内MN的IP地址分配, 并且每个MAR都维护一个本地BCE用于保存与之相关联的MN的信息。MN在移动过程中会在每个新的接入MAR处配置一个新的IP地址用于新会话的建立, 这样新发起的会话无需经过MN之前的锚点。同时, MN保持从之前接入MARs配置的且正在使用当中的IP地址来保证切换会话的连续性。由于新的接入MAR处没有MN的移动上下文信息, 因此当MAR检测到MN离开或接入时需要查询CMD。

3.2“革命性”方案

3.2.1 基于路由的DMM方案

在演进性DMM方案中, 经历IP切换的流量需经过双向隧道转发, 其路由仍非最优。在理想状态下, MN切换到新的接入网络后, 所有来自或发往MN的流量都能够通过最优的路径交付。现有域内路由协议采用距离向量算法或链路状态算法进行路由表更新, 从而使得数据包可通过最优的路由交付。基于路由的算法借鉴了路由表更新方法的思想, MN在移动过程中使用且仅使用一个IP地址。在MN移动并接入到新的网络接入点时, 保持之前使用的IP地址不变, 通过更新路由表实现来自或发往MN的数据流量的最优路由。由于MN的IP地址属于特定的BGP域内, 因此基于路由的方案仅考虑BGP域内路由的更新, MN在BGP域间切换时需重新配置新的IP地址。

在基于路由的DMM方案中, 当MN移动并连接到不同的接入路由器时, 接入路由器 (AR, Access Router) 在接入认证时发现MN配置的IP地址并对其进行路由更新。基于路由的DMM方法可以使得所有流量的路由路径最优化, 但该方法在更新路由时需要较大的信令开销, 即以信令开销为代价换取路由路径的优化。此外, 该方法在切换时延和扩展性方面仍存在诸多问题:路由限制在域内收敛更新路由会产生路由风暴, 路由收敛时间需要限定在足够小的时间间隔内避免切换中断时间过长。因此, 基于路由的DMM方案仍需进一步研究。

3.2.2 基于SDN的DMM方案

SDN通过更为灵活的方式设置数据路径能够实现更高效的DMM路由[17]。仅需通过更新流表即可实现路由优化, SDN不仅可以控制数据路径, 也可控制路由器之间的其他类型的消息。SDN提供非常灵活的方式进行包和流处理, 天生能够快速应对网络路由改变。当MN改变网路接入点时, 转发功能通知运行在SDN控制器之上的移动性管理功能根据IP数据包的目的IP地址计算转发规则并将该转发规则推送给转发功能, IP数据包根据该规则进行转发。当用户会话结束时, 移动性管理功能将删除这一转发规则。通过这种方式, 在移动过程中不改变MN的IP地址以保证应用层会话连续性。

使得SDN支持移动性还有很多问题需要解决, 例如转发功能需要获取MN的移动事件并及时通知SDN控制器和移动性管理功能实体, 需要及时建立从分布式移动性接入锚点到网络接入点的路由路径。为实现这些, IETF可能需要定义新的协议和机制。

4 结论

本文介绍了当前移动互联网移动性管理所面临的挑战。基于移动性管理将会话标识和路由位置进行分离的基本思想, 将现有移动性管理协议的逻辑功能进行拆分。根据移动性管理逻辑功能的部署情况, 将移动性管理划分为集中式移动性管理和分布式移动性管理两种方式。文章重点对分布式移动性管理方案的研究现状及其典型管理架构进行了研究。根据DMM架构研究思路的不同, 文章将DMM架构进一步划分为“演进性”方案和“革命性”方案。随着移动互联网架构和应用业务的快速发展, 移动性管理在地址和隧道管理、注册延迟与信令开销、网络配置和资源管理以及安全等方面仍面临挑战。如何解决这些问题是未来移动性管理技术的研究方向之一。

摘要：本文首先对移动性管理协议的产生和发展进行了简要回顾, 引出当前网络移动性管理协议所面临的挑战与发展, 并得出进行分布式移动性管理协议研究的必要性。文章对移动性管理的基本原理、类别划分和分布式移动性管理的研究现状进行了阐述。根据设计思路的不同, 将现有分布式移动性管理方案分为“革命性”性的设计方案和“演进性”的设计方案两大类, 并采用统一的架构对当前分布式移动性管理的不同形式进行了统一的描述、分析和对比。最后, 文章指出了分布式移动性管理仍面临的挑战及未来发展方向。

移动管理分布式部署 篇3

互联网上有大量关于各类健身运动等资源供参考,能够帮助人们更合理地安排健身计划和饮食计划。移动设备和移动互联网的普及使这些海量资源可以随时随地被获取,满足了人们对运动和饮食信息的即时性需求。然而面对海量的信息资源,用户很难在短时间内获取符合自身需要的信息,有价值的资源有很多,帮助用户找到符合自身需求的信息至关重要。推荐系统正是为解决这个问题而产生的。推荐系统可以通过采集和分析用户的历史浏览数据,从大量视频中找到符合用户需求的视频,生成推荐列表返回给用户。

1 系统概要设计

1.1 系统架构设计

(1)系统物理架构

本系统实现了客户端/服务器(C/S)和浏览器/服务器(B/S)两种软件架构。普通用户通过Android移动客户端与服务器进行交互,实现健身管理和视频观看功能;系统管理员通过浏览器与服务器进行交互,对基础数据和用户进行管理。实时推荐系统的主节点运行在应用服务器上,其他工作节点运行在分布式集群上,为用户提供实时视频推荐服务。

(2)系统逻辑架构

移动健身管理平台中有用户和后台管理员两种角色,分别通过移动客户端和浏览器与服务器交互。系统的结构自顶向下分为视图层、控制层、模型层、基础服务层和数据层。移动客户端的视频推荐功能由独立的实时视频推荐系统和服务器通过Redis数据库交互,为视频推荐功能提供用户的推荐列表。系统的架构图如图1所示。

实时视频推荐需要经过离线计算和在线计算两个步骤。离线计算以用户的历史行为数据为注入,建立用户兴趣模型,生成离线推荐列表。由于用户不断有新的行为,离线推荐列表需要每天更新一次。在线计算综合离线推荐结果和用户的当前行为,生成实时推荐列表。

1.2 系统功能模块设计

1.2.1 用户功能模块设计

(1)编辑运动日志。用户查看运动日志,可选择添加新的运动项目或删除已有项目。

(2)同步健身数据。用户可以手动同步健身数据到服务器,防止数据丢失。

(3)获取视频推荐。客户端将获取视频推荐列表的请求发送给服务器,响应的servlet调用视频推荐类,调取数据库中的视频推荐列表返回给客户端。

(4)播放视频。用户进入视频主页,查看视频列表。选择一个视频后,系统分别加载视频和视频简介等信息。

1.2.2 后台管理功能模块设计

(1)数据更新模块

管理员可对运动和食物数据进行更新。首先查看运动数据,输入要添加的运动项目。如果项目已经存在则不能添加,需要重新输入。

(2)视频管理模块

视频首页由管理员维护的视频列表,固定的显示在客户端视频页面的上方。管理员登陆系统后,查看视频列表,可选择添加视频。

1.3 数据库设计

1.3.1 关系数据库设计

移动客户端产生的用户数据,如训练计划、运动日志和饮食日志等存储在Android客户端的SQLite数据库中。这些数据需要被用户频繁地查看和编辑,因此把数据存放在本地可以提高数据的加载速度,减少从网络中读取数据所耗费的时间。这些数据要定期同步至服务器端的My SQL数据库,防止用户信息丢失。My SQL数据库还存有视频、视频评论、用户收藏等信息。

1.3.2 非关系数据库设计

(1)用户事件队列。用户每一次点击视频、收藏视频的行为都会被存储到事件队列中。

(2)相似度矩阵。相似度矩阵存储任意两个视频的相似度,使用hash实现。

(3)用户评分向量。一个用户对所有视频的评分构成一个n维向量,同样使用hash数据结构实现。用户ID作为键,视频ID作为字段,存储对应的评分。

2 推荐系统算法及评测方法

2.1 基于内容的推荐

基于内容的推荐只需要用户模型和项模型,不受到项的评分信息数量少的约束,这点是协同过滤系统无法实现的。由于只关注内容,因此不会降低新项目、冷门项目被推荐给用户的几率,有助于增加推荐结果的新颖度。但基于内容的推荐系统只适用于可描述内容的项推荐,不适用于视频、声音、图片等特征提取困难的对象。

2.2 协同过滤算法

协同过滤算法中最重要的方法是基于邻域的方法,主要包含基于用户的协同过滤(User⁃based Collabora⁃tive Filtering,User CF)和基于项的协同过滤(Item⁃based Collaborative Filtering,Item CF)两类算法。

推荐系统当中有两类研究对象,一类是用户(us⁃er),另一类是项(item)。用户和某些项具有一定关系,这个关系可以被描述成一个数值。

用户和项可以构成一个效用矩阵(utility matrix),矩阵中每个值代表某用户对某个项的喜爱程度。如图2所示的效用矩阵,代表用户a、b、c对6部电影的评分,其中空白的部分表示用户还没有对电影评分。推荐系统的一个主要目标就是预测空白部分的数值,把分数最高的前n个项推荐给用户。

2.2.1 基于用户的协同过滤

基于用户的协同过滤算法的工作方式是首先找到和目标用户的兴趣相似的用户集合,然后找到这个集合中用户喜爱的项中目标用户不知晓的项推荐给该用户。判断两个用户的兴趣是否相似,通过判断用户对相同项的行为是否相似得出。

2.2.2 基于项的协同过滤

基于项的协同过滤算法广泛地应用于各种推荐系统中,它基于的假设是两个项被同样的用户喜爱则具有很高的相似度。基于项的协同过滤主要分为两步。计算项之间的相似度,然后根据项的相似度和用户的行为数据生成推荐列表。

2.3 健身视频实时推荐系统算法设计

(1)离线算法的选择

基于用户的协同过滤推荐适合用户个性化需求不太丰富但时效性较强的场合。相反,基于项的协同过滤具有很强的发掘长尾物品的能力,适合用户个性化需求强烈的领域。基于项的协同过滤推荐可以解决新用户的冷启动问题。相比较而言,基于用户的协同过滤要先更新用户的行为数据。

目标系统的用户个性化需求强烈,对新用户的冷启动有要求,由于对时效性没有要求,因此可以容忍新项的冷启动问题。本系统选择基于项的协同过滤算法作为推荐系统的离线算法。

(2)实时推荐过程算法设计

要让实时推荐的结果反应用户当前兴趣,需要将用户的点击行为和收藏行为转化成量化的喜爱程度。本算法用可调节参数a和b表示用户对未评价过视频的喜爱程度,a表示用户对点击的视频的喜爱程度,b表示用户对收藏的视频的喜爱程度。令用户对视频i的预测兴趣度为Pui,定义如下:

式中:N(i)表示喜欢视频i的用户集合;N(j)表示喜欢视频j的用户集合;s(i,j)的定义如式(2)所示。其中分母惩罚了热门物品的相似度,热门物品被大多数用户知晓,应该避免推荐。

令视频的关联矩阵为C,式(3)表示用户u的兴趣向量P,其中从上到下依次表示用户u对视频的兴趣度。

去掉用户已评价过的视频,得到待推荐视频集合,集合中的元素是视频ID和对应的预测兴趣度。取预测兴趣度最高的前k项,生成推荐列表R,如式(4)所示:

由于不同用户的评分高低的习惯不同,a和b应由用户的历史评分的平均分决定。

用户每产生一次点击操作或收藏操作,就对用户评分向量进行相应的修改,如果用户对同一个视频有数个操作,则取模拟评价分数的最高值。当用户事件数量累计达到预先设定的阈值,系统使用以上算法为用户产生实时推荐列表。

2.4 推荐系统测评

(1)实验方法

离线实验首先通过系统工具获得用户行为数据,并按照一定的格式生成数据集。然后将数据集按照一定的比例分为训练集和测试集,将训练集算法注入到推荐系统中训练用户兴趣模型,在测试集上进行预测。最后通过离线实验指标评测在测试集上生成的预测结果与实际结果。

(2)评测指标

衡量推荐质量的指标有很多,根据不同的实验方式,使用不同的指标进行评估。离线实验一般使用评分预测准确度(RMSE)、覆盖率、多样性等指标评价推荐系统。用户调查和在线实验可以获得用户满意度、惊喜度等离线实验无法获得的指标。

3 系统详细设计与实现

3.1 移动客户端设计与实现

移动客户端的架构图如图3所示。要实现移动客户端的用户功能模块,需要使用一些中间件作为基础,包括网络连接模块、网络检测模块和图片缓存模块。

(1)网络连接模块

首先通过Volley工具创建Request Queue对象,Re⁃quest Queue是使用Volley框架的核心,通过将创建的请求添加到Request Queue中,该对象就可以按照先进先出的方式按顺序分发请求。在分发请求时,首先判断该请求是否被缓存过,如果已经缓存在本地,则使用Cache⁃Dispatcher调用缓存的内容返回给客户端。如果没有缓存,则调用Network Dispatcher向网络发送请求,Dis⁃patcher返回后,通过调用相应的on Response接口,处理返回后的数据。

(2)网络检测模块

网络检测模块还负责检测网络状态是连接还是断开。当网络断开时,给用户发送提示。在Android系统中,使用Connectivity Manager类对网络进行检测。网络检测用到的主要方法如表1所示。

(3)图片缓存模块

LRU(Least Recently Used)缓存把最近最少使用的数据移除,将系统内存让给最新读取的数据。要想实现LRU存储策略,可以使用哈希表和双链表实现。将Cache的所有位置都用双向链表连接起来。当一个Cache被访问之后,通过相应的链表操作,将该Cache调整到链表表头的位置。新加入的Cache直接插入到链表表头。在进行多次调整操作后,最近被命中的Cache就会向链表头方向移动,而没有命中的则向链表尾部移动。因此,链表尾表示的是最近最少使用的Cache。当空间不足需要清除一部分内容时,链表最后的节点就是最少被使用的数据,根据需要将最后面的几个数据清除。

3.2 后台管理子系统详细设计与实现

(1)视频管理模块

管理员对视频首页进行管理,可以增加和删除视频,这些视频将显示在移动客户端的视频界面。

(2)用户管理模块

管理员删除用户评论的流程图如图4所示。首先查询被举报的评论是否存在,如果存在则删除,否则终止操作。

(3)数据更新模块

管理员也可以对已有的运动和食物数据进行修改。图5所示为管理员更新运动数据的流程图。

3.3 实时推荐系统详细设计与实现

(1)Storm分布式流处理框架

在Storm集群中,有主节点和工作节点。主节点上运行着Nimbus进程,工作节点上运行着Supervisor进程。主节点上的Nimbus后台程序负责资源分配和任务调度,它会尽量均匀地将任务分配给Supervisor。Super⁃visor负责接收Nimbus分配的任务,启动和停止属于自己管理的进程。Nimbus和Supervisor的通信通过Zoo⁃keeper集群完成。

(2)事件生成模块

一个事件纪录了时间戳、Sessionid、事件类型、用户ID和视频ID。事件流的类型分为三类,分别为点击事件、推荐事件和会话终止事件,分别代表用户的点击操作、推荐请求和会话结束状态。

(3)实时视频推荐模块

要实现实时视频推荐,首先要计算离线推荐结果,编写Map Reduce批处理任务。离线结果和它的中间结果是实时推荐的基础。得到了离线推荐结果和它的中间结果后,将这些数据存储到Redis中。运行在Storm集群上的topology接收用户的点击事件流,根据用户的点击时间和离线推荐的计算结果生成实时推荐列表。

(4)推荐系统实验

本文的实时推荐系统实验数据基于Youtube上的用户评价健身视频数据的仿真数据。在Youtube上搜索关键词,取最热门的N个视频链接作为起点使用爬虫工具抓取用户对视频的评价信息。将这些数据整理,得到8千个用户对2千个视频的行为。进而可以得到用户对视频的评价矩阵和视频的相似度矩阵。将评论了视频但是没有把视频标记为喜欢的用户作为用户的点击数据。选择某一个时间点的点击数据作为实时数据。

4 系统测试

对系统的功能测试主要涉及健身管理模块、视频模块和账户管理模块的主要功能。通过测试得出,结果均通过。本系统使用Monkey对Android系统进行压力测试,使用命令adb shell monkey⁃p com.bit.fitlab⁃v 10对com.fitlab.manage包发送一定数量的随机事件流,模拟用户随机操作,然后返回这些操作对系统的影响。该测试结果说明,模拟了100次操作,系统没有产生崩溃,Wi Fi传输数据的耗时为520 ms。

5 结论

本文实现了一款基于实时视频推荐系统的Android平台健身管理类应用软件,将健身视频资源和健身管理应用整合,便于用户提高健身效率。提出了实时视频推荐与健身管理结合的研究方向,系统的健身管理功能实现了对运动的时间、持续的时间、消耗的能量、项目完成的进度、摄取食物的质量和能量的全面管理功能,设计并实现了视频实时推荐系统,解决了新用户推荐的冷启动问题,并且增强了系统的实时性,使用户的兴趣点被实时捕捉。使用Storm分布式流处理框架实现,系统的性能卓越。

参考文献

[1]MILICEVIC A K,NANOPOULOS A,IVANOVIC M.Social tagging in recommender systems:a survey of the state-of-theart and possible extensions[J].Artificial intelligence review,2010,33(3):187-209.

[2]周海平,黄凑英.两种协同过滤推荐算法的比较研究[J].贵阳学院学报(自然科学版),2015,10(1):1-4.

[3]SNEHA S,JAYALAKSHMI D S,SHRUTHI J,et al.Recommending music by combining content-based and collaborative filtering with user preferences[C]//Proceedings of 2012 International Conference on ICERECT.India:Springer,2012:507-515.

[4]CUGOLA G,MARGARA A.Processing flows of information:from data stream to complex event processing[J].ACM computing surveys,2012,44(3):359-360.

[5]CANTADOR I,BELLOGÍN R,VALLET D.Content-based recommendation in social tagging systems[C]//Proceedings of2010 ACM Conference on Recommender Systems.New York:ACM,2010:237-240.

[6]XIA M J,ZHANG J G.Research on personalized recommendation system for e-commerce based on Web log mining and user browsing behaviors[C]//Proceedings of 2010 International Conference on Computer Application&System Modeling.Zhengzhou,China:IEEE,2010:408-411.

[7]刘建国,周涛,郭强,等.个性化推荐系统评价方法综述[J].复杂系统与复杂性科学,2009,6(3):1-10.

移动管理分布式部署 篇4

随着信息化进程的不断深入, IT运维在电力企业生产中发挥着越来越重要的作用。但随之而来的是物理服务器数量不断增长, 每一项业务应用都部署了一台单独的服务器, 由此导致多数公司的机房变成一片服务器的海洋, 其中多数资源没有得到充分利用, 但同时又有一些服务器资源需求得不到满足。

虚拟化技术对此提出了很好的解决思路, 目前也在电力企业中大量地应用起来。

1 虚拟化标准架构

目前虚拟化软件可以非常好地实现分布式处理的功能。在集群内部, 所有的物理服务器形成一个资源池, 通过虚拟化管理平台来进行资源调度和高可用保障等操作。以VMware为例, 虚拟化的标准化部署如图1所示。

由图1可以看出, 通过在物理服务器上构建虚拟层, 可以在此之上生成多个虚拟服务器。每一个虚拟服务器, 从功能、性能和操作方式上等同于传统的单台物理服务器, 在虚拟服务器上再安装操作系统和应用软件, 这样以前的每个物理服务器就成为提供虚拟机运行的资源平台, 从而大大提高资源利用率, 降低成本, 实现了服务器虚拟架构的整合。

通过标准的SAN集中存储架构, 将由虚拟架构套件生产出来的虚拟机的封装文件存放在SAN存储阵列上, 从而可以在线地迁移正在运行的虚拟机, 进行动态的资源管理, 实现即插即用的数据中心和集中式虚拟机整合备份等。

如果按照物理CPU个数来进行资源调度, 并不能体现虚拟资源池的概念, 而且普通虚拟交换机的配置和管理也非常复杂, 必须加以重新考量。

2 合理配置虚拟机分布

2.1 对虚拟CPU资源的部署

采用虚拟架构整合后, 除了服务器的利用率提高之外, 还可以充分满足不同应用对系统资源的不同要求。在传统方式下, 如果用一种或几种标准配置的服务器来统一采购, 则势必会造成应用资源分配不均, 且应用之间不能互相调配资源。而采用虚拟架构后, 每个虚拟机所需使用的系统资源都是由虚拟架构软件统一调配, 这种调配可以最大限度地提高整体系统的资源利用率。

显然, 业务重要性不同的服务器应分配不同的资源。而在分配过程中, 最重要的无疑是CPU处理资源。从普通物理机来说, 四路六核比两路六核的处理器性能更强大, 但虚拟机并不一定如此。由于虚拟机是按资源池的概念进行资源分配, 各厂商对于资源分配有不同的概念。以VMware为例, 如果针对一台虚拟机分配了8个vCPU, 并不代表能拥有8倍于1个vCPU的处理器能力。针对虚拟C P U处理请求, VMware采用的是同时获得即分配的原则, 即对于某个虚拟机而言, 如果请求4个vCPU的资源, 则只有在4个vCPU都空闲的时候才进行分配。所以, 随着vCPU个数增加, 虚拟机的处理能力呈现出图2 (a) 的曲线。从图2 (a) 可以看出, 虚拟机性能和vCPU数量并不呈现线性关系, 而是会逼近一个极限值。针对目前物理服务器CPU处理性能和核数越来越高的情况下, 有必要对CPU资源分配策略进行调整。

以SAP应用为例, 中广核目前在小型机上双机部署一个DB, 一个APP。如果将APP转移至X86服务器, 则APP对处理性能的要求对于单台X86服务器压力不可承受。为了能尽量争取到CPU资源, 在业务系统允许分布式处理的前提下, 应把作业分布在多个系统运行。这样做的优势显而易见, 由于单个虚拟CPU空闲的几率比多个虚拟CPU同时空闲的几率要大得多, 从而使计算任务可以顺利进行。如此虽然每段曲线是渐进式的, 但是几段曲线之和可以大于原来非分布式执行方式, 即1+1>2, 如图2 (b) 所示。

在具体数据中心实施虚拟化时, 应利用业务系统的分布式处理能力, 拆分业务至多个虚拟机运行, 以更好地获得CPU对处理请求的响应。如果多个不同业务的虚拟机放置于同一物理机上, 可以利用VMware的CPU资源控制进行微调。调节阀有3个值:reserved、limited、share。其中reserved和limited表示最少和最多分配的资源数, 单位一般为实际物理值MHz。但share表示了资源竞争优先级的概念。如设VM1的share为8 000, VM2为6 000, 则表示VM1所占权重为8/14。这样, 可以为同一物理机上重要的业务赋予更高的CPU权重, 达到综合控制CPU资源的目的。

2.2 优化虚拟机在物理机上的部署

目前, 部分企业的服务器虚拟化整合比已经达到了20:1。然而当工作负载被虚拟化后, 服务器位置变得模糊起来。如前所述, 在分插着分布式业务和普通业务的虚拟机环境下, 如何合理地部署虚拟机是一个值得考虑的问题。

优化虚拟机布局的最佳方法是从服务器工作负载分类开始, 尽量将分类最小化, 然后通过对资源的需求进行分组。例如, Web服务器和Email服务器需要网络资源, 数据库服务器需要内存和CPU, 中间件服务器需要处理能力, 这些都是生产中需要用到的系统, 另外还需要测试系统、培训系统和开发系统。部署的原则是:各个虚拟机之间不应该存在频繁的资源竞争。据统计, 目前在各项Windows服务中, 存在如图3所示的资源需求时间点关系。

从图3可以看出, 域控制器在刚上班时需要网络和处理器资源, 如清晨或下午;文件和打印服务器在峰值期需要硬盘、网络I/O资源, 如上午11点或中午;Web服务器主要集中在网络资源, 并需要保持稳定;SQL服务器和交换服务器全天需要稳定的内存和处理器资源;企业应用程序则定期执行, 如工资单应用程序通常2个月或2周运行1次。

所以应尽量避免配置相同的工作负载在同一物理机上。可以在1台物理服务器上运行1个域控制器、1个网络基础设施服务器、1个文件服务器、1个或多个Web服务器, 甚至可以加上1个企业应用程序。其中的关键是要保证在不同的时间工作负载需要不同的资源。

3 利用分布式交换机简化虚拟网络配置

虚拟化带来的好处之一就是网络管理能力较物理网卡大大加强。在虚拟化环境下, 网卡即虚拟交换机, 而虚拟交换机可以等同于普通的物理交换机。虽然一般虚拟交换机也可以实现一些网络管理功能, 但仍存在缺陷。集群的搭建一开始就需要考虑高可用 (HA) 和在线迁移 (Vmotion) 等功能。为保证操作的顺利执行, 需在每台物理机上配置一个相同的普通虚拟交换机, 但在物理机较多或网卡配置更加频繁的情况下, 这并不是一个好办法。

分布式虚拟交换机可以很好地解决这一问题。它是集群内一台可以连接所有虚拟机的虚拟交换机, 而这台虚拟交换机再上联至集群的物理网卡以进行流量传输。这样可以对整个集群内的所有虚拟机使用同一个交换机而无需单独配置。唯一的前提是出于逻辑上的完整性, 分布式虚拟交换机要求每台主机都至少有一块网卡属于一个上联端口。

通过分布式虚拟交换机, 可以实现如网络隔离和流量控制等网络管理功能。和利用分布式交换机进行网络隔离相比, 这并不是最优选择。从管理上来看, VLAN的划分粒度小, 从而多个不同的VLAN的划分会增加网络管理复杂性。从使用上来看, VLAN划分属于逻辑层面, 无法实现物理层面的网络隔离。所以, 在物理网卡较多的前提下, 应将虚拟机部署到相同宿主主机上不同的网络区域, 让它们在完全独立的环境中运行。例如可以在同一台宿主服务器上部署供测试、培训、开发甚至生产用的虚拟机, 只要将它们连接到不同的虚拟交换机进行隔离即可, 如图4中的VM-prd和VM-dev。也可以让一台虚拟机机处于不同虚拟交换机下, 一台对内, 一台对外, 在此虚拟机上安装防火墙, 让在内网的其他服务器从此虚拟机出口, 即可实现双宿主堡垒防火墙的应用模式, 如图4中的VM-FW。

在流量控制方面, 普通虚拟交换机只能针对同一网络标签下的虚拟机的发送包的流量进行控制。所以如果出现多个虚拟机处于同一网络标签 (端口组) 的情况, 如图4中的VM-dev开发机和VM-test测试机, 只有分布式虚拟交换机才能单独对每个虚拟机进行发送与接收流量的同时控制, 从而避免测试系统与生产虚拟机抢夺网络资源。

4 结语

针对目前在数据中心建设中虚拟CPU资源划分问题, 给出了拆分虚拟机的建议, 并提出应利用分布式虚拟交换机来进行网络管理, 以更好地利用虚拟资源池。通过分散使用和统一管理的方式来利用虚拟化技术, 使得物理服务器资源利用更具效率和完整性。

由于虚拟机的生成非常简单, 可以预见将来会有虚拟机数量的爆炸式增长过程, 如何对数量众多的虚拟机和物理机进行统一管理是一个亟待解决的问题。另外, 在虚拟化后, 对于安全性的考虑也须提上日程。

参考文献

[1]杨先杰.利用虚拟机技术进行服务器整合的应用和研究[J].电力信息化, 2007, 5 (11) .

山东移动DRA部署探讨 篇5

随着4G时代的到来和基于PCC/EPC/IMS的下一代核心网网络的部署, 未来核心网是一个基于IP的全互联网络, 信令网从承载面的IP化 (Sigtran协议) 逐渐向信令层IP化演进, 网络的IP化驱动信令网向全IP演进。构建下一代核心网的信令网, 扩大TD-LTE阵营, 优化网络结构, 保证网络的可扩展性和易维护性, 成为4G网络演进过程中的关键问题。通过下一代信令网路由代理 (DRA, Diameter RoutingAgent) 的部署和建设, 可以真正实现未来核心网的扩展, 实现高效维护、快速部署并增强网络安全。

2 DRA 介绍

(1) DRA引入背景

Diameter/SIP是全IP信令时代典型的核心网网元间通信协议, 最初提出是作为Radius协议的改进或者替代。它的引入是作为支持基于IP技术的AAA (Authentication、Authorization、Accounting) 协议 , 有链路管理、路由寻址、事务管理等功能。Diameter在PCC/EPC/IMS架构中广泛应用于网元之间通信, 成为应用最广泛的IP信令基础协议。3GPP及ITU标准组织定义了Diameter路由代理 (DRA) 这一信令网核心网元来完成信令的汇聚和转接。

(2) DRA应用场景

山东移动在2012年开始建设PCC/EPC。随着后续业务的发展和网络规模的不断扩大, 大量网元之间的Diameter信令互通需要部署、建设合理的Diameter信令网, 因此, 基于DRA的下一代信令网建设势在必行。结合山东移动实际, DRA建设分三阶段进行 (表1) 。

1) 第一阶段:DRA的首要功能就是实现LTE用户跨网漫游, 包括省内多个本地网LTE漫游 (S6a接口) ;与香港万众等LTE国际漫游 (S6a接口) ;与其他省LTE国内漫游 (S6a接口) 等。DRA可以作为IWF提供MAP-Diameter转换, 完成2G/TD/LTE网络间漫游时的互联互通, 满足LTE用户跨运营商的网络互联以及漫游需求。并且在用户进行跨网漫游时, DRA能够作为国际漫游边界网关屏蔽归属网络的网间结构, 保护网络安全。为便于进行网间结算, DRA还可以提供信令计费和信令监测功能, 实现不同运营商之间的信令计费和排障功能。

2) 第二阶段: 随着网络和业务规模的扩大, 在LTE网络中对Diameter信令消息提出了负载均衡的要求, 例如对在线计费系统 (OCS) 和HSS服务。这一阶段的建设重点在于需要实现GGSN与多套负荷分担的PCRF之间通过DRA组网 (Gx接口) ;PCRF与PCRF之间跨省漫游 (S9接口) ;SAE GW与PCRF之间通过DRA组网 (Gx接口) 等。

3) 第三阶段: 在设置多套PCRF的业务区域, PCRF与AF之间需要设置DRA设备进行多PCRF的会话绑定以及负载均衡。DRA能够保存IMSI和IP, 以及IMSI和PCRF的对应关系, 保证同一个用户在Rx、Gx等不同接口上的Diameter信令路由到同一个PCRF, 解决多PCRF部署带来的寻址和绑定等技术问题。

3 DRA 在 LTE 网络中的部署建议

在LTE网络中引入DRA还需要考虑LTE网络部署情况, 遵循业务驱动原则, 分阶段采用不同的解决方案, 在不同规模的网络中不断验证DRA的商用能力, DRA建设应坚持独立组网, 采用先大区汇接、后各省的建设模式。山东移动应首先在LTE领域引入进行规模商用, 再推广到PCC组网进行大规模商用, 长期演进应考虑与IP STP进行融合。

(1) LTE试商用阶段

在LTE试商用阶段, 由于业务需求量小, 山东移动在省内采用各核心网元直连方式实现业务互通, 跨省的S6a、S9通过DRA进行转接 (图1) 。

中国移动选择在南、北方基地配置DRA, 进行Diameter信令转发路由以及漫游互通方面的测试。中国移动在北京 (北方基地) 部署一对DRA, 作为一对双平面的DRA负责北京、天津、杭州、南京、上海、青岛、沈阳7城市的MME与北方国际信息港的HSS间的S6a信令转发;在广州 (南方基地) 部署一对DRA, 作为一对双平面的DRA负责广州、深圳、福州、厦门、成都5城市的MME与南方基地的HSS间的S6a信令转发。每个城市的核心网元首选直达路由, DRA作为备选路由;跨区域的EPC网元互通通过DRA。

(2) LTE规模商用阶段

到了LTE正式商用阶段, 当省内同一信令区内的网络规模大于3台MME时, 部署DRA汇聚各网元信令可获收益 (组网复杂度随之减低30%以上) , 可以简化网络数据配置, 降低运维成本, 并平滑演进到目标网络。随着山东业务的飞速发展, 山东移动在省内LTE网络可以配置一对H/LDRA (省内不同的两个城市各部署一台) , 实现Diameter信令路由, 并为PCC提供PCRF绑定和选择服务; 这对H/LDRA通过与南方 / 北方基地互通, 还可以提供与他省间的互联互通和跨运营商的漫游服务。

Diameter/SIP的协议机制与No.7信令相似, 原有的No.7信令安全机制 (网元备份、路由备份、链路备份) , 在Diameter信令组网中仍然有效且不可缺少。所以, DRA的部署和实施方式可以借鉴山东已有成熟商用的IP STP部署, 继承现有信令网组网架构。在信令消息流量不大、对时延不敏感的前提下, 基于目前IP网络的可视化运营面临挑战的考虑, 建议优先考虑网络结构的优化、网络维护的方便, 采用A/B平面组网 (图2) 。

(3) LTE长期发展阶段

到了LTE规模发展阶段, 随着互联互通业务量的增长, 全省一对DRA已无法满足业务需求, 可以按照不同信令业务区组成多个区域, 在每个区域的中心地市设置一对区域LDRA, 负责该区域内的Diameter信令路由, 支持多网元接入和信令业务的转接;以省为中心设置一对HDRA (可以由一对LDRA兼顾) , 提供省际间的互联互通和跨运营商的漫游服务, 逐步构建一张完善的Diameter信令网络 (图3) 。

山东移动DRA部署可以参考STP部署经验, 将全省分为东、西部两个区域:西部区域中心设置在济南, 负责济南、泰安、莱芜、临沂、枣庄、菏泽、济宁、滨州、淄博、东营、德州、聊城等12地市;东部区域中心设置在青岛, 负责青岛、烟台、威海、潍坊、日照等5地市。济南、青岛各再新增一台DRA与原有DRA成对设置, 成对DRA之间与同平面的DRA之间分别互联, 共同负责省内互联互通;济南一对DRA同时兼做HDRA, 负责省际间业务转接和跨运营商的漫游服务。实际组网中, Diameter信令通过IP专用承载网承载, DRA所用站点接入CE必须同业务面的接入CE分别设置, 同局址时须共用IP STP接入CE;MME和HSS的Diameter信令接口可共同业务面接入CE;S6a接口信令共用IP化信令VPN, Gx接口共用Gx接口VPN。

由于STP全网IP化正在实施改造中, 还需较长时间, 结合快速发展的新业务和减少对现网影响的考虑, 初期DRA设备的独立部署可降低对STP网络的影响, 长期DRA与IP STP是否融合, 业界对此一直存在争论。就山东移动而言, 目前公司信令网具有清晰的信令分区, 现网主要STP设备采用成熟规模商用的平台, 支持面向未来的平滑演进, 并且在2011年已经完成了部分A链、B链和C链的IP化正式商用, 积累了丰富的信令IP化经验。在后续的信令IP化改造过程中, 山东移动可以考虑将当前的IP STP改造为具备DRA能力的产品设备, 为后续的融合做好平台和业务准备, 节约网络投资, 减少对现有信令网络的影响, 降低网络运维成本 (图4) 。

4 结束语