CN113966014B

CN113966014B - Secondary network device release method, computer readable storage medium and device

Info

Publication number: CN113966014B
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: 2024-06-25
Anticipated expiration: 2040-08-06
Also published as: CN113966014A; WO2022017329A1

Abstract

The embodiment of the application relates to a secondary network device release method, which comprises the steps of sending configuration information to secondary network devices, wherein the configuration information is used for indicating a primary network device to allow the secondary network devices to initiate secondary network device release demand messages, and the secondary network device release demand messages are used for requesting the primary network devices to execute secondary network device release; and receiving a secondary network device release demand message from the secondary network device. Embodiments of the application also relate to a machine-readable medium and apparatus.

Description

Secondary network device release method, computer readable storage medium and device

Technical Field

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

Background

When a User Equipment (UE) is performing a service with a high transmission rate, for example, the UE performs a real-time fight game, uses GSP navigation, high definition video call, etc., to support the above communication service, the UE may be configured to connect to two base stations and perform data communication at the same time, thereby increasing the transmission rate of the UE.

A scenario where a UE connects to two network devices simultaneously and communicates data may be referred to as multiple access technology dual connectivity (Multi-Radio Dual Connectivity, MR-DC). When a network device of E-UTRA (Evolved-UMTS Terrestrial Radio Access, evolved UMTS terrestrial Radio access) is used as a Master network device (MN), and a network device of NR (New Radio, new air interface) is used as a Secondary network device (SN), the scenario is specifically called E-UTRA-NR dual connectivity (E-UTRA-NR Dual Connectivity, EN-DC) in MR-DC; similarly, there are NR-E-UTRA double linkages (NR-E-UTRA Dual Connectivity, NE-DC) and NR-NR double linkages (NR-NR Dual Connectivity, NR-DC).

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

Disclosure of Invention

The application is described in terms of several aspects, embodiments and advantages of which can be referenced to one another.

According to a first aspect of the present application, there is provided a secondary network device release method for a primary network device, comprising: transmitting configuration information to the auxiliary network device, wherein the configuration information is used for indicating the main network device to allow the auxiliary network device to initiate an auxiliary network device release requirement message, and the auxiliary network device release requirement message is used for requesting the main network device to execute the auxiliary network device release; and receiving a release requirement message of the auxiliary network equipment from the auxiliary network equipment.

According to a second aspect of the present application, there is provided a secondary network device release method for a primary network device, comprising: transmitting configuration information to the auxiliary network device, wherein the configuration information is used for indicating a condition that the main network device allows the auxiliary network device to initiate an auxiliary network device release requirement message, and the auxiliary network device release requirement message is used for requesting the main network device to execute the auxiliary network device release; and receiving a release requirement message of the auxiliary network equipment from the auxiliary network equipment.

In some embodiments, the method further comprises sending, to the secondary network device, indication information indicating a condition 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 quantity distributed to the auxiliary network equipment by the main network equipment is lower than a first threshold value in a first preset time, the main network equipment allows the auxiliary network equipment to initiate the auxiliary network equipment to release a demand message;

In the case that the data volume between the user equipment and the auxiliary network equipment is lower than a second threshold value in a second preset time, the main network equipment allows the auxiliary network equipment to initiate the auxiliary network equipment to release a demand message;

And the main network equipment allows the auxiliary network equipment to initiate the auxiliary network equipment to release a demand message under the condition that the data volume between the user equipment and the main network equipment 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 secondary network device release requirements includes at least one of:

the master network device always allows the auxiliary network device to initiate the release requirement of the auxiliary network device;

The primary network device always does not 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, the indication message being for indicating that the secondary network device supports a secondary network device release request from the user device; or the indication message is used for indicating the auxiliary network equipment to support the auxiliary network equipment release request based on the 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 device; or after the auxiliary network equipment receives the auxiliary network equipment release request based on the energy saving purpose of the user equipment, the indication message is sent to the main network equipment.

According to a third aspect of the present application, there is provided a secondary network device release method for use with the secondary network device, the method comprising: receiving configuration information from a primary network device, the configuration information comprising information indicating 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 execute the secondary network device release; and receiving a release request of the auxiliary network equipment, and sending a release requirement 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, wherein the secondary network device release requirement is for requesting the primary network device to perform the secondary network device release; and receiving a secondary network device release request, and sending a secondary network device release requirement message to the primary network device under the condition that the primary network device allows the secondary network device to initiate the secondary network device release requirement message.

In some embodiments, the method further comprises receiving, from the primary network device, indication information indicating a condition 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 quantity distributed to the auxiliary network equipment by the main network equipment is lower than a first threshold value in a first preset time, the main network equipment allows the auxiliary network equipment to initiate the release requirement of the auxiliary network equipment;

In the case that the data volume between the user equipment and the auxiliary network equipment is lower than a second threshold value in a second preset time, the main network equipment allows the auxiliary network equipment to initiate the release requirement of the auxiliary network equipment;

And the main network equipment allows the auxiliary network equipment to initiate the release requirement of the auxiliary network equipment under the condition that the data volume between the user equipment and the main network equipment is lower than a third threshold value in a third preset time.

In some embodiments, the method further comprises 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 for indicating the auxiliary network equipment to support the auxiliary network equipment release request based on the energy saving purpose from the user equipment.

