本地监测系统范文

本地监测系统范文（精选4篇）

本地监测系统 第1篇

伴随电信行业重组方案的确定, 通信市场竞争日趋激烈, 特别是全业务捆绑销售将是未来市场竞争的重要手段。尤其对于新移动旗下独立运作发展固网、数据业务的铁通公司, 一方面受网络覆盖不足、制约业务发展, 另一方面传统的PSTN网络的封闭性又极大限制了增值业务的开发和推广, 同时话务量被移动等异质分流的速度也逐渐加快, 按传统的方式去发展固网、数据业务业务已不可能。如何使用新技术拓宽建网思路、寻求新的业务增长点, 形成与移动业务结合的全业务竞争优势成为铁通固网业务谋求科学、可持续发展所面临的新课题。因此, 要逐步实现战略融合, 从传统的电信运营商向全业务综合信息服务提供商转, 业务创新和技术转型都需要网络支撑, 基于IP承载的、分布式开放的软交换系统作为向下一代网络演进的关键技术之一, 不仅可以降低网络建设成本, Parlay第三方开发接口也使新业务、增值业务的迅速开发和广泛应用成为可能, 通过软交换系统逐步提供多网络、多终端的业务融合, 为实现全业务运营提供强有力技术支撑应该作为我们铁通下一步的重点方向, 可以预见软交换应用将在网络转型中担当重要角色, 并在通信运营商和设备供应商的积极推动下如火如荼的展开。

2、软交换技术商用运营模式

2.1 长途网应用

经过试商用, 软交换技术和设备在长途分流或备份应用上基本成熟, 采用软交换系统对现有PSTN长途网实施优化并逐步向NGN演进, 充分体现了软交换在长途层组网和跨域经营的优势, 而且长途网的软交换应用对现有的运行维护体系压力不大。

2.2 本地网应用

需要看到的是:对于缺乏PSTN资源的铁通, 利用软交换其优先性以及快速、低成本的优势, 结合移动公司完善的光缆资源, 容易形成与同质运营商的竞争优势, 争取语音、数据客户, 获取收入;同时弥补移动大客户不能提供语音、数据业务的不足, 是最切合实际的软交换商用运营模式。目前本地网商用解决方案主要有以下几:, 一是宽窄带综合接入, 即通过大容量接入网关, 对用户提供宽带ADSL和普通电话业务。二是利用广电HFC接入资源, 向用户提供数据+语音+增值业务一揽子解决方案。三是针对LAN接入小区, 通过五类线+PC+IP PHONE或五类线+IAD+PC+普通电话等灵活接入方式解决语音及数据业务, 从目前市场普遍需求来看, 这种方式应用前景比较广, 尤其对竞争地区, 通过综合布线实现光纤到楼、五类线到户, 为用户提供高质量、上下行对称大带宽数据业务, 可以快速形成竞争比较优势。

3、软交换本地网商用需要考虑的问题

3.1 业务开放与网络标准化要求

软交换本地网商用要立足现有业务, 语音业务是切入点, 所以首先要实现语音业务从PSTN到软交换的平滑过渡, 软交换系统必须能够很好的实现与在线网络的无缝对接, PSTN网、智能网、信令网等多不为独家设备供应商组网, 由于各厂家对协议的理解不同, 可能产生与软交换网络互通的障碍, 所以要求软交换业务访问网络资源的接口要标准化, 以利于不同厂家设备在线互联;软交换系统提供的业务开发接口可以方便实现第三方业务的开发和应用, 但也需要软交换系统能够统一业务开发接口的标准, 使第三方开发业务可以应用于不同厂家的软交换系统;此外、业务规范也需要标准化, 比如传真业务、广域虚拟网业务等, 不论采取AG方式接入还是IAD方式接入, 都要保证不同厂家产品的良好兼容, 方便运营商的维护和管理。有效解决以上几个标准, 才能保证PSTN具有的基本业务方便移植到软交换系统, 在此基础上通过提供开放的增值业务平台, 快速响应企业转型的需要。

3.2 软交换与业务支撑系统的对接

