通信业论文范文

引言：寻求写作上的突破？我们特意为您精选了4篇通信业论文范文，希望这些范文能够成为您写作时的参考，帮助您的文章更加丰富和深入。

篇1

在参与了某个通信公司的一套网管系统以及决策支持系统的设计后，我们分析了两者的集成与应用工作，深切地感受到有一个良好的设计策略以及重视所选用的工具是一个关键。这个项目主要是对下属各分站的子网以及有关链路的连通情况进行实时监控、实现报警、路由控制和授权等功能，其关键在于提供一个实时显示情况的地图界面，井将数据汇总和组织，建立起数据仓库以及进一步实施数据挖掘分析，从而能支持企业的决策分析。我作为设计人员之一，着重在本文中讨论控制系统与信息系统集成时的策略。

【正文】

众所周知，通信行业需要有一整套监控通信网络的手段，其工作特点是涉及到的各分站与基站的在地理位置L的分布性，更加需要有在更高一级提供检测不同分站链接情况的手段。一般来讲，由于数据都是海量的，所以，如何将整个网络系统所得的数据及时处理，以便和决策部门的分析相结合，也成为迫切需要解决的重要课题。简言之，分布性、实时性以及数据海量性是解决整个系统设计和集成的核心问题。

首先，让我们来讨论一下“网管监控系统”。由于我参与设计与开发的这个系统并不是位于基层的分站，其定位在将下属各分站的主机通信数据（包括数据流量、链路负荷、通往其他结点即主机的连通情况等）加以收集，所以对于具体通信事务的底层操作要求并不很高。

考虑到上述原因，我们采用了一个地理信息系统开发平台Mapinfo并采用Delphi编程，后台用SQLServer数据库（这是由于考虑到决策所需要用到的是Microsoft公司的OLAPService）。在分析和计划之前，我们先对ITU801标准做了详细的探讨，这只是一个有关子网和链路定义以及分层等描述的标准，在听取了许多分站人员的建议后，将MAPINFO公司提供的一个相关的MAPX的ActiveX控件嵌入到Delphi程序中，利用MAPX中提供的丰富的类以及操作，比如Object、Layer等实现网管界面，井且加入了子网和链路的概念，对属下的分站可以随意地组合成为不同子网，而且实现了放大与缩小的功能，大致可以将整个地区的分站集中在一张地图中，能显示在屏幕上，这时，只是显示出各个分站的概要，小到可以显示出某台主机的机柜、机柜直到插件板（因为这些都要实时监控）。我们采用了分层的方法来实现以上缩放。对于一些静态的数据，如分站，主机的位置等则先用Mapinfo公司提供的一套编制地理信息的工具（MAPX是其提供给编程工具的一个ActiveX控件）做成静态的层次图放置于数据库中。

我们新做成的这套系统通过与各分站的专用线路加以连接，能实时地得到数据，显示于地图上，反映出各站、各子网、各链路的实时状态，并能将控制命令传回分站（如强制链路中断、路由转换等）。

现在，让我们来讨论其中最为关键的问题，即是要将实时控制系统与企业信息系统加以集成，我们的设想和体系结构大体上可以用一张简图表示。

在这个体系结构中，由各分站保留着详细的数据，网管系统则在一定时间间隔内将汇总到的数据作少量统计，抽取其中需要保存的内容放入数据库，如每分钟流量，某分站与其他分站每分钟通信流量，在该分站中某个链路的负荷（这些链路有可能是动态分配的，也可能是固定分站之间的通信链路）。尽管如此，数据仍然是海量的，因此，如果要把这些数据都直接送到各个决策部门，比如送给市场部门是不现实的。所以，我们在数据库的基础上建立了数据仓库，确定了客户、时间、通信量、计费和故障等几个数据仓库的主题，每隔一定时间对数据库中的原始数据进行清理与抽取等预处理工作，建立好数据仓库。这里的预处理包括了许多方面的内容，比如有建立计算时间，但是无计费的（计费值为零）的数据，应视为建立失败的无效数据，需要予以剔除；某些企业租用的是专用线路按月计费，中间的通信因此无计费的一些有关记录也应剔除等。在预处理之后，再利用OLAPService的分析将数据融合与汇总。按照决策部门的需要提供相应数据（比如：市场部门需要每一分站的收益，客户分布情况以及客户费用等）。这些都可以由OLAPService对数据作预先处理，此时处理完的数据在逻辑上是以立方体（CUBE）形式存在的，其占用的存储空间便能显著地降低，如1999年8月有2000万条通讯记录，即使形成作为备份的文本都需要4G空间，经过OLAPService处理后仅需200M左右空间，因此，经处理后的数据主要存放于另外的相关部门的机器中，而不能与主服务器放在一起。