In some embodiments, receiving a secondary network device release request includes receiving the secondary network device release request from a user device; or receiving a secondary network device release request from the user device for energy saving purposes.

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 to release the secondary network device.

In some implementations, determining that the primary network device allows the secondary network device to be released includes at least one of:

The primary network device allows the secondary network device to initiate a release request message if the amount of data shunted to the secondary network device by the primary network device is below a first threshold within a first predetermined time;

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 for 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 falls below a third threshold for a third predetermined time.

In some embodiments, the indication message for indicating to release 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 device; or after receiving the release request of the auxiliary network device based on the energy saving purpose of the user device, the auxiliary network device sends the release request to the main 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 to release 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 to release the secondary network device.

According to a seventh aspect of the present application, there is provided a secondary network device release method for a primary network device, the method comprising receiving a first secondary network device release requirement message for 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 for adding the secondary network device and an indication message for indicating that the secondary network device is not allowed to be released for a preset time to the secondary network device; 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 configured at the auxiliary network equipment.

In some embodiments, the method further comprises receiving a second secondary network device release requirement message for 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 for a secondary network device, the method comprising sending a first secondary network device release requirement message to a primary network device for requesting the primary network device to perform the secondary network device release, receiving a confirmation message from the primary network device for the secondary network device release, and receiving a request message from the primary network device to add the secondary network device and an indication message for indicating that the secondary network device is not allowed to be released for a preset time; or receiving a request message from the primary network device for adding the secondary network device, wherein the request message is also used for indicating that the secondary 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, sending a second secondary network device release requirement 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 that, when executed by the processor, cause the user equipment to perform the method according to the first to eighth aspects of the application.

Drawings

FIGS. 1 (a) -1 (c) are schematic diagrams of several standardized SN release mechanisms in the prior 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 an SN release method according to one embodiment of the present application;

Fig. 4A is a flowchart of an SN release method for a MN according to one embodiment of the present application;

FIG. 4B is a flow chart of an SN release method for an SN in accordance with one embodiment of the present application;

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

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

FIG. 6B is a flow chart of an SN release method for an SN in accordance with another embodiment of the present application;

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

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

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

Detailed Description

The application will be further described with reference to specific examples and figures.

It will 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 only used to distinguish one feature from another. For example, a first feature may be referred to as a second feature, and similarly a second feature may be referred to as a first feature, without departing from the scope of the example embodiments.

It should be noted that in this specification, like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Relevant specifications are made for SN release machines in standard TS 38.423 of the third generation partnership project (3rd Generation Partnership Project,3GPP). Fig. 1 (a) -1 (c) are schematic diagrams of several standardized SN release mechanisms in the prior art. The SN release mechanism is SN release for a certain UE. Fig. 1 (a) and 1 (b) show SN release initiated by MN. Wherein the MN sends an SN release request (S-Node Release Request) message to the SN, and if the SN determines that release is possible, the SN stops providing user data to the UE and sends an SN release acknowledgement (S-Node Release Request Acknowledge) message to the MN as shown in fig. 1 (a); if the SN determines that release is not possible, the SN sends an SN release rejection (S-Node Release Reject) message, as shown in FIG. 1 (b). After receiving the release acknowledgement (S-Node Release Request Acknowledge) message sent by the SN, the MN performs SN release, and releases the SN configured to the corresponding UE, and the UE may also clear the corresponding SN-related configuration, where the UE is no longer in the dual-connectivity network architecture.

And SN-initiated SN release as shown in fig. 1 (c), the SN sends an SN release request (S-Node Release Required) message to the MN, and the SN receives an SN release acknowledgement (S-Node Release Confirm) message from the MN and stops providing user data to the UE. According to existing SN release mechanisms, SN release initiated by the SN is not failed. After the MN sends an acknowledgement message (S-Node Release Confirm) of SN release to the SN, the MN performs SN release, and releases the SN to be configured to the corresponding UE, and the UE may also clear the corresponding SN-related configuration, where the UE is no longer under the dual-connectivity 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 connected to and in data communication with both the network device 200 and the network device 300, wherein 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 MN (MN), and the network device 300 establishing only a user plane connection with the UE100 is referred to as a Secondary network device, a Secondary Node, a Secondary base station or SN (SN). It will be appreciated that all radio link control signaling messages and functions of the UE are managed by the MN (primary network device), whereas data plane radio bearers may be served by the MN or SN (secondary network device) independently or by both the MN and SN. The throughput of the network can be improved by transmitting data through the two legs of the MN and the SN. For UEs with power saving requirements, the UE may indicate to the SN that SN release is desired for power saving purposes, in particular, the UE may indicate to the SN that SN release is desired for power saving purposes via a UE assistance information message, which may be sent directly to the SN or forwarded to the SN via the MN.

When the SN receives the UE's desire to release the SN, the SN may decide whether to release the SN to the UE. If the SN decides to release the SN, then an SN release procedure can be initiated and an SN release requirement message can be sent to the MN. As described above, according to existing SN release mechanisms, SN release initiated for SN must succeed.

In the EN-DC scene, the load information of the base station is not interacted between the MN and the SN. When the MN is heavily loaded, from the MN's point of view, the MN needs the SN to offload data to balance the load, which may result in the MN being heavily loaded if the SN directly initiates SN release, affecting the data rate. Thus, while the UE may have a need for power saving in order to expect SN to be released, it is necessary to consider the data load in the network from the network perspective, which may result in a more severe data rate reduction if SN is still released when the network data volume is large.

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

