CN113966014A

CN113966014A - Auxiliary network equipment release method, computer readable storage medium and equipment

Info

Publication number: CN113966014A
Application number: CN202010785680.8A
Authority: CN
Inventors: 邝奕如; 王燕; 杨旭东; 谢曦
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-07-20
Filing date: 2020-08-06
Publication date: 2022-01-21
Also published as: WO2022017329A1

Abstract

The embodiment of the application relates to a method for releasing auxiliary network equipment, which comprises the steps of sending configuration information to the auxiliary network equipment, wherein the configuration information is used for indicating that the main network equipment allows the auxiliary network equipment to initiate an auxiliary network equipment release demand message, and the auxiliary network equipment release demand message is used for requesting the main network equipment to execute auxiliary network equipment release; and receiving a secondary network device release requirement message from the secondary network device. Embodiments of the present application also relate to a machine-readable medium and apparatus.

Description

Auxiliary network equipment release method, computer readable storage medium and equipment

Technical Field

One or more embodiments of the present application relate generally to the field of communications, and in particular, to a secondary network device release method, medium, and device

Background

When a User Equipment (UE) performs a service with a high transmission rate, such as a real-time combat game, a GSP navigation, a high-definition video call, etc., to support the communication service, the UE may be configured to simultaneously connect with two base stations and perform data communication, thereby increasing the transmission rate of the UE.

A scenario in which the UE is simultaneously connected to two network devices and performs data communication may be referred to as Multi-Radio Dual Connectivity (MR-DC). When a network device of E-UTRA (Evolved-UMTS Terrestrial Radio Access) is used as a Master network device (Master Node, MN), and a network device of NR (New Radio, New air interface) is used as a Secondary network device (Secondary Node, SN), the scenario is specifically referred to as E-UTRA-NR Dual Connectivity (EN-DC) in MR-DC; similarly, there are also NR-E-UTRA double junctions (NR-E-UTRA Dual Connectivity, NE-DC) and NR-NR double junctions (NR-NR Dual Connectivity, NR-DC).

In a DC scenario, the UE may generate high power consumption and thus the temperature of the device increases, which may cause the user to feel that the device is too hot or power down quickly when the UE is in use, resulting in a poor user experience. At this time, the power consumption of the UE can be reduced by releasing the SN.

Disclosure of Invention

The present application is described below in terms of several aspects, embodiments and advantages of which are mutually referenced.

According to a first aspect of the present application, there is provided a secondary network device release method for a primary network device, comprising: sending configuration information to the secondary network device, where the configuration information is used to instruct the primary network device to allow the secondary network device to initiate a secondary network device release demand message, where the secondary network device release demand message is used to request the primary network device to execute the secondary network device release; receiving the secondary network device release requirement message from the secondary network device.

According to a second aspect of the present application, there is provided a secondary network device release method for a primary network device, comprising: sending configuration information to the secondary network device, where the configuration information is used to indicate a condition that the primary network device allows the secondary network device to initiate a secondary network device release demand message, where the secondary network device release demand message is used to request the primary network device to execute the secondary network device release; receiving the secondary network device release requirement message from the secondary network device.

In some embodiments, the method further includes sending, to the secondary network device, indication information indicating a condition for allowing the secondary network device to initiate the secondary network device release requirement, the condition including at least one of:

the master network device allows the auxiliary network device to initiate the auxiliary network device release demand message when the data volume shunted to the auxiliary network device by the master network device is lower than a first threshold value within a first preset time;

the primary network device allows the secondary network device to initiate the secondary network device release demand message when the data volume between the user device and the secondary network device is lower than a second threshold value within a second predetermined time;

and the main network device allows the auxiliary network device to initiate the auxiliary network device release demand message when the data volume between the user device and the main network device is lower than a third threshold value in a third preset time.

In some embodiments, the condition indicating that the primary network device allows the secondary network device to initiate a secondary network device release requirement comprises at least one of:

the primary network device always allows the secondary network device to initiate the secondary network device release requirement;

the primary network device does not always allow the secondary network device to initiate the secondary network device release requirement;

In some embodiments, the method further comprises the primary network device receiving an indication message from the secondary network device indicating that the secondary network device supports a secondary network device release request from the user device; or, the indication message is used to indicate that the secondary network device supports a secondary network device release request based on an energy-saving purpose from the user equipment.

In some embodiments, the indication message is sent to the primary network device after the secondary network device receives a secondary network device release request of the user equipment; or, after the secondary network device receives a secondary network device release request based on the energy saving purpose of the user equipment, the indication message is sent to the primary network device.

According to a third aspect of the present application, there is provided a secondary network device release method for the secondary network device, the method comprising: receiving configuration information from a primary network device, the configuration information including an indication that the primary network device allows the secondary network device to initiate a secondary network device release requirement message, wherein the secondary network device release requirement message is used for requesting the primary network device to perform the secondary network device release; and receiving a release request of the auxiliary network equipment, and sending a release demand message of the auxiliary network equipment to the main network equipment.

According to a fourth aspect of the present application, there is provided a secondary network device release method for a secondary network device, the method comprising receiving configuration information from a primary network device, the configuration information comprising a condition indicating that the primary network device allows the secondary network device to initiate a secondary network device release requirement for requesting the primary network device to perform the secondary network device release; and receiving a release request of the auxiliary network equipment, and sending a release demand message of the auxiliary network equipment to the main network equipment under the condition that the main network equipment allows the auxiliary network equipment to initiate the release demand message of the auxiliary network equipment is met.

In some embodiments, the method further comprises receiving, from the primary network device, indication information indicating a condition for allowing the secondary network device to initiate the secondary network device release requirement, the condition comprising at least one of:

the method comprises the steps that under the condition that the data volume shunted to the auxiliary network equipment by the main network equipment is lower than a first threshold value in first preset time, the main network equipment allows the auxiliary network equipment to initiate the auxiliary network equipment release requirement;

the primary network device allows the secondary network device to initiate the secondary network device release requirement when the data volume between the user device and the secondary network device is lower than a second threshold value within a second predetermined time;

and the main network device allows the auxiliary network device to initiate the auxiliary network device release requirement when the data volume between the user device and the main network device is lower than a third threshold value in a third preset time.

In some embodiments, further comprising sending an indication message to the primary network device, the indication message indicating that the secondary network device supports a secondary network device release request from the user device; or, the indication message is used to indicate that the secondary network device supports a secondary network device release request based on an energy-saving purpose from the user equipment.

In some embodiments, receiving a secondary network device release request comprises receiving the secondary network device release request from a user equipment; or receiving a secondary network device release request based on energy saving purpose from the user equipment.

According to a fifth aspect of the present application, there is provided a secondary network device release method for a primary network device, the method comprising receiving an indication message from the secondary network device indicating release of the secondary network device; and sending a secondary network device release request message to the secondary network device under the condition that the primary network device is determined to allow the secondary network device to be released, wherein the secondary network device release request message is used for requesting the release of the secondary network device.

In some embodiments, determining that the primary network device allows release of the secondary network device comprises at least one of:

the method comprises the steps that under the condition that the data volume shunted to the auxiliary network equipment by the main network equipment is lower than a first threshold value in first preset time, the main network equipment allows to initiate a release request message of the auxiliary network equipment;

the primary network device allows the secondary network device to initiate a release request message if the amount of data between the user device and the secondary network device is below a second threshold within a second predetermined time;

the primary network device allows initiation of the secondary network device release request message if the amount of data between the user device and the primary network device is below a third threshold within a third predetermined time.

In some embodiments, the indication message for indicating the release of the secondary network device is sent to the primary network device after the secondary network device receives a secondary network device release request of the user equipment; or, after receiving a secondary network device release request based on the energy saving purpose of the user equipment, the secondary network device sends the request to the primary network device.

According to a sixth aspect of the present application, there is provided a secondary network device release method for a secondary network device, the method comprising sending an indication message to a primary network device for indicating release of the secondary network device, receiving a secondary network device release request message from the primary network device, wherein the secondary network device release request message is for requesting release of the secondary network device.