最后，再来讨论由决策人员所使用的系统。由于这些部门并不分散，我们就没有采用OLAPServce的Web方案。采用Delphi编制了访问OLAPService的客户端软件，用了OLAPService提供的、CubeBrowser控件，用相似于网页的界面提供了数据立方体的各种操作，如上钻（观察角度从月转到季度甚至年），切片，旋转等操作。为了便于输出打印数据，还内嵌了Microsoft的Excel数据透视表，可以将在CubeBrowser上所看到的数据转化为Excel的表格形式，或者转换成饼形图、柱形图和曲线图等，比如可以观察每天24小时通信流量的分布曲线图，可以发现在夜间12点以后明显通信流量减少，而决策部门便可制定某些优惠或减价措施吸引更多客户在12点之后使用网络。

另外，在采用OLAPService中的数据挖掘功能时，其中提供的两类算法分别是基于决策树的分类和基于决策树的聚类，市场部门的聚类算法将客户根据费用情况加以聚集，以期发现处于同一消费水平的客户的共同特征，便于制定政策，吸引客户。这方面的努力我们将会进一步持续进行，以保证有足够的海量数据而发现其中的规律。

篇2

在参与了某个通信公司的一套网管系统以及决策支持系统的设计后，我们分析了两者的集成与应用工作，深切地感受到有一个良好的设计策略以及重视所选用的工具是一个关键。这个项目主要是对下属各分站的子网以及有关链路的连通情况进行实时监控、实现报警、路由控制和授权等功能，其关键在于提供一个实时显示情况的地图界面，井将数据汇总和组织，建立起数据仓库以及进一步实施数据挖掘分析，从而能支持企业的决策分析。我作为设计人员之一，着重在本文中讨论控制系统与信息系统集成时的策略。

【正文】

众所周知，通信行业需要有一整套监控通信网络的手段，其工作特点是涉及到的各分站与基站的在地理位置L的分布性，更加需要有在更高一级提供检测不同分站链接情况的手段。一般来讲，由于数据都是海量的，所以，如何将整个网络系统所得的数据及时处理，以便和决策部门的分析相结合，也成为迫切需要解决的重要课题。简言之，分布性、实时性以及数据海量性是解决整个系统设计和集成的核心问题。

首先，让我们来讨论一下“网管监控系统”。由于我参与设计与开发的这个系统并不是位于基层的分站，其定位在将下属各分站的主机通信数据（包括数据流量、链路负荷、通往其他结点即主机的连通情况等）加以收集，所以对于具体通信事务的底层操作要求并不很高。

考虑到上述原因，我们采用了一个地理信息系统开发平台Mapinfo并采用Delphi编程，后台用SQLServer数据库（这是由于考虑到决策所需要用到的是Microsoft公司的OLAPService）。在分析和计划之前，我们先对ITU801标准做了详细的探讨，这只是一个有关子网和链路定义以及分层等描述的标准，在听取了许多分站人员的建议后，将MAPINFO公司提供的一个相关的MAPX的ActiveX控件嵌入到Delphi程序中，利用MAPX中提供的丰富的类以及操作，比如Object、Layer等实现网管界面，井且加入了子网和链路的概念，对属下的分站可以随意地组合成为不同子网，而且实现了放大与缩小的功能，大致可以将整个地区的分站集中在一张地图中，能显示在屏幕上，这时，只是显示出各个分站的概要，小到可以显示出某台主机的机柜、机柜直到插件板（因为这些都要实时监控）。我们采用了分层的方法来实现以上缩放。对于一些静态的数据，如分站，主机的位置等则先用Mapinfo公司提供的一套编制地理信息的工具（MAPX是其提供给编程工具的一个ActiveX控件）做成静态的层次图放置于数据库中。

我们新做成的这套系统通过与各分站的专用线路加以连接，能实时地得到数据，显示于地图上，反映出各站、各子网、各链路的实时状态，并能将控制命令传回分站（如强制链路中断、路由转换等）。