For clarity and conciseness in the description of the embodiments below, a brief introduction to some technical terms is first given:

1) A UE is a user equipment, also called a terminal, a terminal device, which is a device that provides voice and/or data connectivity to a user, and common terminal devices include, for example: vehicle-mounted devices, cell phones, tablet computers, notebook computers, palm top computers, mobile internet devices (mobile INTERNET DEVICE, MID), wearable devices (including, for example, smart watches, smart bracelets, 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 devices, and other devices.

2) A network device, also known as a radio access network (Radio Access Network, RAN) device, is a device that accesses user equipment to a wireless network, including network devices in various communication schemes, including, for example, but not limited to: a base station, an evolved Node B (eNB), a radio network controller (radio network controller, RNC), a Node B (NB), a network device controller (Base Station Controller, BSC), a network device transceiver station (Base Transceiver Station, BTS), a Home network device (e.g., home evolved NodeB, or Home Node B, HNB), a BaseBand Unit (BBU), and the like. Network devices include various types of frequency-based network devices, including, 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 accompanying drawings. In the following embodiments, the primary network device is taken as MN, and the secondary network device is taken as SN, which are not limited to this scenario in the implementation process.

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

MN200 and SN300 further comprise a controller and transceiver. Among other things, the controller may include, but is not limited to, a processing circuit such as a modem, a central processing unit (Central Processing Unit, CPU), an application processor (Application Processor, AP), a microprocessor (Micro-programmed Control Unit, MCU), an artificial intelligence (ARTIFICIAL INTELLIGENCE, AI) processor, or a programmable logic device (Field Programmable GATE ARRAY, FPGA). The modem is configured to modulate information (such as signals and/or data) in a baseband frequency domain to be transmitted into an analog signal that can be transmitted through the transceiver according to a protocol of the 3GPP, and demodulate the analog signal received by the transceiver into information in the baseband frequency domain that can be processed by a 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 implementation, the controller may run an operating system, such as an Android, iOS, windows OS, linux, and hong operating system, among others. In other possible implementations, 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 transmission of signals and to perform an SN release method according to the following.

The transceiver is configured to provide a wireless connection interface (e.g., radio frequency front end module, antenna, etc.) for the MN and SN to communicate with any other suitable device via one or more networks. Those skilled in the art will appreciate that the transceiver may be a network interface that provides wireless communications including data connection services for wireless local area networks (wireless local area networks, WLAN) (e.g., wireless fidelity (WIRELESS FIDELITY, wi-Fi) networks), bluetooth (BT), third generation mobile communication technology (3 rd-generation mobile communication technology, 3G) networks, fourth generation mobile communication technology (the 4th generation mobile communication technology, 4G) networks, fifth generation mobile communication technology (5 th-generation mobile communication technology, 5G) networks, and/or future evolved public land mobile networks (Public Land Mobile Network, PLMNs). Those skilled in the art will appreciate that the MN and SN shown in fig. 3 include one transceiver by way of example only, and the number of transceivers is not particularly limited and may be two or more.

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

In one example, the UE100 initiated SN release may be a UE requested or UE cause triggered SN release, or may be a power saving purpose based SN release, such as where the power of the UE100 is below a threshold, or where the user has turned on a power saving mode of the UE 100. Those skilled in the art will appreciate that UE-initiated SN release is not limited to power saving purposes and may be initiated based on other purposes, as the application is not specifically limited in this regard.

In one example, the SN carries an associated indication in some existing message sent to the MN. That is, the SN may multiplex existing messages, such as a UE context message, a PDU session (Protocol Data Unit session) message, and so forth, to send the indication information. For example, a field of 0 or 1 (of course, multiple bits may be delegated, e.g., 2 bits, three bits, etc.) may be carried in an existing message, where 0 indicates that SN does not support UE 100-initiated SN release and 1 indicates that SN supports UE 100-initiated SN release. For another example, a field of one bit (of course, multiple bits may be used, e.g., 2 bits, 3 bits, etc.) may be carried in an existing message, where the absence of the field indicates that the SN does not support UE 100-initiated SN release, and the presence of the field indicates that the SN supports UE 100-initiated SN release. Those skilled in the art will appreciate that the SN may also indicate to the MN via a new message, as the application is not limited in detail.

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

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

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

In one example, the configuration information sent by the MN to the SN may be configured at the UE, cell, or base station granularity, i.e., the configuration information may vary from UE to UE, cell, or base station to base station. For example, for a certain UE, the MN allows SN release to be initiated, while for another UE, the MN does not allow SN release to be initiated; or the conditions for allowing the SN to initiate SN release indicated by the configuration information sent by the MN to the SN are different for different UEs.

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

Or if the MN sends 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 UE's request. 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; if the value of the preset field is null, the SN is considered not to be allowed to initiate SN release based on the UE's request.

Or whether the SN is allowed to initiate SN release is indicated by whether the MN gives an explicit indication. For example, the MN carries explicit indication information in a certain message sent to the SN, at which point it is indicated that the MN allows the SN to initiate SN release. If no explicit indication information is carried, it means that the MN does not allow the SN to initiate SN release.

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

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

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

In another example, the MN may also allow the SN to initiate SN release if the amount of data between the UE and the SN is below a second threshold for a second predetermined time.

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