According to a seventh aspect of the present application, a secondary network device release method is provided, where the method is used for a primary network device, and the method includes receiving a first secondary network device release demand message requesting the primary network device to perform secondary network device release, performing secondary network device release, and sending a confirmation message of the secondary network device release to the secondary network device, and sending a request message of adding the secondary network device and an indication message to the secondary network device, where the indication message is used to indicate that the secondary network device is not allowed to be released within a preset time; or sending a request message for adding the auxiliary network equipment to the auxiliary network equipment, wherein the request message is also used for indicating that the auxiliary network equipment is not allowed to be released within preset time.

In some embodiments, the indication information carries information of the preset time; and/or the preset time is a time configured to the auxiliary network device.

In some embodiments, the method further comprises receiving a second secondary network device release requirement message requesting the primary network device to perform the secondary network device release, and performing the secondary network device release.

According to an eighth aspect of the present application, there is provided a secondary network device release method, which is used for the secondary network device, the method includes sending a first secondary network device release demand message to a primary network device for requesting the primary network device to perform the secondary network device release, receiving an acknowledgement message of the secondary network device release from the primary network device, and receiving a request message of adding the secondary network device and an indication message from the primary network device, wherein the indication message is used for indicating that the secondary network device is not allowed to be released within a preset time; or receiving a request message for adding the auxiliary network device from the main network device, where the request message is further used to indicate that the auxiliary network device is not allowed to be released within a preset time.

In some embodiments, the method further comprises, after the preset time has elapsed, transmitting a second secondary network device release demand message to the primary network device requesting the primary network device to perform the secondary network device release.

According to a ninth aspect of the present application, there is provided a machine-readable medium having stored thereon instructions which, when run on the machine, cause the machine to perform the method according to the first to eighth aspects of the present application.

According to a tenth aspect of the present application, there is provided an apparatus comprising: a processor; a memory having instructions stored thereon, which when executed by the processor, cause the user equipment to perform the method according to the first to eighth aspects of the present application.

Drawings

Fig. 1(a) -1 (c) are schematic diagrams of several standardized SN release mechanisms that are known in the art;

FIG. 2 is a schematic diagram of an application scenario according to an embodiment of the present application;

fig. 3 is a signal flow diagram of a SN release method according to one embodiment of the present application;

fig. 4A is a flow chart of a SN release method for a MN according to one embodiment of the present application;

fig. 4B is a flow diagram of a SN release method for SNs according to one embodiment of the present application;

fig. 5 is a signal flow diagram of a SN release method according to another embodiment of the present application;

fig. 6A is a flowchart of a SN release method for a MN according to another embodiment of the present application;

fig. 6B is a flow diagram of a SN release method for SNs according to another embodiment of the present application;

fig. 7 is a signal flow diagram of a SN release method according to yet another embodiment of the present application;

fig. 8A is a flowchart of a SN release method for a MN according to yet another embodiment of the present application;

fig. 8B is a flowchart of a SN release method for a SN according to yet another embodiment of the present application.

Detailed Description

The present application is further described with reference to the following detailed description and the accompanying drawings.

It is to be understood that, although the terms first, second, etc. may be used herein to describe various elements or data, these elements or data should not be limited by these terms. These terms are used merely to distinguish one feature from another. For example, a first feature may be termed a second feature, and, similarly, a second feature may be termed a first feature, without departing from the scope of example embodiments.

It should be noted that in this specification, like reference numerals and letters refer to like items in the following drawings, and thus, once an item is defined in one drawing, it need not be further defined and explained in subsequent drawings.

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Relevant provisions are made for the SN release machine in standard TS 38.423 of the third Generation Partnership Project (3rd Generation Partnership Project, 3 GPP). Fig. 1(a) -1 (c) are schematic diagrams of several standardized SN release mechanisms that are known in the art. It should be noted that the SN release mechanism is SN release for a certain UE. Fig. 1(a) and 1(b) show SN release initiated by the MN. Wherein, the MN sends an SN Release Request (S-Node Release Request) message to the SN, and if the SN determines that the Release is possible, as shown in fig. 1(a), the SN stops providing user data to the UE and sends an SN Release Acknowledge (S-Node Release Request Acknowledge) message to the MN; if the SN determines that the Release is not possible, as shown in FIG. 1(b), the SN sends an SN Release Reject (S-Node Release) message. After receiving the Release Acknowledge (S-Node Release Request Acknowledge) message sent by the SN, the MN executes SN Release to Release the SN configured to the corresponding UE, and the UE may also clear the configuration related to the corresponding SN, and the UE is no longer under the dual connectivity network architecture.

The SN Release initiated by the SN is, as shown in fig. 1(c), to send an SN Release Required (S-Node Release Required) message to the MN, and the SN receives an SN Release Confirm (S-Node Release Confirm) message from the MN and stops providing user data to the UE. According to existing SN release mechanisms, there is no failure in SN release initiated by the SN. After the confirmation message (S-Node Release Confirm) of SN Release sent by MN to SN, MN executes SN Release to Release SN configured to corresponding UE, UE can also clear configuration related to corresponding SN, UE is no longer under double-connection network architecture.

Fig. 2 is a schematic diagram of an application scenario according to an embodiment of the present application. As shown in fig. 2, the UE100 is simultaneously connected to the network device 200 and the network device 300 for data communication, where the network device 200 establishing a control plane connection with the UE100 is referred to as a Master network device, a Master Node, a Master base station, or an MN (Master Node, MN), and the network device 300 establishing only a user plane connection with the UE100 is referred to as a slave network device, a slave Node, a slave base station, or a SN (Secondary Node, SN). It is understood that all radio link control signaling messages and functions of the UE are managed by the MN (primary network device), and the data plane radio bearer can be independently served by the MN or the SN (secondary network device) or both. Data transmission is carried out through two legs of the MN and the SN, and the throughput of the network can be improved. For a UE with a power saving requirement, the UE may indicate to the SN that it desires to release the SN for power saving, and specifically, the UE may indicate to the SN that it desires to release the SN for power saving through a UE assistance information message, and the message may be directly sent to the SN or forwarded to the SN through the MN.

When the SN receives the expectation that the UE releases the SN, the SN can decide whether to release the SN for the UE. If the SN decides to release the SN, the SN release flow can be initiated, and the SN release demand message is sent to the MN. As described above, according to the existing SN release mechanism, SN release initiated for SN must succeed.

Under an EN-DC scene, the load information of the base station is not interacted between the MN and the SN. When the load of the MN is heavy, from the perspective of the MN, the MN needs the SN to offload data so as to balance the load, and if the SN directly initiates SN release, the load of the MN may be heavy, which affects the data rate. Therefore, although the UE may have a need for power saving and thus desire to release the SN, it is necessary to consider the data load in the network from the network perspective, which may result in a more serious data rate reduction if the SN is still released when the network data volume is large.

In view of the above problems, the technical solution of the present application provides an SN releasing method, which can perform effective and reasonable SN releasing according to the requirement of a main network device (e.g., MN).

For the sake of clarity and conciseness of the following description of the various embodiments, a brief introduction of some technical terms is first given:

1) a UE is a user equipment, also called a terminal or a terminal device, and is a device for providing voice and/or data connectivity to a user, and common terminal devices include: in-vehicle devices, cell phones, tablets, laptops, palmtops, Mobile Internet Devices (MIDs), wearable devices (including, for example, smartwatches, smartbands, pedometers, etc.), personal digital assistants, portable media players, navigation devices, video game devices, set-top boxes, virtual reality and/or augmented reality devices, internet of things devices, industrial control devices, streaming media client devices, electronic books, reading devices, POS machines, and other devices.

2) A Network device, also called a Radio Access Network (RAN) device, is a device for accessing a user equipment to a wireless Network, and includes Network devices in various communication systems, for example, including but not limited to: a Base Station, an evolved Node B (eNB), a Radio Network Controller (RNC), a Node B (NB), a network equipment Controller (BSC), a network equipment Transceiver Station (BTS), a Home network equipment (e.g., Home evolved Node B or Home Node B, HNB), a BaseBand Unit (BBU), and the like. The network device includes network devices of various frequency systems, for example, but not limited to: low-frequency network equipment and high-frequency network equipment.