现在，让我们来讨论其中最为关键的问题，即是要将实时控制系统与企业信息系统加以集成，我们的设想和体系结构大体上可以用一张简图表示。

在这个体系结构中，由各分站保留着详细的数据，网管系统则在一定时间间隔内将汇总到的数据作少量统计，抽取其中需要保存的内容放入数据库，如每分钟流量，某分站与其他分站每分钟通信流量，在该分站中某个链路的负荷（这些链路有可能是动态分配的，也可能是固定分站之间的通信链路）。尽管如此，数据仍然是海量的，因此，如果要把这些数据都直接送到各个决策部门，比如送给市场部门是不现实的。所以，我们在数据库的基础上建立了数据仓库，确定了客户、时间、通信量、计费和故障等几个数据仓库的主题，每隔一定时间对数据库中的原始数据进行清理与抽取等预处理工作，建立好数据仓库。这里的预处理包括了许多方面的内容，比如有建立计算时间，但是无计费的（计费值为零）的数据，应视为建立失败的无效数据，需要予以剔除；某些企业租用的是专用线路按月计费，中间的通信因此无计费的一些有关记录也应剔除等。

在预处理之后，再利用OLAPService的分析将数据融合与汇总。按照决策部门的需要提供相应数据（比如：市场部门需要每一分站的收益，客户分布情况以及客户费用等）。这些都可以由OLAPService对数据作预先处理，此时处理完的数据在逻辑上是以立方体（CUBE）形式存在的，其占用的存储空间便能显著地降低，如1999年8月有2000万条通讯记录，即使形成作为备份的文本都需要4G空间，经过OLAPService处理后仅需200M左右空间，因此，经处理后的数据主要存放于另外的相关部门的机器中，而不能与主服务器放在一起。

最后，再来讨论由决策人员所使用的系统。由于这些部门并不分散，我们就没有采用OLAPServce的Web方案。采用Delphi编制了访问OLAPService的客户端软件，用了OLAPService提供的、CubeBrowser控件，用相似于网页的界面提供了数据立方体的各种操作，如上钻（观察角度从月转到季度甚至年），切片，旋转等操作。为了便于输出打印数据，还内嵌了Microsoft的Excel数据透视表，可以将在CubeBrowser上所看到的数据转化为Excel的表格形式，或者转换成饼形图、柱形图和曲线图等，比如可以观察每天24小时通信流量的分布曲线图，可以发现在夜间12点以后明显通信流量减少，而决策部门便可制定某些优惠或减价措施吸引更多客户在12点之后使用网络。

另外，在采用OLAPService中的数据挖掘功能时，其中提供的两类算法分别是基于决策树的分类和基于决策树的聚类，市场部门的聚类算法将客户根据费用情况加以聚集，以期发现处于同一消费水平的客户的共同特征，便于制定政策，吸引客户。这方面的努力我们将会进一步持续进行，以保证有足够的海量数据而发现其中的规律。

篇3

引言

由于历史发展的原因，当前通信电源供电体制基本上是以集中放置、集中供电方式为主，有人值守、故障维修为主。而电源的负载，如传输、交换、数据、移动等专业的维护方式正朝着集中监控、集中维护、少人或无人值守方向发展。通信基站是通信网络系统中的重要组成部分，保证任何情况下的正常供电，是保证通信网络安全运行的重要环节。为此各通信基站内均配备了较先进的电力电源供电系统，包括开关整流设备、免维护蓄电池、油机等。这些设备是保障供电稳定和连续性的重要设备，对这些设备维护的好坏，不仅影响电源系统设备的寿命和故障率，而且直接涉及通信网络的平稳运行。

一、通信电源概述

