深圳市公交车电子监控项目解决方案

深圳市公交车电子监控项目解决方案 1 深圳市公交车电子监控项目 解决方案 中国移动广东深圳分公司 2010 年 9 月 深圳市公交车电子监控项目解决方案 2 目 录 1.系统介绍 . 3 2.系统构成 . 4 2.1 监控前端设备 . 4 2.2 流媒体服务器 . 5 3 资费与结算 . 7 3.1 EDGE 流量费用 . 7 3.1.1 单卡计费方式 . 7 3.2 支付方式优惠 . 8 4 网络维护与保障 . 8 4.1 深圳移动的网络情况 . 8 4.1.1 优质的网络 . 8 4.1.2 保障机制 . 8 4.1.3 EDGE 建设 . 9 4.2 与联通网络的对比 . 9 4.3 网络运行质量 . 10 4.4 网络故障处理服务 . 11 4.5 监控系统设备故障处理服务 . 12 4.6 日常维护计划 . 13 4.7 其它服务承诺。 . 15 5 项目团队构成。 . 15 5 项目团队构成 17 深圳市公交车电子监控项目解决方案 3 1.系统介绍 深圳移动公司提供的移动监控系统由监控前端设备、流媒体服务器、监控业务管理平台、监控客户端组成。 图（ 1）移动监控系统组网结构 监控前端设备可通过 GPRS/EDGE/WCDMA、 Internet 等无线、有 线网络连接到流媒体服务器上，由流媒体服务器发布给监控客户端。用户可以通过手机终端、PC 终端接入到监控业务管理平台，通过用户认证和业务鉴权后，查看流媒体服务器上转发的视频监控内容。 监 控 前 端 设 备 分 无 线 和 有 线 两 种 类 型 ， 无 线 监 控 前 端 支 持GPRS/EDGE/WCDMA 等网络接入流媒体服务器，有线监控前端通过以太网线接入 Internet 网络，从而接入流媒体服务器。 监控客户端包括手机终端和 PC 终端，可以直接用手机终端上自带的流媒体播放软件打开监控视频流， PC 终端支持多画面监控应用。监控客户端接入流媒体服务器前都需 要进行用户认证和业务鉴权。 深圳市公交车电子监控项目解决方案 4 系统支持点播和直播模式，直播模式主要用于公众监控应用，监控前端设备一旦向流媒体服务器注册成功，就一直传播监控业务媒体数据流；点播主要用于个人监控应用，通常情况下只建立链接，不传输监控业务媒体数据流，当用户点击监控业务时，才传输业务媒体数据流，这样可以节省无线 /有线网络带宽。 2.系统构成 2.1 监控前端设备 以支持 GPRS/EGDE 的无线监控前端设备为例，介绍监控系统组网和监控前端设备的性能指标参数。 S / G G S NR O U T E RE D G EB S CW i r e l e s s V i d e o S e r v e rI N T E R N E T服 务 器用 户 W E B 浏 览视 频 流 ( R D P )视 频 流 ( U D P 、T C P )C M N E T用 户 终 端 浏 览视 频 流 ( R S T P )上图为系统的媒体 流传输过程， H.264/MPEG4 码流通过 EDGE 网络接入流媒体服务器。在 EDGE 网络上采用 RDP 协议，实现高效、可靠的视频传输。 RDP带宽利用率比 TCP 要高出 20%左右，而且传输延时比 TCP 小，比直接 UDP 传输方式丢包率提高上千倍。用户在移动终端上登录流媒体服务器即可浏览移动前端的图像，也可在 PC 机上通过客户端软件（或者 IE 浏览器）登录流媒体服务器浏览移动前端的图像，从流媒体服务器到客户端可以选用 UDP 或者 TCP 方式传输视频流。通过流媒体服务器可以支持多用户观看同一个前端设备的图像，用户不需要了解前端设备 的 IP 地址等信息。用户还可使用支持流媒体的移动终端 深圳市公交车电子监控项目解决方案 5 接入流媒体服务器，查看前端监控视频。 系统的无线监控前端设备，包括无线视频服务器（摄像头和编码传输单元分离）、无线网络摄像机（摄像头和编码传输单元一体），采用高性能 DSP 实现H.264/MPEG4 视频压缩算法，集成无线视频传输模块，只需要插入支持移动数据业务的 SIM 卡即可实现移动无线视频传输，可支持 EDGE、 GPRS、 WCDMA等网络承载。 视频采集 H.264 MPEG4 编码 带宽自适应单元 RDP TCP/IP PPP HDLC Serial EDGE 无线模块 上表为前端设备的功能模块，视频采集单元捕获图像后提交给 H264/MPEG4编码器，编码器将编码后的码流送给传输控制单元进行 RDP 封装，传输控制单元会根据当前的信道发送情况实时的调整编码器的参数，实现动态编码， RDP数据经由 TCP/IP 协议栈、 PPP 模块、 HDLC 模块和串口驱动提交给 EDGE 无线模块发送出去。 2.2 流媒体服务器 对于流媒体的组网方案，在负载均衡方面主要有如下需求。 1、实现冗余 实现冗余方案，对于移动流媒体这种长时间进行运行的设备来讲，是非常必要的，如果不实现流媒体服务器的冗余 方案，将会给以移动流媒体平台为基础的其他业务造成巨大的损失。 2、实现负载均衡 建立一个 ICP的核心服务器群，必须灵活实现虚拟服务器群的真正负载均衡，根据用户访问的特点来制定合适的负载均衡算法，保证整个业务平台能够快速高效的提供服务。 3、健康检查机制 当对流媒体服务器进行选择性的流量转发时，应考虑到对服务器进行状态监控，检查服务器是否处于非正常状态，当出现异常时，就不能转发数据到该服务器上，并告警。 深圳市公交车电子监控项目解决方案 6 目前负载均衡的算法有多种，主要有轮循法、加权轮循、最少连接（用户）、最少流量、动态观察法等。 针对本项目的 自身特点，主要用于移动用户的流媒体需求，正常情况下，我们的流媒体服务器将选择同一型号的服务器，这些服务器具有相同的性能，并提供相同的功能，因此，在仅有服务器的情况下，我们在选择负载均衡算法时，可不考虑不采用服务器加权的方式。但当数据中心添加 Cache 时，我们要考虑将Cache 设置为较大的权重值，作为对流媒体服务器有效的压力缓解和备份。 由于我们的组网结构采用本地单脚模式，因此，从服务器发向用户的返回多媒体数据流将不经过负载均衡设备，直接从网关发送到公网。因此，选用流量负载均衡将不能真实的反映实际的服务器流量 情况。 而采用轮循法，则不能根据服务器的状态进行动态调节算法。使用观察法则可能不能有效的对流媒体服务器进行均衡。选用最少用户数则较为客观的反应了用户的连接情况。 因此，我们认为，当不选用 Cache 时，比较符合项目需求的是基于最少用户数的负载均衡算法。选用 Cache 时可以考虑使用服务器权重的负载均衡算法。 顾名思义，本地单脚模式就是负载均衡器只有一条物理链路连接到网络中，将负载均衡设备用单条线连接到网络中，用户对流媒体服务器的访问的数据包全部经过负载均衡设备进入，返回的数据包则直接经过网关返回。手机终端用户发起的流媒体请求，将首先发送到负载均衡器，负载均衡器根据设置的策略转发到相应的服务器上，服务器返回的数据将不再经过负载均衡器，直接由服务器通过自己的网关，发送到手机终端。 这种组网方式避免了负载均衡器处理大量的下行数据，适合于数据下行量较大的应用，因此，这种组网方式较为适合大流量流媒体数据的传输应用。 此流媒体系统还支持全局和局部服务调度负载均衡的功能。 在大规模分布式多点组网业务系统中，需要更强大的负荷分担的能力。流媒体系统支持对全局服务调度，根据配置的规则，例如根据分布式流媒体节点的负载及用户位置灵活调度 服务到某节点，均衡全网负载，确保服务质量。 局部负载均衡，可根据流媒体服务节点内部的各个流媒体服务器的状况，将用户的服务请求引导到负荷较轻的服务器上。 深圳市公交车电子监控项目解决方案 7 流 媒 体 服 务 器流 媒 体 服 务 器流 媒 体 服 务 器I n t e r n e t / C N 核心网防火墙二层交换机二层交换机负载均衡器路由器流媒体服务器群无 线 流 媒 体 终 端用户发起访问请求的数据服务器返回的数据I P : 1 9 2 . 1 6 8 . 1 . 2 / 2 4V I P : 2 0 0 . 0 . 0 . 1I P : 1 9 2 . 1 6 8 . 1 . 1 / 2 4I P : 1 9 2 . 1 6 8 . 1 . 3 / 2 4L o o p b a c k 0 : 2 0 0 . 0 . 0 . 1I P : 1 9 2 . 1 6 8 . 1 . 4 / 2 4L o o p b a c k 0 : 2 0 0 . 0 . 0 . 1I P : 1 9 2 . 1 6 8 . 1 . 5 / 2 4L o o p b a c k 0 : 2 0 0 . 0 . 0 . 1另外，服务配额控制，即按照系统配置的数据，配置流媒体服务器的并发流数和流量（直播，点播，轮播），同时，还要限定各个业务运营商的可用并发流数，提高了系统的稳健性。 3 资费与结算 3.1 EDGE 流量费用 根据公交车电子监控系统项目的需求，确保更准确的成本费用核算，我公司建议 采用以单卡计费方式 。同时我公司也提供 按端口计费 的方式，具体费用可以磋商。 3.1.1 单卡计费方式 经过对公交车电子监控系统实际使用流量需求的研究后，我方推荐使用套餐套餐类型 月租费（元） 包含流量 （ MB） 超出省内流量费率（元 /KB） 超出省外流量费 率（元 /KB） 套餐 1 20 30 不区分省内外流量，超出部分 0.01 元 /KB 套餐 2 28 70 套餐 3 38 120 套餐 4 50 250 0.01 元 /KB 0.01 元 /KB 套餐 5 100 1,000 0.01 元 /KB 0.01 元 /KB 套餐 6 150 3,000 0.01 元 /KB 0.01 元 /KB 深圳市公交车电子监控项目解决方案 8 2 和 套餐 3,该套餐预估能够满足正常的数据传输。同时，随着治安整治情况的改善，预估数据量会逐渐减少。 3.2 支付方式优惠 我方提供的支付方式主要有两种：预存通信费用支付和帐号托收月结支付。 若提供预存通信费用支付方式，我方会给予一定的优惠。 4 网络维护与保障 4.1 深圳移动的网络情况 深圳手机的单机话务量是澳洲的 6 倍，更是全球手机最繁忙网络香港的 2.5倍；深圳移动精品网络的道路覆盖率已达 99 9；每年高交会深圳移动高峰期服务密度达 11.5 万户，远超悉尼奥运会开幕式 6.5 万户服务密度，深圳移动全球通网络 涉及通话质量的两项关键指标：无线接通率、掉话率，均优于欧洲世界一流同类网络平均水平。 4.1.1 优质 的网络 深圳移动的手机网络已跻身世界一流网络，成为深圳移动通信市场的领军角色，成为深圳建设国际化城市信息化的“主力军”。为了进一步打造精品网络，为广大移动用户提供优质的通信服务，深圳移动的网络覆盖实现了从室外覆盖到室内覆盖的纵深发展。在延续市区、陆地的覆盖上，目前移动网络信号又延伸到深圳海域上。在移动情况下的平均数据传输速率达到 75Kbit/s 以上，静止情况下平均速率达到 150Kbit/s 以上，峰值速率超过 200kbit/s。 4.1.2 保障机制 随着城市信息化水平的不断提高，如何加强网络优化、不断提高网络覆盖、改善网络质量，是深圳移动开展服务提升的重中之重。为提升网络服务综合素质，近期已完成由基础业务网向智能目标网的升级，建立了一支高效的网络维护、建设、优化技术人员队伍，实现了网络监控、维护的集中化管理。 同时，深圳移动清楚地认识到网络质量优劣的唯一评判标准来自于客户，为建设客户满意的网络，深圳移动建立起一套面向客户需求的快速应变机制，仿照 深圳市公交车电子监控项目解决方案 9 公安系统的做法，在前台服务窗口和后台网络维护部门之间建立起“ 110”系统作为绿色通道，实行 24 小时网络投诉即刻响应计划。通过“投诉处理 110 系统”，网络部门 24 小时随时接受来自服务前台的信息，对客户的投诉、反映的网络故障做出最快响应，随时抢修；同时，网络部门不断把网络的状况发布给服务前台，使前台服务人员准确解答客户的问题。 110 系统的建立，使 1860 客户服务热线不仅成为了客户解决疑难的渠道，而且变成了明鉴网络质量、网络覆盖和运行状况的一面镜子。 4.1.3 EDGE 建设 目前，我公司正在大力推进的 EDGE 网络建设已经接近尾声，实现了关内的全覆盖和关外的重点覆盖；其中，关内 道路实现 100覆盖，关外道路覆盖已经超过 50，并将在 2006 年年底之前实现关内外的 EDGE 全覆盖。 4.2 与联通网络的对比 1 覆盖率和话音质量 从覆盖率和话音质量看，移动 GSM 网优于联通 G 网、 C 网以及电信的市话通。 2 接通率和掉话率 从接通率和掉话率的数据看，移动 GSM 网优于联通 G 网、 C 网以及电信的市话通。 91.00%92.00%93.00%94.00%95.00%96.00%97.00%98.00%99.00%100.00%101.00%移 动 G S M 联 通 G S M 联 通 C D M A 市话通覆盖率 话音质量 深圳市公交车电子监控项目解决方案 10 3 定点测试数据上下传对比 除深圳大学下行速率略低于联通外，其余测试点的上下行速率均超过联通。 4.3 网络运行质量 1. 手机接收信号 强度低于 -85dBm的测试点的数量在 3%以下； 2. 用 TEMS 进行误码率（ RxQual） 测试，等级大于 3 的测试点的数量占 4以92.00%93.00%94.00%95.00%96.00%97.00%98.00%99.00%100.00%101.00%移 动 G S M 联 通 G S M 联 通 C D M A 市话通0.00%1.00%2.00%3.00%4.00%5.00%6.00%接 通 率 （ % ） 掉 话 率 （ % ） 深圳市公交车电子监控项目解决方案 11 下； 3. 道路沿线小区连续 2 天的忙时掉话率统计小于 5； 4. 道路沿线小区连续 2 天的忙时接通率统计高于 95； 5. 在静止状态下，数据下载速率不低于 120kbps，数据上传速率不低于 70kbps；在 2030km 移动状态下，数据上传速率不低于 80kbps，数据上传速率不低于 60kbps； 6. 全年业务全断时间不超过 60 分钟； 7. 在节假日高峰期，我公司对公交分局的数据传送优先提供网络支撑，优先处理公交分局业 务相关的网络故障。 4.4 网络故障处理服务 网络故障分为紧急故障和普通故障。定义如下： 紧急故障： 30%以上公交视频监控点同时发生通信中断，不能判断是否网络原因造成的故障。 普通故障：除了紧急故障以外的其他故障，均为普通故障 故障响应时间： 紧急故障： 提供 7 天 24 小时故障受理服务，设置 24 小时服务热线。故障服务的响应时间小于 3 小时，即：在收到故障申报后 3 小时之内 有能够处理故障的技术人员到达现场或者通过电话给出初步回复， 排除故障时间不超过 12 小时 。如果故障在检修 6 小时后仍无法排除， 移动公司会在 6 小时内提供 备用线路（设备）供 用户 使用，直至故障修复。 普通故障：受理普通故障申报后， 1 个工作日内做出响应， 3 个工作日给出初步解决， 5 个工作日内最终解决（需要新建基站视当地情况定）。 随时作好障碍抢修的准备，做到在任何时间、任何情况下都能迅速出发抢修；抢修专用的器材、仪表、机具及车辆等应处于待用状态，不得外借或挪作它用；我方自带维修器具如下： 序号 名称及型号 数量 备注 1 支持 GPRS/EDGE 4+2 模式的测试 TEMS 手机 1 台 深圳市公交车电子监控项目解决方案 12 2 数字万用表 1 部 3 12 信道 GPS（卫星定位系统）及配件 1 套 4 维护笔记本电脑 1 台 5 车载交流供电设备 1 套 6 应急抢修工具 1 套 7 数码相机 1 台 4.5 监控系统设备故障处理服务 监控系统设备 故障分为四个等级 ： 一级故障 整个系统瘫痪； 整个系统再装入； 整个系统连续再启动； 整个系统无法恢复成初始状态； 整个系统无法进行人机操作； 二级故障 偶尔发生系统再启动； 管理模块，通信模块或系统模块丧失诊断功能； 任一个中央信息控制模块，主时钟模块，网络模块，输入输出控制模块，电源模块，外围处理模块退出服务； 任何极有可能引起系统中断的硬件故 障； 三级故障 处理机短暂的故障导致时钟同步丢失（每天二次或更多）； 软件或硬件故障连续不断地影响某一类型或多类型的用户服务； 核心设备诊断故障（每天二次或更多）； 告警模块退出服务； 四级故障 深圳市公交车电子监控项目解决方案 13 软件或硬件故障仅断续的影响某一类用户的服务； 外围设备诊断故障； 服务分析：记录文件、操作测量、维护程序、网络管理不准确； 测试设备故障。 监控系统设备 故障解决方案及时间 一级故障： 由设备提供商 驻当地用户服务处的工程师 于 2 小时内 到达故障现场处理故障。如果不能够定位故障原因，排除故障，那么将及时与技术支援中心的工程 师联系，并提供全面的设备运行报告和故障现象，在 4 小时内恢复系统， 12 小时内解决故障。 二级故障： 由设备提供商 驻当地用户服务处的工程师 于 4 小时内 到达故障现场处理故障。如果不能够定位故障原因，排除故障，那么将与技术支援中心的工程师联系，并提供全面的设备运行报告和故障现象，在 8 小时内恢复， 24 小时内解决故障。 三级故障： 由设备提供商驻 当地用户服务处解决。当地用户服务处的工程师可以确定故障原因，找出损坏的部件并替换掉，使设备正常运行。此事件将被记录在案。如果驻当地用户服务处的工程师不能够定位故障原因，排除故障， 那么将与技术支援中心的工程师联系，并提供全面的设备运行报告和故障现象，以利于尽快分析问题，拿出解决方案。除了通过电话交换信息外，还可以通过更为先进的通讯手段进行远端数据采集、远端诊断。若仍不能解决， 设备提供商派工程师到达最终用户 现场，在 12 小时内恢复，在到达现场 36 小时内解决。 四级故障： 由 设备提供商 驻当地用户服务处在 48 小时内解决。当地用户服务处的工程师可以确定故障原因，找出损坏的部件并替换掉，使设备正常运行。此事件将被记录在案。 4.6 日常维护计划 1. 测试周期：每月一次，每月 1 日前后开始测试， 5 日前（节 假日提前）完成， 深圳市公交车电子监控项目解决方案 14 每月总计测试时间不得少于 10 小时； 2. 测试路线：特区内罗湖、福田、南山、盐田区的所有主干道路；特区外宝安、龙岗城区内的所有主要道路；特区内外各镇之间的所有道路；到机场的道路，测试车的行驶速度在闹市区保持正常速度，在一般市区保持 30-50 公里 /小时左右； 3. 测试时间：特区内罗湖、福田、南山三个区域的测试时间为：周一至周五上午 9:30 12:30，下午 3:00 7:00，其它时段不能测试；特区内其它区域和特区外宝安等区域的测试时间不限； 4. 测试数据：所有原始测试数据和后台转换数据（ MAPINFO 格式） 存档半年 (可刻录为光盘 )； 5. 每月的测试原始文件按月分类存档；每个测试软件按照不同道路保存相应的测试文件，同一条道路不同格式的测试文件包含的测试路段尽量相同； 6. 按照每条道路记录、保存测试数据，测试记录文件名取名规则为：yymmabcd_AAA，其中， yy 代表年份， mm 代表月份 ,abcd 为测试道路名称缩写 ,AAA 代表测试类型，如 ftp、 wap； 7. 现场测试时必须随时及时记录发生问题的详细路段及使用的小区，填写测试文件说明表格； 8. 详细分析所有掉线事件，列出掉线发生的地点、涉及小区、掉线前的小区切换顺序、掉线前依次 使用过的三个小区及所有邻区的相关参数、掉话后依次使用的三个小区及邻区的相关参数、掉话前后的信令流程等信息，提出相应的解决方案，每月 15 日前提供； 9. 详细分析所有接不通事件，列出接不通事件发生的地点、总呼叫详细清单及接不通原因（相关代码）、涉及小区及相应的邻区、接不通前后的信令流程等信息，对接不通原因进行分类统计，并提出相应的解决方案，每月 15 日前提供； 10. 分析位置更新失败事件，列出失败发生的地点、失败次数、涉及的小区及对应邻区、失败前后依次使用过的小区、切换失败前后的信令流程等信息，提出解决方案，每月 15 日前提 供； 11. 分析切换频繁事件，列出切换频繁事件发生的地点、涉及的小区及相应的邻 深圳市公交车电子监控项目解决方案 15 区，提出解决方案，每月 15 日前提供； 12. 对比本月与上月的掉话、拥塞、切换失败等异常事件，列出本月及上月各类异常事件发生的地点、涉及小区及邻区、掉话前后切换顺序、拥塞原因代码等信息，分析其中的规律，提出解决建议，每月 15 日前提供； 13. 移动网络覆盖率的本月、上月对比（包括城区总体比较和各条道路分别比较），分析变化的原因，每月 15 日前提供；