Next, the SN release method according to the present application will be described in detail with reference to the drawings. In the following embodiments, the primary network device is an MN, and the secondary network device is an SN as an example, and in a specific implementation process, the present invention is not limited to this scenario.

Fig. 3 is a signal flow diagram of a SN release method according to one embodiment of the present application. As shown in fig. 3, the UE100 is simultaneously connected to the MN200 and the SN300 and performs data communication.

MN200 and SN300 further comprise a controller and a transceiver. The controller may include, but is not limited to, a modem, a Central Processing Unit (CPU), an Application Processor (AP), a Micro-programmed Control Unit (MCU), an Artificial Intelligence (AI) Processor, or a Programmable logic device (FPGA) Processing circuit. Wherein the modem is configured to modulate information (e.g., signals and/or data) in a baseband frequency domain to be transmitted into analog signals that can be transmitted through the transceiver according to a protocol of 3GPP, and demodulate the analog signals received by the transceiver into information in the baseband frequency domain that can be processed by the processor of the UE 100. The different processing units may be separate devices or may be integrated in one or more processors. In one possible embodiment, the controller may run an operating system, such as an Android, iOS, Windows OS, Linux, and hong meng operating system, among others. In other possible embodiments, the controller may run a specific application. A memory may also be provided in the controller for storing instructions and data. In an embodiment of the present application, the controller may be configured to control the transceiver to perform the transmission of the signal and to perform an SN release method according to the following.

The transceiver is used to provide a wireless connectivity interface (e.g., radio frequency front end module, antenna, etc.) for the MN and the SN to communicate with any other suitable devices via one or more networks. Those skilled in the art will appreciate that the transceiver may be a Network interface that provides wireless communication including data connectivity services for Wireless Local Area Networks (WLANs), such as wireless fidelity (Wi-Fi) networks, Bluetooth (BT), third generation Mobile communication technology (3rd-generation Mobile communication technology, 3G) networks, fourth generation Mobile communication technology (the4th generation Mobile communication technology, 4G) networks, fifth generation Mobile communication technology (5th-generation Mobile communication technology, 5G) networks, and/or future-evolution Public Land Mobile Networks (PLMNs). Those skilled in the art will appreciate that the MN and the SN shown in fig. 3 include one transceiver only for illustration, and the number of transceivers is not particularly limited, and may be two or more.

As shown in fig. 3, in step 301, the SN300 sends an indication message to the MN200 indicating whether the SN300 supports SN release initiation based on the UE 100.

In one example, the UE100 initiated SN release may be a UE requested or UE reason triggered SN release, or may be a SN release based on energy saving purposes, such as when the power of the UE100 is below a threshold, or when a user has turned on an energy saving mode of the UE 100. Those skilled in the art will understand that the SN release initiated by the UE is not limited to energy saving purpose, and the SN release may be initiated based on other purposes, which is not specifically limited in the present application.

In one example, the SN carries the relevant indication in some existing message sent to the MN. That is, the SN may multiplex an existing message, such as a UE context (UE context) message, a PDU session (Protocol Data Unit session) message, and the like, to transmit the indication information. For example, a field of one bit (of course, a plurality of bits, e.g., 2 bits, three bits, etc.) of 0 or 1 may be carried in one existing message, where 0 indicates that the SN does not support the SN release initiated by the UE100, and 1 indicates that the SN supports the SN release initiated by the UE 100. For another example, a field of one bit (of course, multiple bits, for example, 2 bits, 3 bits, etc.) may be carried in one existing message, where the absence of the field indicates that the SN does not support the SN release initiated based on the UE100, and the presence of the field indicates that the SN supports the SN release initiated based on the UE 100. Those skilled in the art will appreciate that the SN may also indicate to the MN through a new message, which is not specifically limited in this application.

In one example, if the indication in the indication information indicates that the SN does not support UE 100-initiated SN based release, the MN need not respond to the SN. If the indication information indicates that the SN supports the UE 100-initiated SN release, the MN further configures how the SN responds to the UE 100-initiated SN release in a next step 302 according to an embodiment of the present application.

Next, in step 302, if the SN indicates to the MN that it can support a UE-initiated SN release in step 301, the MN sends configuration information to the SN for configuring how the SN responds to the UE 100-initiated SN release.

In a specific implementation process, step S301 is an optional step, and the MN may send the configuration information to the SN based on the indication information of the SN, or the MN may actively send the configuration information to the SN.

In one example, the configuration information sent by the MN to the SN may be configured at the granularity of UE, cell, or base station, i.e., the configuration information may be different depending on the UE, cell, or base station. For example, for one UE, the MN is allowed to initiate SN release, while for another UE, the MN is not allowed to initiate SN release; or different conditions for allowing the SN to initiate SN release are different, wherein the conditions are indicated by the configuration information sent by the MN to the SN.

In one example, the configuration information can be whether the MN allows the SN to initiate a SN release, e.g., allowed or not, based on a UE's request. Also, the MN can make the relevant allow or disallow indication in some existing message sent to the SN. That is, the SN may multiplex an existing message, such as a UE context (UE context) message, a PDU session (Protocol Data Unit session) message, and the like, to transmit the indication information. For example, a field of one bit (or multiple bits) of 0 or 1 may be carried in one existing message, and permission or non-permission is identified based on a value of the field, for example: no permission is indicated by 0 and permission is indicated by 1. For another example, a field of one bit (of course, multiple bits, for example, 2 bits, 3 bits, etc.) may be carried in one existing message, where the absence of the field indicates that the SN does not support the SN release initiated based on the UE100, and the presence of the field indicates that the SN supports the SN release initiated based on the UE 100.

Or, if the MN sends the configuration information to the UE, the SN is considered to be allowed to initiate SN release based on the request of the UE; if the MN does not feed back information to the UE, the SN is not considered to be allowed to initiate SN release based on the request of the UE. Or, if the preset field in the configuration information has a value, the SN is considered to be allowed to initiate SN release based on the request of the UE; and if the value of the preset field is null, the SN is not allowed to initiate SN release based on the request of the UE.

Or whether the MN gives an explicit indication to indicate whether the SN is allowed to initiate a SN release. For example, the MN carries explicit indication information in a certain message sent to the SN, which indicates that the MN allows the SN to initiate SN release. If the explicit indication information is not carried, the indication indicates that the MN does not allow the SN to initiate SN release.

In addition, those skilled in the art can understand that the configuration information may be carried in an existing message, or may be implemented as a new message, which is not specifically limited in the present application.

In one example, the configuration information may also be a condition for indicating that the MN allows the SN to initiate a SN release. For example, the MN may or may not always allow the SN to initiate a SN release.

In another example, the MN allows the SN to initiate a SN release if the amount of data shunted by the MN to the SN falls below a first threshold within a first predetermined time. For example, assuming that the amount of data shunted by the MN to the SN is below 20Mb in one minute, it can be considered that the MN is not heavily loaded after releasing the SN, and thus the MN allows the SN to initiate a SN release.

In another example, the condition that the MN allows the SN to initiate the SN release may be that the MN allows the SN to initiate the SN release if the amount of data between the UE and the SN is below a second threshold within a second predetermined time.

In another example, it may also be that the MN allows the SN to initiate a SN release, etc. in case the amount of data between the UE and the MN is below a third threshold within a third predetermined time.

The above conditions may be used in combination without conflict.

The predetermined time may be one minute, five minutes, or the like, and the predetermined time may be a default value preset by the SN or may be specified by the MN through configuration information. Also, those skilled in the art can understand that the threshold of the data amount may be a default value preset by the SN, or a value specified by the MN through configuration information, and the predetermined time and the threshold of the data amount are variable according to actual situations and needs, which is not specifically limited in the present application.

