辅网络设备释放方法、计算机可读存储介质及设备与流程

1.本技术的一个或多个实施例通常涉及通信领域，具体涉及辅网络设备释放方法、介质及设备


背景技术：

2.当用户设备(user equipment，ue)在进行高传输速率的业务时，例如ue进行实时对战游戏、使用gsp导航、高清视频通话等，为支持上述通信业务，ue可能会被配置为同时跟两个基站连接并进行数据通信，从而增加ue的传输速率。
3.ue同时连接到两个网络设备并进行数据通信的场景，可以称为多接入技术双连接(multi-radio dual connectivity，mr-dc)。其中，当e-utra(evolved-umts terrestrial radio access，进化的umts陆地无线接入)的网络设备作为主网络设备(master node，mn)，nr(new radio，新空口)的网络设备作为辅网络设备(secondary node，sn)时，该场景具体称为mr-dc中的e-utra-nr双连接(e-utra-nr dual connectivity，en-dc)；类似的，还有nr-e-utra双连接(nr-e-utra dual connectivity，ne-dc)以及nr-nr双连接(nr-nr dual connectivity，nr-dc)。
4.在dc场景下，ue会产生高的功率消耗从而出现设备的温度升高，可能导致用户在使用时感觉到设备过烫或掉电快，造成不好的用户体验。此时可以通过释放sn的方式，减少ue的功耗。


技术实现要素：