商用软交换系统发展语音业务要充分考虑到与现有业务支撑系统的对接, 软交换系统可以实现立即计费, 在商用前要解决通过提供接口实现与业务支撑系统对接, 按照计费结算周期, 实现用户的帐务处理, 根据用户信誉度和欠费情况, 通过软交换系统向用户播放话费催缴通知, 根据约定时限进行自动停机, 在交费后的承诺时限内自动开机, 在此基础上逐步实现如来电显示等新业务自动登记与取消功能, 保证用户业务变更的及时准确, 减轻操作人员的手工劳动强度。

3.3 软交换与网络资源管理系统的对接

软交换基于IP承载网, 在本地网实际应用中, 接入层设备如IAD需要占用一定量的公、私网IP地址资源, 这些资源要进行合理的规划和分配, 确保统一管理, 根据光纤+LAN组网方式, 我们一般仅先把光纤布放到写字楼或住宅楼, 或者再进一步把五类线布放到楼道, 根据用户的装机需要安装楼宇交换机和楼道多口IAD, 这样虽然减轻建设初期投资压力, 也保证了设备的合理配置和利用率;但同时也为网络资源管理增加了难度, 大量的传输资源, 设备资源需要随时变更使用情况, 为了保证资源管理系统的动态更新, 以及网络资源的合理规划, 软交换系统要能够提供与网络资源管理系统衔接的功能, 减轻网络资源管理人员工作强度, 提高网络资源录入的及时性和准确性以及网络扩容的前瞻性。

3.4 业务受理流程的新特点

根据本地网组网特点, 除驻地网接入资源预先分配外, 其他接入方式都是动态的, 即在营业受理业务人员能够准确掌握软交换网络覆盖范围同时, 能够根据用户分布, 迅速准确判断接入资源是否到位, 比如:用户装机位置是否已经被IAD覆盖?是否在楼宇交换机理论接入范围内?根据实际情况承诺用户装机时限、或进行预受理, 避免由于资源分布配置不清, 影响用户开通引发不必要投诉。因此, 网络建设和资源管理部门要出具资源覆盖区域图, 并在营业场所公示或由营业人员准确掌握;同时由于在网络覆盖范围内, 设备资源是动态的, 所以还要做到设备安装配置信息同步向营业提供, 目的都是保证受理业务准确。

3.5 用户数据管理的新要求

软交换系统用户配置相对于PSTN用户配线配号要更加繁琐。首先操作人员要从业务受理系统流转的装机工单提取装机地址等信息, 根据装机地址查询是否具备设备资源, 如果具备则可以直接在软交换网管系统配置用户, 同时将工单进行下一环节的流转, 即进入外线装机, 如果设备资源不具备, 则要将工单做待装处理, 然后将装机信息交由资源管理人员配置设备信息, 设备配置完毕后由具体施工人员进行安装和测试, 并把结果反馈, 此时即可以按设备资源具备来处理。可以看出, 工单的流转是有条件的, 条件的判断需要查询相关设备配置信息, 所以既要保证设备资源配置的及时更新, 又要准确核对工单的收转情况, 避免工单处理遗漏, 人为造成装机超时。由于具体资源配置人员是不固定的, 因此还要确保每名操作人员掌握信息的一致性, 所以信息共享和一致性成为必须, 具体情况可以根据组网和接入方式, 考虑开发资源管控系统通过网络实现信息共享和变更一致性。

3.6 网管系统的实际需求

目前软交换设备厂家通常都能够提供对软交换网络设备 (比如软交换、媒体网关等) 的管理, 但是很难提供网络级的管理, 即对整个网络的安全管理、对网络的资源管理。部分厂家能够对主要设备实现分权分域管理, 但是功能比较弱, 同时软交换增值业务的网管需要完善, 接入层设备如IAD也需要提供网管系统, 解决由于配置信息查询、障碍处理增加障碍历时, 以及及时根据告警信息主动发现问题, 争取时间和主动。

3.7 对装机维护人员素质的要求