In the case of no conflict, the above conditions may also be used in combination.

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

In one example, the MN may also send configuration information to the SN to indicate that the MN allows the SN to initiate SN release, where the MN may send configuration information to the SN to indicate that the SN is allowed to initiate SN release based on a request from the UE, may not indicate that the SN is not allowed to initiate SN release based on a request from the UE, or the MN may indicate that the SN is allowed to release either, and how to indicate specifically is described above and not described herein. In an alternative embodiment, the MN may further send an indication message including the above-described condition for indicating that the MN allows the SN to initiate 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, e.g. implicitly indicating that the MN allows the SN to initiate the SN release by indicating the condition for initiating the SN release, or that some fields of the configuration message carry the indication message. Also, the indication message and the configuration information may be different messages, for example, the existing two different messages respectively carry the field of the configuration information and the field of the indication message, or may be two separate different messages. The present application is not limited to the indication message and the configuration message.

In step 303, UE100 issues an indication message to SN300 that it is desired to release SN, which as described above, UE100 may wish to release SN based on power saving purposes or other purposes. The indication message of the SN release hope may carry a cause value, where the cause value indicates a cause of SN release hope (e.g., energy saving purpose), and the indication message of the SN release hope may not carry the cause value, and default that the request of SN release hope is initiated for energy saving purpose. Or the indication information of desiring to release SN may indicate only that UE desires to release SN, not the cause.

In step 304, after the SN receives the SN release indication message from the UE, it is determined 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 SN release, the SN will not initiate the flow of SN release; if the configuration information and/or the indication message indicate that the MN allows the SN to initiate SN release, the SN may initiate a flow of SN release; if the configuration information and/or the indication information indicate the conditions for initiating the SN release, the SN can judge according to the conditions, and the SN release process can be initiated only if the conditions are met, otherwise, the SN release process is not initiated.

If the SN determines that SN release can be initiated in step 304, an SN release requirement (S-Node Release Required) message is sent to the MN in step 305. The MN receives the release requirement message from the SN, performs SN release in step 306, and transmits an SN release acknowledgement (S-Node Release Confirm) message to the SN in step 307. After the MN sends an SN release acknowledgement message (S-Node Release Confirm) to the SN, the MN performs SN release, and configures SN release for the corresponding UE, and the UE may further clear the corresponding SN-related configuration, so that the UE is no longer under the dual-connectivity network architecture.

Here, the initiation, execution, and acknowledgement procedures of SN release of steps 305-307 are referred to the relevant standards of the above 3GPP as the prior art, and will not be described herein.

In another possible implementation, the configuration information in step 302 may also be sent by MN200 to UE100. Based on the specified or defined conditions of the configuration information, the UE100 may decide whether to initiate SN release, and the specific procedure may refer to fig. 3, which is not described herein.

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 an SN release method for a MN according to one embodiment of the present application. As shown in fig. 4A, the mn receives an indication message from the SN indicating whether the SN300 supports initiation of SN release based on the UE100 in step 401.

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

In one example, the UE100 initiated SN release may be a UE-requested or UE-cause triggered SN release, or may be a SN release based on a power-saving purpose, such as where the power of the UE100 is below a threshold, or where the user has turned on a power-saving mode of the UE 100. Those skilled in the art will appreciate that UE-initiated SN release is not limited to power saving purposes and may be initiated based on other purposes, as the application is not specifically limited in this regard.

In one example, the SN carries an associated indication in some existing message sent to the MN. That is, the SN may multiplex existing messages, such as: context (UE context), PDU session (Protocol Data Unit session) messages, and so on. For example, a field of 0 or 1 (of course, multiple bits may be delegated, e.g., 2 bits, three bits, etc.) may be carried in an existing message, where 0 indicates that SN does not support UE 100-initiated SN release and 1 indicates that SN supports UE 100-initiated SN release. For another example, a field of one bit (of course, multiple bits may be used, e.g., 2 bits, 3 bits, etc.) may be carried in an existing message, where the absence of the field indicates that the SN does not support UE 100-initiated SN release, and the presence of the field indicates that the SN supports UE 100-initiated SN release. Those skilled in the art will appreciate that the SN may also indicate to the MN via a new message, as the application is not limited in detail.

Next, if the SN does not support SN release initiated based on the UE100, the MN does not need to respond to the SN, and the flow ends at step 404. If the SN supports UE100 initiated SN release, the mn will further configure how the SN responds to UE100 initiated SN release in a next step 403 according to one embodiment of the present application.

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

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

In one example, the configuration information may be whether the MN allows the SN to initiate SN release based on the UE's request, e.g., allowed or not allowed. Also, the MN can make an indication of the relative permission or non-permission 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 some existing message, and permission or non-permission may be identified based on the value of the field, for example: disallowed by 0 and allowed by 1. For another example, a field of one bit (of course, multiple bits may be used, e.g., 2 bits, 3 bits, etc.) may be carried in an existing message, where the absence of the field indicates that the SN does not support UE 100-initiated SN release, and the presence of the field indicates that the SN supports UE 100-initiated SN release.

Or if the MN sends 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 UE's request. 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; if the value of the preset field is null, the SN is considered not to be allowed to initiate SN release based on the UE's request. Or whether the SN is allowed to initiate SN release is indicated by whether the MN gives an explicit indication. For example, the MN carries explicit indication information in a certain message sent to the SN, at which point it is indicated that the MN allows the SN to initiate SN release. If no explicit indication information is carried, it means that the MN does not allow the SN to initiate SN release.