In an example, the MN may also send the configuration information to the SN to indicate that the MN allows the SN to initiate SN release, where sending the configuration information to the SN by the MN may only indicate that the SN is allowed to initiate SN release based on a request of the UE, and may not indicate that the SN is not allowed to initiate SN release based on a request of the UE, or the MN may indicate both permission and non-permission to release, and for how to indicate specifically, what has been described above is omitted here for further details. In an alternative embodiment, the MN may further send an indication message including the above-mentioned condition for indicating that the MN allows the SN to initiate a SN release. Wherein the configuration information and the indication information may be contained in the same message (or information) or in different information.

Those skilled in the art will appreciate that the indication message indicating the release condition and the configuration information may be the same message, for example, implicitly indicating that the MN allows the SN to initiate the SN release by indicating the condition to initiate the SN release, or some fields of the configuration message carry the indication message. Similarly, the indication message and the configuration information may also be different messages, for example, fields carrying the configuration information and the indication message in two existing different messages respectively, or two separate different messages. The indication message and the configuration message are not specifically limited in this application.

In step 303, the UE100 sends an indication message to the SN300 that release of the SN is desired, as described above, and the UE100 may wish to release the SN for power saving purposes or other purposes. The indication message desiring to release the SN may carry a cause value, where the cause value indicates a reason (e.g., energy saving purpose) for desiring to release the SN, or the indication message desiring to release the SN may not carry the cause value, and the request desiring to release the SN may default to be initiated for energy saving purpose. Alternatively, the indication information of desire to release the SN may only indicate that the UE desires to release the SN without indicating the cause.

In step 304, after receiving the indication message for releasing the SN from the UE, the SN determines whether to initiate SN release according to the configuration information and/or the indication message obtained in step 302.

As described above, if the configuration information and/or the indication message indicates that the MN does not allow the SN to initiate the SN release, the SN will not initiate the SN release flow; if the configuration information and/or the indication message indicates that the MN allows the SN to initiate SN release, the SN can initiate a SN release flow; if the configuration information and/or the indication message indicates conditions for initiating the SN release, the SN can judge according to the conditions, and the SN release process can be initiated only when the conditions are met, otherwise, the SN release process is not initiated.

In step 304, if the SN determines that the SN Release can be initiated, an SN Release Required (S-Node Release Required) message is sent to the MN in step 305. The MN receives the Release required message from the SN, performs SN Release in step 306, and transmits an SN Release Confirm (S-Node Release Confirm) message to the SN in step 307. After the confirmation message (S-Node Release Confirm) of SN Release sent by MN to SN, MN executes SN Release to Release SN configured to corresponding UE, UE can also clear configuration related to corresponding SN, so that UE is no longer under dual-connection network architecture.

Here, the initiation and execution of SN release and the confirmation process of SN release in step 305 and 307 are referred to the above-mentioned 3GPP related standards as prior art, and are not described herein again.

In another possible implementation, the configuration information in step 302 may also be sent to the UE100 by the MN 200. Based on the specified or limited condition of the configuration information, the UE100 may determine whether to initiate SN release, and the specific procedure may refer to fig. 3, which is not described herein again.

Next, a flow of an SN release method according to an embodiment of the present application will be described with reference to fig. 4A and 4B.

Fig. 4A is a flowchart of a SN release method for a MN according to one embodiment of the present application. As shown in fig. 4A, in step 401, the MN receives an indication message from the SN indicating whether the SN300 supports SN release initiation based on the UE 100.

In a specific implementation process, step S401 is an optional step, and the MN may send the configuration information to the SN based on the indication information of the SN, or the MN may actively send the configuration information to the SN.

In one example, the SN carries the relevant indication in some existing message sent to the MN. That is, the SN may multiplex an existing message to send the indication information, where the existing message is, for example: context (UE context), PDU session (Protocol Data Unit session) message, and so on. For example, a field of one bit (of course, a plurality of bits, e.g., 2 bits, three bits, etc.) of 0 or 1 may be carried in one existing message, where 0 indicates that the SN does not support the SN release initiated by the UE100, and 1 indicates that the SN supports the SN release initiated by the UE 100. For another example, a field of one bit (of course, multiple bits, for example, 2 bits, 3 bits, etc.) may be carried in one existing message, where the absence of the field indicates that the SN does not support the SN release initiated based on the UE100, and the presence of the field indicates that the SN supports the SN release initiated based on the UE 100. Those skilled in the art will appreciate that the SN may also indicate to the MN through a new message, which is not specifically limited in this application.

Next, if the SN does not support UE 100-initiated SN based release, the MN does not need to respond to the SN and the flow ends at step 404. If the SN supports UE 100-initiated SN release, the MN may further configure how the SN responds to the UE 100-initiated SN release at a next step 403, according to an embodiment of the present application.

In step 403, if the SN indicates to the MN that it can support the UE-initiated SN release in step 401, the MN will send configuration information to the SN for configuring how the SN responds to the UE 100-initiated SN release.

In one example, the configuration information sent by the MN to the SN may be configured at the granularity of UE, cell, or base station, i.e., the configuration information may be different depending on the UE, cell, or base station. For example, for different UEs, it is different whether the MN is allowed to initiate the SN release based on the UE's request or not, or different conditions are indicated by the configuration information that allow the SN to initiate the SN release.

In one example, the configuration information can be whether the MN allows the SN to initiate a SN release, e.g., allowed or not, based on a UE's request. Also, the MN can make the relevant allow or disallow indication in some existing message sent to the SN. For example, a field of one bit (or multiple bits) of 0 or 1 may be carried in one existing message, and permission or non-permission is identified based on a value of the field, for example: no permission is indicated by 0 and permission is indicated by 1. For another example, a field of one bit (of course, multiple bits, for example, 2 bits, 3 bits, etc.) may be carried in one existing message, where the absence of the field indicates that the SN does not support the SN release initiated based on the UE100, and the presence of the field indicates that the SN supports the SN release initiated based on the UE 100.

Or, if the MN sends the configuration information to the UE, the SN is considered to be allowed to initiate SN release based on the request of the UE; if the MN does not feed back information to the UE, the SN is not considered to be allowed to initiate SN release based on the request of the UE. Or, if the preset field in the configuration information has a value, the SN is considered to be allowed to initiate SN release based on the request of the UE; and if the value of the preset field is null, the SN is not allowed to initiate SN release based on the request of the UE. Or whether the MN gives an explicit indication to indicate whether the SN is allowed to initiate a SN release. For example, the MN carries explicit indication information in a certain message sent to the SN, which indicates that the MN allows the SN to initiate SN release. If the explicit indication information is not carried, the indication indicates that the MN does not allow the SN to initiate SN release.

Those skilled in the art will understand that the above defined condition may also be that the MN allows the SN to initiate a SN release in case the amount of data between the UE and the SN is below a second threshold within a second predetermined time; or the amount of data between the user equipment and the MN is below a third threshold within a third predetermined time, the MN allows the SN to initiate a SN release, etc. The above conditions may be used in combination without conflict.

Next, if the configuration information and/or the indication message sent in step 403 indicates that the MN allows the SN to initiate SN Release, or the SN meets the condition that the MN allows to initiate SN Release, in step 405, the MN receives an SN Release requirement message (S-Node Release Required) from the SN. The MN receives the Release required message from the SN, performs SN Release in step 406, and transmits an SN Release Confirm message (S-Node Release Confirm) to the SN in step 407. After the confirmation message (S-Node Release Confirm) of SN Release sent by MN to SN, MN executes SN Release to Release SN configured to corresponding UE, UE can also clear configuration related to corresponding SN, so that UE is no longer under dual-connection network architecture.

Similarly, the initiation and execution of SN release and the confirmation process of SN release in steps 405 and 407 described herein are referred to the above-mentioned 3GPP related standards as prior art, and are not described herein again.

Fig. 4B is a flow diagram of a SN release method for SNs according to one embodiment of the present application. As shown in fig. 4B, the SN sends indication information indicating whether the SN supports the UE-initiated SN based release to the MN in step 410.

As shown in steps 301 and 401, a field (or multiple bits) such as 0 or 1 may be added to the existing message to indicate support or non-support, and the indication information may be a new message. In addition, the SN release initiated by the UE may be based on the purpose of energy saving or other purposes, which is not described herein again.