PSTN用户装机包括语音和数据, 对装机人员的素质要求不是很高, 尤其对于语音用户, 从MDF架到交接箱到用户端, 基本可以通过判断物理链路通断, 是否混线等即可处理装机障碍;但IAD+语音则需要装机人员具备数据通讯知识基础, 也许从IAD端可以实现注册和登录, 但仍然可能出现语音不通、单通、掉线等障碍, 一般的处理手段应该是通过抓取数据包进行分析、判断, 当然数据链路在临界长度或超常也会干扰障碍的判断, 障碍处理历时也相应增加, 由于IAD掉电导致无法远程登录, 也会干扰障碍的判断, 而因为掉电致使语音不通, 对于习惯于PSTN网的用户是无法认同的, 所以一方面需要我们的维护和装机人员熟悉软件换网络的特点, 另一方面需要设备供应商能够及时做好理论及现场实际能力的培训工作, 迅速完成运行维护人员的转型。

3.8 网络安全的要求

一方面基于IP承载网的软交换系统、为获得端到端的服务质量保证, Qo S问题凸现出来, 现在的数据网没有严格的Qo S概念和机制, 软交换系统需要能够保证运营的Qo S机制, 也就是要求IP承载网要具备业务质量保证和业务质量控制等能力。另一方面软交换网络接入层节点如楼宇交换机、户用交换机、IAD等设备暴露在用户侧, 非常容易受到破坏和攻击, 尤其交换机的商用价值也会引起不法分子注意, 当然还要考虑节点被非法用户接入等, 所以端口绑定和同一端口语音数据信息分离控制等都是要在实际应用中予以考虑的。

4、结束语

如何删除系统中多余的本地连接 第2篇

Step1:在运行框输入regedit.exe，打开注册表编辑器，如果是Windows Vista或Windows 7，可能需要获得管理员账户的授权。

ep2：依次跳转到hkey_local_MachineSYstemCUrrentControlSetCOntrolNetwork{4D36E972-E325-11CEBFC1-08002BE10318}，在这里保存了关于本地连接的信息，

hkey_local_machineSYstemCurrentControlSetControlNetwork{4D36E972-E325-11CEBFC1-08002BE10318}{FC85D7BD-735F-492B-A03B-C31F364EF84B}Connection就是本地连接，而hkey_local_machineSYstemCurrentCOntrolSetControlNetwork{4D36E972-E325-11CEBFC1-08002BE10318}{FEF499AF-6AA7-4A0C-9049-8934F5C0322F}Connection所对应的自然就是本地连接2.