As will be appreciated by those skilled in the art, the above-defined condition may also be that the MN allows the SN to initiate SN release if the amount of data between the UE and the SN is below a second threshold for a second predetermined time; or in case the amount of data between the user equipment and the MN is below a third threshold for a third predetermined time, the MN allows the SN to initiate SN release, etc. In the case of no conflict, the above conditions may also be used in combination.

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 that the SN satisfies the condition that the MN allows SN release to be initiated, the MN receives an SN release requirement message from the SN in step 405 (S-Node Release Required). The MN receives the release requirement message from the SN, performs SN release in step 406, and sends an SN release acknowledgement message (S-Node Release Confirm) to the SN in step 407. After the MN sends an SN release acknowledgement message (S-Node Release Confirm) to the SN, the MN performs SN release, and configures SN release for the corresponding UE, and the UE may further clear the corresponding SN-related configuration, so that the UE is no longer under the dual-connectivity network architecture.

Also, the initiation and execution of SN release and the confirmation procedure of SN release of steps 405-407 are referred to as related art by the above-mentioned related standards of 3GPP, and will not be described herein.

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

As described in steps 301 and 401, a field of one bit (or multiple bits), e.g., 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, UE-initiated SN release may be for power saving purposes or other purposes, and will not be described in detail herein.

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

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

The configuration information received by the SN from the MN in step 411 may be a condition indicating whether the MN allows the SN to initiate SN release, may be a condition that the MN allows the SN to initiate SN release, or may further include a condition that the MN allows the SN to initiate SN release in case that the MN allows the SN to initiate SN release. Specific reference may be made to the descriptions of steps 302 and 403 above, and are not repeated here.

Upon receiving the indication message from the UE to release the SN, the SN may determine based on the configuration information and/or the indication message received from the MN, step 412. In step 414, if the SN determines that the specification of the configuration information is not satisfied or the condition defined by the configuration information is not satisfied, the flow ends. If the SN determines that the specification of the configuration information is currently met or the condition that the MN defined by the configuration information allows the SN to initiate SN release is satisfied, step 415 is performed. The indication message of SN release from the UE may carry a cause value, where the cause value indicates a cause of SN release (e.g., for energy saving purposes), and the indication message of SN release may not carry the cause value, and may default that the request for SN release is initiated for energy saving purposes. Or the indication information of desiring to release SN may indicate only that UE desires to release SN, not the cause.

In step 415, the SN sends an SN release request message to the MN (S-Node Release Required), and the MN receives the release request message from the SN and performs SN release. And the SN receives an SN release acknowledgement message from the MN at step 416 (S-Node Release Confirm) indicating that the release of the SN has been completed.

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

Further, after the SN release is completed, the MN may also choose to add SN. The SN added by the MN may be the SN released before, or may be other SNs, which is not specifically limited in the present application. According to the embodiment of the application, the MN can also realize control of SN release based on UE initiation during SN addition, and specific procedures and methods will be described in detail in the following embodiments.

Fig. 5 is a signal flow diagram of an SN release method according to another embodiment of the present application. UE100 is simultaneously connected to MN200 and SN300 and performs data communication. The transceivers in MN200 and 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. Specific reference may be made to the above description of fig. 3, and details are not repeated here.

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 for power saving purposes, such as when the power of the UE100 is below a threshold, or when the user has turned on a power saving mode of the UE 100. Those skilled in the art will appreciate that UE-initiated SN release is not limited to power saving purposes and may be initiated based on other purposes, as the application is not specifically limited in this regard.

Upon receipt of the indication from the UE to release the SN, the SN300 sends an indication of SN release to the MN200 in step 502, which may be used to indicate that the SN requests the MN to initiate SN release or may be a request that the MN allow the SN to initiate SN release, in accordance with another embodiment of the present application.

In one example, SN300 may be forwarding an indication message from UE100 to MN200; the SN300 may either notify the MN200 of the received SN release indication message of the UE100, or the SN300 may generate a new SN release indication message based on the SN release indication message sent by the UE and send it to the MN, and may notify the MN of whether or not it can initiate SN release, and finally determine whether to initiate SN release by the MN200, which is not specifically limited by the embodiment of the present application. Those skilled in the art will appreciate that at step 502 the mn200 knows that an SN release is about to be initiated and will make a decision in a subsequent step 503 whether to initiate an SN release.

In step 503, the mn200 performs a determination as to 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 that the SN requests the MN to initiate SN release, MN200 may decide whether to release SN according to the desire 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 SN release to be initiated. Specifically, MN200 may determine according to its own load condition, where MN allows SN to initiate SN release, for example, if the amount of data that MN shunts to SN is below a first threshold for a first predetermined time. For example, assuming that the amount of data that the MN shunts to the SN is below 20Mb in one minute, it can be considered that the MN is not burdened after releasing the SN, so the MN allows the SN to initiate SN release.

In another example, the condition whether 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 for a second predetermined time.

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

The predetermined time may be one minute, five minutes, or the like, and here, the predetermined time may be a default value set in advance, and may be changed according to actual conditions and needs. Similarly, it will be understood by those skilled in the art that the threshold setting of the data amount may be a preset default value, or may be changed according to the actual situation and needs, which is not particularly limited by the present application.

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