从远古时代以来，阳光、空气、食物和水一直是人们赖以生存的必需品，而今在科学技术飞跃发展的时代，电也已成为人们的必需品。因为有了电，我们的生活才有了欢乐。正是由于通信系统的安全优质运转，无处不在的通信电源则是坚实的基础和根本保障。实施集中监控管理是网络技术发展的必然趋势，是现代通信网的要求，也是企业减员增效的有效措施。各种电源设备要智能化、标准化，符合开放式通信协议。若电源系统不能输出规定电流，电压超出允许波动范围，杂音电压高于允许值时间并持续10s以上者均判定为系统故障。原交流系统中的电压、频率或波形畸变超出规定范围持续时间大于60s者均判定为故障。为此，要保证通信电源系统的可靠性，有条件的通信部门应尽量从两个不同的地方引入2路市电输入，并设置2路市电电能自动倒换装置；所用设备要选用可靠性高的高频开关整流设备，采用模块化、热插拔式结构以便于更换，并合理配置备份设备。任何新技术、新设备未经充分验证、试运行前均不得进入供电系统。供电方式要大力推广分散供电，使用同一种直流电压的通信设备采用两个以上的独立供电系统，这也是今后通信网络容量和规模不断扩大、各种新业引入的新要求。为了尽量缩短设备的平均故障修复时间，要经常分析运行参数，预测故障发生的时间并及时排除。还要提高技术维护水平，采用集中维护、远程遥信、遥测维护。在实施过程中，三遥点的设置要合理，绝不是越多越好，要以可靠性、实用性为基本原则，宜简勿繁。

二、电源系统使用中应重视的问题

电源系统目前广泛使用高频开关电源系统设备，其智能化程度高，电池采用了免维护蓄电池，这虽给用户带来了许多便利，但在使用过程中还应在多方面引起注意，确保使用安全。

2.1按电源系统的使用要求和功率余量大小来分，在使用中要避免随意增加大功率的额外设备，也不允许在满负载状态下长期运行。工作性质决定了电源系统几乎是在不间断状态下运行的，增加大功率负载或在基本满载状态下工作，都会造成整流模块出故障，严重时将损坏变换器。自备发电机的输出电压、波形、频率和幅度应满足电源系统对输入电压的要求，另外发电机的功率要大于开关电源设备的额定输入功率，否则，将会造成电源系统设备工作异常或损坏。

2.2电池应避免大电流充放电，理论上充电时可以接受大电流，但在实际操作中应尽量避免，否则会造成电池极板膨胀变形，使得极板活性物质脱落，电池内阻增大且温度升高，严重时将造成容量下降，寿命提前终止。在任何情况下都应防止电池短路或深度放电，因为电池的循环寿命和放电深度有关。放电深度越深循环寿命越短。在容量试验或放电检修中，通常放电达到容量的30％－50％就可以了。

2.3铅酸蓄电池的容量和电解液的比重是线性关系，通过测量比重可以了解电池的存储能量情况。阀控式密封蓄电池是贫液电池，且无法进行电解液比重测量，所以如何判定它的好坏，预测贮备容量已成为当今业界的一大难题。用电导仪测电池的内阻是判定蓄电池好坏的一种有参考价值的方法，但尚不能准确测定电池的好坏程度。目前，最可靠的方法还是放电法。在可靠性、经济性、可使用性、维护性等方面综合比较，应选用四冲程油机为原动机发电机组。四冲程油机结构简单，采用多缸均衡做功、增压等一系列成熟技术适合于大容量机组的要求。其噪音小、污染小、性价比高。使用中把机组产生的热量排到室外，保证机组周围环境湿度不超过指标要求。

三、电源系统的维护与检修

