CN1859198A - 一种检测网元连接状态的方法 - Google Patents
一种检测网元连接状态的方法 Download PDFInfo
- Publication number
- CN1859198A CN1859198A CN 200610033708 CN200610033708A CN1859198A CN 1859198 A CN1859198 A CN 1859198A CN 200610033708 CN200610033708 CN 200610033708 CN 200610033708 A CN200610033708 A CN 200610033708A CN 1859198 A CN1859198 A CN 1859198A
- Authority
- CN
- China
- Prior art keywords
- layer
- med
- state
- connection
- connection status
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种检测网元连接状态的方法,该方法包括以下的步骤:a.由网管的网络适配MED层检测网管与网元NE的物理连接和业务连接;b.当MED层检测到网管与NE物理和/或业务连接断连时,MED层对网管服务层进行置位,网管服务层的NE连接状态变迁为“断连状态”;当MED层检测到网管与NE物理和业务连接均正常时,网管服务层的NE连接状态保持“连接状态”。本发明所述的方法满足了电信网管客户所要求的实时准确了解NE连接状态、接收告警的要求。
Description
技术领域
本发明涉及到网络管理领域,更具体的说,涉及到对电信级网管与其管理的网元之间的连接状态进行检测的方法。
背景技术
电信级网管通常依据功能进行分层,一般都有服务层以及网络适配层。服务层向网管用户提供的一系列服务,包括拓扑管理(TM),配置管理(CM),性能管理(PM),安全管理(SM),故障管理(FM)等多种管理服务。其中,网管服务层提供的拓扑管理(TM)提供网络拓扑界面展示,包括网管所管理网元(网管所管理的设备为网元Network Element NE)的实际网络的TOPO结构、网元连接状态、网元基本属性等;故障管理(FM)负责向用户及时显示网管所管理网元的告警,包括网元自身所产生的告警,以及由网管产生的网元断连告警或恢复告警,对于直接同网管连接的网元来说,其断连告警或恢复告警均由网管负责产生和展现。网络适配层介于服务层与网元之间,根据网元支持的协议向网元发送命令和接收网元响应,与各种网元直接交互,交换协议数据、协调发送至网元处的数据以及来自网元的数据。服务层可调用网络适配层,执行各种网元操作,如与网元建立连接,修改某网元属性等。NE Engine(网元引擎)是网络适配层与实际物理网元交互的网管侧代理对象,它向网管系统其他模块提供与具体网元协议无关的功能接口,将物理网元的协议版本等差异性屏蔽在其内部实现中,NE Engine可与网元直接进行交互,如建立连接、进行登陆等。
网管对网元进行管理的前提是与网元建立网络连接(物理连接),网络连接建立后,网管与网元之间还需建立业务连接,建立业务连接的过程也就是登陆操作的过程:网管向网元发送鉴权请求,网元对网管进行鉴权,如果鉴权成功,则网元即可加入到网管的管理中。网管与网元之间建立上述的两种连接之后,网管用户即可通过网管服务层提供的各种服务,对网元进行各种操作。网元与网管的连接状态在服务层一般指示为两种:网元连接正常时的“连接状态”和网元断连时的“断连状态”。但在服务层所表现出的网元与网管的连接状态事实上是由网管与网元的物理连接状态和业务连接状态的共同决定的:若网元物理连接断连或业务连接异常,则均在网管服务层表现为网元断连;只有网元与网管的物理连接和业务连接状态均为正常时,在网管服务层才表现为网元连接正常。
如上所述,现有技术中在网管服务层表现出的网管与网元的连接状态是由网管与网元之间的物理连接状态和业务连接状态共同决定的。但如附图1所示,现有网管系统出于功能分层的考虑,物理连接由MED层完成,即与网元建立网络连接由MED层完成,同时MED层直接根据网元的物理连接状态对网元在网管服务层的状态进行置位:MED层检测到网管与网元之间的物理连接有变化时将网元在网管服务层的连接状态改变。网管与网元之间业务连接状态的检测由服务层中的TOPO层完成,TOPO层同样可直接对网元在网管服务层的连接状态进行置位,即TOPO层检测到网元业务连接有变化时将网元在网管服务层的连接状态改变。
在网管与网元处于正常连接状态时也需要对连接状态进行监测,MED层进行网管与网元之间物理连接的检测,即进行TCP(Transfer Control Protocol传输控制协议)或UDP(User Datagram Protocol用户数据报协议)等连接的检测,而TOPO层对网管与网元的连接状态的检测是基于业务的检测,即检测网元的业务连接状态是否正常,但因为网络物理连接断连时网管无法检测到网元业务是否运行正常,如果出现网络物理连接断连,那么TOPO层也会认为是业务连接异常并据此对服务层的网元连接状态进行相应的改变。
因此,在网元的物理连接断连的情况下,TOPO层和MED层都均会对网管与网元在网管服务层的状态指示进行置位,但由于二者各自独立进行检测,并且极难同时检测到连接异常,这就导致对NE连接状态的置位混乱。同时,由于TOPO层、MED层均检测NE的连接状态,均可根据检测结果产生断连告警或恢复告警,又会导致NE的断连告警或恢复告警产生入口较多,无法控制,易出现异常。而对于网管用户来说及时准确的接收到设备的断连告警或恢复告警是十分重要和必须的。因此,现有技术由于功能分层的考虑,导致物理连接状态检测和业务连接状态检测分离,致使对NE连接状态的检测混乱且容易出错,并且现有技术在检测到NE断连后发送断连告警或者检测到NE已恢复连接后发送恢复告警的及时性、准确性上严重不足,无法满足电信网管客户所要求的实时准确了解NE连接状态、接收告警的要求。
发明内容
本发明的目的在于提供一种检测网元连接状态的方法,以解决现有技术中电信级网管不能正确及时对网元的连接状态进行检测以及断连告警和恢复告警容易出错的问题。
为达到上述目的,本发明的技术方案是这样实现的:一种检测网元连接状态的方法,该方法包括以下步骤:
a、由网管的网络适配MED层检测网管与网元NE的物理连接和业务连接;
b、当MED层检测到网管与NE物理和/或业务连接断连时,MED层对网管服务层进行置位,网管服务层的NE连接状态变迁为“断连状态”;当MED层检测到网管与NE物理和业务连接均正常时,网管服务层的NE连接状态保持“连接状态”。
其中步骤a之前还包括:
MED层应服务层的请求创建与NE对应的NE Engine并对其进行初始化,MED层的NE的连接状态在初始化成功后由“初始状态”变迁到“断连状态”,对应的服务层NE连接状态为“断连状态”;
MED层通过NE Engine与NE建立物理连接,MED层的NE的连接状态变迁到“已连接未登陆状态”,对应的服务层NE连接状态为“断连状态”;
MED层向NE发送登陆请求,建立业务连接,MED层的NE的连接状态在登陆成功后变迁到“已连接且登陆状态”,对应的服务层NE连接状态为“连接状态”。
其中步骤a中所述的MED层对NE的连接状态进行检测是通过MED层与NE建立心跳连接检测NE的物理连接状态和业务连接状态来实现的。
其中所述的MED层与NE建立心跳连接检测NE的物理连接状态和业务连接状态具体包括以下步骤:
定时器到时,MED层发送心跳,如果与NE建立心跳成功,则NE状态保持不变,等待下次定时器到时再启动心跳发送;如果与NE建立心跳失败,则连续发送第二次心跳,如果发送心跳成功则NE状态不变化,并等待下一次定时器到时再启动心跳发送,否则连续发送第三次心跳,如果第三次心跳成功则NE状态不变化,并等待下一次定时器到时,否则将服务层的NE连接状态均置为“断连状态”,同时发送断连告警到FM层。
其中所述的发送心跳的时间间隔以及发送心跳后等待返回的时间都是可配置的。
其中步骤b之后还包括:MED层检测到NE的连接状态为“断连状态”后由MED层进行连接恢复检测并在检测到网管与NE的物理连接和业务连接均恢复后将服务层的NE连接状态置为 “连接状态”,并发送恢复告警到FM层。
其中所述的网管与NE的物理连接和业务连接均正常时,服务层能够对NE进行操作。
本发明克服现有技术的不足,通过由MED层独立完成对NE的物理连接状态和业务连接状态的检测并且只有MED层能够根据检测结构对服务层的NE连接状态进行置位和向FM层发送断连告警或者恢复告警,克服了现有技术中对NE物理连接状态和业务连接状态的检测分离而导致的混乱并且断连告警和恢复告警的入口过多导致的容易出错的问题,达到了及时准确的检测并标识NE连接状态以及及时准确产生断连告警和恢复告警的目的。
附图说明
图1为现有技术检测网元连接状态的原理图;
图2为本发明技术方案检测网元连接状态的原理图;
图3为本发明网元连接状态跃迁图;
图4为本发明TOPO层创建网元流程图;
图5为本发明正常状态NE连接状态检测机制流程图;
图6为本发明断连状态NE断连恢复检测机制流程图;
图7为本发明服务层对NE操作的流程图。
具体实施例
下面结合具体实施例和附图对本发明进行详细说明。
如附图2所示,本发明技术方案是只由MED层检测网管与网元的物理连接和业务连接,并且只由MED层对服务层的连接状态进行置位,也就是说,MED层单独检测并单独置位。
当网管创建网元时,MED层首先创建一个与网元唯一对应的NE Engine并进行必要的初始化工作,在初始化成功之前,网元的连接状态应为“初始状态”,在初始化成功后,因尚未与网元建立任何连接,故此时处于“断连状态”,这种“断连状态”是物理连接和业务连接都断连的状态,随后MED层和NE建立物理连接,如果物理连接建立成功,则网元处于物理连接已建立但业务连接断连的状态,可称之为“已连接未登陆状态”,然后进行登陆操作,即进行业务连接,如果成功,那么网元就处于物理连接和业务连接都正常的状态,即“已连接且登陆状态”,此时是正常工作状态。因此,如下表所示,在MED层网元的连接状态为四种:“初始状态”、“断连状态”、“连接未登陆状态”和“已连接且登陆状态”,但如前所述,在服务层表现出来的网元连接状态只有两种:“连接状态”和“断连状态”,其中连接状态对应MED层的正常工作状态,而MED层的其他三种状态对应到服务层均为“断连状态”。本实施例中MED层检测到网元连接状态的变化后,按照下表所示的对应关系对服务层的网元连接状态进行置位,也就是说只有当MED层检测到网元的连接状态为“已连接且登陆状态”时网管服务层才显示“连接状态”,而MED层检测到上述的其他三种状态时(“初始状态”、“断连状态”、“连接未登陆状态”)网管服务层均显示“断连状态”,并且规定只有MED层可对服务层的网元连接状态进行置位,由此实现MED层对服务层网元连接状态的直接置位和单独置位。
网元实际连接情况 | MED层网元连接状态 | 服务层网元连接状态 |
物理连接,业务连接均断连 | 初始化 | 断连 |
物理连接,业务连接均断连 | 断连 | 断连 |
物理连接正常,业务连接断连 | 已连接未登陆 | 断连 |
物理连接,业务连接均正常 | 已连接且登陆 | 连接 |
在MED层网元状态变化如下:初始状态=>断连状态=>连接未登陆状态=>连接且登陆状态,可据此设计新的状态机。具体的状态跃迁如附图3所示:首先,在MED层与网管管理的网元一一对应的NE Engine创建时,网元的状态处于“初始状态”,这个时候,除了进行NE Engine初始化操作之外,其他任何MED层上的操作,或服务层通过MED层进行的操作都将是无效的。NEEngine创建后,MED层需对NE Engine进行初始化——与网元建立连接相应的初始操作,如果在初始化过程中,出现错误,网元的状态将不作变迁,仍处于“初始状态”,如果初始化成功,那么网元的状态将变迁为“断连状态”,等待连接。在“断连状态”下,除了可进行与网元的连接操作和结束操作外,其它操作都将是无效的。
在初始化成功之后,MED层与网元首先进行网络连接的操作(如TCP/IP、UDP连接等),如果在连接过程中出现了错误,MED层网元的连接状态将不作迁移,仍处于“断连状态”,等待下一次连接的发生,如果建立网络连接成功,网元的连接状态将迁移到“连接未登陆状态”,等待进行业务连接(登陆)。在“连接未登陆”状态,除了登陆操作和结束操作外,其他操作无效。
随后,MED层进行与NE业务连接的操作——与网元进行的登陆操作的交互并等待响应,如果登陆失败,MED层的NE连接状态将不会作变迁,仍处于“连接未登陆状态”,等待下一次的登陆,如果登陆过程中,发送命令失败,MED层网元的连接状态将变迁回“断连状态”,等待下一次的连接,如果登陆成功,网元的状态将变迁到“连接且登陆状态”。在正常工作状态(“连接且登陆状态”),MED层的操作或服务层通过MED层进行的操作才能正常进行。
当网元在正常工作状态下,MED层对网元将进行发送心跳的操作。如果连续3次发送心跳操作失败,表明网元与网管的连接出现故障,无论是物理连接断连还是业务连接断连,服务层网元的连接状态都将迁移到“断连状态”。
此外,在上述的各个状态下调用结束操作,MED层网元的连接状态都会迁移到“初始状态”(服务层网元的连接状态将为“断连状态”),此时,网元除了能进行初始化操作外,其他操作无效。如果状态迁移到“初始状态”时,MED层的操作或服务层通过MED层进行的操作正在进行中,那么结束操作将会等到每个操作完成才会进行。
以上是对本发明实施例原理的说明,下面详细描述本发明实施例的具体实现的过程:
第一步,TOPO层创建网元,其连接状态变化情况如附图4所示:
1)TOPO层发送创建NE请求到MED层,MED接收到请求后创建与该网元对应的NE Engine,并将该网元在网络适配层的状态置为“初始状态”,然后在MED层对NE Engine进行内部初始化,初始化成功后,MED层的NE状态变迁为“断连状态”,对应的服务层的NE连接状态也为“断连状态”;
2)MED层通过NE Engine向NE发送连接请求,请求建立物理连接。如果与NE建立物理连接失败,则MED层的NE连接状态仍然为“断连状态”,MED层通知TOPO层MED层创建NE失败;若MED层与NE建立连接成功,则MED层将NE的连接状态置为“已连接未登陆状态”,对应的服务层的NE连接状态仍为“断连状态”;
3)MED层与NE建立物理连接成功后,MED层向NE发送登陆请求,进行业务连接。若登陆NE失败,则MED层的NE的连接状态仍为“已连接未登陆状态”,MED层通知TOPO层MED层创建NE失败;若登陆NE成功,则MED层将NE的连接状态置为“已连接且登陆状态”,即正常状态,并通知TOPO层MED层创建NE成功,同时MED层对服务层的NE连接状态进行置位,服务层网元连接状态由“断连状态”变迁为“连接状态”。
第二步,网管对连接正常网元的连接状态进行检测。
在TOPO层创建NE并且NE进入正常工作状态后,网管对正常连接状态的NE需要进行连接状态检测,这一检测在本实施例中是由MED层独立完成的,通过MED层对NE进行发送心跳的操作来完成物理连接状态和业务连接状态的检测。MED层对NE进行的发送心跳操作的具体过程包括:首先由MED层通过心跳连接检测网管与设备的网络连接是否正常,如果心跳操作失败,则网络连接断连;如果心跳操作成功,则网络连接正常,然后MED层向NE发送查询NE业务的命令。查询业务的命令一般是选取NE最基本的业务查询命令。NE接收到网管下发的命令后会返回与此命令相对应的响应报文。如果NE没有在网管设置的超时时间内返回响应报文,或者在网管设置的超时时间内返回的响应报文是错误的,则说明NE的业务连接异常,也即发送心跳操作失败。如果连续3次发送心跳操作失败,则表明网管与网元之间的物理连接或者业务连接存在断连的情况,MED层对网管服务层的NE连接状态进行置位,网元的状态将迁移到“断连状态”,其检测机制流程如附图5所示:定时器到时,启动连接状态检测,MED层发送心跳,如果与NE建立心跳成功,则网元物理连接和业务连接仍然为正常状态,并等待下次定时器到时,启动心跳发送;如果与NE建立心跳失败,则连续发送第二次心跳,如果发送心跳成功则服务层网元连接状态不变化,并等待下一次定时器到时,否则连续发送第三次心跳,如果第三次心跳成功则服务层网元连接状态不变化,并等待下一次定时器到时,否则检测机制将视网元确实已断连,将服务层网元的连接状态置为“断连状态”并通知服务层网元已断连,同时发送断连告警到FM层。
定时发送心跳的时间间隔以及发送心跳等待返回的时间均是可配置的。因为在较差的网络环境下,NE针对网管的心跳的返回时间也会是较长的,故定时发送心跳的时间间隔以及发送心跳等待返回的时间的可配置,可以避免因为网络环境的因素导致对设备的连接状态的误判断,灵活准确反映网管与设备的连接状态。
因此,连接正常的网元只有在MED层发送三次心跳都失败的情况下,才会由MED层产生NE的断连告警,并发送到FM层,展现给网管用户。因此断连告警只由MED层产生,保证了断连告警产生入口的唯一性,同时前述的MED层正确有效检测网元物理连接和业务连接的机制,保证了断连告警产生的正确性。
第三步,网管对处于断连状态网元的断连恢复检测。
在MED层检测到网元断连并且发送断连告警到FM层之后,网管对处于断连状态的网元的连接恢复需要进行检测,断连状态的网元连接恢复检测仍然是有MED层单独完成的,具体的流程附图6所示:
1)MED层通过NE Engine向NE发送建立连接请求,如果与NE建立物理连接失败,则MED层的NE连接状态仍然为“断连状态”,MED层对服务层不发送任何通知;如果与NE建立物理连接成功,则MED层NE连接状态变迁为“已连接未登陆状态”,同时向设备发送登陆请求;
2)若登陆NE失败,则MED层的NE的连接状态仍然为“断连状态”,并通知服务层MED层创建NE失败;若登陆NE成功,则MED层NE的连接状态变迁为“已连接且登陆状态”,即正常状态,并通知服务层NE连接恢复正常,将服务层NE连接状态置位“连接状态”同时发送连接恢复告警到FM层。
因此,MED层检测到断连的网元正确建立物理连接和业务连接之后,就会产生恢复告警,并发送到FM层,展现给网管用户,恢复告警只由MED层产生,保证了恢复告警产生入口的唯一性,同时通过上述的MED层正确有效检测网元物理连接和业务连接恢复的机制,保证了恢复告警产生的正确性。
此外,在所有网络适配层进行操作之前都进行网元是否处于正常工作状态的判断,以禁止未登陆时对网元的操作,服务层对网元操作处理的流程如附图7所示:
1)服务层向MED层下发对NE操作的请求;
2)MED层接到服务层的请求后,在下发命令之前,对NE连接状态进行判断,如果NE处于正常状态(已连接且登陆状态),则下发操作请求到NE;
3)若MED层判断NE处于非正常状态,则拒绝请求,通知服务层拒绝操作。
如上所述,首先由MED层完成与NE的物理连接和业务连接的建立,并且对网元连接状态的检测由MED层单独完成,网元的连接状态分别为“初始状态”、“断链状态”、“连接未登陆状态”和“正常工作状态”四种,这四种连接状态可反映出网元与网管的物理连接状态和业务连接状态,即网元在MED层的连接状态是物理连接状态和业务连接状态的整合。网元连接为正常状态下对连接状态的检测也由MED层独立完成,此检测是通过MED层与NE建立心跳完成的,包括检测物理连接状态和业务连接状态。在MED层检测到网元断连并且发送断连告警到FM层之后,网管对处于断连状态网元的连接恢复需要进行检测,断连状态网元连接恢复检测仍然是由MED层单独完成的,这样就达到了及时准确的检测并标识NE连接状态以及及时准确产生断连告警和恢复告警的目的。
Claims (7)
1、一种检测网元连接状态的方法,其特征在于,该方法包括以下步骤:
a、由网管的网络适配MED层检测网管与网元NE的物理连接和业务连接;
b、当MED层检测到网管与NE物理和/或业务连接断连时,MED层对网管服务层进行置位,网管服务层的NE连接状态变迁为“断连状态”;当MED层检测到网管与NE物理和业务连接均正常时,网管服务层的NE连接状态保持“连接状态”。
2、根据权利要求1所述的检测网元连接状态的方法,其特征在于,其中步骤a之前还包括:
MED层应服务层的请求创建与NE对应的NE Engine并对其进行初始化,MED层的NE的连接状态在初始化成功后由“初始状态”变迁到“断连状态”,对应的服务层NE连接状态为“断连状态”;
MED层通过网元引擎NE Engine与NE建立物理连接,MED层的NE的连接状态变迁到“已连接未登陆状态”,对应的服务层NE连接状态为“断连状态”;
MED层向NE发送登陆请求,建立业务连接,MED层的NE的连接状态在登陆成功后变迁到“已连接且登陆状态”,对应的服务层NE连接状态为“连接状态”。
3、根据权利要求1所述的检测网元连接状态的方法,其特征在于,步骤a中所述的MED层对NE的连接状态进行检测是通过MED层与NE建立心跳连接检测NE的物理连接状态和业务连接状态来实现的。
4、根据权利要求3所述的检测网元连接状态的方法,其特征在于,所述的MED层与NE建立心跳连接检测NE的物理连接状态和业务连接状态具体包括以下步骤:
定时器到时,MED层发送心跳,如果与NE建立心跳成功,则NE状态保持不变,等待下次定时器到时再启动心跳发送;如果与NE建立心跳失败,则连续发送第二次心跳,如果发送心跳成功则NE状态不变化,并等待下一次定时器到时再启动心跳发送,否则连续发送第三次心跳,如果第三次心跳成功则NE状态不变化,并等待下一次定时器到时,否则将服务层的NE连接状态均置为“断连状态”,同时发送断连告警到故障管理FM层。
5、根据权利要求4所述的检测网元连接状态的方法,其特征在于,所述的发送心跳的时间间隔以及发送心跳后等待返回的时间都是可配置的。
6、根据权利要求1所述的检测网元连接状态的方法,其特征在于,步骤b之后还包括:MED层检测到NE的连接状态为“断连状态”后由MED层进行连接恢复检测并在检测到网管与NE的物理连接和业务连接均恢复后将服务层的NE连接状态置为“连接状态”,并发送恢复告警到FM层。
7、根据权利要求1所述的检测网元连接状态的方法,其特征在于,所述的网管与NE的物理连接和业务连接均正常时,服务层能够对NE进行操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100337082A CN100396011C (zh) | 2006-02-15 | 2006-02-15 | 一种检测网元连接状态的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100337082A CN100396011C (zh) | 2006-02-15 | 2006-02-15 | 一种检测网元连接状态的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1859198A true CN1859198A (zh) | 2006-11-08 |
CN100396011C CN100396011C (zh) | 2008-06-18 |
Family
ID=37298064
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100337082A Expired - Fee Related CN100396011C (zh) | 2006-02-15 | 2006-02-15 | 一种检测网元连接状态的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100396011C (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103001822A (zh) * | 2012-08-29 | 2013-03-27 | 五八同城信息技术有限公司 | 网络异常的处理方法及装置 |
CN103346832A (zh) * | 2013-05-31 | 2013-10-09 | 华为技术有限公司 | 一种光纤连接状态的检测方法及装置 |
CN108900005A (zh) * | 2018-08-03 | 2018-11-27 | 北京邮电大学 | 一种能源交换机附属设备智能监控系统及监控方法 |
WO2023246092A1 (zh) * | 2022-06-23 | 2023-12-28 | 中兴通讯股份有限公司 | 网络设备接入管理方法、网络管理设备及存储介质 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3159999B2 (ja) * | 1991-03-20 | 2001-04-23 | 富士通株式会社 | 伝送システム |
CN1063898C (zh) * | 1998-05-13 | 2001-03-28 | 广东省邮电科学技术研究院 | 模拟移动通信网的集中操作维护方法 |
JP3530036B2 (ja) * | 1998-08-21 | 2004-05-24 | 日本電信電話株式会社 | マルチレイヤネットワーク故障影響範囲推定方法及びその装置 |
KR100428767B1 (ko) * | 2002-01-11 | 2004-04-28 | 삼성전자주식회사 | 트래픽 정보를 이용한 가입자 라우팅 설정 방법 및 이를위한 기록매체 |
-
2006
- 2006-02-15 CN CNB2006100337082A patent/CN100396011C/zh not_active Expired - Fee Related
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103001822A (zh) * | 2012-08-29 | 2013-03-27 | 五八同城信息技术有限公司 | 网络异常的处理方法及装置 |
CN103001822B (zh) * | 2012-08-29 | 2016-07-06 | 五八同城信息技术有限公司 | 网络异常的处理方法及装置 |
CN103346832A (zh) * | 2013-05-31 | 2013-10-09 | 华为技术有限公司 | 一种光纤连接状态的检测方法及装置 |
CN103346832B (zh) * | 2013-05-31 | 2016-03-30 | 华为技术有限公司 | 一种光纤连接状态的检测方法及装置 |
CN108900005A (zh) * | 2018-08-03 | 2018-11-27 | 北京邮电大学 | 一种能源交换机附属设备智能监控系统及监控方法 |
WO2023246092A1 (zh) * | 2022-06-23 | 2023-12-28 | 中兴通讯股份有限公司 | 网络设备接入管理方法、网络管理设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN100396011C (zh) | 2008-06-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104092718B (zh) | 分布式系统及分布式系统中配置信息的更新方法 | |
CN102045332B (zh) | 智能弹性架构中处理控制报文的方法和线卡板 | |
CN1885816A (zh) | 使用软永久虚电路的多端点保护 | |
CN1946058A (zh) | 适用于软交换网络的软交换设备异地容灾系统及其方法 | |
CN102047643B (zh) | 用于在服务器故障的事件中能使客户端应用更快恢复的方法 | |
CN1665198A (zh) | 堆叠式交换机管理方法 | |
CN101075861A (zh) | 一种实现主备板热备份和主备倒换的方法 | |
CN102006189A (zh) | 用于双机冗余备份的主用接入服务器确定方法及装置 | |
WO2007048319A1 (fr) | Systeme et procede de recuperation sur sinistre de dispositif de commande de service dans un reseau intelligent | |
CN1992707A (zh) | 一种组播业务快速恢复方法及网络设备 | |
CN1859198A (zh) | 一种检测网元连接状态的方法 | |
CN101060485A (zh) | 拓扑改变报文的处理方法和处理装置 | |
WO2008014696A1 (fr) | Méthode et dispositif pour effectuer un transfert de communications | |
CN101056254A (zh) | 一种网络存储设备的扩展方法、系统及其装置 | |
CN1533100A (zh) | 对基于流控制传送协议的偶联进行保护的方法 | |
CN101035075A (zh) | 异步传输模式反向复用组重新激活的方法、系统和装置 | |
CN102075351A (zh) | 一种网管远程控制方法及系统 | |
CN103297279B (zh) | 一种多软件进程系统上软件控制的主备单盘倒换方法 | |
JP2003520477A (ja) | インテリジェントネットワークにおける信頼性の高い通信を実行する方法およびその装置 | |
CN100488129C (zh) | 处理批配置的方法和网管设备及网络系统 | |
CN1279724C (zh) | 网管接口信息采集控制点的系统及其控制方法 | |
CN102480366A (zh) | 一种关于会议系统软件的双机热备份运行方法 | |
CN1160246A (zh) | 具有检错处理功能的数据处理系统 | |
WO2002103969A1 (fr) | Procede de mise en oeuvre d'un groupe de gardes-portes telephoniques ip, et systeme de gardes-portes | |
CN101060525A (zh) | 一种sctp建链方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080618 Termination date: 20150215 |
|
EXPY | Termination of patent right or utility model |