5.以下从多个方面介绍本技术，以下多个方面的实施方式和有益效果可互相参考。
6.根据本技术的第一方面，提供了一种辅网络设备释放方法，所述方法用于主网络设备，包括：向所述辅网络设备发送配置信息，所述配置信息用于指示所述主网络设备允许所述辅网络设备发起辅网络设备释放需求消息，其中，所述辅网络设备释放需求消息用于请求所述主网络设备执行所述辅网络设备释放；接收来自所述辅网络设备的所述辅网络设备释放需求消息。
7.根据本技术的第二方面，提供了一种辅网络设备释放方法，所述方法用于主网络设备，包括：向所述辅网络设备发送配置信息，所述配置信息用于指示所述主网络设备允许所述辅网络设备发起辅网络设备释放需求消息的条件，其中，所述辅网络设备释放需求消息用于请求所述主网络设备执行所述辅网络设备释放；接收来自所述辅网络设备的所述辅网络设备释放需求消息。
8.在一些实施方式中，所述方法还包括，向所述辅网络设备发送用于指示允许所述辅网络设备发起所述辅网络设备释放需求的条件的指示信息，所述条件包括以下至少一个：
9.所述主网络设备分流给所述辅网络设备的数据量在第一预定时间内低于第一阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息；
10.用户设备与所述辅网络设备之间的数据量在第二预定时间内低于第二阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息；
11.所述用户设备与所述主网络设备之间的数据量在第三预定时间内低于第三阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息。
12.在一些实施方式中，所述指示所述主网络设备允许所述辅网络设备发起辅网络设备释放需求的条件包括以下中的至少一个：
13.所述主网络设备始终允许所述辅网络设备发起所述辅网络设备释放需求；
14.所述主网络设备始终不允许所述辅网络设备发起所述辅网络设备释放需求；
15.所述主网络设备分流给所述辅网络设备的数据量在第一预定时间内低于第一阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息；
16.用户设备与所述辅网络设备之间的数据量在第二预定时间内低于第二阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息；
17.所述用户设备与所述主网络设备之间的数据量在第三预定时间内低于第三阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息。
18.在一些实施方式中，方法还包括所述主网络设备接收来自所述辅网络设备的指示消息，所述指示消息用于指示所述辅网络设备支持来自所述用户设备的辅网络设备释放请求；或者，所述指示消息用于指示所述辅网络设备支持来自所述用户设备的基于节能目的的辅网络设备释放请求。
19.在一些实施方式中，所述指示消息由所述辅网络设备接收到所述用户设备的辅网络设备释放请求之后，发送给所述主网络设备；或者，所述指示消息由所述辅网络设备接收到所述用户设备的基于节能目的的辅网络设备释放请求之后，发送给所述主网络设备。
20.根据本技术的第三方面，提供了一种辅网络设备释放方法，该方法用于所述辅网络设备，所述方法包括：接收来自主网络设备的配置信息，所述配置信息包括指示所述主网络设备允许所述辅网络设备发起辅网络设备释放需求消息，其中所述辅网络设备释放需求消息用于请求所述主网络设备执行所述辅网络设备释放；以及接收辅网络设备释放请求，向所述主网络设备发送辅网络设备释放需求消息。
21.根据本技术的第四方面，提供了一种辅网络设备释放方法，该方法用于所述辅网络设备，所述方法包括接收来自主网络设备的配置信息，所述配置信息包括指示所述主网络设备允许所述辅网络设备发起辅网络设备释放需求的条件，其中所述辅网络设备释放需求用于请求所述主网络设备执行所述辅网络设备释放；以及接收辅网络设备释放请求，在满足所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息的条件的情况下，向所述主网络设备发送辅网络设备释放需求消息。
22.在一些实施方式中，所述方法还包括，从所述主网络设备接收用于指示允许所述辅网络设备发起所述辅网络设备释放需求的条件的指示信息，所述条件包括以下至少一个：
23.所述主网络设备分流给所述辅网络设备的数据量在第一预定时间内低于第一阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求；
24.用户设备与所述辅网络设备之间的数据量在第二预定时间内低于第二阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求；
25.所述用户设备与所述主网络设备之间的数据量在第三预定时间内低于第三阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求。
26.在一些实施方式中，所述指示所述主网络设备允许所述辅网络设备发起辅网络设备释放需求的条件包括以下中的至少一个：
27.所述主网络设备始终允许所述辅网络设备发起所述辅网络设备释放需求；
28.所述主网络设备始终不允许所述辅网络设备发起所述辅网络设备释放需求；
29.所述主网络设备分流给所述辅网络设备的数据量在第一预定时间内低于第一阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息；
30.用户设备与所述辅网络设备之间的数据量在第二预定时间内低于第二阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息；
31.所述用户设备与所述主网络设备之间的数据量在第三预定时间内低于第三阈值的情况下，所述主网络设备允许所述辅网络设备发起所述辅网络设备释放需求消息。
32.在一些实施方式中，还包括向所述主网络设备发送指示消息，所述指示消息用于指示所述辅网络设备支持来自所述用户设备的辅网络设备释放请求；或者，所述指示消息用于指示所述辅网络设备支持来自所述用户设备的基于节能目的的辅网络设备释放请求。
33.在一些实施方式中，接收辅网络设备释放请求，包括接收来自用户设备的所述辅网络设备释放请求；或者接收来自用户设备的基于节能目的的辅网络设备释放请求。
34.根据本技术的第五方面，提供了一种辅网络设备释放方法，该方法用于主网络设备，所述方法包括接收来自所述辅网络设备的用于指示释放所述辅网络设备的指示消息；在确定所述主网络设备允许释放所述辅网络设备的情况下，向所述辅网络设备发送辅网络设备释放请求消息，其中所述辅网络设备释放请求消息用于请求释放所述辅网络设备。
35.在一些实施方式中，确定所述主网络设备允许释放所述辅网络设备包括以下至少一种情况：
36.所述主网络设备分流给所述辅网络设备的数据量在第一预定时间内低于第一阈值的情况下，所述主网络设备允许发起所述辅网络设备释放请求消息；
37.所述用户设备与所述辅网络设备之间的数据量在第二预定时间内低于第二阈值的情况下，所述主网络设备允许发起所述辅网络设备释放请求消息；
38.所述用户设备与所述主网络设备之间的数据量在第三预定时间内低于第三阈值的情况下，所述主网络设备允许发起所述辅网络设备释放请求消息。
39.在一些实施方式中，用于指示释放所述辅网络设备的指示消息由所述辅网络设备接收到所述用户设备的辅网络设备释放请求之后，发送给所述主网络设备；或者，由所述辅网络设备接收到所述用户设备的基于节能目的的辅网络设备释放请求之后，发送给所述主网络设备。
40.根据本技术的第六方面，提供了一种辅网络设备释放方法，该方法用于辅网络设备，所述方法包括向主网络设备发送用于指示释放所述辅网络设备的指示消息，接收来自所述主网络设备的辅网络设备释放请求消息，其中所述辅网络设备释放请求消息用于请求释放所述辅网络设备。
41.在一些实施方式中，用于指示释放所述辅网络设备的指示消息由所述辅网络设备接收到所述用户设备的辅网络设备释放请求之后，发送给所述主网络设备；或者，由所述辅
网络设备接收到所述用户设备的基于节能目的的辅网络设备释放请求之后，发送给所述主网络设备。
42.根据本技术的第七方面，提供了一种辅网络设备释放方法，该方法用于主网络设备，所述方法包括接收用于请求所述主网络设备执行所述辅网络设备释放的第一辅网络设备释放需求消息，执行所述辅网络设备释放，并向所述辅网络设备发送所述辅网络设备释放的确认消息，向所述辅网络设备发送添加所述辅网络设备的请求消息以及指示消息，所述指示信息用于指示预设时间内不允许释放所述辅网络设备；或向所述辅网络设备发送添加所述辅网络设备的请求消息，所述请求信息还用于指示预设时间内不允许释放所述辅网络设备。
43.在一些实施方式中，所述指示信息中携带所述预设时间的信息；和/或所述预设时间为配置于所述辅网络设备的时间。
44.在一些实施方式中，所述方法还包括，接收用于请求所述主网络设备执行所述辅网络设备释放的第二辅网络设备释放需求消息，并执行所述辅网络设备释放。
45.根据本技术的第八方面，提供了一种辅网络设备释放方法，该方法用于所述辅网络设备，所述方法包括向主网络设备发送用于请求所述主网络设备执行所述辅网络设备释放的第一辅网络设备释放需求消息，接收来自所述主网络设备的所述辅网络设备释放的确认消息，以及接收来自所述主网络设备的添加所述辅网络设备的请求消息以及指示消息，所述指示信息用于指示预设时间内不允许释放所述辅网络设备；或接收来自所述主网络设备的添加所述辅网络设备的请求消息，所述请求信息还用于指示预设时间内不允许释放所述辅网络设备。
46.在一些实施方式中，所述指示信息中携带所述预设时间的信息；和/或所述预设时间为配置于所述辅网络设备的时间。
47.在一些实施方式中，所述方法还包括，在经过所述预设时间之后，向所述主网络设备发送请求所述主网络设备执行所述辅网络设备释放的第二辅网络设备释放需求消息。
48.根据本技术的第九方面，提供了一种机器可读介质，在所述介质上存储有指令，当所述指令在所述机器上运行时，使得所述机器执行根据本技术第一到第八方面所述的方法。
49.根据本技术的第十方面，提供了一种设备，包括：处理器；存储器，在所述存储器上存储有指令，当所述指令被所述处理器运行时，使得所述用户设备执行根据本技术第一到第八方面所述的方法。
附图说明
50.图1(a)-图1(c)是现有的几种标准化的sn释放机制的示意图；
51.图2是根据本技术实施例的一种应用场景的示意图；
52.图3是根据本技术的一个实施例的sn释放方法的信号流图；
53.图4a是根据本技术的一个实施例的用于mn的sn释放方法的流程图；
54.图4b是根据本技术的一个实施例的用于sn的sn释放方法的流程图；
55.图5是根据本技术的另一个实施例的sn释放方法的信号流图；
56.图6a是根据本技术的另一个实施例的用于mn的sn释放方法的流程图；
57.图6b是根据本技术的另一个实施例的用于sn的sn释放方法的流程图；
58.图7是根据本技术的又一个实施例的sn释放方法的信号流图；
59.图8a是根据本技术的又一个实施例的用于mn的sn释放方法的流程图；
60.图8b是根据本技术的又一个实施例的用于sn的sn释放方法的流程图。
具体实施方式
61.下面结合具体实施例和附图对本技术做进一步说明。
62.应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元或是数据，但是这些单元或数据不应当受这些术语限制。使用这些术语仅仅是为了将一个特征与另一个特征进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一特征可以被称为第二特征，并且类似地第二特征可以被称为第一特征。
63.应注意的是，在本说明书中，相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
64.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术的实施方式作进一步地详细描述。
65.第三代合作伙伴计划(3rd generation partnership project，3gpp)的标准ts 38.423中对sn释放机制做了相关的规定。图1(a)-图1(c)是现有的几种标准化的sn释放机制的示意图。需要说明的是，该sn释放机制为针对某一个ue的sn释放。图1(a)和图1(b)显示的是由mn发起的sn释放。其中，mn向sn发送sn释放请求(s-node release request)消息，如果sn确定能够释放，则如图1(a)所示，sn停止向ue提供用户数据并向mn发送sn释放承认(s-node release request acknowledge)消息；如果sn确定不能够释放，如图1(b)所示，sn发送sn释放拒绝(s-node release reject)消息。mn接收到sn发送的释放承认(s-node release request acknowledge)消息后，mn执行sn释放，将配置给对应ue的sn释放，ue还可以清除对应的sn相关的配置，ue不再处于双连接网络架构下。
66.而由sn发起的sn释放则如图1(c)所示，sn向mn发送sn释放需求(s-node release required)消息，sn会接收到来自mn的sn释放确认(s-node release confirm)消息并停止向ue提供用户数据。根据现有的sn释放机制，由sn发起的sn释放不存在失败的情况。mn向sn发送的sn释放的确认消息(s-node release confirm)消息后，mn执行sn释放，将配置给对应ue的sn释放，ue还可以清除对应的sn相关的配置，ue不再处于双连接网络架构下。
67.图2是根据本技术实施例的一种应用场景的示意图。如图2所示，ue100同时与网络设备200和网络设备300连接并进行数据通信，其中与ue100建立控制面连接的网络设备200称为主网络设备、主节点、主基站或者mn(master node，mn)，而与ue100只建立用户面连接的网络设备300称为辅网络设备、辅节点、辅基站或者sn(secondary node，sn)。可以理解为，ue的全部无线链路控制信令消息和功能都由mn(主网络设备)进行管理，而数据面无线承载可以由mn或者sn(辅网络设备)独立服务，也可由mn和sn同时服务。通过mn和sn两条腿进行数据传输，可以提高网络的吞吐量。对于有节能需求的ue来说，ue可以向sn指示由于节能的目的期望释放sn，具体的，ue可以通过ue辅助信息消息向sn指示由于节能目的期望释放sn，该消息可以直接发送给sn、或者通过mn转发给sn。
68.当sn接收到ue释放sn的期望后，sn可以决定是否给ue释放sn。若sn决定释放sn，则可以发起sn释放流程，向mn发送sn释放需求消息。如上所述，根据现有的sn释放机制，对于sn发起的sn释放必定成功。
69.在en-dc场景下，mn与sn之间不交互基站的负载信息。当mn负载较重的时候，从mn的角度来说，mn需要sn分流数据从而均衡负载，如果sn直接发起sn释放可能导致mn负载更重，影响数据速率。因此，虽然ue可能有节能的需求从而期望释放sn，但从网络角度需要考虑网络中的数据负载，当网络数据量较大的时候仍然释放sn的话，可能导致更严重的数据速率降低。
70.针对上述的问题，本技术的技术方案提供了一种sn释放方法，能够根据主网络设备(例如：mn)的需求来执行有效合理的sn释放。
71.为了下述各实施例的描述清楚简洁，首先给出一些技术术语的简要介绍：
72.1)ue为用户设备，又称为终端、终端设备，是一种向用户提供语音和/或数据连通性的设备，常见的终端设备例如包括：车载设备、手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，mid)、可穿戴设备(例如包括：智能手表、智能手环、计步器等)、个人数字助理、便携式媒体播放器、导航设备、视频游戏设备、机顶盒、虚拟现实和/或增强现实设备、物联网设备、工业控制设备、流媒体客户端设备、电子书、阅读设备、pos机以及其他设备。
73.2)网络设备，又称为无线接入网(radio access network，ran)设备是一种将用户设备接入到无线网络的设备，其包括各种通信制式中的网络设备，例如包括但不限于：基站、演进型节点b(evolved node b，enb)、无线网络控制器(radio network controller，rnc)、节点b(node b，nb)、网络设备控制器(base station controller，bsc)、网络设备收发台(base transceiver station,bts)、家庭网络设备(例如，home evolved nodeb，或home node b，hnb)、基带单元(baseband unit，bbu)等。网络设备包括了各类频率制式的网络设备，例如包括但不限于：低频网络设备、高频网络设备。
74.接下来，结合附图对根据本技术的sn释放方法进行详细的说明。在以下实施例中，以主网络设备为mn、辅网络设备为sn为例进行介绍，在具体实施过程中，并不限于这种场景。
75.图3是根据本技术的一个实施例的sn释放方法的信号流图。如图3所示，ue100同时连接到mn200以及sn300，并进行数据通信。
76.mn200和sn300进一步包括控制器和收发器。其中，控制器可以包括，但不限于，调制解调器、中央处理器(central processing unit，cpu)、应用处理器(application processor，ap)、微处理器(micro-programmed control unit，mcu)、人工智能(artificial intelligence，ai)处理器或可编程逻辑器件(field programmable gate array，fpga)等的处理电路。其中，调制解调器用于根据3gpp的协议，将处于需要发射的基带频域的信息(例如信号和/或数据)调制成可以通过收发器传输的模拟信号，和将收发器接收到的模拟信号解调成ue100的处理器能够处理的基带频域的信息。不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。在一种可能的实施方式中，控制器可以运行操作系统，例如，android、ios、windows os、linux和鸿蒙操作系统等。在另一些可能的实施方式中，控制器可以运行特定的应用程序。控制器中还可设置存储器，用于存储指令和数据。在
本技术的实施例中，控制器可以被配置为控制收发器进行信号的传送，并执行根据下文所述的sn释放方法。
77.收发器用于为mn和sn提供无线连接接口(如射频前端模块，天线等)，进而通过一个或多个网络与任意其他合适的设备进行通信。本领域技术人员可以理解，收发器可以是提供包括无线局域网(wireless local area networks，wlan)(如无线保真(wireless fidelity，wi-fi)网络)、蓝牙(bluetooth，bt)、第三代移动通信技术(3rd-generation mobile communication technology，3g)网络、第四代移动通信技术(the4th generation mobile communication technology，4g)网络、第五代移动通信技术(5th-generation mobile communication technology，5g)网络、和/或未来演进的公共陆地移动网络(public land mobile network，plmn)的数据连接服务等无线通信的网络接口。本领域技术人员可以理解，图3所示的mn和sn包括一个收发器仅为举例说明，收发器的数量不具体限定，还可以是两个或更多。
78.如图3所示，在步骤301，sn300向mn200发送指示sn300是否支持基于ue100发起sn释放的指示消息。
79.在一个实例中，ue100发起的sn释放可以是基于ue请求的或ue原因触发的sn释放，或者可以是基于节能目的的sn释放，例如ue100的电量低于阈值，或者用户开启了ue100的节能模式的情况。本领域技术人员能够理解，ue发起的sn释放不局限于节能目的，可以基于其他目的而发起sn释放，本技术对此不作具体的限定。
80.在一个实例中，sn在发送给mn的某一个现有的消息里携带相关的指示。也即:sn可以复用现有的消息来发送该指示信息，现有的消息例如为ue上下文(ue context)消息、pdu会话(protocol data unit session)消息等等。例如，可以在某一个现有的消息中携带0或1的一个比特(当然也可以委多个比特，例如:2个比特、三个比特等等)的字段，用0表示sn不支持基于ue100发起的sn释放，用1表示sn支持基于ue100发起的sn释放。又例如，可以在某一个现有的消息中携带一个比特(当然也可以为多个比特，例如：2个比特、3个比特等等)的字段，该字段不存在表示sn不支持基于ue100发起的sn释放，该字段存在表示sn支持基于ue100发起的sn释放。本领域技术人员能够理解，sn也可以通过一个新的消息给mn发出指示，本技术对此不作具体的限定。
81.在一个实例中，如果该指示信息中指示sn不支持基于ue100发起的sn释放，则mn不需要对sn做出响应。如果该指示信息中指示sn支持基于ue100发起的sn释放，根据本技术的一个实施例，在接下来的步骤302，mn会进一步配置sn如何对基于ue100发起的sn释放做出响应。
82.接下来，在步骤302，如果步骤301中sn向mn指示了其能够支持基于ue发起的sn释放，mn会向sn发送配置信息，用于配置sn如何对基于ue100发起的sn释放做出响应。
83.在具体实施过程中，步骤s301为可选步骤，mn既可以基于sn的指示信息向sn发送配置信息，mn也可以主动向sn发送配置信息。
84.在一个实例中，mn发送给sn的配置信息可以以ue、小区或基站为粒度进行配置，即配置信息取决于ue、小区或基站的不同而不同。例如，对于某一个ue，mn允许发起sn释放，而对于另一个ue，mn不允许发起sn释放；或者是针对不同的ue，mn发送给sn的配置信息所指示的允许sn发起sn释放的条件不同。
85.在一个实例中，配置信息可以是mn是否允许sn基于ue的请求而发起sn释放，例如允许或不允许。同样，mn可以在发送给sn的某一个现有的消息里做出相关的允许或不允许的指示。也即:sn可以复用现有的消息来发送该指示信息，现有的消息例如为ue上下文(ue context)消息、pdu会话(protocol data unit session)消息等等。例如，可以在某一个现有的消息中携带0或1的一个比特(或多个比特)的字段，基于字段的取值来标识允许或者不允许，例如：用0表示不允许，用1表示允许。又例如，可以在某一个现有的消息中携带一个比特(当然也可以为多个比特，例如：2个比特、3个比特等等)的字段，该字段不存在表示sn不支持基于ue100发起的sn释放，该字段存在表示sn支持基于ue100发起的sn释放。
86.又或者，如果mn向ue发送配置信息，则认为允许sn基于ue的请求而发起sn释放；如果mn未向ue反馈信息，则认为不允许sn基于ue的请求而发起sn释放。又或者，如果该配置信息中的预设字段存在取值，则认为允许sn基于ue的请求而发起sn释放；如果该预设字段的取值为空，则认为不允许sn基于ue的请求而发起sn释放。
87.或者是以mn是否给出明确指示来表示是否允许sn发起sn释放。例如，mn在发送给sn的某个消息中携带明确的指示信息，此时，表示mn允许sn发起sn释放。如果未携带明确的指示信息，则表示mn不允许sn发起sn释放。
88.另外，本领域技术人员能够理解，配置信息可以携带在现有的某个消息中，或者也可以作为一个新的消息实现，本技术对此不作具体的限定。
89.在一个实例中，配置信息还可以是用于指示mn允许sn发起sn释放的条件。例如，mn始终允许或者始终不允许sn发起sn释放。
90.在另一个实例中，mn分流给sn的数据量在第一预定时间内低于第一阈值的情况下，mn允许sn发起sn释放。举例来说，假设在一分钟内mn分流给sn的数据量低于20mb，此时可以认为释放sn之后不会加重mn的负载，因此mn允许sn发起sn释放。
91.在另一种实例中，mn允许sn发起sn释放的条件还可以是ue与sn之间的数据量在第二预定时间内低于第二阈值的情况下，mn允许sn发起sn释放。
92.在另一种实例中，也可以是ue与mn之间的数据量在第三预定时间内低于第三阈值的情况下，mn允许sn发起sn释放等等。
93.在不冲突的情况下，以上各条件也可以组合使用。
94.上述的预定时间可以是一分钟、五分钟等等，并且预定时间可以是sn预先设定的默认值，也可以由mn通过配置信息指定。同样，本领域技术人员能够理解，数据量的阈值可以是sn预先设定的默认值，也可以由mn通过配置信息指定的值，并且预定的时间和数据量的阈值根据实际情况和需要都是可变的，本技术不对此做具体限定。
95.在一个实例中，还可以是mn向sn发送配置信息指示mn允许sn发起sn释放其中，mn向sn发送配置信息可以仅指示允许sn基于ue的请求发起sn释放，对于不允许sn基于ue的请求发起sn释放可以不指示，或者mn也可以既指示允许释放，也指示不允许释放，对于具体如何指示，前面已作介绍，在此不再赘述。在一种可选的实施例中，mn还可以进一步发送包括上述用于指示mn允许sn发起sn释放的条件的指示消息。其中该配置信息与指示信息可以包含在同一条消息(或者信息)，或者包含在不同的信息中。
96.本领域技术人员能够理解，指示释放条件的指示消息和配置信息可以是同一个消息，例如通过指示发起sn释放的条件而隐含指示了mn允许sn发起sn释放，或者配置消息的
某些字段中携带了指示消息。同样，指示消息和配置信息也可以是不同的消息，例如现有的两个不同的消息中分别携带配置信息和指示消息的字段，也可以是单独的两个不同的消息。本技术不对指示消息和配置消息做具体的限定。
97.在步骤303，ue100向sn300发出希望释放sn的指示消息，如上所述，ue100可以是基于节能目的或者是其他目的而希望释放sn。其中，该希望sn释放的指示消息中可以携带原因值，该原因值指示希望释放sn的原因(例如：节能目的)，该希望sn释放的指示信息也可以不携带该原因值，可以默认为该希望释放sn的请求是处于节能目的发起的。或者，该希望释放sn的指示信息也可以仅仅指示ue希望释放sn，而不指示原因。
98.在步骤304，sn接收到来自ue的释放sn的指示消息后，会根据上述步骤302中获得的配置信息和/或指示消息来判断是否发起sn释放。
99.如上所述，如果配置信息和/或指示消息指示mn不允许sn发起sn释放，则sn不会发起sn释放的流程；如果配置信息和/或指示消息指示mn允许sn发起sn释放，则sn可以发起sn释放的流程；如果配置信息和/或指示消息是指示了发起sn释放的条件，sn会根据这些条件进行判断，在满足条件的情况下才可以发起sn释放流程，反之则不发起sn释放流程。
100.在步骤304中，如果sn判断能够发起sn释放，则在步骤305，向mn发送sn释放需求(s-node release required)消息。mn接收到来自sn的释放需求消息，在步骤306执行sn释放，并且在步骤307，将sn释放确认(s-node release confirm)消息发送给sn。mn向sn发送的sn释放的确认消息(s-node release confirm)消息后，mn执行sn释放，将配置给对应ue的sn释放，ue还可以清除对应的sn相关的配置，使得ue不再处于双连接网络架构下。
101.这里，步骤305-307的sn释放的发起、执行以及sn释放的确认过程作为现有技术，可参考上述3gpp的相关标准，在此不再赘述。
102.在另一种可能实现方式中，步骤302中的配置信息也可以是由mn200发送给ue100。基于配置信息的规定或限定的条件，ue100可以决定是否能够发起sn释放，具体的流程可参考图3，在此不再赘述。
103.接下来参考图4a和图4b对根据本技术一个实施例的sn释放方法的流程进行说明。
104.图4a是根据本技术一个实施例的用于mn的sn释放方法的流程图。如图4a所示，在步骤401，mn从sn接收指示sn300是否支持基于ue100发起sn释放的指示消息。
105.在具体实施过程中，步骤s401为可选步骤，mn既可以基于sn的指示信息向sn发送配置信息，mn也可以主动向sn发送配置信息。
106.在一个实例中，ue100发起的sn释放可以是ue请求的或ue原因触发的sn释放，或者可以是基于基于节能目的的sn释放，例如ue100的电量低于阈值，或者用户开启了ue100的节能模式的情况。本领域技术人员能够理解，ue发起的sn释放不局限于节能目的，可以基于其他目的而发起sn释放，本技术对此不作具体的限定。
107.在一个实例中，sn在发送给mn的某一个现有的消息里携带相关的指示。也即:sn可以复用现有的消息来发送该指示信息，现有的消息例如为：上下文(ue context)、pdu会话(protocol data unit session)消息等等。例如，可以在某一个现有的消息中携带0或1的一个比特(当然也可以委多个比特，例如:2个比特、三个比特等等)的字段，用0表示sn不支持基于ue100发起的sn释放，用1表示sn支持基于ue100发起的sn释放。又例如，可以在某一个现有的消息中携带一个比特(当然也可以为多个比特，例如：2个比特、3个比特等等)的字
段，该字段不存在表示sn不支持基于ue100发起的sn释放，该字段存在表示sn支持基于ue100发起的sn释放。本领域技术人员能够理解，sn也可以通过一个新的消息给mn发出指示，本技术对此不作具体的限定。
108.接下来，如果sn不支持基于ue100发起的sn释放，则mn不需要对sn做出响应，流程在步骤404结束。如果sn支持基于ue100发起的sn释放，根据本技术的一个实施例，在接下来的步骤403，mn会进一步配置sn如何对基于ue100发起的sn释放做出响应。
109.在步骤403，如果步骤401中sn向mn指示了其能够支持基于ue发起的sn释放，mn会向sn发送配置信息，用于配置sn如何对基于ue100发起的sn释放做出响应。
110.在一个实例中，mn发送给sn的配置信息可以以ue、小区或基站为粒度进行配置，即配置信息取决于ue、小区或基站的不同而不同。例如，针对不同的ue，mn发送给sn的配置信息中指示mn是否允许sn基于ue的请求而发起sn释放是不同的，或者配置信息所指示的允许sn发起sn释放的条件不同。
111.在一个实例中，配置信息可以是mn是否允许sn基于ue的请求而发起sn释放，例如允许或不允许。同样，mn可以在发送给sn的某一个现有的消息里做出相关的允许或不允许的指示。例如，可以在某一个现有的消息中携带0或1的一个比特(或多个比特)的字段，基于字段的取值来标识允许或者不允许，例如：用0表示不允许，用1表示允许。又例如，可以在某一个现有的消息中携带一个比特(当然也可以为多个比特，例如：2个比特、3个比特等等)的字段，该字段不存在表示sn不支持基于ue100发起的sn释放，该字段存在表示sn支持基于ue100发起的sn释放。
112.又或者，如果mn向ue发送配置信息，则认为允许sn基于ue的请求而发起sn释放；如果mn未向ue反馈信息，则认为不允许sn基于ue的请求而发起sn释放。又或者，如果该配置信息中的预设字段存在取值，则认为允许sn基于ue的请求而发起sn释放；如果该预设字段的取值为空，则认为不允许sn基于ue的请求而发起sn释放。或者是以mn是否给出明确指示来表示是否允许sn发起sn释放。例如，mn在发送给sn的某个消息中携带明确的指示信息，此时，表示mn允许sn发起sn释放。如果未携带明确的指示信息，则表示mn不允许sn发起sn释放。
113.另外，本领域技术人员能够理解，配置信息可以携带在现有的某个消息中，或者也可以作为一个新的消息实现，本技术对此不作具体的限定。
114.在一个实例中，配置信息还可以是用于指示mn允许sn发起sn释放的条件。例如，mn始终允许或者始终不允许sn发起sn释放。
115.在另一个实例中，mn分流给sn的数据量在第一预定时间内低于第一阈值的情况下，mn允许sn发起sn释放。举例来说，假设在一分钟内mn分流给sn的数据量低于20mb，此时可以认为释放sn之后不会加重mn的负载，因此mn允许sn发起sn释放。
116.本领域技术人员能够理解，上述限定的条件还可以是ue与sn之间的数据量在第二预定时间内低于第二阈值的情况下，mn允许sn发起sn释放；或者是用户设备与mn之间的数据量在第三预定时间内低于第三阈值的情况下，mn允许sn发起sn释放等等。在不冲突的情况下，以上各条件也可以组合使用。
117.上述的预定时间可以是一分钟、五分钟等等，并且预定时间可以是sn预先设定的默认值，也可以由mn通过配置信息指定。同样，本领域技术人员能够理解，数据量的阈值可
以是sn预先设定的默认值，也可以由mn通过配置信息指定的值，并且预定的时间和数据量的阈值根据实际情况和需要都是可变的，本技术不对此做具体限定。
118.在一个实例中，还可以是mn向sn发送配置信息指示mn允许sn发起sn释放其中，mn向sn发送配置信息可以仅指示允许sn基于ue的请求发起sn释放，对于不允许sn基于ue的请求发起sn释放可以不指示，或者mn也可以既指示允许释放，也指示不允许释放，对于具体如何指示，前面已作介绍，在此不再赘述。在一种可选的实施例中，mn还可以进一步发送包括上述用于指示mn允许sn发起sn释放的条件的指示消息。其中该配置信息与指示信息可以包含在同一条消息(或者信息)，或者包含在不同的信息中。
119.本领域技术人员能够理解，指示释放条件的指示消息和配置信息可以是同一个消息，例如通过指示发起sn释放的条件而隐含指示了mn允许sn发起sn释放，或者配置消息的某些字段中携带了指示消息。同样，指示消息和配置信息也可以是不同的消息，例如现有的两个不同的消息中分别携带配置信息和指示消息的字段，也可以是单独的两个不同的消息。本技术不对指示消息和配置消息做具体的限定。
120.接下来，如果步骤403中发送的配置信息和/或指示消息指示mn允许sn发起sn释放，或者是sn满足了mn允许发起sn释放的条件，在步骤405，mn接收来自sn的sn释放需求消息(s-node release required)。mn接收到来自sn的释放需求消息，在步骤406执行sn释放，并且在步骤407，将sn释放确认消息(s-node release confirm)发送给sn。mn向sn发送的sn释放的确认消息(s-node release confirm)消息后，mn执行sn释放，将配置给对应ue的sn释放，ue还可以清除对应的sn相关的配置，使得ue不再处于双连接网络架构下。
121.同样，这里所说的步骤405-407的sn释放的发起、执行以及sn释放的确认过程作为现有技术，可参考上述3gpp的相关标准，在此不再赘述。
122.图4b是根据本技术一个实施例的用于sn的sn释放方法的流程图。如图4b所示，在步骤410，sn向mn发送指示sn是否支持基于ue发起的sn释放的指示信息。
123.如步骤301和401所述，可以是在现有的消息中添加例如0或1的一个比特(或者多个比特)的字段来表示支持或不支持，指示信息也可以是一个新的消息。另外，ue发起的sn释放可以是基于节能的目的或其他目的，在此不再赘述。
124.在一个实例中，sn在发送给mn的某一个现有的消息里携带相关的指示。也即:sn可以复用现有的消息来发送该指示信息，现有的消息例如为ue上下文(ue context)消息、pdu会话(protocol data unit session)消息等等。例如，可以在某一个现有的消息中携带0或1的一个比特(当然也可以委多个比特，例如:2个比特、三个比特等等)的字段，用0表示sn不支持基于ue100发起的sn释放，用1表示sn支持基于ue100发起的sn释放。又例如，可以在某一个现有的消息中携带一个比特(当然也可以为多个比特，例如：2个比特、3个比特等等)的字段，该字段不存在表示sn不支持基于ue100发起的sn释放，该字段存在表示sn支持基于ue100发起的sn释放。本领域技术人员能够理解，sn也可以通过一个新的消息给mn发出指示，本技术对此不作具体的限定。
125.在具体实施过程中，步骤s410为可选步骤，mn既可以基于sn的指示信息向sn发送配置信息，mn也可以主动向sn发送配置信息。
126.接下来，如果sn不支持基于ue发起的sn释放，则流程在步骤413结束。如果sn发送的指示消息表示sn支持发起sn释放，则在步骤411会接收到来自mn的配置信息。
127.步骤411中，sn接收的来自mn的配置信息可以是指示mn是否允许sn发起sn释放，也可以是mn允许sn发起sn释放的条件，或者也可以是在mn允许sn发起sn释放的情况下，进一步包括mn允许sn发起sn释放的条件。具体的可参考上述步骤302和403的描述，在此不再赘述。
128.在步骤412，接收到来自ue的释放sn的指示消息后，sn会基于从mn接收的配置信息和/或指示消息进行判断。在步骤414中，如果sn判断不符合配置信息的规定或不满足配置信息限定的条件的情况下，则流程结束。如果sn判断当前符合配置信息的规定或者满足了配置信息所限定的mn允许sn发起sn释放的条件的情况下，执行步骤415。其中，来自ue的sn释放的指示消息中可以携带原因值，该原因值指示希望释放sn的原因(例如：节能目的)，该希望sn释放的指示信息也可以不携带该原因值，可以默认为该希望释放sn的请求是处于节能目的发起的。或者，该希望释放sn的指示信息也可以仅仅指示ue希望释放sn，而不指示原因。
129.在步骤415，sn向mn发送sn释放需求消息(s-node release required)，mn接收到来自sn的释放需求消息，会执行sn释放。并且在步骤416，sn会接收到来自mn的sn释放确认消息(s-node release confirm)，用于表示sn的释放已经完成。
130.参考以上图3以及图4a和图4b对根据本技术一个实施例的sn释放方法进行了说明。根据本技术一个实施例的sn释放方法，通过mn向sn发送配置信息和/或指示信息，对于sn释放设定了一定的限制和条件，避免了由于sn释放可能导致mn负载更重、影响数据速率的问题。
131.进一步的，sn释放完成之后，mn还可以选择添加sn。mn添加的sn可以是在之前释放的sn，也可以是其他的sn，本技术不对此做具体限定。根据本技术的实施例，mn还可以在sn添加过程中实现对sn基于ue发起的sn释放的控制，具体的流程和方法将在后面的实施例中详细描述。
132.图5是根据本技术另一个实施例的sn释放方法的信号流图。ue100同时连接到mn200以及sn300，并进行数据通信。mn200和sn300中的收发器负责信息传送，控制器用于控制收发器进行信息传送，并执行根据本技术的sn释放方法。具体的可参考上述图3的说明，在此不再赘述。
133.如图5所示，在步骤501，sn300接收到来自ue100的发起sn释放的指示消息。
134.在一个实例中，ue100发起的sn释放可以是基于节能目的的sn释放，例如ue100的电量低于阈值，或者用户开启了ue100的节能模式的情况。本领域技术人员能够理解，ue发起的sn释放不局限于节能目的，可以基于其他目的而发起sn释放，本技术对此不作具体的限定。
135.sn收到ue释放sn的指示后，与sn直接向mn发送sn释放需求消息不同，根据本技术的另一个实施例，在步骤502，sn300向mn200发送sn释放的指示消息，该指示消息可以用于指示sn请求mn发起sn释放或者也可以是请求mn允许sn来发起sn释放。
136.在一个实例中，sn300可以是将来自ue100的指示消息转发给mn200；或者，sn300可以将收到ue100的释放sn的指示消息通知mn200，或者sn300可以基于ue发送的sn释放的指示消息生成新的sn释放的指示消息，并将其发送给mn，同时可以将自己是否能够发起sn释放的情况通知mn，最终由mn200来决定是否发起sn释放，本技术实施例不对此做具体限定。
但是本领域技术人员能够理解，在步骤502，mn200获知即将发起的sn释放，并且会在之后的步骤503中做出决定是否发起sn释放。
137.在步骤503，mn200基于接收到的指示信息，执行是否发起sn释放的判断。
138.在一个实例中，如果上述步骤502的指示消息是用于指示sn请求mn发起sn释放的情况下，mn200可以根据sn300的期望结合mn200自身的需要来决定是否释放sn。
139.在一个实例中，与图3所示的实施例一样，mn200执行的判断可以是mn是否允许发起sn释放。具体的，mn200可以根据自身的负载条件进行判断，例如上述的mn分流给sn的数据量在第一预定时间内低于第一阈值的情况下，mn允许sn发起sn释放。举例来说，假设在一分钟内mn分流给sn的数据量低于20mb，此时可以认为释放sn之后不会加重mn的负载，因此mn允许sn发起sn释放。
140.在另一个实例中，mn是否允许发起sn释放的条件可以是ue与sn之间的数据量在第二预定时间内低于第二阈值的情况下，mn允许sn发起sn释放。
141.在另一个实例中，mn是否允许发起sn释放的条件也可以是用户设备与mn之间的数据量在第三预定时间内低于第三阈值的情况下，mn允许sn发起sn释放等等。在不冲突的情况下，上述条件也可以组合使用。
142.上述的预定时间可以是一分钟、五分钟等等，这里所说的预定时间可以是预先设定的默认值，并且可以根据实际情况和需要进行更改。同样，本领域技术人员能够理解，数据量的阈值设置也可以是预先设定的默认值，也可以根据实际情况和需要进行更改，本技术不对此做具体限定。
143.本领域技术人员能够理解，在步骤503中，如果mn决定不进行sn释放的情况下，则流程结束，如果mn决定要发起sn释放，则执行以下的步骤504和505。
144.在步骤504，mn200向sn300发送sn释放请求((例如为：s-node release request)消息并执行sn释放，接下来在步骤505会接收来自sn的sn释放确认(例如为：s-node release request acknowledge)消息。mn接收到sn发送的释放承认(s-node release request acknowledge)消息后，mn执行sn释放，将配置给对应ue的sn释放，ue还可以清除对应的sn相关的配置，使得ue不再处于双连接网络架构下。
145.同样，步骤504和505中的sn释放的发起、sn释放的确认以及执行的过程作为现有技术，可参考上述3gpp的相关标准，在此不再赘述。
146.在又一个实例中，如果上述步骤502的指示消息是用于指示请求mn允许sn来发起sn释放的情况下，在步骤503，mn同样可以根据自身的负载条件进行判断。这里所说的负载条件可以是上述实例中的某个条件或者多个条件的组合，在此不再赘述。
147.在步骤503中，如果mn判断不允许sn发起sn释放的情况下，则流程结束，如果mn判断允许sn发起sn释放，则mn可以将允许sn发起sn释放的消息发送给sn。
148.接下来，接收到来自mn的允许sn发起sn释放的消息后，sn会发起sn释放。sn发起sn释放的步骤同上所述，具体过程如下：sn向mn发送sn释放需求(s-node release required)消息，sn会接收到来自mn的sn释放确认(s-node release confirm)消息并停止向ue提供用户数据。mn向sn发送的sn释放的确认消息(s-node release confirm)消息后，mn执行sn释放，将配置给对应ue的sn释放，ue还可以清除对应的sn相关的配置，使得ue不再处于双连接网络架构下。
149.接下来参考图6a和图6b对根据本技术一个实施例的sn释放方法的流程进行说明。
150.图6a是根据本技术一个实施例的用于mn的sn释放方法的流程图。如图6a所示，在步骤601，mn200接收来自sn300的sn释放的指示消息。
151.sn收到ue释放sn的指示后，与sn直接将sn释放需求消息发送给mn不同，根据本技术的另一个实施例，在步骤502，sn300向mn200发送sn释放的指示消息，该指示消息用于指示ue100期望释放sn，即在步骤502，sn300将ue100想要释放sn的期望通知mn200。
152.在一个实例中，sn300可以是将来自ue100的指示消息转发给mn200；或者，sn300可以将收到ue100的释放sn的指示消息通知mn200，同时可以将自己是否能够发起sn释放的情况通知mn，最终由mn200来决定是否发起sn释放，本技术实施例不对此做具体限定。但是本领域技术人员能够理解，在步骤601，mn200获知ue100发起的sn释放，并且会在之后的步骤中做出决定是否发起sn释放。
153.在步骤602，mn200决定是否发起sn释放。
154.在一个实例中，mn200可以根据sn300的期望结合mn200自身的需要来决定是否释放sn。
155.在一个实例中，与前述的实施例一样，mn200执行的判断可以是mn是否允许发起sn释放。
156.具体的，mn200可以根据自身的负载条件进行判断，例如上述的mn分流给sn的数据量在第一预定时间内低于第一阈值的情况下，mn允许发起sn释放。举例来说，假设在一分钟内mn分流给sn的数据量低于20mb，此时可以认为释放sn之后不会加重mn的负载，因此mn允许sn发起sn释放。
157.在另一个实例中，mn是否允许发起sn释放的条件可以是ue与sn之间的数据量在第二预定时间内低于第二阈值的情况下，mn允许发起sn释放。
158.在另一个实例中，mn是否允许发起sn释放的条件可以是用户设备与mn之间的数据量在第三预定时间内低于第三阈值的情况下，mn允许发起sn释放等等。在不冲突的情况下，上述条件也可以组合使用。
159.上述的预定时间可以是一分钟、五分钟等等，预定时间可以是预先设定的默认值，也可以根据实际情况和需要进行更改。同样，本领域技术人员能够理解，数据量的阈值设置可以是预先设定的默认值，也可以根据实际情况和需要进行更改，本技术不对此做具体限定。
160.本领域技术人员能够理解，在步骤602中，如果mn决定不进行sn释放的情况下，则转到步骤603，流程结束，如果mn决定要发起sn释放，则执行以下的步骤604和605。
161.在步骤604，mn200向sn300发送sn释放请求((s-node release request)消息，接下来会在步骤605接收来自sn的sn释放确认(s-node release request acknowledge)消息并执行sn释放。同样，步骤604和605中的sn释放的发起、执行以及sn释放的确认过程作为现有技术，可参考上述3gpp的相关标准，在此不再赘述。
162.图6b是根据本技术一个实施例的用于sn的sn释放方法的流程图。如图6b所示，在步骤610，sn300接收到来自ue100的sn释放的指示消息。
163.在一个实例中，ue100发起的sn释放可以是ue请求的或ue原因触发的sn释放，或者可以是基于基于节能目的的sn释放，例如ue100的电量低于阈值，或者用户开启了ue100的
节能模式的情况。本领域技术人员能够理解，ue发起的sn释放不局限于节能目的，可以基于其他目的而发起sn释放，本技术对此不作具体的限定。
164.接下来，在步骤611，sn300向mn200发送sn释放的指示消息。
165.同样，在一个实例中，sn300可以是将来自ue100的指示消息转发给mn200；或者，sn300可以将收到ue100的释放sn的指示消息通知mn200，同时可以将自己是否能够发起sn释放的情况通知mn，最终由mn200来决定是否发起sn释放，本技术实施例不对此做具体限定。本领域技术人员能够理解，在步骤611，mn200获知即将发起的sn释放，并且会在之后的步骤中做出决定是否发起sn释放。
166.如上述步骤602所述，如果mn200决定释放sn，则在步骤612，sn300会接收到来自mn200的释放请求(s-node release request)消息。
167.sn300会在步骤613向mn200发送sn释放确认(s-node release request acknowledge)消息。同样，步骤612和613中的sn释放的发起、执行以及sn释放的确认过程作为现有技术，可参考上述3gpp的相关标准，在此不再赘述。
168.参考以上图5以及图6a和图6b对根据本技术另一个实施例的sn释放方法进行了说明。根据本技术另一个实施例的sn释放方法，mn会基于sn的需求以及mn自身的情况做出是否释放sn的决定，避免了由于sn释放可能导致mn负载更重、影响数据速率的问题。
169.进一步的，sn释放完成之后，mn还可以选择添加sn。mn添加的sn可以是在之前释放的sn，也可以是其他的sn，本技术不对此做具体限定。根据本技术的实施例，mn还可以在sn添加过程中实现对sn基于ue发起的sn释放的控制，具体的流程和方法将在后面的实施例中详细描述。
170.图7是根据本技术又一个实施例的sn释放方法的信号流图。ue100同时连接到mn200以及sn300，并进行数据通信。mn200和sn300中的收发器负责信息传送，控制器用于控制收发器进行信息传送，并执行根据本技术的sn释放方法。具体的可参考上述图3的说明，在此不再赘述。
171.在步骤701，sn300接收到来自ue100的发起sn释放的指示消息。
172.在一个实例中，ue100发起的sn释放可以是基于节能目的的sn释放，例如ue100的电量低于阈值，或者用户开启了ue100的节能模式的情况。本领域技术人员能够理解，ue发起的sn释放不局限于节能目的，可以基于其他目的而发起sn释放，本技术对此不作具体的限定。
173.接下来，在步骤702，mn200和sn300之间完成sn释放的过程。本领域技术人员能够理解，sn的释放可以是mn200发起的，可以是sn300发起的，也可以是基于ue发送的sn释放请求或者基于节能目的的释放请求发起的等。具体的sn释放的过程可以是如1中所示的的执行机制，也可以是如上述图3或图5实施例中所示的sn释放的流程，在此不再赘述。
174.完成了sn300的释放之后，在步骤703，mn200执行sn添加。根据本技术的又一个实施例，mn在sn添加过程中实现对sn基于ue发起的sn释放的控制。
175.在一个实例中，mn200向sn300发送sn添加请求(s-node addition request)消息以实现sn添加。sn添加可以是在sn300释放完成之后立即执行，也可以是完成sn300释放之后经过预定时间，比如1分钟后执行，或者也可以是根据mn200的负载情况发起添加sn等等。
176.本领域技术人员能够理解，mn添加的sn可以是在步骤702中释放的sn，也可以是其
他sn，本技术不对此做具体限定。
177.在一个实例中，mn200在发送给sn300的sn添加请求消息中增加指示信息，以便在后续的过程中指示sn是否允许发起sn释放。指示信息可以是简单的指示允许或不允许，也可以是附加了允许sn发起sn释放的条件，或者仅仅是允许sn发起sn释放的条件等等。
178.同上述的实施例一样，这种指示可以实现为在sn添加消息中携带0或1的一个比特的字段，用0表示不允许，用1表示允许。或者是以mn是否给出明确指示来表示是否允许sn发起sn释放，mn在发送给sn的某个消息中携带明确的指示信息表示允许，如果未携带明确的指示信息表示不允许。
179.附加了允许sn发起sn释放的条件可以是基于时间的条件。例如，指示在预定时间内不允许释放sn，这里所说的预定时间可以是一分钟、五分钟等等。预定时间可以是sn预先设定的默认值，也可以由mn通过配置信息指定的值，也可以是在标准中预先规定的值，本技术不对此做具体限定。进一步的，允许sn发起sn释放的时间条件也可以由mn通过配置信息直接指定。例如，mn200可以在发送给sn300的sn添加请求消息中增加明确的时间的指示信息。sn300在接收到该指示信息后即开启定时，例如五分钟、十分钟等等。在这定时的五分钟或十分钟期间内，sn300不被允许发起sn释放。本领域技术人员能够理解，无论是sn默认的时间还是mn指定的时间的长短根据实际情况和需要是可变的，本技术不对此做具体限定。
180.在具体实施过程中，该指示信息与添加请求信息可以为同一条消息(或信息)，例如：在该添加请求信息设置一用于指示该指示信息的字段；该指示信息与添加请求信息也可以为不同的消息(或信息)。在具体实施过程中，该添加请求信息还可以默认指示预定时间内不允许释放sn，例如：sn在接收到添加请求信息之后，发现在该添加请求信息的预设时长内，mn曾释放该sn，则sn在默认的预定时间内不再释放sn。该默认的预定时间，可以有mn基于配置信息配置，也可以由标准设定，或者预存于sn中，本发明实施例不作限制。
181.在一个实例中，mn200发送给sn300的sn添加请求消息中也可以不添加明确的指示信息，以表示mn200不希望发起sn释放，这种情况下，sn300可以在一定时长内不发起sn释放。这里说的一定时长可以是从sn接收到sn添加请求消息起算，也可以是从上一次sn释放完成起算，时长可以是一分钟、五分钟等等。本领域技术人员能够理解，这里所说的一定时长可以是sn300的默认配置，也可以是根据实际情况和需要通过网络实现，时间的长短根据实际情况和需要也是可变的，本技术不对此做具体限定。
182.在一个实例中，不添加任何的指示信息也可以是表示sn不能发起sn释放需求消息、不能发指示释放所述sn的指示消息，mn不能发送sn释放请求消息，或者mn或者sn一方发出sn释放后，对方不作响应等。
183.在上述的实例中，上述指示信息可以被携带在sn添加请求消息中，还可以被包括在sn添加过程中的任意其他消息中，或者是以单独的消息的形式由mn发送给sn。本领域技术人员能够理解，指示信息是为了完成指示目的，本技术不对指示信息的形式或载体做具体的限定。
184.接下来，在步骤704，sn300接收到来自ue100的释放sn的指示信息。并且在步骤705，根据上述步骤703中的mn200对于sn300的指示，sn300判断是否要发起sn释放。
185.举例来说，步骤703mn200添加sn过程中指示sn在五分钟内不允许发起sn释放，则sn300会根据时间做出判断，如果自sn添加至ue发出sn释放请求已经过了五分钟的时间，则
sn300决定可以发起sn释放。
186.接下来，在步骤706，sn300向mn200发出sn释放需求(s-node release required)消息，在步骤707，mn200执行sn释放，并且在步骤708，将sn释放确认(s-node release confirm)消息发送给sn。
187.这里，步骤706-708的sn释放的发起、执行的具体的过程可以是如1中所示的现有标准的执行机制，也可以是如上述图3或图5实施例中所示的sn释放的流程，在此不再赘述。
188.接下来参考图8a和图8b对根据本技术一个实施例的sn释放方法的流程进行说明。
189.图8a是根据本技术一个实施例的用于mn的sn释放方法的流程图。如图8a所示，在步骤801，mn200接收来自sn300的sn释放需求消息，在步骤802执行sn释放，并且在步骤803向sn发送sn释放的确认消息(s-node release confirm)。步骤801、802和803的发起、执行sn释放的具体过程可以是如1中所示的现有标准的执行机制，也可以是如上述图3或图5实施例中所示的sn释放的流程，在此不再赘述。
190.在步骤804，mn向sn发送sn添加的请求消息(s-node addition request)。根据本技术的实施例，mn会在sn添加过程中实现对sn基于ue发起的sn释放的控制。
191.在一个实例中，mn200向sn300发送sn添加请求消息(s-node addition request)以实现sn添加。sn添加可以是在sn300释放完成之后立即执行，也可以是完成sn300释放之后经过预定时间，比如1分钟后执行，或者也可以是根据mn200的负载情况发起添加sn等等。
192.本领域技术人员能够理解，mn添加的sn可以是在步骤702中释放的sn，也可以是其他sn，本技术不对此做具体限定。
193.在一个实例中，mn200在发送给sn300的sn添加请求消息中增加指示信息，以便在后续的过程中指示sn是否允许发起sn释放。指示信息可以是简单的指示允许或不允许，也可以是附加了允许sn发起sn释放的条件，或者仅仅是允许sn发起sn释放的条件等等。
194.同上述的实施例一样，这种指示可以实现为在sn添加消息中携带0或1的一个比特(或者多个比特)的字段，用0表示不允许，用1表示允许。或者是以mn是否给出明确指示来表示是否允许sn发起sn释放，mn在发送给sn的某个消息中携带明确的指示信息表示允许，如果未携带明确的指示信息表示不允许。
195.附加了允许sn发起sn释放的条件可以是基于时间的条件。例如，指示在预定时间内不允许释放sn，这里所说的预定时间可以是一分钟、五分钟等等。预定时间可以是sn预先设定的默认值，也可以由mn通过配置信息指定的值，也可以是在标准中预先规定的值，本技术不对此做具体限定。
196.进一步的，允许sn发起sn释放的时间条件也可以由mn通过配置信息直接指定。例如，mn200可以在发送给sn300的sn添加请求消息中增加明确的时间的指示信息。sn300在接收到该指示信息后即开启定时，例如五分钟、十分钟等等。在这定时的五分钟或十分钟期间内，sn300不被允许发起sn释放。本领域技术人员能够理解，无论是sn默认的时间还是mn指定的时间的长短根据实际情况和需要是可变的，本技术不对此做具体限定。
197.在具体实施过程中，该指示信息与添加请求信息可以为同一条消息(或信息)，例如：在该添加请求信息设置一用于指示该指示信息的字段；该指示信息与添加请求信息也可以为不同的消息(或信息)。在具体实施过程中，该添加请求信息还可以默认指示预定时间内不允许释放sn，例如：sn在接收到添加请求信息之后，发现在该添加请求信息的预设时
长内，mn曾释放该sn，则sn在默认的预定时间内不再释放sn。该默认的预定时间，可以有mn基于配置信息配置，也可以由标准设定，或者预存于sn中，本发明实施例不作限制。
198.在一个实例中，sn添加请求消息中也可以不添加明确的指示信息，以表示mn200不希望发起sn释放，这种情况下，sn300可以在一定时长内不发起sn释放。这里说的一定时长可以是从sn接收到sn添加请求消息起算，也可以是从上一次sn释放完成起算，时长可以是一分钟、五分钟等等。本领域技术人员能够理解，这里所说的一定时长可以是sn300的默认配置，也可以是根据实际情况和需要通过网络实现，时间的长短根据实际情况和需要也是可变的，本技术不对此做具体限定。
199.在一个实例中，不添加任何的指示信息也可以是表示sn不能发起sn释放需求消息、不能发送指示释放所述sn的指示消息，mn不能发送sn释放请求消息，或者是mn或sn一方发出sn释放后，对方不作响应等指示。
200.在上述的实例中，上述指示信息可以被携带在sn添加请求消息中，还可以被包括在sn添加过程中的任意其他消息中，或者是以单独的消息的形式由mn发送给sn。本领域技术人员能够理解，指示信息是为了完成指示目的，本技术不对指示信息的形式或载体做具体的限定。
201.之后，如果满足了发起sn释放的条件，在步骤805，mn200会接收到来自sn300的sn释放需求消息，并且流程转到步骤802，执行sn释放。
202.这里要说明的是，mn首次添加sn使得ue处于双连接的网络架构时，mn可以不向sn发送限制发起sn释放条件的指示信息。在第一次释放sn之后，mn第二次添加sn时，mn可以向sn发送限制发起sn释放条件的指示信息，又或者，mn在添加sn时，如果距离上次释放的时长小于特定时长，则可以sn发送限制sn发起sn释放的条件的指示信息，这里所说的指示信息是如上述实施例的步骤703中所述的各种指示或条件。同样，指示信息可以携带在sn添加请求信息中，或者以单独信息的形式发送，在此不再赘述。
203.图8b是根据本技术一个实施例的用于sn的sn释放方法的流程图。如图8b所示，在步骤810，sn300接收来自ue100的指示sn释放的指示消息，并且在步骤811，向mn200发送sn释放需求消息，mn200执行sn释放后，sn300会在步骤812接收到来自mn200的sn释放的确认消息。步骤810-812的发起、执行sn释放的具体过程可以是如1中所示的现有标准的执行机制，也可以是如上述图3或图5实施例中所示的sn释放的流程，在此不再赘述。
204.在步骤813，sn300接收到来自mn200的sn添加请求消息(s-node addition request)。根据本技术的实施例，mn会在sn添加过程中实现对sn基于ue发起的sn释放的控制。
205.在一个实例中，mn200向sn300发送sn添加请求消息(s-node addition request)以实现sn添加。sn添加可以是在sn300释放完成之后立即执行，也可以是完成sn300释放之后经过预定时间，比如1分钟后执行，或者也可以是根据mn200的负载情况发起添加sn等等。
206.本领域技术人员能够理解，mn添加的sn可以是在步骤702中释放的sn，也可以是其他sn，本技术不对此做具体限定。
207.在一个实例中，mn200在发送给sn300的sn添加请求消息中增加指示信息，以便在后续的过程中指示sn是否允许发起sn释放。指示信息可以是简单的指示允许或不允许，也可以是附加了允许sn发起sn释放的条件，或者仅仅是允许sn发起sn释放的条件等等。
208.同上述的实施例一样，这种指示可以实现为在sn添加消息中携带0或1的一个比特(或者多个比特)的字段，用0表示不允许，用1表示允许。或者是以mn是否给出明确指示来表示是否允许sn发起sn释放，mn在发送给sn的某个消息中携带明确的指示信息表示允许，如果未携带明确的指示信息表示不允许。
209.附加了允许sn发起sn释放的条件可以是基于时间的条件。例如，指示在预定时间内不允许释放sn，这里所说的预定时间可以是一分钟、五分钟等等。预定时间可以是sn预先设定的默认值，也可以由mn通过配置信息指定的值，也可以是在标准中预先规定的值，本技术不对此做具体限定。
210.进一步的，允许sn发起sn释放的时间条件也可以由mn通过配置信息直接指定。例如，mn200可以在发送给sn300的sn添加请求消息中增加明确的时间的指示信息。sn300在接收到该指示信息后即开启定时，例如五分钟、十分钟等等。在这定时的五分钟或十分钟期间内，sn300不被允许发起sn释放。本领域技术人员能够理解，无论是sn默认的时间还是mn指定的时间的长短根据实际情况和需要是可变的，本技术不对此做具体限定。
211.在具体实施过程中，该指示信息与添加请求信息可以为同一条消息(或信息)，例如：在该添加请求信息设置一用于指示该指示信息的字段；该指示信息与添加请求信息也可以为不同的消息(或信息)。在具体实施过程中，该添加请求信息还可以默认指示预定时间内不允许释放sn，例如：sn在接收到添加请求信息之后，发现在该添加请求信息的预设时长内，mn曾释放该sn，则sn在默认的预定时间内不再释放sn。该默认的预定时间，可以有mn基于配置信息配置，也可以由标准设定，或者预存于sn中，本发明实施例不作限制。
212.在一个实例中，sn添加请求消息中也可以不添加明确的指示信息，以表示mn200不希望发起sn释放，这种情况下，sn300可以在一定时长内不发起sn释放。这里说的一定时长可以是从sn接收到sn添加请求消息起算，也可以是从上一次sn释放完成起算，时长可以是一分钟、五分钟等等。本领域技术人员能够理解，这里所说的一定时长可以是sn300的默认配置，也可以是根据实际情况和需要通过网络实现，时间的长短根据实际情况和需要也是可变的，本技术不对此做具体限定。
213.在一个实例中，不添加任何的指示信息也可以是表示sn不能发起sn释放需求消息、不能发送指示释放所述sn的指示消息，mn不能发送sn释放请求消息，或者是mn或sn一方发出sn释放后，对方不作响应等指示。
214.在上述的实例中，上述指示信息可以被携带在sn添加请求消息中，还可以被包括在sn添加过程中的任意其他消息中，或者是以单独的消息的形式由mn发送给sn。本领域技术人员能够理解，指示信息是为了完成指示目的，本技术不对指示信息的形式或载体做具体的限定。
215.这里要说明的是，mn首次添加sn使得ue处于双连接的网络架构时，mn可以不向sn发送限制发起sn释放条件的指示信息。在第一次释放sn之后，mn第二次添加sn时，mn可以向sn发送限制发起sn释放条件的指示信息，这里所说的指示信息是如上述实施例的步骤703中所述的各种指示或条件。同样，指示信息可以携带在sn添加请求信息中，或者以单独信息的形式发送，在此不再赘述。
216.接下来，在步骤814，sn300又接收到来自ue100的sn释放请求。在步骤815，根据来自mn的sn添加请求消息的指示，sn300判断当前是否符合发起sn释放的要求。
217.如上所述，满足发起sn释放的情况可以是mn允许发起sn释放，也可以是满足mn允许发起sn释放的条件，这里的条件可以是上述的时间条件，也可以是传输的数据量的条件等等。
218.当步骤815中的判断为否的情况下，表示当前mn200不允许发起sn释放，流程转到步骤817结束。如果步骤815的判断为是，则执行步骤816，sn300向mn200发送sn释放需求消息。从步骤816开始的发起、执行sn释放的具体过程可以是如1中所示的现有标准的执行机制，也可以是如上述图3或图5实施例中所示的sn释放的流程，在此不再赘述。
219.参考以上图7以及图8a和图8b对根据本技术又一个实施例的sn释放方法进行了说明。根据本技术又一个实施例的sn释放方法，mn通过添加sn的过程可以实现对sn释放的控制，避免了由于sn释放可能导致mn负载更重、影响数据速率的问题。
220.本技术的各方法实施方式均可以以软件、磁件、固件等方式实现。
221.可将程序代码应用于输入指令，以执行本文描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本技术的目的，处理系统包括具有诸如例如数字信号处理器(dsp)、微控制器、专用集成电路(asic)或微处理器之类的处理器的任何系统。
222.程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本文中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。
223.至少一个实施例的一个或多个方面可以由存储在计算机可读存储介质上的表示性指令来实现，指令表示处理器中的各种逻辑，指令在被机器读取时使得该机器制作用于执行本文所述的技术的逻辑。被称为“ip核”的这些表示可以被存储在有形的计算机可读存储介质上，并被提供给多个客户或生产设施以加载到实际制造该逻辑或处理器的制造机器中。
224.虽然本技术的描述将结合较佳实施例一起介绍，但这并不代表此申请的特征仅限于该实施方式。恰恰相反，结合实施方式作发明介绍的目的是为了覆盖基于本技术的权利要求而有可能延伸出的其它选择或改造。为了提供对本技术的深度了解，以下描述中将包含许多具体的细节。本技术也可以不使用这些细节实施。此外，为了避免混乱或模糊本技术的重点，有些具体细节将在描述中被省略。需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。
225.此外，各种操作将以最有助于理解说明性实施例的方式被描述为多个离散操作；然而，描述的顺序不应被解释为暗示这些操作必须依赖于顺序。特别是，这些操作不需要按呈现顺序执行。
226.如这里所使用的，术语“模块”或“单元”可以指代、是或者包括：专用集成电路(asic)、电子电路、执行一个或多个软件或固件程序的(共享、专用或组)处理器和/或存储器、组合逻辑电路和/或提供所描述的功能的其他合适的组件。
227.在附图中，以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可以不需要这样的特定布置和/或排序。在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包含结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其
他特征组合。
228.本技术公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本技术的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括多个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、多个输入设备以及多个输出设备。
229.可将程序代码应用于输入指令，以执行本技术描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本技术的目的，处理系统包括具有诸如例如数字信号处理器(dsp)、微控制器、专用集成电路(asic)或微处理器之类的处理器的任何系统。
230.程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本技术中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。
231.在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。在一些情况下，至少一些实施例的一个或多个方面可以由存储在计算机可读存储介质上的表示性指令来实现，指令表示处理器中的各种逻辑，指令在被机器读取时使得该机器制作用于执行本技术所述的技术的逻辑。被称为“ip核”的这些表示可以被存储在有形的计算机可读存储介质上，并被提供给多个客户或生产设施以加载到实际制造该逻辑或处理器的制造机器中。
232.这样的计算机可读存储介质可以包括但不限于通过机器或设备制造或形成的物品的非瞬态的有形安排，其包括存储介质，诸如：硬盘任何其它类型的盘，包括软盘、光盘、紧致盘只读存储器(cd-rom)、紧致盘可重写(cd-rw)以及磁光盘；半导体器件，例如只读存储器(rom)、诸如动态随机存取存储器(dram)和静态随机存取存储器(sram)之类的随机存取存储器(ram)、可擦除可编程只读存储器(eprom)、闪存、电可擦除可编程只读存储器(eeprom)；相变存储器(pcm)；磁卡或光卡；或适于存储电子指令的任何其它类型的介质。
233.因此，本技术的各实施例还包括非瞬态的计算机可读存储介质，该介质包含指令或包含设计数据，诸如硬件描述语言(hdl)，它定义本技术中描述的结构、电路、装置、处理器和/或系统特征。