当电源系统出现故障时，应先查明原因，分清是负载还是电源系统，是主机还是电池组。虽说开关电源系统主机有故障自检功能，但它对面而不对点，对更换配件很方便，但要维修故障点，仍需做大量的分析、检测工作。另外如自检部分发生故障，显示的故障内容则可能有误。对主机出现击穿、断保险或烧毁器件的故障，一定要查明原因并排除故障后才能重新启动，否则会接连发生相同的故障。再好的设备也有寿命期，也会出现各类故障，但维护工作做得好可以延长寿命并减少故障的发生，不要因为高智能、免维护而忽略了本应进行的维护工作，预防在任何时候都是安全运行的重要保障。高频开关电源设备在正常使用情况下，主机的维护工作量很少，主要是防尘和定期除尘。特别是气候干燥的地区，空气中的灰粒较多，灰尘将在机内沉积，当遇空气潮湿时会引起主机控制紊乱造成主机工作失常，并发生不准确告警。另大量灰尘也会造成器件散热不好。一般每季度应彻底清洁一次。其次就是在除尘时检查各连接件和插接件有无松动和接触不牢的情况。由于整流器对瞬时脉冲干扰不能消除，整流后的电压仍存在干扰脉冲。蓄电池除有存储直流电能的功能外，其等效电容量的大小与蓄能电池容量大小成正比。因此，维护检修蓄电池的工作是非常重要的，虽说蓄电池组目前都采用了免维护电池，但这只是免除了以往的测比、配比、定时添加蒸馏水的工作。但因工作状态对电池的影响并没有改变，不正常工作状态对电池造成的影响没有变，所以蓄电池的工作全部是在浮充状态，在这种情况下至少应每年进行一次放电。放电前应先对电池组进行均衡充电，以达全组电池的均衡。放电过程中如有一只达到放电终止电压时，应停止放电，继续放电须先排除落后电池后再放。核对性放电不是追求放出容量的百分比，而是关注并发现和处理落后电池，经对落后电池处理后再作核对性放电实验。这样可防止事故，以免放电中落后电池恶化为反极电池。平时每组电池至少应有8只电池作标示电池，作为了解全电池组工作情况的参考，对标示电池应定期测量并做好记录。在日常维护中需经常检查的项目有：清洁并检测电池两端电压、温度；连接处有无松动腐蚀现象，检测连接条压降；电池外观是否完好，有无壳变形和渗漏；极柱、安全阀周围是否有酸雾逸出；主机设备是否正常等。免维护电池要做到运行、日常管理周到、细致和规范，保证设备保持良好的运行状况，从而延长使用年限；保证直流母线经常保持合格的电压和电池的放电容量；保证电池运行和人员的安全可靠。这是电池维护的目的，也是电池运行规程中包括的内容和运行规则。当电池组中发现电压反极、压降大、压差大和酸雾泄漏的电池时，应及时采用相应的方法恢复和修复，对不能恢复和修复的电池要换掉。但不能把不同容量、不同性能、不同厂家的电池联在一起，否则可能会对整组电池带来不利影响。对寿命已过期的电池组要及时更换，以免影响到电源系统和设备主机。

篇4

运营商在开展3G业务时,短消息业务占据着最重要的地位。本文将论述短消息系统的互通网络结构,并对互通时遇到的相关问题进行讨论。

短消息业务实现了移动用户之间、移动用户和应用之间的信息传递,用户也可以通过短消息中心查询或预定信息。短消息业务提供终端发起、终端接收的信息服务,必须由MSC或SGSN及HLR配合完成。

不同平台及运营商间短消息的互通原则上都是由短消息网关完成的。短消息网关负责消息转发、协议转换、路由管理、话单输出等,具体包括互联网关和汇接网关的功能,前者用于SMSC和SP之间的交互,后者用于路由信息的管理即与其它平台及运营商的短信系统互通。

与固定网短消息的互通

所谓固定网短消息,就是利用现有的固定电话网,向固定电话用户提供多种信息的服务。

为实现固定网用户和移动网用户之间相互成功发送和接收短消息,可以直接在短消息中心之间互通,也可以经过短消息网关互通,一般情况下为了使网路结构简化,网间结算以及组网方便,大都是经过短消息的互联网关互通。运营商通过网间互联网关的连接以及互联网关与短消息中心之间的连接达到互通的目的,也就是一方的短消息中心在向对方用户发送短消息时,该短消息经双方的互联网关提交给对方短消息中心,由对方短消息中心向自己全网内用户发送。

网络结构

和固定网短消息互通的网络结构如下图所示:

在此方案中,运营商可新建3G移动短信网关,并与其他运营商的固网短信网关相连实现3G移动网短消息和其他运营商固网短消息的互通。

此方案互联点位于3G短信网关和固网短信网关之间(即虚线处),互联点清晰且便于3G短信及固网短信系统各自的计费结算及维护管理。

编号问题

目前,移动用户给移动用户发送点对点短消息的时候,被叫用户的号码(接受短消息用户的号码)就是移动用户的号码。但是,移动网的短消息业务除点对点的短消息以外,还包括了与各个ICP发送的短消息,为此必须给每个ICP分配相应的号码,而这些号码的分配是由移动运营商自行分配的。号码的分配当时并没有考虑移动网的短消息业务还会与固定网的短消息业务互通,因此给ICP所分配的号码是与固定网电话用户的号码类似的号码。据初步统计,已经被占用的长途区号达几百个,包括已经使用的和空余的,同样也占用了一部分本地电话号码。当移动用户向固定用户发送短消息的时候,被叫用户的号码与现有的ICP的号码是重复的,而且这种重复没有规律。因此,在固定网和移动网的短信互通时就需要解决号码的冲突问题。