tp3：将本地连接2对应的整个子键值直接删除即可，即删除hkey_local_machineSYstemCurrentControlSetControlNetwork{4D36E972-E325-11CEBFC1-08002BE10318}{FEF499AF-6AA7-4A0C-9049-8934F5C0322F，考虑到系统的稳定性，建立在删除之前执行导出操作。

注销或重启系统，系统中多余的地本连接2即可被删除。

★ Win7删除系统文件速度太慢

★ 删除Win7系统中多余的输入法的教程

★ Win7系统如何批量删除C盘log日志文件？

★ 强行删除系统中顽固文件的十二招技巧

★ 删除高中作文

★ 永远删除的记忆诗歌

★ 永远删除的记忆诗歌

★ 记忆删除以后作文

★ 金山毒霸怎么彻底删除文件

电信本地网集中告警系统的研究 第3篇

随着电信市场引入竞争机制,各运营商之间传统的、原有的网络优势已经逐步被分割,在市场竞争加剧的同时,通信技术和计算机技术的不断突破,大容量、低成本的光纤通信技术也不断地在吞食着各电信运营商原有的网络资源优势,不规范的市场竞争与不对称管制以及资费的大幅下调,电信运营商具有含金量的优势项目正在大幅下降,直接后果就是所有电信运营商面临ARPU下降、业务竞争加剧、客户消费要求多元化等诸多挑战。正是在这样的背景下,提出了建设电信本地网集中告警系统的研究。

2. 告警相关性技术

2.1 基本定义

在网络管理领域,故障被定义为产生功能异常的原因,产生告警事件的原因。告警是由在特定事件发生时被管对象发出的通报构成的一种事件报告,用于传递告警信息。但它只是表明可能有故障发生,并不一定有故障发生。资源的被管对象可以发出告警事件作为对系统当前发生异常的响应。告警事件包含被管对象状态异常的信息。当网络中出现故障时,会引发一系列告警,但并不是所有告警都表明故障原因,所以需要对网络中发生的告警事件进行相关性分析,确定产生故障的根本原因。

2.2 基本问题

实际上,许多告警事件并没有包含产生故障原因的信息。因为,在网络中如果有一个故障产生,经常会导致接收到多个告警事件。在此种情况下,收到的告警报告中含有很多冗余信息,准确分离和定位产生故障的原因非常困难。具体有以下几种情况:

(1)由于一个故障,导致设备产生多个告警;单独的一个告警可能己经被多个网络部件检测到,每一个部件都发出告警事件;己知部件的故障可能影响到其它几个部件,产生故障扩散,即故障的影响会沿着网络设备扩散,如路由器和主机连接关系所形成的路径。

(2)故障本身间歇性发作,这意味着每当故障发生时便发送告警事件。

(3)当设备中某一个部件发生故障时,每次由设备部件提供的服务被激活时都可能发生告警事件。

(4)告警事件中可能包括许多无意义信息、冗余信息;多个故障同时发生,则此时告警事件有许多潜在重叠,产生故障的问题并不总可以观察到,许多产生故障的根本性问题可能无法直接观察到。

(5)通常都假设可以获得网络设备发出的全部告警信息,但某种特殊情况下,一些信息是不可能得到的,例如传输的中断就无法获得告警信息;在大型、异构通信网络中没有统一的网络事件,这为告警事件的分析和比较带来无法克服的困难。

(6)可能存在多个反映故障的告警事件同时发生,例如网络的连接出现故障时,连接两端都会发出告警事件;由于通信网络是一个不断发展变化的网络如配置参数发生变化和网络拓扑结构改动都会引起告警相关性规则出现变化。

3. 系统架构设计

3.1 网络规划

本次接入的专业网络主要包括传输、交换、动力、数据、小灵通等。目前各个专业之间彼此是互相独立的,根据本地网集中告警系统的接入需要,各专业网络都将与系统网络进行连通。所以,本次项目的网络建设需要从以下几个方面来考虑:

(1)各系统网络的安全性。原有的各个系统之间彼此是相互独立的,增加新的系统后,仍然要确保各个系统原有的独立性,并且确保数据不会被随意访问。

(2)数据的安全性。增加新的系统后,由于网络是全部打通的,要考虑增加相应的硬件和软件,做好病毒的预防和控制。

(3)通过防火墙,可以控制广播包的传播,有效的控制病毒的扩散。

由于老的系统有些地址是重叠的,通过防火墙的地址转换,可以解决防火墙的地址冲突问题。

3.2 硬件平台结构

系统对于全网各专业的告警整合到一个平台上进行集中处理、显示;在本系统中需要相应的配置采集服务器设备对各个专业网管的告警进行信息采集。对于综合平台系统的网络建设应做到网络结构清晰、易于管理、减少投资,便于网络系统的维护,对关键的网络核心交换机连接采用主备方式,以保证数据的传输的可靠性。

3.3 系统层次结构

系统以沟通(Communication)、协作(Collaboration)、协调(Coordination)、分析(Construe)这四“C”为目标,以自主开发的中间件平台为核心,采用多层架构体系,实现界面表现与业务逻辑分离,采集系统独立的构件方式,通过CORBA中间件作为数据总线,连接所有的应用服务程序,并提供安全可靠的数据传输通道,保障实施数据的上送显示。系统的层次结构图如图1所示:

4. 系统的数据库设计

数据库设计是系统设计中非常重要的环节,数据是一切系统设计的基础。数据库设计就像高楼大厦的根基一样,如果设计不合理、不完善,将在系统开发、甚至后期的系统维护、功能变更和功能扩充时,引起较多问题,严重时甚至要进行重新设计,重做大量已完成的工作。集中告警系统数据繁杂,重复性很大,数据库使用率高,需要一种能被现行的管理系统所接受、易于维护、效率较高的数据管理方法。数据库设计要建立一个结构分明、逻辑体系严谨、相对独立的数据库体系。

(1)基本告警信息数据结构

基本告警信息数据结构用于在进行告警预处理访问原始告普数据库时存放告替记录,以便于进行告普信息整理和字段提取。告警基本信息结构为:

(2)连接上下文数据结构

采用C/S结构的系统,服务器要同时和多个客户机建立连接并交互数据。为了便于同时管理多个连接套接字,并和客户机进行高效的数据交互,可以为每个连接建立一个客户连接上下文的结构,用于标识和服务器通信的远程客户机。该数据结构含有和对应远程客户机通信的所有信息,包括套接字句柄、连接的远程地址、连接状态、接收/发送缓冲区等。

5. 告警采集接口设计

集中告警系统和其它外部系统共同协作完成对业务保障的要求,除了和专业集中网管系统/厂商网管系统/网元的接口互连外,还和综合网络资源管理系统、前端系统、用户网管、知识管理系统、综合保障(故障单子系统)、具有重大事件公示功能的系统以及其它系统交互。在告警接口采集方面,主要采用了数据库、CORBA、ASCII、SYSLOG及SNMP方式。

(1)数据库接口方式

数据库接口方式主要是通过分析厂家网管数据库结构,在相关的告警表或历史告警表上创建触发器,并创建告警数据临时存放表,当厂家网管数据库中有数据入库或数据发生变化时,会将新的数据或变化的数据反应到临时告警数据存放表中,采集机会定时(定时时间可以设置,一般情况下设置为3秒)向厂家网管数据库中的临时告警存放表中取到数据,并转发给中心服务器数据库,当插入中心服务器成功后,会清除临时告警存放表中相应的数据。

(2)Corba接口方式

Corba方式主要是利用网管服务器提供的Corba服务,接入步骤如下:调通网络,使采集机可以和网管机网络连通;在采集机编译nokia提供的idl接口文件;然后根据接口文件做适配器联接网管取得告警和配置信息。最后一步需要局方提供网管的用户和密码,要通过corba接口联接网管需要用户和密码的验证。

(3)ASCII接口方式

这种方式主要利用被采集方提供的Socket服务来取得需要的数据然后进行适配。格式化后转发至中心服务器数据库中。接入步骤如下:调通网络,使我方采集机可以和网管提供的代理服务器建立连接;按照网管服务中心提供的接口文件,建立到网管服务中心代理服务器的socket连接;程序通过读取网管服务中心代理服务器的告警信息分析告警数据。

(4)SYSLOG接口方式

这种方式是由用户将网管数据转发到指定的采集机上,采集机被动接受数据,然后再发送到中心服务器上入库。接入步骤如下:调通网络,使采集机可以和网管机(whatsup)网络连通;设置whatsup使whatsup接收到的告警转发到采集机上;启动采集程序进行采集。这个接入的前两步由用户完成,采集机甚至可以不知道whatsup网管机的地址,只在自采集机上启动接收器,完全是被动运行,所以不会对网管及网络有任何影响。

(5)SNMP接口方式

SNMP接口是采集方与被采集对象都遵守相同的格式来接收和发送数据。接入步骤如下:调通网络,采集机可以和要管理的路由器联通;由用户设置给采集机对路由器进行snmp轮询的读权限;启动采集程序对路由器按rfc1213(国际数据标准mib)标准进行数据的采集。取到的数据包括数据链路层的标准信息,包括单板和端口速率等信息。由于这种方式是采集机只有读权限,不会对路由器造成影响,也不会更改路由器的配置。

6. 小结

本文分析了集中告警系统的总体目标,提出了系统的总体架构。在此基础上,介绍了告警系统的数据结构,重点对告警采集接口设计进行了讨论。

参考文献

[1]张有才.美国、加拿大电信见闻与感想[J].世界电信.1997,10;21-24.

本地监测系统 第4篇

本着开拓、创新的精神, 苏州分公司拟在南京大后台管理系统前提下, 在苏州新建一个本地内容注入管理平台, 做到本地注入、本地审核、本地定价、本地管理, 也力求为地市级互动电视发展开拓新的思路。

1平台定位

1.1满足本地互动电视业务运营需要

包括从媒资注入、上片下片等日常管理操作功能到互动业务运营需要的各种信息统计及账目处理再到终端用户通过机顶盒终端看到的本地互动电视内容的展示。

1.提供本地互动电视业务展现

提供成熟的用户端互动电视业务展现系统, 与互动电视应用系统存在着成熟的对接接口, 保证用户界面和应用系统之间的完美结合。互动电视业务展现系统同时需要与省网的互动电视展现系统完成对接, 保证本地业务的可用性。

2.提供本地互动电视业务运营管理能力

提供成熟的互动电视应用系统来完成本地媒资文件的注入、VPG信息管理、区域及用户组管理、上片下片及审核管理、定价管理等本地进行互动电视业务运营的日常操作管理功能。

3.提供本地互动电视内容定价管理

提供进行本地媒资的自主定价, 并能够完成本地用户针对本地媒资的认证、鉴权和购买的完全控制, 形成独立的CDR信息, 在本地进行相应账目的处理, 并要求能与省网账目处理系统完成功能对接。

1.2与省网系统完美结合

作为江苏有线的地市级分公司, 苏州有线在追求更好地开展好互动电视业务的同时, 需要本地自营的互动电视系统与省网系统的完美对接。在利用省网的现有资源平台的基础上, 通过建立相对灵活的具有本地运营能力的地市级应用系统丰富广电系统的整体运营模式, 探索出适应未来广电有线网络发展的新道路。

1.与现有系统完美结合

在实现和省网系统的对接和配合的前提下, 支持本地运营的各种功能。

2.与省网业务发展规划一致

本次方案中各个系统需要和省网系统融为一体, 在进行本地运营的同时不变更省网系统的主要业务流程和运营策略, 并保证在省网进行全省范围内的业务变更和新业务上线时可以顺利进行。

1.3技术领先的内容平台

系统采用可快速灵活扩展的平台架构。因为业务需求的不确定性, 业务量可能爆发性增长, 系统支持横向扩展, 投资可按需调整, 提高成本效益, 达到有线运营商级的高可用性及高可靠性。总体而言, 能以较低的成本, 达到高水平的客户体验。

2建设方案介绍

2.1总体架构

本次苏州本地的互动电视新系统的整体架构如图1所示, 其中苏州本地需要建设AMS系统、APP系统及Portal系统和增值业务管理系统, 如图1中橙色部分所示, 本次方案中不包括负责内容制作的MAM系统, 以后可以视运营需要, 进行添加。同时, 我们复用省网中M3P系统、AMS系统、BOSS系统、BO与VS系统及省网VOD Portal系统及覆盖本地的IPQAM设备和本地的BOSS系统。

苏州本地新建设的4个系统中, AMS系统负责完成本地媒资的注入及管理工作, APP系统完成本地互动电视的业务运营及计费, Portal系统完成本地视频点播的页面展现, 增值业务管理系统负责用户鉴权和记录本地用户使用本地互动业务时的用户使用记录作为BOSS系统计费的基础, 同时增值业务管理系统完成多业务的管理与支撑。

省网M3P系统增加分发策略处理功能以支持苏州本地媒资文件注入省网统一的视频服务器当中。

省网AMS系统提供在苏州媒资文件的注入过程中的文件缓存的一个过程。

省网的BO系统、视频服务器及覆盖本地的IPQAM设备共同提供了苏州本地用户使用视频点播业务时为用户进行视频推流的功能。

省网的Portal系统需要完成苏州本地portal系统的导航工作。

2.2系统功能

本次方案中提供了苏州本地能够进行本地自主运营互动电视视频点播业务的整体功能, 主要由新建设的AMS系统、APP与Portal系统共同完成的。同时支持业务快速开展及上线除了复用现有系统外, 也会要求现有系统做某些功能上的增强, 下面将就几个方面对新系统提供的主要功能进行描述。

2.2.1本地资产注入

苏州本地进行本地媒资资产向中心的视频服务器注入的功能, 主要由本地AMS系统、M3P系统及省网AMS系统及VS系统完成。

目前省网统一注入节目的流程如图2所示。

基本的注入流程说明如下:

第一步:大洋的MAM系统向南京M3P系统请求进行媒资注入;

第二步:南京M3P系统向南京的AMS系统传递注入请求;

第三步:南京AMS系统从大洋的MAM系统通过PULL方式将媒资文件下载到AMS系统中;

第四步:南京M3P系统根据媒资分发的策略设置通知南京的BO系统进行媒资的注入或同时通知昆明的M3P系统进行资产同步, 而后南京与昆明两地的节目注入及发布扩成采用异步方式完成。南京方面, MOTO BMI采用pull方式从南京的AMS系统中下载媒资文件并注入到视频服务器中。昆明方面, 昆明M3P系统通知昆明AMS系统从南京AMS系统中采用pull方式下载相应的媒资文件。然后昆明AMS系统通知昆明的BO系统向视频服务器进行注入;

第五步:南京方面, 在MOTO BMI注入完成后, 通知南京M3P, M3P根据媒资分发策略向相应的互动电视APP或酒店互动APP进行资产的发布。昆明方面, 在昆明BO完成了资产的注入之后, 通知昆明的互动电视APP系统进行资产发布。

在苏州本地新系统建立完成之后, 我们苏州本地的操作员将本地的媒资资产通过本地AMS系统完成必要的转码处理后, 通知省网的M3P进行节目注入, 省网的M3P系统通过升级增加苏州媒资文件的识别和苏州媒资分发策略的设定功能, 通知省网的BO完成资产注入后通知苏州本地的APP完成资产的发布。

具体的资产注入流程如图3所示。

具体的注入流程说明如下:

第一步:苏州AMS通过ISA接口向南京M3P发起注入请求;

第二步:南京M3P向南京AMS发出注入请求;

第三步:南京AMS通过Pull方式从苏州AMS系统下载媒资文件;

第四步:南京M3P通知MOTO BMI进行注入, MOTO BMI到南京AMS系统采用Pull方式获取媒资文件并完成向视频服务器的注入;

第五步:南京M3P根据媒资分发策略的设置完成资产元数据分发到本地APP、本地酒店APP或苏州APP完成预定的资产发布过程。

2.2.2本地上片及审核

苏州本地互动新系统的建设实现了苏州本地互动视频点播日常运营的所有功能, 图4以典型的上片及审核功能为例来说明苏州本地的日常运营操作是如何完成的。具体的日常运营操作中的上片及审核发布流程如图4所示。在完成本地的资产注入以后, 省网M3P系统通知苏州APP系统资产元数据进行发布, 苏州本地的操作员在APP系统中完成影片的定价后, 做上片的申请操作。根据预设的上片审核策略, 由审核人员在APP系统中完成本次上片的审核工作, 审核完成后, 苏州APP系统自动向苏州的Portal系统进行节目的发布操作。

苏州本地通过新建APP及Portal系统从而完成了“本地上片、本地审核、本地发布”, 将互动视频点播的日常运营工作全部做到了本地完成, 增强了苏州本地开展互动视频点播业务的灵活性, 实现了自主运营策略的制定。

2.2.3苏州本地定价管理

本方案中提供的系统提供互动电视定价管理包括查询of fer信息、修改of fer价格类型、影片定价和反定价等功能。

BOSS系统作为广电基本业务运营支撑系统, 在日常运营中涉及到运营策略及产品定价和账目处理等基础运营工作。互动电视APP系统作为互动电视运营的工具系统主要负责具体互动电视业务内容的定价管理。

从BOSS系统定义价格计划, 到互动电视APP系统为具体的视频内容定价的关系如图5所示。

BOSS系统为某一组的视频内容定义一个价格计划, 如图5中OFFER信息, 将每部电影定义为一个产品 (当然可以把电影按不同的标准进行分类并分别设定价格计划) , 并为该产品设定基本价格。通过接口传递给VOD APP系统, 互动电视操作员在APP系统中提供的操作界面中为某个电影 (如《让子弹飞》) 设定为某个of fer的ID, 从而建立起具体的影片和价格之间的关系。

如果广电运营商的市场部门想策划某项营销活动, 只需要在BOSS系统中对产品 (或价格计划) 进行营销品的设定就好。例如, 在春节期间, 用户点播所有的电影均为八折。这个优惠策略就会在BOSS系统中设定在相关的产品之上。

在活动的期限内, 终端机顶盒用户通过Portal展现系统进行某个电影的点播时, 展现系统的逻辑关系如图6所示。当用户在使用视频点播业务在具体影片介绍页面时, 能够查看到影片的基本价格, 当用户选择点播后, APP系统会实时向BOSS系统进行of fer询价, BOSS系统根据各种相关的优惠策略计算出最终的结算价格, 并通过APP系统和Portal系统呈现给最终用户。

2.2.4用户访问本地业务

苏州本地新建Portal系统作为本地互动视频点播业务的展现系统, 通过与省网Portal系统的对接来实现省网Portal到苏州本地Portal的链接跳转, 在不改变业务流程和用户体验的前提下, 保证了苏州本地业务的顺利开展。

用户通过访问Portal来使用互动电视业务的示意图如图7所示。苏州本地的广电用户通过机顶盒访问互动电视业务时, 在保证省网业务的业务流程不变的前提下, 用户首先访问省网的Portal系统, 通过省网的APP系统完成用户的登陆认证, 根据用户所在的区域和用户组, 用户看到的首页是省网Portal的苏州页面。

通过在苏州页面中添加苏州本地Portal的导航链接, 保证了苏州本地用户可以很方便地访问苏州本地视频点播内容的同时, 又不会对其他地市用户访问省网互动内容造成影响。

在用户通过链接访问苏州本地Portal的时候, 通过苏州APP和苏州BOSS的AAA模块完成用户在苏州本地的用户认证、购买等操作, 保证了本地互动内容运营的本地计费的实现。

当用户退出苏州本地Portal时, 通过Portal上的页面跳转可以帮助用户到达省网Portal页面或直播节目界面。

2.2.5用户本地内容的点播实现

苏州本地用户在苏州Portal页面上访问本地提供的互动内容时, 进行订阅购买并通过省网的推流系统完成视频点播的过程是典型的用户业务使用场景。下面就该典型业务场景进行示例说明。

如图8所示, 用户点播本地视频内容的典型流程说明。

第一步:用户访问本地Portal页面;

第二步:通过在本地Portal页面上浏览进行包括产品订阅购买或点播等业务使用操作。其中产品订购后通过流程3来完成, 点播通过流程4完成;

第三步:Portal通过APP向苏州本地BOSS系统进行产品的订购或购买, 最终在BOSS系统的AAA模块中形成用户和产品的订购关系;

第四步:用户在Portal页面上进行视频内容的点播操作, APP系统处理点播请求, 为保证用户体验, 特采用BO推流及用户鉴权同步完成。一方面执行流程4向省网BO系统请求建流, 一方面执行流程7向增值业务管理系统请求用户的鉴权;

第五步:省网BO系统调动视频服务器建流并推向边缘节点的IPQAM;

第六步:在完成流程5之后, IPQAM向机顶盒推流;

第七步:在BO推流的同时, 本地的APP系统向增值业务管理系统发送用户鉴权请求;

第八步:增值业务管理系统记录用户点播信息并向苏州BOSS系统请求用户鉴权;

第九步:在预设周期结束后, 增值业务管理系统通过异步定时机制向苏州BOSS系统发送用户的点播记录详单作为BOSS计费的依据。

3现有系统功能变更

除了苏州本地新建的系统之外, 需要对现省互动系统进行升级或功能变更。主要的变更如表1所示。

摘要：随着苏州家庭高清互动升级计划的不断深入, 苏州互动电视用户总量迅速攀升, 迄今已经达到20余万户。目前省公司统一平台、统一内容的运营模式, 已经不适应各地分公司互动业务的蓬勃发展, 省互动平台统一内容的模式更使得各地节目千篇一律, 许多深受当地老百姓喜爱的特色内容无法快速有效的得到展现, 使得有线互动电视受欢迎度无法进一步突破。

关键词：互动电视,本地内容,IPQAM

参考文献