In step 504, the MN200 sends an SN release request ((e.g., S-Node Release Request) message to the SN300 and performs SN release, and then in step 505 receives an SN release acknowledgement (e.g., S-Node Release Request Acknowledge) message from the SN after receiving the SN sent release acknowledgement (S-Node Release Request Acknowledge) message, the MN performs SN release, configuring the SN release to the corresponding UE, and the UE can also clear the corresponding SN-related configuration such that the UE is no longer in dual connectivity network architecture.

Also, the initiation of SN release, acknowledgement of SN release and the procedure performed in steps 504 and 505 are referred to the related standards of the 3GPP as the prior art, and will not be described herein.

In yet another example, if the indication message of the above 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 determination according to its own load condition in step 503. The load condition may be a certain condition or a combination of a plurality of conditions in the above examples, which will not be described herein.

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

Next, upon receiving a message from the MN that allows the SN to initiate SN release, the SN initiates SN release. The SN initiates SN release as described above, and the specific procedure is as follows: the SN sends an SN release need (S-Node Release Required) message to the MN, and the SN receives an SN release acknowledgement (S-Node Release Confirm) message from the MN and stops providing user data to the UE. After the MN sends an SN release acknowledgement message (S-Node Release Confirm) to the SN, the MN performs SN release, and configures SN release for the corresponding UE, and the UE may further clear the corresponding SN-related configuration, so that the UE is no longer under the dual-connectivity 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 an SN release method for a MN according to one embodiment of the present application. As shown in fig. 6A, at step 601, the mn200 receives an indication message of SN release from the SN 300.

Upon receipt of the indication from the UE to release the SN, the SN300 sends an indication message of SN release to the MN200 in step 502 according to another embodiment of the present application, which indicates that the UE100 desires to release the SN, i.e., the SN300 informs the MN200 of the desire of the UE100 to release the SN in step 502, instead of the SN directly sending the SN release requirement message to the MN.

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

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

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

In one example, as in the previous embodiment, the determination performed by MN200 may be whether MN allows SN release to be initiated.

Specifically, MN200 may determine according to its own load condition, and if the amount of data that is shunted to the SN by the MN is below a first threshold for a first predetermined time, the MN may allow SN release to be initiated. For example, assuming that the amount of data that the MN shunts to the SN is below 20Mb in one minute, it can be considered that the MN is not burdened after releasing the SN, so the MN allows the SN to initiate SN release.

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

In another example, the condition whether the MN allows the SN release to be initiated may be that the MN allows the SN release to be initiated if the amount of data between the user equipment and the MN is below a third threshold for a third predetermined time, and so on. The above conditions may also 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 set in advance, or may be changed according to actual situations and needs. Also, as those skilled in the art will understand, the threshold setting of the data amount may be a preset default value, or may be changed according to the actual situation and needs, which is not specifically limited by the present application.

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

In step 604, the mn200 sends an SN release request ((S-Node Release Request) message to the SN300, and then receives an SN release acknowledgement (S-Node Release Request Acknowledge) message from the SN and performs SN release in step 605. Likewise, the initiation, execution, and acknowledgement procedures of SN release in steps 604 and 605 are referred to the related standards of the 3GPP as the prior art, and will not be described herein.

Fig. 6B is a flowchart of an SN release method for an SN according to one embodiment of the application. As shown in fig. 6B, at step 610, the SN300 receives an indication message of SN release from the UE 100.

Next, in step 611, SN300 sends an indication message of SN release to MN 200.

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

If MN200 decides to release SN, as described above in step 602, then SN300 receives a release request (S-Node Release Request) message from MN200 in step 612.

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

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 requirement of the SN and the situation of the MN itself, so that the problems that the load of the MN is heavier and the data rate is influenced due to the release of the SN are avoided.

Fig. 7 is a signal flow diagram of an SN release method according to yet another embodiment of the present application. UE100 is simultaneously connected to MN200 and SN300 and performs data communication. The transceivers in MN200 and 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. Specific reference may be made to the above description of fig. 3, and details are not repeated here.

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

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

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

In one example, MN200 sends an SN addition request (S-Node Addition Request) message to SN300 to effect SN addition. SN addition may be performed immediately after SN300 release is completed, may be performed after a predetermined time, such as 1 minute, has elapsed after SN300 release is completed, may be initiated according to the load situation of MN200, and the like.

Those skilled in the art will appreciate 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 by the present application.

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

As in the embodiments described above, this indication may be implemented as a field carrying one bit of 0 or 1 in the SN addition message, with 0 indicating disallowed and1 indicating allowed. Or whether the MN gives an explicit indication to indicate whether the SN is allowed to initiate SN release, the MN carrying the explicit indication information in a message sent to the SN to indicate permission, if not carrying the explicit indication information to indicate non-permission.

The condition to allow SN to initiate SN release may be a time-based condition. For example, the SN is indicated not to be allowed to be released for a predetermined time, which here may be one minute, five minutes, or the like. 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 preset in the standard, which is not particularly limited by the present application. Further, the time condition that allows the SN to initiate SN release may also be directly specified by the MN through configuration information. For example, MN200 may add explicit time indication information in the SN addition request message sent to SN 300. The SN300 starts timing upon receiving the indication information, for example, five minutes, ten minutes, and so on. During the five minutes or ten minutes of this timing, the SN300 is not allowed to initiate SN release. Those skilled in the art will appreciate that whether the default time of SN or the duration of the time specified by MN is variable according to the actual situation and needs, and the present application is not limited in detail.

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 instruction information and the addition request information may be different messages (or information). In a specific implementation, the addition request information may further indicate by default that SN is not allowed to be released for a predetermined time, for example: the SN, after receiving the addition request information, finds that the MN released the SN within a preset time period of the addition request information, and the SN does not release the SN any more within a default predetermined time period. 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 by the embodiment of the present invention.

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

In one example, the indication information is not added, which may be an indication message indicating that the SN cannot initiate the SN release request message, an indication message indicating that the SN is released cannot be sent, the MN cannot send the SN release request message, or after the MN or the SN party sends the SN release, the other party does not respond, or the like.

In the above example, the 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. It will be understood by those skilled in the art that the indication information is for indication purposes, and the form or carrier of the indication information is not particularly limited in the present application.

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

For example, if the SN is indicated by the SN addition process of the MN200 in step 703 that the SN is not allowed to initiate SN release within five minutes, the SN300 makes a determination based on time, and if five minutes have elapsed since the SN was added to the SN release request from the UE, the SN300 decides that SN release can be initiated.

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

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

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 an SN release method for a MN according to one embodiment of the present application. As shown in fig. 8A, the mn200 receives the SN release requirement message from the SN300 in step 801, performs SN release in step 802, and transmits an acknowledgement message of SN release to the SN in step 803 (S-Node Release Confirm). The specific process of initiating and executing SN release in steps 801, 802 and 803 may be an existing standard execution mechanism as shown in fig. 1, or may be a SN release flow as shown in the embodiment of fig. 3 or fig. 5, which is not described herein.

In step 804, the MN sends a request message to the SN for SN addition (S-Node Addition Request). According to the embodiment of the application, the MN can realize control of SN release based on UE initiation in the SN adding process.

In one example, MN200 sends an SN addition request message (S-Node Addition Request) to SN300 to effect SN addition. SN addition may be performed immediately after SN300 release is completed, may be performed after a predetermined time, such as 1 minute, has elapsed after SN300 release is completed, may be initiated according to the load situation of MN200, and the like.

As in 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 disallowed and 1 indicating allowed. Or whether the MN gives an explicit indication to indicate whether the SN is allowed to initiate SN release, the MN carrying the explicit indication information in a message sent to the SN to indicate permission, if not carrying the explicit indication information to indicate non-permission.

The condition to allow SN to initiate SN release may be a time-based condition. For example, the SN is indicated not to be allowed to be released for a predetermined time, which here may be one minute, five minutes, or the like. 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 preset in the standard, which is not particularly limited by the present application.

Further, the time condition that allows the SN to initiate SN release may also be directly specified by the MN through configuration information. For example, MN200 may add explicit time indication information in the SN addition request message sent to SN 300. The SN300 starts timing upon receiving the indication information, for example, five minutes, ten minutes, and so on. During the five minutes or ten minutes of this timing, the SN300 is not allowed to initiate SN release. Those skilled in the art will appreciate that whether the default time of SN or the duration of the time specified by MN is variable according to the actual situation and needs, and the present application is not limited in detail.

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 SN release, in which case SN300 may not initiate SN release for a certain period of time. The duration may be one minute, five minutes, or the like from the time when the SN addition request message is received by the SN, or from the time when the last SN release is completed. Those skilled in the art will appreciate that the certain duration may be a default configuration of the SN300, or may be implemented through a network according to actual situations and needs, and the duration may also be variable according to actual situations and needs, which is not specifically limited by the present application.

In one example, the indication information is not added, and the indication information can also be an indication that the SN cannot initiate the SN release requirement message, cannot send an indication message indicating to release the SN, cannot send an SN release request message, or is an indication that after the MN or the SN party sends the SN release, the other party does not respond, and the like.

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

It is 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 SN indication information limiting the initiation of the SN release condition. After the SN is released for the first time, the MN may send, to the SN, indication information limiting the SN release initiation condition when the MN adds the SN for the second time, or if the duration from the last release is less than a specific duration when the MN adds the SN, the MN may send indication information limiting the SN release initiation condition when the SN initiates the SN, where the indication information is various indications or conditions as described in step 703 of the above embodiment. Also, the indication information may be carried in the SN addition request information or transmitted in the form of separate information, which is not described herein.

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

At step 813, SN300 receives the SN addition request message from MN200 (S-Node Addition Request). According to the embodiment of the application, the MN can realize control of SN release based on UE initiation in the SN adding process.

It is 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 SN indication information limiting the initiation of the SN release condition. After the first SN release, the MN may send indication information limiting the initiation of the SN release condition to the SN when the MN adds the SN a second time, where the indication information is various indications or conditions as described in step 703 of the above embodiment. Also, the indication information may be carried in the SN addition request information or transmitted in the form of separate information, which is not described herein.

Next, in step 814, SN300 in turn receives a SN release request from UE 100. In step 815, the SN300 determines whether the current requirements for initiating SN release are met based on an indication of an SN addition request message from the MN.

As described above, the case where the SN release is initiated may be that the MN allows the SN release to be initiated, or that the MN allows the SN release to be initiated, which may be the above-described time condition, or the condition of the amount of data transferred, or the like.

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

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

The method embodiments of the application can be realized in the modes of software, magnetic elements, firmware and the like.

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 the 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. Program code may 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 either 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, cause the machine to fabricate logic to perform the techniques described herein. These representations, referred to as "IP cores," may be stored on a tangible computer readable storage medium and provided to a plurality of customers or production facilities for loading into the manufacturing machine that actually manufactures the logic or processor.

While the description of the application will be presented in connection with a preferred embodiment, it is not intended that the application be limited to this embodiment. Rather, the purpose of the application described in connection with the embodiments is to cover other alternatives or modifications, which may be extended by the claims based on the application. The following description contains many specific details for the purpose of providing a thorough understanding of the present application. The application may be practiced without these specific details. Furthermore, some specific details are omitted from the description in order to avoid obscuring the application. It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other.

Moreover, 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 execute 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 structural or methodological features are shown in a particular arrangement and/or order. However, it should be understood that such a particular arrangement and/or ordering may not be required. In some embodiments, these features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of structural or methodological features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments, may not be included or may be combined with other features.

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

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. Program code may also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described in the present application are not limited in scope by any particular programming language. In either 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, cause the machine to fabricate logic to perform the techniques described herein. These representations, referred to as "IP cores," may be stored on a tangible computer readable storage medium and provided to a plurality of customers or production facilities for loading into the manufacturing machine that actually manufactures the logic or processor.

Such computer-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles manufactured or formed by a machine or device, including 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 cards or optical cards; or any other type of medium suitable for storing electronic instructions.

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

Claims

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

Transmitting configuration information to the auxiliary network device, wherein the configuration information is used for indicating the main network device to allow the auxiliary network device to initiate an auxiliary network device release requirement message, and the auxiliary network device release requirement message is used for requesting the main network device to execute the auxiliary network device release;

and receiving a release requirement message of the auxiliary network equipment from the auxiliary network equipment.

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

Transmitting configuration information to the auxiliary network device, wherein the configuration information is used for indicating a condition that the main network device allows the auxiliary network device to initiate an auxiliary network device release requirement message, and the auxiliary network device release requirement message is used for requesting the main network device to execute the auxiliary network device release;

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

4. The method of claim 2, wherein the condition indicating that the primary network device allows the secondary network device to initiate secondary network device release requirements comprises at least one of:

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

The main network equipment receives an indication message from the auxiliary network equipment, wherein the indication message is used for indicating the auxiliary network equipment to support an auxiliary network equipment release request from the user equipment; or the indication message is used for indicating the auxiliary network equipment to support the auxiliary network equipment release request based on the 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 of the user device is received by the secondary network device; or after the auxiliary network equipment receives the auxiliary network equipment release request based on the energy saving purpose of the user equipment, the indication message is sent to the main network equipment.

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

Configuration information is received from the primary network device,

The configuration information comprises information indicating 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 execute the secondary network device release; and

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

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

Configuration information is received 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

And receiving a release request of the auxiliary network equipment, and sending the release requirement information 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 requirement information of the auxiliary network equipment is met.

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

10. The method of claim 8, wherein the condition indicating that the primary network device allows the secondary network device to initiate secondary network device release requirements comprises at least one of:

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

Sending an indication message to the main network device, wherein the indication message is used for indicating the auxiliary network device to support an auxiliary network device release request from the user device; or the indication message is used for indicating the auxiliary network equipment to support the auxiliary network equipment release request based on the 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 the user device; or receiving a secondary network device release request from the user device for energy saving purposes.

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

Transmitting configuration information to the auxiliary network device, where the configuration information is used to instruct the main network device to allow the auxiliary network device to initiate a first auxiliary network device release requirement message, or the configuration information is used to instruct the main network device to allow the auxiliary network device to initiate a condition of the first auxiliary network device release requirement message; the first auxiliary network device release requirement message is used for requesting the main network device to execute the auxiliary network device release;

Receiving a first secondary network device release requirement message for 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,

Transmitting a request message for adding the auxiliary network equipment and an indication message 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 preset time; or alternatively

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.

14. The method of claim 13, wherein the indication information carries information of the preset time; and/or the preset time is configured at the auxiliary network equipment.

15. The method of claim 13 or 14, further comprising 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.

16. A secondary network device release method for use with a secondary network device, the method comprising

Configuration information is received from the primary network device,

The configuration information comprises a condition indicating that the primary network device allows the secondary network device to initiate a first secondary network device release requirement message, or the configuration information comprises a condition indicating that the primary network device allows the secondary network device to initiate a first secondary network device release requirement message; wherein the first secondary network device release requirement message is used to request the primary network device to perform the secondary network device release; and

Receiving a secondary network device release request, sending a first secondary network device release requirement message to a primary network device for requesting the primary network device to perform the secondary network device release,

Receiving an acknowledgement message released by the secondary network device from the primary network device, and

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

And receiving a request message from the main network equipment for adding 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 a preset time.

17. The method of claim 16, wherein the indication information carries information of the preset time; and/or the preset time is configured at the auxiliary network equipment.

18. The method of claim 16 or 17, further comprising, after the preset time has elapsed, sending a second secondary network device release requirement message to the primary network device requesting the primary network device to perform the secondary network device release.

19. A computer readable storage medium having stored thereon instructions which, when run on the computer, cause the computer to perform the method of any of claims 1 to 18.

20. An apparatus, comprising:

A processor;

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