In a specific implementation process, step S410 is an optional step, and the MN may send the configuration information to the SN based on the indication information of the SN, or the MN may actively send the configuration information to the SN.

Next, if the SN does not support UE-initiated SN based release, the flow ends at step 413. If the indication message sent by the SN indicates that the SN supports initiation of SN release, configuration information from the MN will be received in step 411.

In step 411, the configuration information received by the SN from the MN may be whether the MN allows the SN to initiate SN release, may also be a condition that the MN allows the SN to initiate SN release, or may also further include a condition that the MN allows the SN to initiate SN release in a case that the MN allows the SN to initiate SN release. Specifically, reference may be made to the description of steps 302 and 403, which is not described herein again.

After receiving the indication message releasing the SN from the UE, the SN determines based on the configuration information and/or the indication message received from the MN in step 412. In step 414, if the SN determines that the provisioning of the configuration information is not met or the conditions defined by the configuration information are not met, the flow ends. If the SN determines that the SN currently meets the specification of the configuration information or meets the condition that the MN allows the SN to initiate SN release as defined by the configuration information, step 415 is performed. The indication message of SN release from the UE may carry a cause value, where the cause value indicates a reason (e.g., energy saving purpose) for which SN release is desired, or the indication message of SN release may not carry the cause value, and the request of SN release is defaulted to be initiated for energy saving purpose. Alternatively, the indication information of desire to release the SN may only indicate that the UE desires to release the SN without indicating the cause.

In step 415, the SN sends an SN Release Required message (S-Node Release Required) to the MN, and the MN receives the Release Required message from the SN and performs SN Release. And the SN receives an SN Release Confirm message (S-Node Release Confirm) from the MN to indicate that the Release of the SN is completed at step 416.

The SN release method according to an embodiment of the present application is explained with reference to fig. 3 and fig. 4A and 4B above. According to the SN release method of one embodiment of the application, the configuration information and/or the indication information are sent to the SN by the MN, certain limits and conditions are set for SN release, and the problems that the load of the MN is heavier and the data rate is influenced due to the SN release are avoided.

Further, after the release of the SN is completed, the MN may also choose to add the SN. The SN added by the MN may be a SN released before or may be another SN, and this is not specifically limited in this application. According to the embodiment of the present application, the MN may further implement control of SN release initiated by the UE in the SN adding process, and a specific procedure and method will be described in detail in the following embodiments.

Fig. 5 is a signal flow diagram of a SN release method according to another embodiment of the present application. The UE100 is simultaneously connected to the MN200 and the SN300 and performs data communication. The transceivers in the MN200 and the SN300 are responsible for information transfer, and the controller is used to control the transceivers to perform information transfer and to perform the SN release method according to the present application. Specifically, reference may be made to the description of fig. 3, which is not repeated herein.

As shown in fig. 5, in step 501, the SN300 receives an indication message from the UE100 to initiate SN release.

In one example, the UE100 initiated SN release may be a SN release based on energy saving purposes, such as where the power of the UE100 is below a threshold, or where a user has turned on an energy saving mode of the UE 100. Those skilled in the art will understand that the SN release initiated by the UE is not limited to energy saving purpose, and the SN release may be initiated based on other purposes, which is not specifically limited in the present application.

After receiving the indication of releasing the SN by the UE, unlike the case where the SN directly sends a SN release demand message to the MN, according to another embodiment of the present application, in step 502, the SN300 sends an SN release indication message to the MN200, where the indication message may be used to indicate that the SN requests the MN to initiate a SN release or may be used to request the MN to allow the SN to initiate a SN release.

In one example, the SN300 may forward an indication message from the UE100 to the MN 200; or, the SN300 may notify the MN200 of the received indication message for releasing the SN of the UE100, or the SN300 may generate a new indication message for releasing the SN based on the indication message for releasing the SN sent by the UE, and send the new indication message to the MN, and at the same time, may notify the MN of whether the SN release can be initiated by itself, and finally, the MN200 determines whether to initiate the SN release, which is not specifically limited in the embodiment of the present application. Those skilled in the art will appreciate that MN200 knows that an SN release is to be initiated at step 502 and will make a decision whether to initiate a SN release at a later step 503.

In step 503, the MN200 performs determination whether to initiate SN release based on the received indication information.

In one example, if the indication message of step 502 is used to indicate the SN requesting the MN to initiate SN release, MN200 may decide whether to release the SN according to the expectation of SN300 in combination with the needs of MN200 itself.

In one example, as with the embodiment shown in fig. 3, the determination performed by MN200 may be whether the MN allows initiation of a SN release. Specifically, the MN200 may determine according to a load condition of itself, for example, when the data amount shunted to the SN by the MN is lower than a first threshold in a first predetermined time, the MN allows the SN to initiate SN release. For example, assuming that the amount of data shunted by the MN to the SN is below 20Mb in one minute, it can be considered that the MN is not heavily loaded after releasing the SN, and thus the MN allows the SN to initiate a SN release.

In another example, the condition whether the MN is allowed to initiate the SN release may be that the MN allows the SN to initiate the SN release if the amount of data between the UE and the SN is below a second threshold within a second predetermined time.

In another example, the condition whether the MN is allowed to initiate the SN release may be that the MN allows the SN to initiate the SN release in case the amount of data between the user equipment and the MN is below a third threshold within a third predetermined time, and so on. The above conditions may be used in combination without conflict.

The predetermined time may be one minute, five minutes, etc., and the predetermined time may be a default value preset and may be changed according to actual conditions and needs. Similarly, those skilled in the art can understand that the threshold setting of the data amount may also be a preset default value, and may also be modified according to actual situations and needs, and this application does not specifically limit this.

Those skilled in the art will appreciate that in step 503, if the MN decides not to perform a SN release, the flow ends, and if the MN decides to initiate a SN release, the following steps 504 and 505 are performed.

In step 504, MN200 sends SN Release Request (e.g., S-Node Release Request) message to SN300 and performs SN Release, and then receives SN Release acknowledgement (e.g., S-Node Release Request acknowledgement) message from SN in step 505.

Also, the initiation of SN release, the confirmation of SN release, and the execution process in steps 504 and 505 are referred to the relevant standards of 3GPP as prior art, and are not described herein again.

In another example, if the indication message of step 502 is used to indicate that the MN is requested to allow the SN to initiate SN release, the MN may also make a decision according to its own load condition in step 503. The load condition may be a certain condition or a combination of conditions in the above examples, and will not be described herein again.

In step 503, if the MN determines that the SN is not allowed to initiate the SN release, the flow ends, and if the MN determines that the SN is allowed to initiate the SN release, the MN may send a message that allows the SN to initiate the SN release to the SN.

Next, after receiving the message from the MN that allows the SN to initiate a SN release, the SN may initiate a SN release. The step of the SN initiating the SN release is as described above, and the specific process is as follows: the SN sends an SN Release Required (S-Node Release Required) message to the MN, and the SN receives an SN Release confirmation (S-Node Release Confirm) message from the MN and stops providing the user data to the UE. After the confirmation message (S-Node Release Confirm) of SN Release sent by MN to SN, MN executes SN Release to Release SN configured to corresponding UE, UE can also clear configuration related to corresponding SN, so that UE is no longer under dual-connection network architecture.

Next, a flow of an SN release method according to an embodiment of the present application will be described with reference to fig. 6A and 6B.

Fig. 6A is a flowchart of a SN release method for a MN according to one embodiment of the present application. As shown in fig. 6A, the MN200 receives an indication message of SN release from the SN300 in step 601.

After receiving the indication of releasing the SN by the UE, unlike the SN directly sending the SN release demand message to the MN, according to another embodiment of the present application, in step 502, the SN300 sends an indication message of releasing the SN to the MN200, where the indication message is used to indicate that the UE100 desires to release the SN, that is, in step 502, the SN300 notifies the MN200 of the desire of releasing the SN by the UE 100.

