CN101388881A - 通信协议版本协商的方法、网元及系统 - Google Patents
通信协议版本协商的方法、网元及系统 Download PDFInfo
- Publication number
- CN101388881A CN101388881A CNA2007101217576A CN200710121757A CN101388881A CN 101388881 A CN101388881 A CN 101388881A CN A2007101217576 A CNA2007101217576 A CN A2007101217576A CN 200710121757 A CN200710121757 A CN 200710121757A CN 101388881 A CN101388881 A CN 101388881A
- Authority
- CN
- China
- Prior art keywords
- network element
- protocol version
- supported
- version
- protocol
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 63
- 230000006854 communication Effects 0.000 title claims abstract description 33
- 238000004891 communication Methods 0.000 title claims abstract description 32
- 230000003993 interaction Effects 0.000 claims abstract description 61
- 230000004044 response Effects 0.000 claims description 42
- 230000008569 process Effects 0.000 claims description 36
- 230000002159 abnormal effect Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Images
Landscapes
- Communication Control (AREA)
Abstract
一种通信协议版本协商的方法、网元及系统,其主要包括:首先,支持高协议版本的第一网元在使用低协议版本与对端第二网元协商协议版本过程中,将第一网元支持的高协议版本通知第二网元;之后,相应的第二网元根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的最高协议版本进行交互。可见,本发明实施例提供的技术方案可以使得两个支持高协议版本的网元之间能够准确的使用双方均支持的最高协议版本进行交互,以避免因误协商为低协议版本而导致出现损失业务功能的问题。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种通信协议版本协商的方案。
背景技术
GTP(通用分组无线服务隧道协议)协议是广泛应用于GPRS(通用分组无线服务)系统或UMTS(通用移动通信系统)系统核心网的一种移动通信协议,同时,在下一代分组域核心网架构中也应用了GTP协议。
在应用了GTP协议的各网元中,通过发送GTP请求消息发起通信的一方称为源侧,另一方则称为目标侧。如图1所示,相应的GTP协议的交互过程主要包括:GTP网元A需要与GTP网元B交互,则GTP网元A向GTP网元B发送特定的GTP请求消息,GTP网元B接收到请求消息后进行处理,处理完成后向GTP网元A返回GTP响应消息。
目前GTP协议包括V0版本和V1版本共两个版本,在网元之间交互的GTP消息头中的第一个字节的前3个bit(比特)用于指示消息的GTP版本号。而且,在GTP的V1版本中规定,在支持GTP协议的V1版本的设备上必须支持GTP协议的V0版本。
由于采用高版本的GTP协议能够获得更强大的功能,因此,在两个GTP网元之间尽量协商选择采用双方均支持的最高GTP版本,例如,若两个GTP网元均支持GTP协议的V1版本时,则采用GTP协议的V1版本进行交互。为此,需要在网络中提供相应的GTP协议版本协商机制,以便于协商采用双方均支持的最高GTP版本,目前采用的版本协商机制包括:
步骤1,支持GTP协议的V1版本的网元A需要与网元B交互,则源侧网元A首先使用自己支持的最高GTP版本,即V1版本向目标侧网元B发送GTP请求消息;
步骤2,网元B接收到所述GTP请求消息后,向网元A返回响应消息,若网元A收到GTP协议的V1版本的响应消息,则确定网元B最高支持GTP协议的V1版本,若网元A没有收到网元B返回的V1版本的响应消息,则网元A向网元B重发GTP协议的V1版本请求消息;
步骤3,若网元A向网元B重发N次GTP协议的V1版本的请求消息后,仍然没有收到网元B的响应,则网元A采用的是GTP协议的V0版本向网元B发送请求消息,其中,重发次数N可以灵活配置;
步骤4,网元B接收到V0版本的GTP请求消息后,向网元A返回响应消息,若网元A收到GTP协议V0版本的响应消息,则网元A认为网元B只支持GTP协议的V0版本,且后续使用GTP协议的V0版本与网元B进行交互。
在上述处理过程中,发明人发现在某些情况下会出现两个均支持高版本的GTP网元误协商为低版本并采用低版本进行交互的情况,例如:
网元A和网元B均支持GTP协议的V1版本,且源侧网元A首先使用自己支持的最高GTP版本GTP协议的V1向目标侧网元B发送请求消息,但是,由于各种原因导致该请求消息经过N次发送后均未能到达网元B;此时,网元A将使用GTP协议的V0版本向网元B发送请求消息,且该请求消息被网元B正常接收并进行处理,之后,向网元A返回了GTP协议的V0版本的响应消息,至此,网元A与网元B之间协商采用V0版本的GTP消息进行交互。
而且,以上描述仅以V0和V1两种GTP协议版本为例,在未来的演进网络中,GTP协议的版本还将继续升级到V2版本、V3版本等等。这样,若网元之间交互无法协商到高版本GTP协议进行交互,则将大大损失高版本的GTP协议交互所独有的业务特性。
发明内容
本发明的实施例提供了一种通信协议版本协商的方法、网元及系统,从而使得网元之间的交互可以尽量采用双方支持的高版本协议,从而获得较佳的业务特性。
本发明实施例提供了一种通信协议版本协商的方法,包括:
支持高协议版本的第一网元在使用低协议版本与对端第二网元协商协议版本过程中,将第一网元支持的高协议版本通知第二网元;
第二网元根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的符合预定要求的协议版本进行交互。
本发明实施例提供了一种通信协议版本协商的系统,包括:
第一网元,其在支持高协议版本的情况下,使用低协议版本发送协商协议版本的信息时,在该信息中包含第一网元支持的高协议版本;
第二网元,用于接收所述第一网元发来的协商协议版本的信息,并根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的符合预定要求的协议版本进行交互。
本发明实施例提供了一种网元,包括与对端网元之间协商协议版本的单元,该网元还包括:
协议版本通知单元,用于在支持高协议版本的情况下,使用低协议版本发送协商协议版本的信息,并在该信息中包含本网元支持的高协议版本。
本发明实施例提供了一种网元,包括与对端网元之间协商协议版本的单元,该网元还包括:
接收单元,用于接收对端网元发来的协商协议版本的信息,且所述信息中包含对端网元支持的高协议版本;
控制单元,用于根据信息接收单元接收的信息中的对端网元支持的高协议版本控制两端网元之间采用共同支持的符合预定要求的协议版本进行交互。
由上述本发明的实施例提供的技术方案可以看出,本发明实施例提供的技术方案可以使得两个支持高协议版本的网元之间能够准确的使用双方均支持的符合预定要求的协议版本进行交互,以避免因误协商为低协议版本而导致出现损失业务功能的问题。
附图说明
图1为现有技术中GTP协议通信过程示意图;
图2为本发明实施例中应用的GTP协议消息结构示意图;
图3为本发明实施例一的处理过程示意图;
图4为本发明实施例二的处理过程示意图;
图5为本发明实施例三的处理过程示意图;
图6为本发明实施例四的处理过程示意图;
图7为本发明实施例五的处理过程示意图;
图8为本发明实施例六的处理过程示意图;
图9为本发明实施例七的处理过程示意图;
图10为本发明实施例八的处理过程示意图;
图11为本发明实施例九的处理过程示意图;
图12为本发明实施例提供的系统及网元结构示意图。
具体实施方式
本发明实施例中,若由于通信链路或者网元状态暂时故障等原因导致两个均支持高版本协议的网元误协商为使用低版本协议进行交互,则可以通过相应的技术手段使得两网元之间重新协商到采用符合预定要求的本协议进行交互,如采用两网元均支持的最高协议版本进行交互,以避免损失高版本独有的业务特性。
本发明实施例采用的技术手段包括在向对端网元发送的低版本的请求协商通信协议版本的消息中携带本端网元支持的最高协议版本或指示本端可以支持更高版本的协议,以使得对端网元可以获知本端网元支持的最高协议版本,从而可以避免协商到低版本协议下进行交互。
进一步讲,本发明实施例中,首先,由支持高协议版本的第一网元在使用低协议版本与对端第二网元协商协议版本过程中,将第一网元支持的高协议版本通知第二网元;之后,第二网元根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的最高协议版本进行交互。
在上述处理过程中,将第一网元支持的高协议版本通知第二网元的处理方式具体可以采用以下任一方式实现:
(1)第一网元将自身支持的最高协议版本发送给第二网元;
(2)第一网元将自身支持更高协议版本的指示发送给第二网元;
(3)第一网元将自身支持的所有的协议版本发送给第二网元;
(4)第一网元将自身支持的最高协议版本和最低协议版本发送给第二网元,以使得在支持的协议版本连续的情况下,第二网元可以获知第一网元支持的所有协议版本。
而且,所述的第一网元具体可以使用协议消息中的扩展头携带所述支持的高协议版本并发送给第二网元;或者,使用协议消息中的信元携带所述支持的高协议版本并发送给第二网元;或者,使用协议消息中的协议头部的空闲比特位携带所述支持的高协议版本并发送给第二网元。
在本发明实施例中,相应的控制第一网元和第二网元之间采用共同支持的最高协议版本进行交互的处理过程具体可以为以下任一方式:
方式一:第二网元接收到第一网元发来的使用低协议版本的消息后,比较第一网元支持的最高协议版本和第二网元支持的最高协议版本,若双方均支持的最高协议版本高于接收到的消息使用的低协议版本,则通知第一网元使用双方均支持的最高协议版本进行交互;
方式二:第二网元接收到第一网元发来的使用低协议版本的消息后,直接确定第一网元和第二网元之间共同支持的最高协议版本,并采用该最高协议版本进行信息交互。
在上述方式一中,相应的通知第一网元使用双方均支持的最高协议版本进行交互的实现方式具体可以为以下任一方式:
(1)第二网元将自身支持的高协议版本通知第一网元,第一网元根据收到的第二网元发来的通知在第一网元和第二网元之间采用共同支持的最高协议版本进行交互;
在该方式下,所述的第二网元将自身支持的高协议版本通知第一网元的处理过程进一步可以为以下任一方式:
第二网元通过扩展已有的协议消息将所述自身支持的高协议版本通知给所述第一网元;
第二网元通过新增的协议消息将所述自身支持的高协议版本通知给所述第一网元;
第二网元在响应消息中使用协议消息的扩展头携带所述自身支持的高协议版本通知给所述第一网元;
第二网元在响应消息中使用协议消息的信元携带所述自身支持的高协议版本通知给所述第一网元;
第二网元在响应消息中使用协议消息的协议头部的空闲比特位携带所述自身支持的高协议版本通知给所述第一网元。
其中,所述的自身支持的高协议版本可以但不限于包括:自身支持的最高协议版本,或者,支持的最高协议版本和最低协议版本,或者,支持的所有协议版本(如支持的所有协议版本列表),或者,第一网元和第二网元均支持的最高协议版本,或者,自身支持更高版本的指示(即不指明具体支持某种协议而仅表明自身仍能够支持更高的协议版本)。
(2)第二网元向第一网元发送第二网元支持的高协议版本的消息,第一网元根据收到的该消息在第一网元和第二网元之间采用共同支持的最高协议版本进行交互。
以协商GTP协议过程为例,若一个支持高版本的GTP网元A在使用GTP高版本向对端GTP网元B发送配置次数的请求消息后,仍然没有接收到响应,则采用GTP低版本向对端发送请求消息,此时,在低版本请求消息中携带本端网元A所能支持的最高GTP版本信息或携带本端能够支持更高GTP版本的指示信息,这样,在GTP网元B接收到该低版本的请求消息后,如果确定自己也能够支持更高GTP版本,则通知网元A使用高版本进行交互。
具体地,本发明实施例中,可以但不限于采用以下任一方式将源侧网元支持更高版本的指示信息发送给目标侧网元:
(1)使用GTP协议扩展头携带相应的指示信息;
如图2所示,GTP协议的V1版本的消息中包含扩展头ExtensionHeader,该扩展头具体位于GTP消息头部和信元列表之间区段,而且,该GTP扩展头为可选。
所述的扩展头位于的区段中可以包括一个或多个相互连接的扩展头,每个扩展头由三部分组成,分别为:扩展头类型、扩展头长度和扩展头的值,因此,可以增加一种扩展头类型用于指示本端支持的最高GTP版本。
在本发明实施例中,具体可以新增的扩展头的类型值的高2个比特可以设置为“00”,并可以在扩展头的值中填写本端支持的最高GTP版本号。
通过该GTP扩展头可以解决最高支持GTP协议的V2版本及更高版本的GTP版本误协商的问题。
(2)使用GTP可选信元携带相应的指示信息;
在该实施例中,具体是在两个GTP网元初次交互时源侧可能发出的请求消息中,增加一个可选信元用于指示本端所支持的最高GTP版本号。
(3)使用GTP头部的空闲比特位携带相应的指示信息;
在该实施例中,是将本端支持的最高GTP版本信息设置在GTP头部的空闲比特位中;
目前,由于GTP协议的V1版本消息的头部仅有一个比特空闲位,其无法容纳一个完整的GTP版本号,故可以利用该空闲比特位携带一个标志,以指示本端可以支持更高版本的GTP协议,例如,当该标志值为0时,表示发送消息的GTP版本即是源端所支持的最高GTP版本,当该标志值为1时,表示发送端支持比发送消息本身的GTP版本更高的GTP版本;
在该实施例中,由于未指明具体支持的最高GTP版本号,目的端接收到消息后,如果本端也能支持比该消息本身版本更高的GTP版本,则通知源端使用比当前版本高一个版本号的版本进行重新发起流程,若相应的高一个版本号仍然不是源端所能支持的最高GTP版本号,则源端仍会在消息中将空闲比特位置为1,目标侧接收到升高了一个版本号的消息后,如果本端还能支持比该消息本身版本更高的GTP版本,则继续通知源端再升高个版本号重新发送消息,直到协商到双方均支持的最高GTP版本。
经过上述处理后,目标侧GTP网元便可以从接收到的低版本GTP请求消息中得到源侧支持的最高或更高GTP版本,此时,目标侧GTP网元需要通知源侧使用更高版本的进行交互。相应的,目标侧GTP网元可以通知源端自己所支持的最高GTP版本,也可以通知源端双方均支持的最高GTP版本,以便于源端GTP网元均可以得到双方均支持的最高GTP版本并使用该双方均支持的最高GTP版本发起后续交互。其中,对于接收到的低版本GTP请求消息,目标侧网元可以正常处理并向源侧响应,也可以拒绝处理并直接向源侧返回合适的原因值。
在本发明实施例中,目标侧通知源侧双方均支持的最高GTP版本的处理方式可以为以下任一方式:
(1)扩展版本不支持消息
在GTP协议实现过程中,只支持低版本的GTP网元在接收到一个本端不支持的高版本GTP消息后,可以通过向对端发送版本不支持消息通知对端,发送该版本不支持消息使用的GTP版本为本端支持的最高GTP版本。
在该方式中,是将版本不支持消息的含义扩展为将双方均支持的最高GTP版本通知给对端,相应的消息名称可以修改为:支持版本通知消息,即Version Supported Notification消息,为了实现将双方均支持的最高GTP版本通知给对端的目的,具体可以采用以下任一方法:
方法一:将所述支持版本通知消息使用与触发本消息的低版本请求消息相同的GTP版本发送,在这条消息中增加一个“最高支持版本”的可选信元,设置为本端所支持的最高GTP版本,该版本可以高于发送支持版本通知消息所使用的GTP版本,若支持版本通知消息没有携带该可选信元,则接收方可以认为发送方支持的最高GTP版本与接收到的支持版本通知消息使用的GTP版本一致;
方法二:将所述支持版本通知消息使用本端和对端均支持的最高GTP版本发送,即不需要再携带额外信元,其中,对端支持的最高GTP版本可以从触发本消息的低版本请求消息中携带信息中获得。
(2)增加新的GTP消息
在该实施例中,采用新增加一条GTP消息,以实现“支持版本通知”功能,其他处理方式与扩展版本不支持消息的处理方式类似,故不再详述。
(3)使用GTP协议扩展头;
在该实施例中,目标侧GTP网元在接收到源端发送的低版本的GTP请求消息,其中携带了源端支持的最高GTP版本的指示时,如果本端也支持高版本的GTP版本,则在响应消息中增加一个GTP协议扩展头,用于通知源侧自己支持的最高GTP版本;
且相应的使用GTP协议扩展头的具体实现方式可以与源侧采用的使用GTP协议扩展头携带相应的指示信息的实现方式类似,或者,也可以新增一个新的扩展头类型。
(4)使用GTP可选信元
在该实施例中,目标侧GTP网元在接收到源端发送的低版本的GTP请求消息,且消息中携带了源端支持的最高GTP版本的指示时,若本端也支持高版本的GTP版本,则可以在响应消息中增加一个可选信元,用于通知源侧自己支持的最高GTP版本;
相应的使用可选信元的具体实现方式可以与源侧采用的使用GTP可选信元的实现方式类似,或者,也可以新增一个新的可选信元类型。
(5)使用GTP头部的空闲比特位。
在该实施例中,目标侧GTP网元在接收到源端发送的低版本的GTP请求消息,且消息中携带了源端支持的最高GTP版本的指示时,若本端也支持高版本的GTP版本,则可以在响应消息利用GTP协议头部的空闲比特位通知源侧自己支持的最高GTP版本;相应的具体实现方式可以与源侧采用的使用GTP头部的空闲比特位的实现方式相同。
本发明实施例中,除了可以采用上述方式在源侧GTP网元和目标侧网元之间互相通知所能支持的最高GTP版本外,还可以将本端所能支持的所有GTP版本列表发送给对端网元,当GTP网元所能支持的GTP版本号连续时,相应的GTP版本列表可以使用所能支持的最低版本和所能支持的最高版本来表示;当GTP网元所能支持的GTP版本号不连续时,则可以将所能支持的每个GTP版本的版本号均包含在该GTP版本列表中。该处理方式适合GTP协议版本不断升级过程中出现的支持高版本的GTP网元不支持低版本的情况,例如,未来支持GTP协议的V2版本的网元同时支持GTP协议的V1,但不支持GTP协议的V0,或者,支持GTP协议的V3版本的网元同时支持GTP协议的V2,但不支持GTP协议的V0版本和V1版本。此时,源侧和目标侧网元之间通过传递本端所能支持的所有GTP版本列表,以使得网元之间可以顺利地协商到双方共同支持的最高版本。
在上述处理过程中,本端所能支持的所有GTP版本列表的携带方式与携带本端所能支持的最高GTP版本的方式相同,在此不再详述。其中,当使用扩展“版本不支持”消息或者增加新的GTP消息来通知对端自己所能支持的所有GTP版本列表时,由于需要携带多个GTP版本号,因此可以在消息中增加扩展头或者可选信元来携带所能支持的所有GTP版本列表信息。
本发明实施例中,在GTP网元通过上述各版本协商机制已经获知双方所能支持的最高GTP版本后,则可以在后续流程交互的消息不再携带本端的版本支持情况信息。
为便于对本发明实施例的理解,下面将结合附图对本发明实施例的具体实施方式进行详细地说明。
实施例一
在该实施例一中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的最高GTP版本携带在请求消息的GTP扩展头中,对应的目标侧网元则使用“支持版本通知”消息通知源侧网元使用更高版本进行交互,其中,目标侧网元支持的最高GTP版本携带在“支持版本通知”消息的可选信元中。
如图3所示,GTP网元A、网元B均支持GTP协议的V1、V2版本,相应的版本协商处理过程具体可以包括以下步骤:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因,GTP网元B未能接收到GTP协议的V2版本的请求消息;
步骤2,GTP网元A确认未收到响应消息后,则改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“最高GTP支持版本”扩展头,扩展头的值填写为GTP网元A支持的最高协议版本V2;
在该步骤中,由于通讯链路恢复正常或GTP网元B状态恢复正常,使得相应的GTP协议的V1版本的请求消息可以被发送到GTP网元B;
步骤3,网元B收到相应的V1版本的请求消息后,向网元A发送一条GTP协议的V1版本的“支持版本通知”消息,并在该消息中携带着网元B支持的最高版本,即GTP协议的V2版本信息;
该步骤具体可以为:GTP网元B从接收到的网元A发送来的GTP协议的V1版本请求消息的扩展头中可以获知对端GTP网元A实际最高支持的协议版本为GTP协议的V2版本,同时,本端最高支持的协议版本也为GTP协议的V2版本,此时,则可以不处理该请求消息而直接向网元A应答响应消息,响应消息中原因值为“版本不匹配”或者其它合适的原因值,同时还向网元A发送“支持版本通知”消息;
步骤4,网元A接收到网元B发送来的GTP协议的V1版本的“支持版本通知”消息后,便可以获知本端和对端均支持GTP协议的V2版本的情况,这样,便可以在后续交互处理过程中使用GTP协议的V2版本进行。
实施例二
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的最高GTP版本携带在请求消息的GTP扩展头中,而目标侧网元使用“支持版本通知”消息通知源侧网元使用更高版本进行交互,其中,所述“支持版本通知”消息使用的协议版本即是源侧网元和目标侧网元均能支持的最高GTP协议版本。
如图4所示,GTP网元A、网元B均支持GTP协议的V1、V2版本,则相应的版本协商处理过程如下:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A确认未收到响应消息后,则改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“最高GTP支持版本”扩展头,扩展头的值填写为GTP网元A支持的最高协议版本V2,由于通讯链路恢复正常或GTP网元B状态恢复正常,则相应的消息将被发送到GTP网元B;
步骤3,GTP网元B接收V1版本的请求消息后,网元B向网元A发送一条GTP协议的V2版本的“支持版本通知”消息;
具体可以为:在GTP网元B接收V1版本的请求消息后,则可以从GTP协议的V1版本请求消息的扩展头中获取对端GTP网元A实际最高支持GTP协议的V2版本,同时,由于自己也最高支持GTP协议的V2版本,因此,不需要处理该请求消息而直接向网元A应答响应消息即可,在所述响应消息中原因值为“版本不匹配”或者其它合适的原因值;同时,网元B向网元A发送一条GTP协议的V2版本的“支持版本通知”消息;
步骤4,网元A接收到网元B发送来的GTP协议的V2版本的“支持版本通知”消息后,则可以获知本端和对端均支持GTP协议的V2版本,并在后续交互处理过程中使用GTP协议的V2版本进行。
实施例三
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的最高GTP版本携带在请求消息的可选信元中,而目标侧网元则使用“支持版本通知”消息通知源侧网元使用更高版本进行交互,其中目标侧网元支持的最高GTP版本具体可以携带在“支持版本通知”消息的可选信元中。
如图5的示,GTP网元A、网元B均支持GTP协议的V1、V2版本,相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,且由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A未收到网元B发来的响应消息后,则改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“最高GTP支持版本”可选信元,信元中的值填写为GTP网元A支持的最高协议版本V2,此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,则相应的请求消息可以发送到GTP网元B;
步骤3,网元B收到网元A发来的V1版本请求消息后,则向网元A发送一条GTP协议的V1版本的“支持版本通知”消息,消息中携带网元B支持的最高GTP版本V2;
GTP网元B从接收到的网元A发来的GTP协议的V1版本请求消息的可选信元中获知对端GTP网元A实际最高支持GTP协议的V2版本,同时,由于自己也最高支持GTP协议的V2版本,故不处理该请求消息而直接向网元A应答响应消息,相应的响应消息中的原因值为“版本不匹配”或其他原因值;同时,网元B向网元A发送GTP协议的V1版本的“支持版本通知”消息;
步骤4,网元A接收到网元B发送来的GTP协议的V1版本的“支持版本通知”消息后,则可以获知本端和对端均支持GTP协议的V2版本,这样,在后续交互处理过程中便可以使用GTP协议的V2版本进行。
实施例四
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的最高GTP版本携带在请求消息的GTP扩展头中,而目标侧也将自己支持的最高GTP版本携带在响应消息的GTP扩展头中。
如图6所示,GTP网元A、网元B均支持GTP协议的V1、V2版本,相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A由于未收到网元B返回的响应消息,则改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“最高GTP支持版本”GTP扩展头,扩展头中的值填写为GTP网元A支持的最高协议版本V2,此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,使得相应的请求消息可以发送到GTP网元B;
步骤3,GTP网元B从网元A发送来的GTP协议的V1版本请求消息的扩展头中获知对端GTP网元A实际最高支持GTP协议的V2版本,同时,自己也最高支持GTP协议的V2版本,此时,便可以按GTP协议的V1协议正常处理该消息,并向网元A应答响应消息,同时在所述响应消息中携带“最高GTP支持版本”GTP扩展头,扩展头中的值填写为GTP网元B支持的最高协议版本V2;
步骤4,网元A接收到网元B发送来的GTP协议的V1版本的响应消息后,便可以获知本端和对端均支持GTP协议的V2版本,这样,在后续交互处理过程中便可以使用GTP协议的V2版本进行。
实施例五
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的最高GTP版本携带在请求消息的GTP扩展头中,而目的侧将自己支持的最高GTP版本携带在响应消息的可选信元中。
如图7所示,GTP网元A、网元B均支持GTP协议的V1、V2版本,相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A在未收到网元B返回的响应消息后,则可以改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“最高GTP支持版本”GTP扩展头,扩展头中的值填写为GTP网元A支持的最高协议版本V2,此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,使得相应的请求消息发送到GTP网元B;
步骤3,GTP网元B从网元A发来的GTP协议的V1版本请求消息的扩展头中可以获知对端GTP网元A实际最高支持GTP协议的V2版本,同时,由于自己也最高支持GTP协议的V2版本,则可以按GTP协议的V1协议正常处理该消息,并向网元A应答响应消息,在所述响应消息中携带“最高GTP支持版本”可选信元,信元的值填写为GTP网元B支持的最高协议版本V2;
步骤4,网元A接收到网元B发送来的GTP协议的V1版本的响应消息后,可以获知本端和对端均支持GTP协议的V2版本,这样,在后续交互处理过程中便可以使用GTP协议的V2版本进行。
实施例六
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的最高GTP版本携带在请求消息的GTP扩展头中,而目标侧只支持GTP协议的V1和GTP协议的V0,且不识别该新增扩展头
如图8所示,GTP网元A支持GTP协议的V1、V2版本,网元B仅支持GTP协议的V1、V0版本,则相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A在未收到网元B返回的响应消息后,则可以改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“最高GTP支持版本”扩展头,扩展头的值填写为GTP网元A支持的最高协议版本V2,此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,因此,相应的请求消息将会被发送到GTP网元B;
步骤3,GTP网元B收到所述请求消息后,由于不识别请求消息中的“支持最高GTP版本”扩展头,故将忽略该扩展头信息,并按照GTP协议的V1协议正常处理该GTP协议的V1请求消息,向网元A返回响应消息;
步骤4,网元A收到相应的响应消息后,则可以在与网元B的后续交互处理过程中使用GTP协议的V1版本进行。
实施例七
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持更高GTP版本的标志携带在请求消息的GTP协议头部空闲比特位中,而目标侧网元使用“支持版本通知”消息通知源侧网元使用更高版本进行交互。
如图9所示,GTP网元A、网元B均支持GTP协议的V1、V2版本,相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,消息头部“支持更高GTP版本”标志位的值设置为0,表示消息本身使用的GTP协议的V2版本是自己所能支持的最高GTP版本;由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A未收到网元B返回的响应消息,则改用GTP协议的V1版本向GTP网元B发送请求消息,消息头部“支持更高GTP版本”标志位的值设置为1,表示自己能够支持比消息本身所用的GTP协议的V1版本更高的版本;此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,使得相应的请求消息可以发送到GTP网元B;
步骤3,GTP网元B从网元A发来的GTP协议的V1版本请求消息的标志位中获知对端GTP网元A实际支持比GTP协议的V1更高的版本,则丢弃该GTP协议的V1版本请求消息,向网元A发送GTP协议的V2版本的“支持版本通知”消息,通知网元A其同样可以支持更高的V2版本;
步骤4,网元A接收到网元B发送来的“支持版本通知”消息后,便可以获知本端和对端均支持GTP协议的V2版本,这样,在后续交互处理过程中便可以使用GTP协议的V2版本进行。
实施例八
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的所有GTP版本列表携带在请求消息的GTP扩展头中,而目的侧将自己支持的所有GTP版本列表均携带在“支持版本通知”消息中通知给网元A。
如图10所示,GTP网元A支持GTP协议的V1、V2版本;GTP网元B支持GTP协议的V3和GTP协议的V2版本,且同时可以支持低版本的版本协商处理,相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A由于未收到网元B发来的响应消息,故将改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“支持GTP版本列表”扩展头,扩展头中的值指示GTP网元A支持的GTP协议的V2和GTP协议的V1版本,此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,使得该请求消息可以被发送到GTP网元B;
步骤3,GTP网元B从网元A发送来的GTP协议的V1版本请求消息的扩展头中获知对端GTP网元A支持GTP协议的V2和V1版本,且自己支持GTP协议的V3和V2版本,即双方能够支持的最高GTP版本为V2,因此,GTP网元B丢弃该GTP协议的V1版本的请求消息,并向网元B发送一条“支持版本通知”消息,该消息本身可以使用GTP协议的V1发送,也可以使用GTP协议的V2发送,在该消息中携带的扩展头或者信元指示GTP网元B支持的GTP协议的V3和GTP协议的V2版本;
步骤4,网元A接收到网元B发送来的“支持版本通知”消息后,可以获知本端和对端均支持的最高GTP版本为V2版本,则在后续交互处理过程中将使用GTP协议的V2版本进行。
实施例九
在该实施例中,源侧网元在使用低版本协议与目标侧网元进行初次交互时,将本端支持的所有GTP版本列表携带在请求消息的GTP扩展头中,而目标侧选择双方均支持的最高GTP版本携带在“支持版本通知”消息中通知网元A。
如图11所示,GTP网元A支持GTP协议的V2和V1版本;GTP网元B支持GTP协议的V3和GTP协议的V2版本,同时可以支持低版本的版本协商处理,相应的版本协商处理过程可以包括:
步骤1,GTP网元A首先使用GTP协议的V2版本向GTP网元B发送请求消息,由于通讯链路故障或GTP网元B当前状态不正常等原因导致GTP网元B未能接收到GTP协议的V2的请求消息;
步骤2,GTP网元A由于未收到网元B发来的响应消息,故将改用GTP协议的V1版本向GTP网元B发送请求消息,并在请求消息中增加“支持GTP版本列表”扩展头,扩展头中的值指示GTP网元A支持的GTP协议的V2和GTP协议的V1版本,此时,由于通讯链路恢复正常或GTP网元B状态恢复正常,使得该请求消息可以被发送到GTP网元B;
步骤3,GTP网元B从网元A发送来的GTP协议的V1版本请求消息的扩展头中可以获知对端GTP网元A支持GTP协议的V2和V1版本,同时,由于自己支持GTP协议的V3和V2版本,故双方能够支持的最高GTP版本为V2;这样,GTP网元B将丢弃该GTP协议的V1版本的请求消息,并向网元B发送一条GTP协议的V2版本的“支持版本通知”消息,消息中不携带信元,该消息用于表示双方能够支持的最高GTP版本为V2;
步骤4,网元A接收到网元B发送来的“支持版本通知”消息后,便可以获知本端和对端均支持的最高GTP版本为V2版本,这样,在后续交互处理过程中便可以使用GTP协议的V2版本进行。
本发明实施例还提供了一种通信协议版本协商的系统,其具体实现结构如图12所示,具体可以包括:
(一)第一网元,可作为协议版本协商中的源侧网元,其在支持高协议版本的情况下,使用低协议版本发送协商协议版本的信息,在该信息中包含第一网元支持的高协议版本;
该第一网元具体可以包括与对端网元之间协商协议版本的单元,且该第一网元还包括:
协议版本通知单元,用于在支持高协议版本的情况下,使用低协议版本发送协商协议版本的信息,并在该信息中包含本网元支持的高协议版本。
可选地,该协议版本通知单元具体包括以下任一单元:
第一通知单元,用于将第一网元支持的最高协议版本发送给第二网元;
第二通知单元,用于将第一网元支持更高协议版本的指示发送给第二网元,例如,在发送的消息中采用标志位“1”表示第一网元支持更高协议版本,若该标志位为“0”则表示第一网元不支持更高协议版本;
第三通知单元,用于将第一网元支持的所有的协议版本发送给第二网元,例如,将第一网元支持的所有协议版本列表承载于消息中发送给相应的第二网元;
第四通知单元,用于将第一网元支持的最高协议版本和最低协议版本发送给第二网元,例如,在第一网元支持的协议版本连续的情况下,则可以通过发送支持的最高协议版本和最低协议版本的方式向第二网元传送第一网元支持的所有协议版本。
(二)第二网元,可作为协议版本协商中的目标侧网元,用于接收所述第一网元发来的协商协议版本的信息,并根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的符合预定要求的协议版本(如最高协议版本)进行交互。
该第二网元包括与对端网元之间协商协议版本的单元,且该网元还包括以下处理单元:
接收单元,用于接收对端网元发来的协商协议版本的信息,且所述信息中包含对端网元支持的高协议版本;
控制单元,用于根据信息接收单元接收的信息中的对端网元支持的高协议版本控制两端网元之间采用共同支持的最高协议版本进行交互。
可选地,相应的控制单元具体可以包括以下单元:
比较单元,用于比较根据所述接收单元接收的消息确定的对端网元支持的最高协议版本和本端网元支持的最高协议版本;
通知单元,用于在根据所述比较单元的比较结果确定两端网元均支持的最高协议版本高于接收到的消息使用的低协议版本时,通知对端网元使用所述均支持的最高协议版本进行交互。
以上各单元具体可以应用于GTP协议的协商过程中,也可以应用于其他协议的协商过程中,而且各单元的具体实现方式在之前的方法实施例中已经描述,故再此不再详细描述。
综上所述,本发明实施例可以使得两个支持高协议版本的网元之间能够准确的使用双方均支持的最高协议版本进行交互,以避免因误协商为低协议版本而导致出现损失业务功能的问题。而且,在本发明实施例中,通过将自己所能支持的所有协议版本列表(或者最高版本和最低版本)通知对端,从而可以加快支持高版本而不支持低版本协议的网元之间确定双方均能支持的最高协议版本的速度,减少消息交互。同时,上述各个本发明实施例可以但不限于应用于GTP协议的协商过程中。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (15)
1、一种通信协议版本协商的方法,其特征在于,包括:
支持高协议版本的第一网元在使用低协议版本与对端第二网元协商协议版本过程中,将第一网元支持的高协议版本通知第二网元;
第二网元根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的符合预定要求的协议版本进行交互。
2、根据权利要求1所述的方法,其特征在于,所述的将第一网元支持的高协议版本通知第二网元的步骤包括:
第一网元将自身支持的最高协议版本发送给第二网元;
或者,
第一网元将自身支持更高协议版本的指示发送给第二网元;
或者,
第一网元将自身支持的所有的协议版本发送给第二网元;
或者,
第一网元将自身支持的最高协议版本和最低协议版本发送给第二网元。
3、根据权利要求1所述的方法,其特征在于,所述的第一网元通过以下任一消息将支持的高协议版本通知第二网元:
第一网元使用协议消息中的扩展头携带所述支持的高协议版本并发送给第二网元;
或者,
第一网元使用协议消息中的信元携带所述支持的高协议版本并发送给第二网元;
或者,
第一网元使用协议消息中的协议头部的空闲比特位携带所述支持的高协议版本并发送给第二网元。
4、根据权利要求1、2或3所述的方法,其特征在于,所述的控制第一网元和第二网元之间采用共同支持的符合预定要求的协议版本进行交互的步骤包括:
第二网元接收到第一网元发来的使用低协议版本的消息后,比较第一网元支持的最高协议版本和第二网元支持的最高协议版本,若双方均支持的最高协议版本高于接收到的消息使用的低协议版本,则通知第一网元使用双方均支持的最高协议版本进行交互;
或者,
第二网元接收到第一网元发来的使用低协议版本的消息后,确定第一网元和第二网元之间共同支持的最高协议版本,并直接采用该最高协议版本进行信息交互。
5、根据权利要求4所述的方法,其特征在于,所述的通知第一网元使用双方均支持的最高协议版本进行交互的步骤包括:
第二网元将自身支持的高协议版本通知第一网元,第一网元根据收到的通知在第一网元和第二网元之间采用共同支持的最高协议版本进行交互;
或者,
第二网元向第一网元发送第二网元支持的高协议版本的消息,第一网元根据收到的该消息采用的高协议版本,在第一网元和第二网元之间采用共同支持的最高协议版本进行交互。
6、根据权利要求5所述的方法,其特征在于,所述的第二网元将自身支持的高协议版本通知第一网元的步骤包括:
第二网元通过扩展已有的协议消息将所述自身支持的高协议版本通知第一网元;
或者,
第二网元通过新增的协议消息将所述自身支持的高协议版本通知第一网元。
7、根据权利要求6所述的方法,其特征在于,所述的通过扩展已有的协议消息将所述自身支持的高协议版本通知第一网元的步骤包括:
第二网元在响应消息中使用协议消息的扩展头携带所述自身支持的高协议版本通知第一网元;
或者,
第二网元在响应消息中使用协议消息的信元携带所述自身支持的高协议版本通知第一网元;
或者,
第二网元在响应消息中使用协议消息的协议头部的空闲比特位携带所述自身支持的高协议版本通知第一网元。
8、根据权利要求6所述的方法,其特征在于,所述的将自身支持的高协议版本通知第一网元的步骤包括:
将自身支持的最高协议版本通知第一网元;
或者,
将支持的最高协议版本和最低协议版本通知第一网元;
或者,
将支持的所有协议版本通知第一网元;
或者,
将第一网元和第二网元均支持的最高协议版本通知第一网元;
或者,
将自身支持更高版本的指示通知第一网元。
9、一种通信协议版本协商的系统,其特征在于,包括:
第一网元,其在支持高协议版本的情况下,使用低协议版本发送协商协议版本的信息时,在该信息中包含第一网元支持的高协议版本;
第二网元,用于接收所述第一网元发来的协商协议版本的信息,并根据第一网元支持的高协议版本控制第一网元和第二网元之间采用共同支持的符合预定要求的协议版本进行交互。
10、根据权利要求9所述的系统,其特征在于,所述第一网元包括:
第一通知单元,用于将第一网元支持的最高协议版本发送给第二网元;
或者,
第二通知单元,用于将第一网元支持更高协议版本的指示发送给第二网元;
或者,
第三通知单元,用于将第一网元支持的所有协议版本发送给第二网元;
或者,
第四通知单元,用于将第一网元支持的最高协议版本和最低协议版本发送给第二网元。
11、根据权利要求9或10所述的系统,其特征在于,所述第二网元包括:
接收单元,用于接收到第一网元发来的使用低协议版本的消息;
比较单元,用于比较根据所述接收单元接收的消息确定的第一网元支持的最高协议版本和第二网元支持的最高协议版本;
通知单元,用于在根据所述比较单元的比较结果确定双方均支持的最高协议版本高于接收到的消息使用的低协议版本时,通知第一网元使用双方均支持的最高协议版本进行交互。
12、一种网元,包括与对端网元之间协商协议版本的单元,其特征在于,该网元还包括:
协议版本通知单元,用于在支持高协议版本的情况下,使用低协议版本发送协商协议版本的信息,并在该信息中包含本网元支持的高协议版本。
13、根据权利要求12所述的网元,其特征在于,所述协议版本通知单元具体包括:
第一通知单元,用于将第一网元支持的最高协议版本发送给第二网元;
或者,
第二通知单元,用于将第一网元支持更高协议版本的指示发送给第二网元;
或者,
第三通知单元,用于将第一网元支持的所有协议版本发送给第二网元;
或者,
第四通知单元,用于将第一网元支持的最高协议版本和最低协议版本发送给第二网元。
14、一种网元,包括与对端网元之间协商协议版本的单元,其特征在于,该网元还包括:
接收单元,用于接收对端网元发来的协商协议版本的信息,且所述信息中包含对端网元支持的高协议版本;
控制单元,用于根据信息接收单元接收的信息中的对端网元支持的高协议版本控制两端网元之间采用共同支持的符合预定要求的协议版本进行交互。
15、根据权利要求14所述的网元,其特征在于,所述控制单元包括:
比较单元,用于比较根据所述接收单元接收的消息确定的对端网元支持的最高协议版本和本端网元支持的最高协议版本;
通知单元,用于在根据所述比较单元的比较结果确定两端网元均支持的最高协议版本高于接收到的消息使用的低协议版本时,通知对端网元使用所述均支持的最高协议版本进行交互。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101217576A CN101388881A (zh) | 2007-09-13 | 2007-09-13 | 通信协议版本协商的方法、网元及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101217576A CN101388881A (zh) | 2007-09-13 | 2007-09-13 | 通信协议版本协商的方法、网元及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101388881A true CN101388881A (zh) | 2009-03-18 |
Family
ID=40478062
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2007101217576A Pending CN101388881A (zh) | 2007-09-13 | 2007-09-13 | 通信协议版本协商的方法、网元及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101388881A (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011023107A1 (zh) * | 2009-08-28 | 2011-03-03 | 华为技术有限公司 | 链路能力信息的协商方法、网络设备和通信系统 |
CN102238159A (zh) * | 2010-05-07 | 2011-11-09 | 华为技术有限公司 | 基于点到点协议的接入控制方法、设备和系统 |
CN102006215B (zh) * | 2009-09-01 | 2012-08-01 | 中国移动通信集团公司 | 一种数据传输方法、系统及设备 |
CN102651777A (zh) * | 2012-04-25 | 2012-08-29 | 华为技术有限公司 | 链路建立方法和设备 |
WO2014026316A1 (zh) * | 2012-08-13 | 2014-02-20 | 华为技术有限公司 | 媒体数据传输方法及设备 |
WO2014047868A1 (zh) * | 2012-09-28 | 2014-04-03 | 华为技术有限公司 | 协议栈类型协商方法及装置 |
CN105491092A (zh) * | 2014-09-18 | 2016-04-13 | 腾讯科技(深圳)有限公司 | 一种消息推送方法和装置 |
CN106454814A (zh) * | 2016-11-10 | 2017-02-22 | 中国科学院计算技术研究所 | 一种用于gtp隧道通信的系统与方法 |
CN106740196A (zh) * | 2016-12-12 | 2017-05-31 | 国网北京市电力公司 | 用于直流充电设备的充电方法和装置 |
CN106740168A (zh) * | 2016-11-18 | 2017-05-31 | 许继电源有限公司 | 一种电动汽车bms通信协议版本识别方法及装置 |
CN107193575A (zh) * | 2016-03-15 | 2017-09-22 | 日本冲信息株式会社 | 信息处理装置、信息处理系统以及信息处理方法 |
WO2019037458A1 (zh) * | 2017-08-22 | 2019-02-28 | 深圳市道通智能航空技术有限公司 | 通信方法和装置 |
CN109981522A (zh) * | 2017-12-27 | 2019-07-05 | 深圳市优必选科技有限公司 | 通信协议的兼容方法及装置 |
WO2022227805A1 (zh) * | 2021-04-25 | 2022-11-03 | 华为技术有限公司 | 通信方法和通信装置 |
-
2007
- 2007-09-13 CN CNA2007101217576A patent/CN101388881A/zh active Pending
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8824888B2 (en) | 2009-08-28 | 2014-09-02 | Huawei Technologies Co., Ltd. | Method for negotiating link capability information, network device, and communication system |
WO2011023107A1 (zh) * | 2009-08-28 | 2011-03-03 | 华为技术有限公司 | 链路能力信息的协商方法、网络设备和通信系统 |
CN102006215B (zh) * | 2009-09-01 | 2012-08-01 | 中国移动通信集团公司 | 一种数据传输方法、系统及设备 |
CN102238159A (zh) * | 2010-05-07 | 2011-11-09 | 华为技术有限公司 | 基于点到点协议的接入控制方法、设备和系统 |
CN102651777A (zh) * | 2012-04-25 | 2012-08-29 | 华为技术有限公司 | 链路建立方法和设备 |
CN102651777B (zh) * | 2012-04-25 | 2015-03-11 | 华为技术有限公司 | 链路建立方法和设备 |
WO2014026316A1 (zh) * | 2012-08-13 | 2014-02-20 | 华为技术有限公司 | 媒体数据传输方法及设备 |
CN103843449A (zh) * | 2012-09-28 | 2014-06-04 | 华为技术有限公司 | 协议栈类型协商方法及装置 |
WO2014047868A1 (zh) * | 2012-09-28 | 2014-04-03 | 华为技术有限公司 | 协议栈类型协商方法及装置 |
CN105491092A (zh) * | 2014-09-18 | 2016-04-13 | 腾讯科技(深圳)有限公司 | 一种消息推送方法和装置 |
CN107193575A (zh) * | 2016-03-15 | 2017-09-22 | 日本冲信息株式会社 | 信息处理装置、信息处理系统以及信息处理方法 |
CN106454814A (zh) * | 2016-11-10 | 2017-02-22 | 中国科学院计算技术研究所 | 一种用于gtp隧道通信的系统与方法 |
CN106740168A (zh) * | 2016-11-18 | 2017-05-31 | 许继电源有限公司 | 一种电动汽车bms通信协议版本识别方法及装置 |
CN106740196A (zh) * | 2016-12-12 | 2017-05-31 | 国网北京市电力公司 | 用于直流充电设备的充电方法和装置 |
CN106740196B (zh) * | 2016-12-12 | 2019-08-09 | 国网北京市电力公司 | 用于直流充电设备的充电方法和装置 |
WO2019037458A1 (zh) * | 2017-08-22 | 2019-02-28 | 深圳市道通智能航空技术有限公司 | 通信方法和装置 |
CN109428773A (zh) * | 2017-08-22 | 2019-03-05 | 深圳市道通智能航空技术有限公司 | 一种通信方法和装置 |
CN109981522A (zh) * | 2017-12-27 | 2019-07-05 | 深圳市优必选科技有限公司 | 通信协议的兼容方法及装置 |
WO2022227805A1 (zh) * | 2021-04-25 | 2022-11-03 | 华为技术有限公司 | 通信方法和通信装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101388881A (zh) | 通信协议版本协商的方法、网元及系统 | |
JP4477882B2 (ja) | 無線ローカル・エリア・ネットワーク中の隠れノードの検出 | |
KR100933399B1 (ko) | 이동통신 시스템에서 기지국이 전송하는 시스템 정보의수신방법 및 장치 | |
US9271195B2 (en) | Radio communication system, base station, gateway, and radio communication method | |
US7848755B2 (en) | Method for recovering ARQ data in wireless portable internet system | |
JP4755173B2 (ja) | 後で受信するデータを指示するため更新される圧縮状態レポートを生成する方法及び装置 | |
EP2392123A1 (en) | Methods and apparatus related to address generation, communication and/or validation | |
US6876631B2 (en) | Method and apparatus for frame transmission | |
CN101674235B (zh) | 数据传输方法和设备 | |
US8312339B2 (en) | Apparatuses and methods for controlling automatic repeat request (ARQ) reset in broadband wireless communication system | |
US7724755B2 (en) | Communications apparatus | |
US7783730B2 (en) | Signalling optimisations using hash functions | |
CN101465739B (zh) | 一种实现认证方式平滑过渡的方法及设备 | |
CN101415219A (zh) | 一种数据处理的方法、系统和装置 | |
JP2008289080A (ja) | 端末装置、ネットワーク装置およびデータ通信方法 | |
KR100735692B1 (ko) | 적응 부호화와 재전송을 이용한 부호화 변환 방법 | |
US20140177575A1 (en) | Method for establishing an application session, device and corresponding notification | |
CN112787759B (zh) | 一种优化跨基站切换效率的方法 | |
CN104683023A (zh) | 一种FCoE网络丢包后快速恢复的方法、设备及系统 | |
WO2007023966A1 (ja) | 通信装置、通信方法および通信プロトコル処理方法、通信端末装置およびその通信方法、ならびに通信システムおよびその通信方法 | |
CN113573252A (zh) | 数据传输方法、系统、芯片、电子设备及存储介质 | |
CN110139228B (zh) | 短信并行发送方法及装置 | |
KR100370060B1 (ko) | 차세대 이동 통신 시스템의 통신 운용 방법 | |
JP2001136209A (ja) | 通信装置 | |
WO2022022383A1 (zh) | 链路切换指示方法、装置、存储介质、芯片及相关设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20090318 |