为了解决这个问题,信息产业部决定在固定号码前面加上一个标识码,即起用一个未使用过的号码“106”。当移动用户给固定用户发送短消息时在被叫用户号码前面加上标识码“106”,号码长度最长可达15位。

第三方短信互联网关

在移动网用户向固定网用户发送短消息的时候,由于从固定网用户编号上无法区分其归属于哪一个运营商,故需经过第三方短信互联网关来完成移动网用户向固定网用户发送短消息时的路由选择工作。

当移动网用户向固定网用户发送短消息时,经过移动网的短消息中心到移动网的互联网关,移动网的互联网关不需要判别该用户是属于哪一个固定网的运营商,把短消息发送给第三方的互联网关,由第三方的互联网关去判别该用户是属于哪一个固定网运营商的用户,随后就可以把短信发送给此固定网运营商的短信互联网关,再经其短消息中心将短消息发送给用户。

在第三方短信互联网关上需要有相应的各本地网的不同运营商的号码分配纪录,且要保持实时更新。

与移动网短消息的互通

可采用3G互联短信网关与其他运营商的移动网短信网关互联的方案,互联短信网关可按照目的地进行接续和计费。互联短信网关之间可采用专线或者INTERNET相连。

由于移动网短信互联互通已经相当成熟,故本文不再赘述。

多媒体消息系统的互联互通

多媒体消息业务(Multi-mediaMessageService)提供了一种非实时基于存储转发机制的多媒体通信方式。它可使多媒体消息在手机、PC/PDA以及email客户端等多种通信终端之间实现互发互收。收发的信息类型包括:文本、图片、音频、email及视频。多媒体消息业务实现了移动用户之间、移动用户和应用之间内容丰富的信息传递,用户也可以通过多媒体消息中心查询或预定信息。多媒体消息作为一种位于IP网络层的增值应用业务,它可连接各种载体(例如:GPRS、CSD及HSCSD等),因此,也是面向3G网络的。多媒体消息业务的实现必须由MMSC、WAPGW和HLR等网元配合完成。此外,多媒体消息业务要使用短消息中心(SMSC)来发送多媒体消息的通知给用户终端。

多媒体消息业务网络结构如下图所示:

多媒体消息中心(MMSC)是整个多媒体消息系统的核心,它主要负责存储并处理进出MMSC的消息,完成在网络上发送由文本、声音、图片及其他媒体格式组成的多媒体消息。多媒体消息中心内部主要分为MMSRelay和MMSServer,互通的功能主要由MMSRelay完成。MMSRelay负责在不同的消息系统之间进行消息传送,它在服务器和用户之间提供一个综合的功能,根据不同的网络综合不同的服务器类型。根据需要,MMSRelay和MMSServer可以合设也可以单独设置。

在多媒体消息业务系统中,MM4接口是多个多媒体消息业务中心之间互联互通的保证。3GPP多媒体消息规范本身对于互联互通就已经定义了MM4接口(在各个多媒体消息业务中心中实现),因此,只要各运营商在3G多媒体消息业务网中遵循3GPP规范设置多媒体消息业务中心,则不必设置多媒体消息网关就能实现多媒体消息的互通。但由于现有移动运营商的多媒体消息系统均未采用3GPP的规范设置,中国移动的“彩信”是采用基于3GPP规范并进行修改的非标准形式,而中国联通的“彩e”则是基于电子邮件的形式,故在与这些运营商的多媒体消息系统互通时,视其采用的多媒体消息系统结构的不同,可通过多媒体消息网关实现运营商之间的多媒体消息的互通。具体的多媒体消息互通网络结构图如下:

在此方案中,当运营商A与其他运营商的标准MMS系统互通时,可以将运营商A的MMSC和运营商B的标准MMS系统直接连接,此时互联点位于运营商A的MMSC和其他运营商标准MMS系统之间。当与运营商B的非标准MMS系统互通时,则需要通过设置MMS网关来进行协议转换,此时互联点位于运营商A的MMS网关和运营商B的非标准MMS系统之间。

即时通信(IMPS)消息系统的互联互通