In one example, the SN300 may forward an indication message from the UE100 to the MN 200; or, the SN300 may notify the MN200 of the indication message of releasing the SN received from the UE100, and may notify the MN of whether it can initiate the SN release, and finally, the MN200 determines whether to initiate the SN release, which is not specifically limited in the embodiment of the present application. Those skilled in the art will appreciate that the MN200 is aware of the UE100 initiated SN release at step 601 and will make a decision whether to initiate a SN release at a later step.

At step 602, the MN200 decides whether to initiate a SN release.

In one example, MN200 can decide whether to release the SN based on the desire of SN300 in conjunction with the needs of MN200 itself.

In one example, as with the previous embodiments, the determination performed by the MN200 can be whether the MN is allowed to initiate a SN release.

Specifically, the MN200 may determine according to a load condition of itself, for example, when the data amount shunted to the SN by the MN is lower than a first threshold within a first predetermined time, the MN allows to initiate SN release. For example, assuming that the amount of data shunted by the MN to the SN is below 20Mb in one minute, it can be considered that the MN is not heavily loaded after releasing the SN, and thus the MN allows the SN to initiate a SN release.

In another example, the condition whether the MN is allowed to initiate the SN release may be that the MN is allowed to initiate the SN release in case the amount of data between the UE and the SN is below a second threshold within a second predetermined time.

In another example, the condition whether the MN is allowed to initiate the SN release may be that the MN is allowed to initiate the SN release in case the amount of data between the user equipment and the MN is below a third threshold within a third predetermined time, and so on. The above conditions may be used in combination without conflict.

The predetermined time may be one minute, five minutes, etc., and the predetermined time may be a preset default value or may be changed according to actual conditions and needs. Similarly, those skilled in the art can understand that the threshold setting of the data amount may be a preset default value, or may be modified according to actual situations and needs, and this application does not specifically limit this.

Those skilled in the art will appreciate that in step 602, if the MN decides not to perform SN release, then the flow goes to step 603, where the flow ends, and if the MN decides to initiate SN release, then the following steps 604 and 605 are performed.

In step 604, MN200 sends SN Release Request ((S-Node Release Request) message to SN300, and then receives SN Release Acknowledge (S-Node Release Request Acknowledge) message from SN and executes SN Release in step 605. similarly, the process of initiating and executing SN Release and SN Release Acknowledge in steps 604 and 605 is prior art, and reference may be made to the above-mentioned 3GPP related standard, and details are not repeated here.

Fig. 6B is a flow diagram of a SN release method for SNs according to one embodiment of the present application. As shown in fig. 6B, the SN300 receives an indication message of SN release from the UE100 in step 610.

Next, the SN300 sends an indication message of SN release to the MN200 in step 611.

Also, in one example, the SN300 may forward an indication message from the UE100 to the MN 200; or, the SN300 may notify the MN200 of the indication message of releasing the SN received from the UE100, and may notify the MN of whether it can initiate the SN release, and finally, the MN200 determines whether to initiate the SN release, which is not specifically limited in the embodiment of the present application. Those skilled in the art will appreciate that at step 611 the MN200 knows that an SN release is to be initiated and will make a decision in a subsequent step whether to initiate a SN release.

As described in step 602 above, if the MN200 decides to Release the SN, the SN300 receives a Release Request (S-Node Release Request) message from the MN200 in step 612.

The SN300 sends an SN Release Acknowledge (S-Node Release Request acknowledgement) message to the MN200 in step 613. Also, the initiation and execution of the SN release and the confirmation process of the SN release in steps 612 and 613 are referred to the relevant standards of the 3GPP as the prior art, and are not described herein again.

An SN release method according to another embodiment of the present application is described with reference to fig. 5 and fig. 6A and 6B above. According to the SN release method of another embodiment of the application, the MN can make a decision whether to release the SN or not based on the SN requirement and the self condition of the MN, and the problem that the SN release may cause heavier load of the MN and influence the data rate is avoided.

Fig. 7 is a signal flow diagram of a SN release method according to yet another embodiment of the present application. The UE100 is simultaneously connected to the MN200 and the SN300 and performs data communication. The transceivers in the MN200 and the SN300 are responsible for information transfer, and the controller is used to control the transceivers to perform information transfer and to perform the SN release method according to the present application. Specifically, reference may be made to the description of fig. 3, which is not repeated herein.

In step 701, the SN300 receives an indication message from the UE100 to initiate SN release.

Next, in step 702, the process of SN release is completed between the MN200 and the SN 300. Those skilled in the art will appreciate that the release of the SN may be initiated by the MN200, may be initiated by the SN300, may be initiated based on a SN release request sent by a UE or a release request for energy saving purposes, etc. The specific SN releasing process may be an execution mechanism as shown in fig. 1, or may be a flow of SN releasing as shown in the embodiment of fig. 3 or fig. 5, which is not described herein again.

After the release of the SN300 is completed, the MN200 performs SN addition in step 703. According to another embodiment of the present application, the MN implements control of SN based UE-initiated SN release during SN addition.

In one example, the MN200 sends an SN Addition Request (S-Node Addition Request) message to the SN300 to enable SN Addition. The SN addition may be performed immediately after the completion of the release of the SN300, may be performed after a predetermined time, such as 1 minute, has elapsed after the completion of the release of the SN300, or may be initiated according to the load condition of the MN200, or the like.

Those skilled in the art will understand that the SN added by the MN may be the SN released in step 702, or may be another SN, which is not specifically limited in this application.

In one example, MN200 adds indication information in the SN add request message sent to SN300 to indicate in a subsequent procedure whether the SN allows initiation of a SN release. The indication information may be a simple indication of permission or non-permission, or may be a condition that allows the SN to initiate the SN release is added, or may be a condition that only allows the SN to initiate the SN release, or the like.

As in the above embodiments, this indication may be implemented as a field carrying a bit of 0 or 1 in the SN add message, with 0 indicating no grant and 1 indicating grant. Or whether the MN gives an explicit indication to indicate whether the SN is allowed to initiate SN release, the MN carries explicit indication information in a certain message sent to the SN to indicate permission, and if the explicit indication information is not carried to indicate that the SN is not allowed.

The conditions that are appended to allow the SN to initiate a SN release may be time-based conditions. For example, indicating that release of the SN is not allowed for a predetermined time, which may be one minute, five minutes, etc. The predetermined time may be a default value preset by the SN, a value specified by the MN through the configuration information, or a value predefined in the standard, which is not specifically limited in the present application. Further, the time condition for allowing the SN to initiate the SN release may also be directly specified by the MN through configuration information. For example, the MN200 may add explicit time indication information in the SN addition request message sent to the SN 300. The SN300 starts a timing, e.g., five minutes, ten minutes, etc., upon receiving the indication. The SN300 is not allowed to initiate a SN release within a five minute or ten minute period of this timing. It will be understood by those skilled in the art that the default time of the SN or the time designated by the MN may be variable according to actual circumstances and needs, and the present application is not limited thereto.

In a specific implementation process, the indication information and the addition request information may be the same message (or information), for example: setting a field for indicating the indication information in the addition request information; the indication information and the addition request information may be different messages (or information). In the specific implementation process, the addition request information may also indicate, by default, that release of the SN is not allowed within a predetermined time, for example: after the SN receives the adding request information, the SN finds that the MN releases the SN within the preset time length of the adding request information, and the SN does not release the SN within the preset time length. The default predetermined time may be configured by the MN based on the configuration information, may be set by a standard, or may be pre-stored in the SN, which is not limited in the embodiment of the present invention.

In one example, explicit indication information may not be added to the SN addition request message sent by the MN200 to the SN300 to indicate that the MN200 does not wish to initiate SN release, in which case, the SN300 may not initiate SN release within a certain time period. The certain time duration may be one minute, five minutes, etc. from the SN receiving the SN addition request message, or from the last completion of the SN release. Those skilled in the art can understand that the certain time duration mentioned here may be a default configuration of the SN300, or may be implemented through a network according to actual situations and needs, and the time duration may also be variable according to actual situations and needs, which is not specifically limited in the present application.

In an example, the indication information that is not added may also be an indication message indicating that the SN cannot initiate a SN release demand message or an indication message indicating that the SN is released, the MN cannot send a SN release request message, or the MN or the SN does not respond after the SN is released.

In the above example, the above indication information may be carried in the SN addition request message, may be included in any other message in the SN addition process, or may be sent to the SN by the MN in a separate message. The skilled person will understand that the indication information is for indication purpose, and the application does not limit the form or carrier of the indication information specifically.

Next, in step 704, the SN300 receives indication information of releasing the SN from the UE 100. And in step 705, the SN300 determines whether to initiate SN release according to the indication of the MN200 to the SN300 in step 703 above.

For example, if the SN is not allowed to initiate a SN release within five minutes as indicated in the process of adding a SN by the MN200 in step 703, the SN300 makes a determination according to the time, and if a SN release request from the SN addition to the UE has elapsed five minutes, the SN300 decides to initiate a SN release.

Next, the SN300 issues an SN Release Required (S-Node Release Required) message to the MN200 in step 706, the MN200 performs SN Release in step 707, and sends an SN Release Confirm (S-Node Release Confirm) message to the SN in step 708.

Here, the specific process of initiating and executing the SN release of step 706-708 may be an execution mechanism of the existing standard as shown in fig. 1, or may be a flow of SN release as shown in the embodiment of fig. 3 or fig. 5, which is not described herein again.

Next, a flow of an SN release method according to an embodiment of the present application will be described with reference to fig. 8A and 8B.

Fig. 8A is a flowchart of a SN release method for a MN according to one embodiment of the present application. As shown in fig. 8A, the MN200 receives an SN Release demand message from the SN300 in step 801, performs SN Release in step 802, and sends an SN Release acknowledgement message (S-Node Release Confirm) to the SN in step 803. The specific process of initiating and executing SN release in steps 801, 802, and 803 may be an execution mechanism of the existing standard as shown in fig. 1, or may be a process of SN release as shown in the embodiment of fig. 3 or fig. 5, which is not described herein again.

In step 804, the MN transmits a SN-added Request message (S-Node Addition Request) to the SN. According to the embodiment of the application, the MN can realize the control of SN release initiated by the SN based on the UE in the SN adding process.

In one example, the MN200 sends an SN Addition Request message (S-Node Addition Request) to the SN300 to implement SN Addition. The SN addition may be performed immediately after the completion of the release of the SN300, may be performed after a predetermined time, such as 1 minute, has elapsed after the completion of the release of the SN300, or may be initiated according to the load condition of the MN200, or the like.

As with the embodiments described above, this indication may be implemented as a field carrying a bit (or bits) of 0 or 1 in the SN addition message, with 0 indicating no permission and 1 indicating permission. Or whether the MN gives an explicit indication to indicate whether the SN is allowed to initiate SN release, the MN carries explicit indication information in a certain message sent to the SN to indicate permission, and if the explicit indication information is not carried to indicate that the SN is not allowed.

The conditions that are appended to allow the SN to initiate a SN release may be time-based conditions. For example, indicating that release of the SN is not allowed for a predetermined time, which may be one minute, five minutes, etc. The predetermined time may be a default value preset by the SN, a value specified by the MN through the configuration information, or a value predefined in the standard, which is not specifically limited in the present application.

Further, the time condition for allowing the SN to initiate the SN release may also be directly specified by the MN through configuration information. For example, the MN200 may add explicit time indication information in the SN addition request message sent to the SN 300. The SN300 starts a timing, e.g., five minutes, ten minutes, etc., upon receiving the indication. The SN300 is not allowed to initiate a SN release within a five minute or ten minute period of this timing. It will be understood by those skilled in the art that the default time of the SN or the time designated by the MN may be variable according to actual circumstances and needs, and the present application is not limited thereto.

In one example, explicit indication information may not be added to the SN addition request message to indicate that MN200 does not wish to initiate a SN release, in which case SN300 may not initiate a SN release for a certain period of time. The certain time duration may be one minute, five minutes, etc. from the SN receiving the SN addition request message, or from the last completion of the SN release. Those skilled in the art can understand that the certain time duration mentioned here may be a default configuration of the SN300, or may be implemented through a network according to actual situations and needs, and the time duration may also be variable according to actual situations and needs, which is not specifically limited in the present application.

In an example, the indication information that is not added may also be an indication that the SN cannot initiate a SN release demand message, cannot send an indication message indicating to release the SN, the MN cannot send a SN release request message, or an indication that the MN or the SN does not respond after sending out a SN release.

Thereafter, if the condition for initiating the SN release is satisfied, the MN200 receives the SN release demand message from the SN300 in step 805, and the flow goes to step 802 to perform the SN release.

It should be noted here that, when the MN first adds the SN so that the UE is in the dual-connection network architecture, the MN may not send the indication information limiting the initiation of the SN release condition to the SN. After releasing the SN for the first time, when the MN adds the SN for the second time, the MN may send indication information limiting the condition for initiating releasing the SN to the SN, or when the MN adds the SN, if the time length from the last releasing is less than a certain time length, the MN may send indication information limiting the condition for initiating releasing the SN by the SN, where the indication information is various indications or conditions as described in step 703 of the above embodiments. Likewise, the indication information may be carried in the SN addition request information or sent in a form of separate information, which is not described herein again.

Fig. 8B is a flow diagram of a SN release method for SNs according to one embodiment of the present application. As shown in fig. 8B, after the SN300 receives an indication message indicating SN release from the UE100 in step 810 and sends an SN release demand message to the MN200 in step 811 and the MN200 performs SN release, the SN300 receives an acknowledgement message of SN release from the MN200 in step 812. The specific process of initiating and executing the SN release in step 810 and 812 may be an execution mechanism of the existing standard as shown in fig. 1, or may be the flow of SN release as shown in the embodiment of fig. 3 or fig. 5, which is not described herein again.

In step 813, the SN300 receives an SN Addition Request message (S-Node Addition Request) from the MN 200. According to the embodiment of the application, the MN can realize the control of SN release initiated by the SN based on the UE in the SN adding process.

It should be noted here that, when the MN first adds the SN so that the UE is in the dual-connection network architecture, the MN may not send the indication information limiting the initiation of the SN release condition to the SN. After releasing the SN for the first time, the MN may send to the SN an indication restricting the initiation of the SN release condition when the MN adds the SN for the second time, which may be various indications or conditions as described in step 703 of the above embodiments. Likewise, the indication information may be carried in the SN addition request information or sent in a form of separate information, which is not described herein again.

Next, in step 814, the SN300 receives a SN release request from the UE100 again. At step 815, the SN300 determines whether it currently meets the requirement to initiate SN release, based on the indication of the SN addition request message from the MN.

As described above, the condition that the initiation of the SN release is satisfied may be that the MN allows the initiation of the SN release, or that a condition that the MN allows the initiation of the SN release is satisfied, where the condition may be the above-mentioned time condition, or a condition of the amount of data to be transmitted, or the like.

When the determination in step 815 is negative, it indicates that the current MN200 is not allowed to initiate SN release, and the flow goes to step 817 to end. If the determination of step 815 is yes, step 816 is performed, and the SN300 sends a SN release required message to the MN 200. The specific process of initiating and executing SN release from step 816 may be an execution mechanism of the existing standard as shown in fig. 1, or may be a flow of SN release as shown in the embodiment of fig. 3 or fig. 5, which is not described herein again.

A SN release method according to still another embodiment of the present application is described with reference to fig. 7 and fig. 8A and 8B above. According to the SN release method of the further embodiment of the present application, the MN can realize control of SN release through the process of adding SNs, avoiding the problem that the MN load is heavier and the data rate is affected due to SN release.

The method embodiments of the present application may be implemented in software, magnetic, firmware, etc.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a computer-readable storage medium, which represent various logic in a processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. These representations, known as "IP cores" may be stored on a tangible computer-readable storage medium and provided to a number of customers or manufacturing facilities to load into the manufacturing machines that actually make the logic or processor.

While the description of the present application will be described in conjunction with the preferred embodiments, it is not intended that the features of the present application be limited to this embodiment. Rather, the invention has been described in connection with embodiments for the purpose of covering alternatives and modifications as may be extended based on the claims of the present application. In the following description, numerous specific details are included to provide a thorough understanding of the present application. The present application may be practiced without these particulars. Moreover, some of the specific details have been omitted from the description in order to avoid obscuring or obscuring the focus of the present application. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

Further, various operations will be described as multiple discrete operations, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

As used herein, the term "module" or "unit" may refer to, be, or include: an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

In the drawings, some features of the structures or methods are shown in a particular arrangement and/or order. However, it is to be understood that such specific arrangement and/or ordering may not be required. In some embodiments, these features may be arranged in a manner and/or order different from that shown in the illustrative figures. Additionally, the inclusion of structural or methodical features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the application may be implemented as computer programs or program code executing on programmable systems comprising multiple processors, a storage system (including volatile and non-volatile memory and/or storage elements), multiple input devices, and multiple output devices.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described in this application are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. In some cases, one or more aspects of at least some embodiments may be implemented by representative instructions stored on a computer-readable storage medium, which represent various logic in a processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. These representations, known as "IP cores" may be stored on a tangible computer-readable storage medium and provided to a number of customers or manufacturing facilities to load into the manufacturing machines that actually make the logic or processor.

Such computer-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles of manufacture or formation by machines or devices that include storage media such as: hard disk any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks; semiconductor devices such as Read Only Memory (ROM), Random Access Memory (RAM) such as Dynamic Random Access Memory (DRAM) and Static Random Access Memory (SRAM), Erasable Programmable Read Only Memory (EPROM), flash memory, Electrically Erasable Programmable Read Only Memory (EEPROM); phase Change Memory (PCM); magnetic or optical cards; or any other type of media suitable for storing electronic instructions.

Thus, embodiments of the present application also include non-transitory computer-readable storage media that contain instructions or that contain design data, such as Hardware Description Language (HDL), that define the structures, circuits, devices, processors, and/or system features described herein.

Claims

1. A secondary network device release method for a primary network device, the method comprising

Sending configuration information to the secondary network device, where the configuration information is used to instruct the primary network device to allow the secondary network device to initiate a secondary network device release demand message, where the secondary network device release demand message is used to request the primary network device to execute the secondary network device release;

receiving the secondary network device release requirement message from the secondary network device.

2. A secondary network device release method for a primary network device, the method comprising

Sending configuration information to the secondary network device, where the configuration information is used to indicate a condition that the primary network device allows the secondary network device to initiate a secondary network device release demand message, where the secondary network device release demand message is used to request the primary network device to execute the secondary network device release;

3. The method of claim 1, further comprising sending, to the secondary network device, indication information indicating conditions for allowing the secondary network device to initiate the secondary network device release requirement, the conditions comprising at least one of:

4. The method of claim 2, wherein the condition instructing the primary network device to allow the secondary network device to initiate a secondary network device release requirement comprises at least one of:

5. The method of claim 3 or 4, further comprising

The primary network device receiving an indication message from the secondary network device, the indication message being used to indicate that the secondary network device supports a secondary network device release request from the user equipment; or, the indication message is used to indicate that the secondary network device supports a secondary network device release request based on an energy-saving purpose from the user equipment.

6. The method of claim 5, wherein the indication message is sent to the primary network device after a secondary network device release request for the user device is received by the secondary network device; or, after the secondary network device receives a secondary network device release request based on the energy saving purpose of the user equipment, the indication message is sent to the primary network device.

7. A secondary network device release method for a secondary network device, the method comprising

Receiving configuration information from the primary network device,

the configuration information comprises an indication that the primary network device allows the secondary network device to initiate a secondary network device release requirement message, wherein the secondary network device release requirement message is used for requesting the primary network device to perform the secondary network device release; and

and receiving a release request of the auxiliary network equipment, and sending a release demand message of the auxiliary network equipment to the main network equipment.

8. A secondary network device release method for a secondary network device, the method comprising

Receiving configuration information from the primary network device,

the configuration information includes a condition indicating that the primary network device allows the secondary network device to initiate a secondary network device release requirement, wherein the secondary network device release requirement is for requesting the primary network device to perform the secondary network device release; and

receiving a release request of the auxiliary network equipment, and sending a release demand message of the auxiliary network equipment to the main network equipment under the condition that the main network equipment allows the auxiliary network equipment to initiate the release demand message of the auxiliary network equipment is met.

9. The method of claim 7, further comprising receiving, from the primary network device, indication information indicating conditions for allowing the secondary network device to initiate the secondary network device release requirement, the conditions comprising at least one of:

10. The method of claim 8, wherein the condition instructing the primary network device to allow the secondary network device to initiate a secondary network device release requirement comprises at least one of:

11. The method of claim 9 or 10, further comprising

Sending an indication message to the primary network device, the indication message being used to indicate that the secondary network device supports a secondary network device release request from the user device; or, the indication message is used to indicate that the secondary network device supports a secondary network device release request based on an energy-saving purpose from the user equipment.

12. The method of claim 11, wherein the receiving the secondary network device release request comprises:

receiving the secondary network device release request from user equipment; or receiving a secondary network device release request based on energy saving purpose from the user equipment.

13. A secondary network device release method for a primary network device, the method comprising receiving an indication message from the secondary network device indicating release of the secondary network device;

and sending a secondary network device release request message to the secondary network device under the condition that the primary network device is determined to allow the secondary network device to be released, wherein the secondary network device release request message is used for requesting the release of the secondary network device.

14. The method of claim 13, wherein determining that the primary network device allows release of the secondary network device comprises at least one of:

15. The method of claim 13 or 14,

the indication message for indicating the release of the secondary network device is sent to the primary network device after the secondary network device receives a secondary network device release request of the user equipment; or, after receiving a secondary network device release request based on the energy saving purpose of the user equipment, the secondary network device sends the request to the primary network device.

16. A secondary network device release method for a secondary network device, the method comprising sending an indication message to a primary network device indicating release of the secondary network device,

receiving a secondary network device release request message from the primary network device, wherein the secondary network device release request message is used for requesting release of the secondary network device.

17. The method of claim 16,

18. A secondary network device release method for a primary network device, the method comprising receiving a first secondary network device release demand message requesting the primary network device to perform the secondary network device release,

performing the secondary network device release and sending a confirmation message of the secondary network device release to the secondary network device,

sending a request message and an indication message for adding the auxiliary network equipment to the auxiliary network equipment, wherein the indication message is used for indicating that the auxiliary network equipment is not allowed to be released within a preset time; or

And sending a request message for adding the auxiliary network equipment to the auxiliary network equipment, wherein the request message is also used for indicating that the auxiliary network equipment is not allowed to be released within preset time.

19. The method of claim 18, wherein the indication information carries information of the preset time; and/or the preset time is a time configured to the auxiliary network device.

20. The method of claim 18 or 19, further comprising receiving a second secondary network device release demand message requesting the primary network device to perform the secondary network device release, and performing the secondary network device release.

21. A secondary network device release method for a secondary network device, the method comprising

Transmitting a first secondary network device release demand message to a primary network device requesting the primary network device to perform the secondary network device release,

receiving an acknowledgement message of the secondary network device release from the primary network device, an

Receiving a request message and an indication message from the primary network device for adding the secondary network device, wherein the indication message is used for indicating that the release of the secondary network device is not allowed within a preset time; or

And receiving a request message for adding the auxiliary network device from the main network device, wherein the request message is also used for indicating that the auxiliary network device is not allowed to be released within a preset time.

22. The method of claim 21, wherein the indication information carries information of the preset time; and/or the preset time is a time configured to the auxiliary network device.

23. The method of claim 21 or 22, further comprising, after the preset time has elapsed, transmitting a second secondary network device release demand message to the primary network device requesting the primary network device to perform the secondary network device release.

24. A computer-readable storage medium having stored thereon instructions which, when executed on the computer, cause the computer to perform the method of any one of claims 1 to 23.

25. An apparatus, comprising:

a processor;

a memory having instructions stored thereon that, when executed by the processor, cause the user equipment to perform the method of any of claims 1-23.