CN1933664A - Method for supporting user equipment transferability in LTE system - Google Patents

Abstract

A method for supporting UE mobility in an LTE system, wherein the UE moves between two ENBs, comprising the steps of: the source ENB decides that the UE will switch to another target ENB's cell according to the "measurement report" received from the UE, And send a "resource request" message to the target ENB; the target ENB sends a "resource response" message to the source ENB, and sends the allocated resources to the source ENB; the target ENB sends a "UP registration" message to register with the EGGSN; the source ENB sends a "handover command" to the UE; the target ENB receives the "handover complete" message from the UE. The invention ensures that the data is not lost when the UE moves between two ENBs, and solves the problem of data forwarding between the two ENBs. The invention is simple, reliable and efficient.

Description

Method for supporting user equipment mobility in LTE system

technical field

The present invention relates to a method for supporting user equipment mobility in a mobile communication system long-term evolution (hereinafter referred to as LTE) system proposed by the Third Generation Partnership Project (hereinafter referred to as 3GPP).

Background technique

The structure of the existing Third Generation Partnership Project (hereinafter referred to as 3GPP) is shown in FIG. 1 . The following is a description of the 3GPP system structure in Figure 1.

101 User equipment (hereinafter referred to as UE) is a terminal device for receiving data. 102 NodeB is the node in the wireless network subsystem (referred to as RNS) responsible for wireless reception/transmission. 103 Controlling Radio Network Controller (hereinafter referred to as CRNC) is a radio network controller that directly controls the NodeB. The interface between RNC and UE is called air interface. 104 Serving Radio Network Controller (hereinafter referred to as SRNC) is a radio network controller (hereinafter referred to as RNC) that controls bearer information, such as radio resource control (hereinafter referred to as RRC) status. 105 Gateway General Packet Radio Service (hereinafter referred to as GPRS) Support Node (hereinafter referred to as Gateway GPRS Support Node as GGSN) and 106 Serving GPRS Support Node (hereinafter referred to as SGSN) provide routing for data transmission. The interface between SGSN and RNC is the Iu interface. 107 E-PDN is an external public data network that provides data sources.

After the existing GGSN receives the user data, it sends the data to the SGSN through the GTP-U through the user plane previously established for the corresponding service of the user. Similarly, after the SGSN receives the data, it sends the data to the RNC through the GTP-U. The processing of user data at RNC and Node B is introduced in detail in conjunction with Figure 2.

Fig. 2 is the existing wireless interface protocol structure. Existing air interfaces are divided into three layers: 205 physical layer (L1), data link layer (L2) and network layer (L3). L2 is divided into sublayers: 204 Media Access Control (hereinafter referred to as MAC), 203 Radio Link Control (hereinafter referred to as RLC), 201 Packet Data Convergence Sublayer (hereinafter referred to as PDCP) and 202 Broadcast Multicast Control (hereinafter referred to as BMC) . 202BMC is only useful when dealing with broadcast services, and will not be described in detail here. The elliptical circle in the figure is a service access point (hereinafter referred to as SAP), which is used for end-to-end communication between sub-layers. 204 The SAP between the MAC and the physical layer is a transport channel. The SAP between RLC and MAC is a logical channel. PDCP and BMC are connected through PDCP and BMC SAP respectively. The service provided by L2 is called a radio bearer (hereinafter referred to as RB). 206 Radio Resource Control (hereinafter referred to as RRC) can configure PDCP, BMC, RLC, MAC and physical layer, and is a function of the control plane. PDCP and BMC are user plane functions only. The functions of RLC in the control plane and the user plane are the same.

After the user data in the packet domain from the SGSN arrives at the RNC, at first the 201 PDCP performs header compression on the data (upstream decompression). Another function of the PDCP is to ensure the relocation of the Serving Radio Network Controller (hereinafter referred to as SRNC) without data loss. It is then processed by the 203 RLC entity. The functions of RLC are framing (segmentation and combination), automatic repeat request (hereinafter referred to as ARQ) and encryption. 204 MAC layer is divided into different network entities, which will not be described in detail here. The functions of the MAC layer are hybrid ARQ (hereinafter referred to as HARQ), random access control, transmission format combination selection, UE identification, and mapping of logical channels and transport channels. The function of the 205 physical layer is to send and receive radio frames, power control, and the like. The functions of the physical layer are realized in Node B. Data is transmitted between the RNC and the Node B through the Frame Protocol (hereinafter referred to as FP) of the transmission channel.

In the existing system, when the UE moves between NodeBs or between RNCs (without relocation), soft handover can ensure that data will not be lost. Because of the strict synchronization relationship, the network side and the UE side only deactivate the old link when activating the new link, so as to ensure seamless mobility.

Fig. 3 is the existing SRNS relocation process. Below is a detailed description of each step in the process.

301 The source RNC decides to execute the SRNS relocation process. 302 The source RNC sends a "relocation request" to the original SGSN. The message contains information elements such as source identification and destination identification. After the original SGSN receives this message, it is relocation within the same SGSN or relocation between SGSNs from the perspective of the destination identifier. If it is relocation between SGSNs, the original SGSN initiates the relocation resource allocation process. 303 The original SGSN sends a "Forward Relocation Request" to the new SGSN. Forwarding Relocation Requests is only used for relocation between SGSNs. 304 The new SGSN sends a "relocation request" to the target RNC, and establishes a radio access bearer (hereinafter referred to as RAB) between the target RNC and the new SGSN. When the resources required by the RAB, including the resources of the user plane, are successfully allocated, the target RNC sends a "relocation request confirmation" message to the new SGSN. Each established RAB includes an information transport layer address (the destination RNC address of user data) and an Iu transmission relationship (the downlink channel end identifier for user data (hereinafter referred to as TEID)). 305 When the destination RNC and the new SGSN have allocated data transmission resources and the new SGSN is ready for SRNS relocation, the new SGSN sends a "Forward Relocation Response" to the original SGSN. This message indicates that the destination RNC is ready to receive forwarded downlink PDUs from the source SRNC. The relocation resource allocation process completed successfully. Forwarded Relocation Responses are only used during relocation between SGSNs. After the original SGSN receives this message, 306 sends a "relocation command" message to the source RNC. The message includes the RAB that needs to be released and the RAB that needs to forward data. The SGSN decides whether to forward data based on Qos. The RAB information that needs to forward data should include the RAB identifier, transport layer address and Iu transport relationship. The transport layer address and Iu transport relationship are the same as those sent by the destination RNC to the new SGSN through the "Relocation Request Acknowledgment" message. These parameters are used for the forwarding of the downlink network protocol data unit (hereinafter referred to as N-PDU) from the source SRNC to the destination RNC through the Iu interface. Forwarding is only used for downlink user data. At this time, the SRNC is ready to forward the downlink user data. 307 Based on the RAB that needs to forward the data determined by Qos, the source RNC starts to copy the data and sends it to the target RNC through the Iu interface. For each radio bearer using no loss PDCP (lossPDCP), GTP-PDUs (corresponding PDCP-PDUs have been sent but not yet acknowledged) are copied and sent to the target RNC through the network protocol layer (hereinafter referred to as IP layer). The source RNC continues to send downlink duplicate data and receive uplink data. Before the role of the serving RNC is replaced by the destination RNC, when the downlink user plane data starts to arrive at the destination RNC, the destination RNC can buffer or discard the arriving downlink GTP-PDUs according to the Qos attribute.

The steps, starting with step 7, do not necessarily reflect the order of events. For example, the source RNC may simultaneously 307 start forwarding data and 308 send a “Relocation Commit” message, unless 307 triggers 308 . The target RNC may send "relocation detection" and "UE mobile information" at the same time, so 310 the destination RNC may receive "UE mobile information confirmation", 307 data forwarding is still in progress 308 source RNC sends "relocation submission" to the target RNC , the process is used to transfer the SRNS context to the target RNC, and the role of the SRNS is transferred from the source RNC to the target RNC. The SRNS context information about the RAB is sent, including the next GTP-PDU sequence number to be sent uplink and downlink, and the next PDCP sequence number used to send and receive data to the UE. For PDP contexts that do not require sequential delivery, the next GTP-PDUs to be sent are not used at the destination RNC. The PDCP sequence number is sent by the source RNC only for radio bearers that do not lose PDCP.

309 When the target RNC receives a trigger message for relocation execution, the target RNC sends a "relocation detection" message to the new SGSN. Afterwards, the target RNC starts to play the role of serving radio network controller (hereinafter referred to as SRNC). 310 The UE and the target RNC exchange mobile-related information, such as the identity of the new SRNC, the identity of the location area and uplink user data, etc. are exchanged between the UE and the target RNC.

311 After receiving the "UTRAN mobile information confirmation" message, the target SRNC initiates a relocation completion process, and the target RNC sends a "relocation complete" message to the new SGSN. The relocation completion procedure is used to notify the CN SRNS of the completion of the relocation procedure. If the relocation process is a process between different SGSNs, 312 the new SGSN sends a "Forwarding Relocation Complete" message to notify the original SGSNSRNS of the completion of the relocation process. The original SGSN sends a response message "forward relocation completion confirmation" message to the new SGSN. After receiving the relocation complete message, the SGSN switches the user plane from the source SRNC to the destination RNC. 311 If SRNS relocation is SRNS relocation between different SGSNs, after the new SGSN receives the "Relocation Complete" message, the new SGSN sends the "Update PDP Context Request" message to the corresponding GGSN, and the GGSN updates the packet data protocol (hereinafter referred to as PDP) context and return the "update PDP context response" message.

When the SGSN receives the relocation complete message or the relocation process between different SGSNs receives the forwarded relocation complete message, 313 the old SGSN sends an Iu release command message to the source SRNC. Release the Iu connection and user resources between the source RNC and the source SGSN.

314 If the new routing area indication (hereinafter referred to as RAI) is different from the original one, the UE initiates a routing location update procedure.

C1, C2, and C3 implement the Personalized Application Process for Enhanced Mobile Networks (CAMEL for short), and the detailed technical content is omitted here.

Here, the SRNS relocation process not involved in the UE is used as an example to describe the data forwarding in the relocation process. For the combined hard handover and SRNS relocation process, there are some differences in the air interface. The forwarding of the SRNS context is performed through the Iu interface. , rather than through the Iur interface. But data forwarding is the same.

The existing 3GPP system structure has many shortcomings such as poor upgradeability, long call setup time, complex system structure, etc. Therefore, the 3GPP standardization organization is working on the standardization of LTE. To meet the requirements of LTE, various companies have proposed desired LTE system structures, and one of the proposed LTE system structures is shown in FIG. 4 . For example, the function of the original RNC and the NodeB are combined into a network entity (herein referred to as ENB 402), and the functions of SGSN and GGSN are combined to form a network entity (herein referred to as EGGSN 403). Among them, the Packet Data Compression Protocol (hereinafter referred to as PDCP) is the function of the original RNC, and it can also be placed in the EGGSN in LTE. In this way, the system is simplified by reducing the number of network nodes, and the delay of the system is reduced. 401 UE and 404 E-PDN are the same as 101 and 107 in Fig. 1 respectively.

In the LTE system, many companies propose to simplify the functions of RLC and MAC. For example, both RLC and MAC have the function of splitting and concatenating, and only one copy is kept. All the functions proposed by RLC and MAC can be combined in one layer, and there is no RLC layer. .

In the newly proposed LTE system structure, PDCP is located in EGGSN, and RLC (or MAC, here refers to the user plane layer 2 protocol for segmenting and concatenating data) is located in ENB. When the UE moves between two ENBs, some RLC SDUs have been divided into PDUs. How to transmit these data (PDUs, SDUs) between two ENBs is an unsolved problem in existing protocols.

In the present invention, for the convenience of description, we still use the concept of RLC, which refers to the layer-2 protocol located in ENB, which first needs to divide and combine data, which can be RLC or a part of MAC. If RLC and MAC are combined in the future, it refers to the functions of the MAC layer, such as MAC PDU and MAC SDU. This will not affect the main content of the present invention.

Contents of the invention

The purpose of the present invention is to provide a method for transmitting RLC PDU and RLC SDU between two ENBs, which improves the transmission efficiency and saves system resources under the condition that data is not lost.

To achieve the above purpose, a method for supporting UE mobility in an LTE system, wherein the UE moves between two ENBs, comprising steps:

The source ENB decides that the UE will switch to another cell of the target ENB according to the "measurement report" received from the UE, and sends a "resource request" message to the target ENB;

The destination ENB sends a "Resource Response" message to the source ENB, and sends the allocated resources to the source ENB;

The destination ENB sends an "UP registration" message to register with the EGGSN;

The source ENB sends a "handover command" to the UE.

The invention ensures that data is not lost when UE moves between two ENBs, and solves the problem of data forwarding between two ENBs. The invention is simple, reliable and efficient.

Description of drawings

Fig. 1 is the existing 3GPP system structure;

Fig. 2 is an existing wireless interface protocol structure;

Fig. 3 is the existing SRNS relocation process;

Fig. 4 is a kind of proposed LTE system structure;

Figure 5 is the process of UE moving between two ENBs in connected mode (method 1)

FIG. 6 is a UE in connection mode, moving between two ENBs (method 1), and the action flow of the source ENB;

FIG. 7 is the action flow of the target ENB when the UE is in the connected mode and moves between two ENBs (method 1);

Figure 8 is the action flow of the EGGSN when the UE is in the connected mode and moves between two ENBs (method 1);

FIG. 9 is the action flow of the UE in the connected mode and moving between two ENBs (method 1);

FIG. 10 is a process in which UE is in connected mode and moves between two ENBs (method 2);

Figure 11 is the UE in the connected mode, moving between two ENBs (method 2), and the action flow of the target ENB;

Figure 12 is a UE in connected mode, moving between two ENBs (method 2), the action flow of the source ENB;

Figure 13 is the action flow of the EGGSN when the UE is in the connected mode and moves between two ENBs (method 2);

Figure 14 is the action flow of the UE in the connected mode and moving between two ENBs (method 2);

Figure 15 is the UE in the connected mode, the process of moving between two ENBs (method 3);

FIG. 16 is a UE in connected mode, moving between two ENBs (method 2), and the action flow of the destination ENB.

Detailed ways

In the present invention, taking the LTE system structure of Fig. 4 as an example to describe the method for UE to move between two ENBs, the interface between the ENB and the UE is called the air interface (hereinafter referred to as Uu), that is, the interface between the original RNC and the UE . The interface between the ENB and the EGGSN is the Iu+ interface (the original interface between the RNC and the SGSN is the Iu interface). The interface between ENBs is the Iur interface. The focus of the present invention lies in the forwarding method of Iur interface data, if the system structure of LTE changes in the future, for example, EGGSN is divided into two network entities of control plane and user plane, this invention is also applicable.

FIG. 5 shows method 1 of UE moving from one ENB to another ENB in connected mode. The feature of this method is that there is a process of preparing radio resources in advance before the UE actually switches to a new cell.

Based on the measurement configured by the source ENB, 501 UE sends a "measurement report" message to the source ENB, and reports the measurement results, such as the information of neighboring cells, to the source ENB. According to the measurement result reported by the UE, if the source ENB decides to move the UE to the cell of another ENB (target ENB), 502 the source ENB sends a "resource request" message to the target ENB. The message contains the identity of the target cell, the identity of the UE, the Qos information of the service that the UE needs to access, the IP address of the EGGSN to which the UE is currently connected, and the tunnel end identifier (hereinafter referred to as TEID) assigned by the EGGSN (used for communication between the source ENB and the EGGSN). Uplink TEID), integrity protection algorithm and password, encryption protection algorithm and password. The source RNC may also inform the destination RNC of the radio resources allocated by the source RNC to the UE through a resource request, instead of directly telling the destination RNC the Qos of the service used by the UE. The destination ENB receives the resource request message, and the ENB configures resources according to the parameters in the request message (such as Qos or wireless resource configuration parameters). If the requested resource can be allocated, the ENB creates the context of the UE and saves the relevant information of the UE as follows: Cell ID, UE ID, EGGSN IP address, user plane ID (such as TEID) assigned by EGGSN, integrity protection algorithm and password, encryption algorithm and password. The destination ENB allocates a user plane identifier (such as TEID) for user Iur data forwarding. 503 The ENB sends a "Resource Response" message to the source ENB, and sends the resources allocated by the target ENB to the source ENB, and the wireless resources allocated by the target ENB can be sent to the source ENB through the RRC container. At the same time, the "Resource Response" message includes the user plane identifier (eg TEID) assigned by the target ENB for data forwarding. If the target ENB cannot allocate corresponding resources, the target ENB sends a failure response message to the source ENB. The failure response message contains the information element reason, and the source ENB is notified of the failure reason such as no wireless resources through the cause value. The destination ENB can now receive uplink data. If the target ENB allocates resources successfully, 504 the target ENB sends an "UP registration" message to register with the EGGSN. The message includes the downlink user plane identifier allocated by the new ENB, such as TEID, UE identifier, and the new ENB IP address. At this time, the EGGSN can start sending data to the target ENB. This message may also be sent to the EGGSN after receiving 508 the "handover complete" message from the UE.

The source ENB receives the successful resource response message, and saves the user plane identifier such as TEID. 505 The source ENB sends a "handover command" to the UE, and notifies the UE of the new radio resources allocated by the target ENB through this message. The source ENB can also determine an activation time and send it to the UE through a "handover command", so that the network and the UE switch to a new cell at the activation time. 506a The source ENB starts to send the RLC SDU to the destination ENB through the established Iur user plane. The RLC SDU here refers to the RLC SDU without segmentation, or the RLC SDU without segmentation, and the RLC SDU that has been segmented but all segments have not been confirmed or sent. 507 The source ENB sends an "RLC context transfer" message to the destination ENB, through which each RLC PDU that has not been acknowledged (NACK) and the corresponding serial number are sent to the destination ENB. If the above-mentioned forwarded RLC SDUs include those RLC SDUs that have been segmented but all segments have not been confirmed or sent, then the unacknowledged RLC PDUs do not include those PDUs that have not been confirmed for a corresponding SDU. The "RLC context transfer" message may also include the next RLC PDU sequence number (the next SN to be used when RLC SDU is framed). The RLC context may also include the segmented data length (hereinafter referred to as LI) in the forwarded first RLC SDU. This information element is optional. If the first RLC SDU is complete and has no fragments, then LI is not present. The RLC context transfer message also includes the starting GTP sequence number and the ending GTP sequence number of the forwarded GTP PDU. Through these two information elements, the destination ENB can discard a copy of the data received from the source ENB and EGGSN at the same time. The RLC context information also includes other automatic repeat request (ARQ for short) context information. There is no absolute sequence for 505, 506a and 507, for example, the source ENB may start data forwarding first, and at the same time send a "handover command" to the UE. If the source ENB notifies the UE of the activation time, the source ENB sends an RLC context transfer message to the target ENB when the activation time is coming, and notifies the target ENB of each unacknowledged RLC PDU and the corresponding serial number, and the source ENB can also pass "RLC The context transfer" message sends the sequence number for the next RLC PDU (the next SN to be used when the RLC SDU is framed) to the destination ENB. The destination ENB buffers received RLC SDUs. The destination ENB saves the received RLC context information and buffers the received RLC PDUs. The destination ENB may cache RLC SDUs in the transmit buffer and save RLC PDUs in the retransmit buffer. The subsequent processing of data by the target ENB is the same as the prior art and is not the focus of the present invention, and the detailed technical description is omitted here.

Correspondingly, the source ENB has no way to determine the activation time. Another way for the source ENB to send RLC PDUs to the destination ENB is to send it through a 502 resource request message, so that the "resource request" message also includes each unacknowledged (NACK) The PDU and the corresponding serial number can also include the serial number for the next RLC PDU (the next SN to be used when the RLC SDU is framed) and can also include LI. This information element is optional. If the first RLC SDU is complete and has no fragments, LI does not exist. It also contains other ARQ context information. Step 507 would not be required.

After receiving the 505 handover command, the UE moves to a new cell. If the activation time is also included in the handover command, the UE switches to a new cell at the activation time. Then 508 the UE sends a "handover complete" message to the target ENB. If the source ENB decides the activation time, when the activation time arrives, the source ENB releases the radio resources, and initiates the process of releasing the resources with the EGGSN, as shown in step 509 in FIG. If the source ENB does not decide the activation time, after receiving the 508 handover completion message, the target ENB sends a message to the source ENB to request the release of resources, the source ENB releases the radio resources, and initiates the process of releasing resources between EGGSN and EGGSN. The process of releasing EGGSN resources may also be initiated by the target ENB.

In the above description of FIG. 5, the forwarding method of user data in Iur is that RLC PDUs are sent to the destination ENB through the "RLC context transfer" message or "resource request" message of the control plane. RLC SDUs are sent over a user plane such as GTP-U. This is the first method of data forwarding in the present invention, that is, RLC PDUs (the RLC PDUs that have not been confirmed or the RLC PDUs that have not been confirmed in the RLC PDUs that have not been confirmed) are forwarded through the control plane, RLC SDUs (referring to RLC SDUs without fragmentation, or RLC SDUs without fragmentation and RLC SDUs that have been fragmented but all fragments have not been acknowledged) are forwarded through the user plane.

The second method of data forwarding is that both RLC SDUs and RLC PDUs are sent through the control plane. The concept of RLC SDUs and RLC PDUs here is the same as the first method. Corresponding to this method, the signaling flow of UE moving between two ENBs will be described with reference to FIG. 5 . Here we focus on the differences from the first method, that is, the above description. RLC PDUs are sent to the destination ENB through the 507 "RLC Context Transfer" message or 502 "Resource Request" message of the control plane. RLC SDUs are sent through the "SDU data forwarding" message in step 506b, and the message includes the SDU container. The corresponding RLC PDUs are forwarded through the 507 RLC context transfer message. "SDU data forwarding" and "RLC context transfer" can be separate messages or one message. If it is a separate message, there is no absolute sequence of 505 and 506b. If it is a message such as "SDU data forwarding", the message includes the SDU container, each unacknowledged PDU and the corresponding serial number, and can also include the serial number of the next RLC PDU (when the RLC SDU is framed, the next SN to use), and optionally LI. This information element is optional. If the first RLC SDU is complete and has no fragments, then LI is not present. It also contains other ARQ context information. 507 step does not exist. 502 and 503 in Figure 5 are only used for the process of requesting the destination ENB to allocate resources (or also include PDUs and SN information), and do not need to establish the user plane of the Iur interface, so the destination ENB does not need to allocate the user plane identifier of the user data forwarding of the Iur interface Such as TEID.

The third method of data forwarding is that both RLC SDUs and RLC PDUs are sent through the user plane, where the concept of RLC SDUs and RLC PDUs is the same as the first method. Corresponding to this method, the signaling flow of UE moving between two ENBs will be described with reference to FIG. 5 . Here we focus on the differences from the first method. RLC PDUs and RLC SDUs pass through the user plane established in steps 502 and 503, and forward RLC SDUs and RLC PDUs to the destination ENB in step 506c. In the packet header of the data, an indicator (indicator bit) is set to indicate whether it is an RLC PDU or an RLC SDU. RLC context information such as the SN used for the next RLC PDU and the SN corresponding to each unacknowledged RLC PDU, (SN and PDU have the same order, so it is a one-to-one relationship), LI (this information element can be Optionally, if the first RLC SDU is complete and there is no segment, then LI does not exist) and other ARQ context information can be sent to the destination ENB through 502 "Resource Request", or through 507 "RLC Context Transfer ” message is sent to the destination ENB. Another way to transmit the SN (the SN corresponding to each unacknowledged RLC PDU) to the destination ENB is to define the SN field in the data packet. One SN and one corresponding RLC PDU are sequentially included in the data packet, and one SN and one corresponding RLC PDU. This field is optional. This field is absent if used to transport SDUs. The SN used for the next RLC PDU can also be transmitted through the user plane, so that if the user plane transmits an RLC SDU, there is an SN field in the data packet.

The fourth method of data forwarding is to forward only the RLC SDUs corresponding to the unacknowledged RLC PDU and the RLC SDUs without segmentation through the user plane. Corresponding to this method, the signaling flow of the UE moving between two ENBs is combined with Figure 5 to illustrate. Here we focus on the differences from the first method. The RLC SDUs pass through the user plane established in steps 502 and 503, and forward the SDUs to the destination ENB in step 506a. The RLC context information such as the SN of the next RLC PDU can be sent to the target ENB through 502 "resource request", or can be sent to the target ENB through the "RLC context transfer" message of 507.

The fifth method of data forwarding is to forward only the RLC SDUs corresponding to the unacknowledged RLC PDUs and the RLC SDUs without segmentation through the user plane. Corresponding to this method, the signaling flow of the UE moving between two ENBs is shown in Figure 5. illustrate. Here we focus on the difference from the fourth method. The source ENB forwards the RLC SDUs to the destination ENB in step 506a through the user plane established in steps 502 and 503. In step 507, the source ENB sends "RLC context transfer" information to the destination ENB. The RLC context information includes which segments of the corresponding SDUs have been confirmed by the UE, and may also include the SN of the RLC SDU, the SN for the next RLC PDU, and Other ARQ context information. The "RLC context transfer" message may also be a message with the "resource request" message. In this way, after the destination ENB receives the forwarded data, it does not need to resend the RLC PDUs confirmed by the UE to the UE.

In the following description of the action description of the node device, the first data forwarding method (PDUs control plane, SDUs user plane) is also used for description. The difference between other data forwarding methods and the first one will be pointed out in particular. The concepts of RLC PDU and RLC SDU have been explained in the above description of each method.

The action flow of the source ENB corresponding to this embodiment is shown in FIG. 6 .

601 ENB receives the message. 602 If the measurement report from the UE is received. According to the measurement report information, 603 the ENB decides whether to move the UE to another cell with better signal. If it is decided to move the UE to a cell under the same ENB, the handover process within the same ENB is performed, which is not the focus of the present invention, and the specific description is omitted. 604 If it is a handover process between different ENBs, 605 the ENB sends a "resource request" message to the ENB where the target cell is located, and the message includes the target cell ID, UE ID, Qos information that the UE needs to access services, and the current UE connected IP address of EGGSN, tunnel end identifier (hereinafter referred to as TEID) assigned by EGGSN (for uplink TEID between source ENB and EGGSN), integrity protection algorithm and password, encryption protection algorithm and password. The source RNC may also inform the destination RNC of the radio resources allocated by the source RNC to the UE through a resource request, instead of directly telling the destination RNC the Qos of the service used by the UE. 606 The source ENB waits for a response.

Corresponding to the method of sending RLC PDUs through the "Resource Request" message, the "Resource Request" message also includes each RLC PDU that has not been acknowledged (NACK) and the corresponding sequence number, and may also include the SN for the next RLC PDU ( The next SN to be used when RLC SDU is framed), and LI can also be included. This information element is optional. If the first RLC SDU is complete and has no fragments, then LI is not present. It also contains other ARQ context information. Thus step 612 would not be required.

607 If the ENB receives a "Resource Response" message from another ENB in 601. 608 If it is a failed response message, such as insufficient resources, the ENB will not continue the process of switching to the cell. If it is a successful response message, 609 ENB saves information, such as the user plane identifier (such as TEID) allocated by the target ENB, RRC container (corresponding to RLC SDUs are also sent through the control plane, and the message does not include the user plane allocated by the target ENB identifier such as TEID). 610 The ENB sends a "handover command" 1 message to the UE, which includes the target cell identifier and the radio resources allocated by the new cell (that is, the RRC container sent by the target ENB to the ENB). The ENB can also determine an activation time for applying the new cell configuration, and the network and the UE can switch to the new cell at the same time at the activation time. Corresponding to this method, the "handover command" message also includes the activation time. 611 The ENB forwards the RLC SDUs to the destination ENB through the established Iur user plane. The corresponding RLC SDUs are also sent through the control plane (the second method). The ENB sends the RLC SDUs to the destination ENB through the control plane message 506b "SDU data forwarding", and the message includes the SDUcontainer. The message may be an independent message, or a merged message with 507 (corresponding to 612). 612 The ENB sends an "RLC context transfer" message to the destination ENB, through which the destination ENB is notified of each currently unconfirmed RLC PDU and the corresponding serial number, and the message may also include the SN (RLC PDU) used for the next RLC PDU The next SN to be used when SDU is framed), LI and other ARQ context information. The ENB can use the PDUcontainer (container) to send RLC PDUs that have not been acknowledged (NACK) to the destination ENB through the RLC context transfer message. The RLC context transfer message also includes a starting GTP sequence number and an ending GTP sequence number.

610, 611, and 612 are not in an absolute order. For example, the ENB may send a "handover command" message to the UE while forwarding data to the target ENB, or may send an "RLC Context Transfer" message to the target ENB while forwarding data.

If the source ENB notifies the UE of the activation time, the source ENB sends an RLC context transfer message to the target ENB when the activation time is coming, and notifies the target ENB of each unacknowledged RLC PDU and the corresponding serial number. The SN of the next RLC PDU (the next SN to be used when RLC SDU is framed).

Corresponding to the third method of data forwarding, the source ENB forwards RLC PDUs and RLC SDUs to the destination ENB through the established user plane in step 611, and indicates whether it is a PDU or an SDU by setting an indicator. RLC context information such as the SN corresponding to each RLC PDU that has not been confirmed and the SN used for the next RLC PDU can be included in the resource request at 606, or can be sent to the destination ENB by sending a "RLC context transfer" message in step 612. In this way, the "RLC context transfer" message contains the SN of each unacknowledged RLC PDU, and can also contain the SN used for the next RLC PDU (the next SN to be used when RLC SDU is framed), LI and other ARQ contexts information. Another way for the source ENB to transmit the SN (the SN corresponding to each unacknowledged RLC PDU) to the destination ENB is to define the SN field in the data packet, and the data packet contains one SN, one corresponding RLC PDU, one SN A corresponding RLC PDU. This field is optional. This field is absent if used to transport RLC SDUs. The SN used for the next RLC PDU can also be transmitted through the user plane, so that if the user plane transmits an RLC SDU, there is an SN field in the data packet.

Corresponding to the fourth method of data forwarding, the source ENB forwards the RLC SDUs corresponding to the unconfirmed RLC PDUs and the RLC SDUs without segmentation to the destination ENB through the established user plane in step 611. RLC context information such as the SN used for the next RLC PDU (the next SN to be used when RLC SDU is framed) can be included in the resource request at 606, or can be sent to the destination ENB by sending an "RLC context transfer" message at 612 steps. In this way the "RLC Context Transfer" message contains the SN for the next RLC PDU.

Corresponding to the fifth method of data forwarding, the source ENB forwards the RLC SDUs corresponding to the unconfirmed RLC PDUs and the RLC SDUs without segmentation to the destination ENB through the established user plane in step 611. RLC context information such as which segment of which SDU has been confirmed by the UE, the SN of the RLC SDU, the SN for the next RLC PDU, and other ARQ context information can be included in the resource request at 606, or can be sent in step 612 by sending " RLC context transfer" message to the destination ENB. In this way, the "RLC context transfer" message contains which segments of which RLC SDUs have been confirmed by the UE, the SN of the RLC SDU, the SN for the next RLC PDU, and other ARQ context information.

Corresponding to the ENB has no method for determining the activation time, 613 if the ENB receives a "resource release request" message from the target ENB, 614 the ENB releases resources, including radio resources, UE context, and user plane identifiers such as TEID. Then 615ENB sends a resource release request message to EGGSN. The process of releasing EGGSN resources may also be initiated by the target ENB. Corresponding to this method initiated by the target ENB, step 615 does not exist.

Corresponding to the method in which the ENB determines the activation time, the ENB releases resources when the activation time arrives, including radio resources, UE context, and TEID. Then the ENB sends a resource release request message to the EGGSN. The process of releasing EGGSN resources can also be initiated by the target ENB.

The action flow of the ENB corresponding to the purpose of this embodiment is shown in FIG. 7 .

701 ENB receives message. 702 If the ENB receives a "resource request" message from another ENB, 703 the ENB performs access control according to the parameters in the request message (such as Qos or radio resource configuration parameters). If the resource cannot be allocated, step 709 is executed, and the ENB sends a failure response message to the source ENB. And inform the source ENB of the reason for the failure, such as no wireless resources, through the cause value. If the requested resources can be allocated, 704 ENB creates the context of this UE, and saves the relevant information of this UE, such as cell identity, UE identity, EGGSN IP address, TEID allocated by EGGSN, integrity protection algorithm and password, encryption algorithm and password . The target ENB allocates the user plane identifier such as TEID for user Iur data forwarding (corresponding RLC SDUs are also sent through the control plane, and the target ENB does not need to allocate user plane identifiers such as TEID for user Iur data forwarding). Corresponding to the method of sending RLC PDUs and RLC context information through the "resource request" message, the ENB saves the RLC PDUs in the message, the serial number corresponding to each unacknowledged RLC PDU, the SN, LI and others for the next RLC PDU ARQ context information. Corresponding to the first data forwarding method, and the method in which RLC PDUs and RLC context information are sent through "resource request", steps 707 and 708 will not be needed. Corresponding to the fifth data forwarding method, and the RLC context information is sent through the "resource request", the ENB saves the received RLC context information such as which segments of the RLC SDU have been confirmed by the UE, the SN of the RLC SDU, and SN for the next RLC PDU.

705 The ENB sends a "Resource Response" message to the source ENB to inform the source ENB of the resources allocated by the target ENB, and the resources allocated by the target ENB can be sent to the source ENB through the RRC container. At the same time, the "Resource Response" message contains the user plane identifier such as TEID allocated by the target ENB for data forwarding (the corresponding RLC SDUs are also sent through the control plane, and the message does not contain the user plane identifier allocated by the target ENB such as TEID). 706 ENB sends "UP registration" message to register with EGGSN. The message contains the downlink TEID assigned by the new ENB, the UE identity and the new ENB IP address. At this time, the EGGSN can send data to the target ENB. Another way for the ENB to register with the EGGSN is to send the "UP Registration" message to the EGGSN after the target ENB receives the "Handover Complete" message (710) from the UE. Corresponding to this method, there is no absolute order in which the target ENB sends the "UP registration" message to the EGGSN and the ENB sends the buffered data to the UE (711).

707 If the ENB receives an "RLC context transfer" message from another ENB at 701, 708 the ENB saves the received RLC context information, such as each unacknowledged PDU and the corresponding serial number, for the next RLC PDU SN, LI, the GTP sequence number at which the forwarded data begins and the GTP sequence at which it ends. The corresponding RLC SDUs are also sent through the control plane and sent with the RLC context information through a message, and the ENB saves the received RLC SDUs. Corresponding to the method of sending RLC PDUs and RLC context information through the "resource request" message, and RLC SDUs through the control plane, the ENB saves the RLC SDUs in the message. The corresponding RLC SDUs are also sent through the control plane and sent through independent messages with the RLC context information. If the ENB receives the 506b "SDU data forwarding" message, the ENB saves the received RLC SDUs.

Corresponding to the third and fourth data forwarding methods, and the RLC context information is sent through the "RLC context transfer" method of 507. When the ENB receives the 707 "RLC context transfer" message, the 708 ENB saves the RLC context information as follows: The SN used for the next RLC PDU, the sequence number corresponding to each unacknowledged RLC PDU, and other ARQ context information.

Corresponding to the fifth method of data forwarding, and the RLC context information is sent through the "RLC context transfer" method of 507, when the ENB receives the 707 "RLC context transfer" message, 708ENB saves the RLC context information such as which RLC SDUs Which segment has been acknowledged by the UE, the SN of the RLC SDU, the SN for the next RLC PDU, and other ARQ context information.

710 If the ENB receives the "handover complete" message from the UE at 701, 711 the ENB processes and sends the buffered data to the UE. The ENB discards duplicate data received from the source ENB and EGGSN at the same time. Correspondingly, the source ENB has no method for determining the activation time, and 712 the ENB sends a "resource release request" message to the source ENB.

Step 713, ENB receives data. 714 After receiving data from the corresponding user plane of the ENB or EGGSN such as the GTP tunnel, 715 the ENB caches the received data. Corresponding to the method of forwarding RLC PDUs and SDUs through the user plane (method 3), according to the indicator in the data packet, ENB saves RLC PDUs and RLC SDUs respectively. The corresponding RLC context information such as the SN corresponding to each RLC PDU or the SN used for the next RLC PDU is sent through the user plane data packet, and the ENB saves the RLC context information. The corresponding RLC SDUs are also sent through the control plane, and the ENB only receives and caches data from the corresponding user plane of the EGGSN, such as the GTP tunnel.

After the target ENB caches the data, the processing of RLC PDUs and RLC SDUs is the same as that of the prior art (method 1 to method 4). If the RLC context information contains LI, the target ENB will start segmenting after the LI length of the first SDU. The process of further processing the data and sending it to the UE is not the focus of the present invention, and the detailed technical description is omitted here. The emphasis here is that in method five, the destination ENB caches the RLC SDUs received from the source ENB. After segmenting the RLC SDUs, according to the RLC context information received from the source ENB, such as which segment of the RLC SDU has been confirmed by the UE, those RLC PDUs that have been confirmed by the UE are discarded, and those RLC PDUs that have not been confirmed by the UE are discarded. PDUs are sent to UE. The processing of data in the lower layer (such as the processing of MAC and physical layer) is not the focus of the present invention, and the detailed technical description is omitted here.

The action flow of the EGGSN corresponding to this embodiment is shown in FIG. 8 .

801 EGGSN receives the message. 802 If the "UP registration" message from the ENB is received, 803 the EGGSN updates the context information of the corresponding UE, and saves the downlink new user plane identifier allocated by the ENB such as TEID and the IP address of the ENB. 804 EGGSN starts sending UE data to this ENB. EGGSN can start sending data to this ENB and stop sending data to the old ENB where the UE is located, or send UE data to two ENBs at the same time, and stop sending data to the old ENB until it receives a resource release request from the old ENB. ENB sends data.

805 If the EGGSN receives a resource release request from the ENB at 801, 806 the EGGSN releases the corresponding resource, such as TEID, according to the request message.

The action flow of the UE corresponding to this embodiment is shown in FIG. 9 .

Step 901, the UE performs measurement according to the measurement configuration of the ENB. 902 According to the measurement configuration, the UE sends a "measurement report" message to the ENB, for example, periodically or time-triggered. Report the result of the measurement to ENB.

In step 903, the UE receives the message. 904 If the UE receives the "handover command" message from the ENB, 905 UE configures resources according to the radio resource conditions of the new cell in the handover command. If resources are successfully configured, the UE moves to a new cell. If the activation time is included in the "handover command", the UE will switch to a new cell when the activation time arrives. 906 The UE sends a "handover complete" message to the ENB in the new cell.

Fig. 10 shows the second method of moving from one ENB to another ENB when the UE is in the connected mode. The feature of this method is that the UE directly switches to a new cell, and the UE notifies the target ENB of the Qos information required by the UE, without the process of preparing radio resources in advance.

Step 1001, according to the measurement result of the UE or the control command and measurement result received by the UE from the ENB, the UE switches to a new cell. The UE sends a "handover request" to the target ENB in the new cell. The handover request message includes UE identity, cell identity and Qos information of the service connected to the UE. After the destination ENB receives the handover request message, it configures radio resources. If the radio resources are allocated successfully, 1002 the ENB allocates the Iu+ interface downlink user plane identifier such as TEID, and the ENB sends a "UP establishment request" message to the EGGSN. The message includes downlink user plane identifiers such as TEID, ENB IP address, and UE identifier. After receiving this message, the EGGSN updates the UE context, saves the user plane identifier such as TEID, ENB IP address, and allocates the uplink user plane identifier such as TEID. 1003 EGGSN sends "UP Setup Response" message to the destination ENB. The EGGSN stops sending data to the UE's original ENB and starts sending data to the new ENB. After receiving the UP setup response, the target ENB saves the uplink user plane identifier such as TEID.

The target ENB can know the source ENB through two methods. Method 1: The UE notifies the target ENB through a handover request message. Corresponding to this method, the "handover request" message also includes the source ENB IP address or source ENB identifier. Method 2: EGGSN notifies the destination ENB. Corresponding to this method, the "UP Setup Response" message includes the source ENB IP address or source ENB identifier.

1004 The destination ENB allocates the user plane identifier such as TEID for data forwarding on the Iur interface. The destination ENB sends a "data forwarding request" message to the source ENB, and the message includes the UE identifier and the user plane identifier such as TEID used for data forwarding by the Iur interface. After receiving the data forwarding request message, the source ENB saves the information, such as the user plane identifier, and sends 1005 a "data forwarding response" message to the destination ENB. The message contains each unacknowledged RLC PDUs and their corresponding sequence numbers, and may also contain the sequence numbers for the next RLC PDU to be sent. LI can also be included. This information element is optional. If the first RLC SDU is complete and has no fragments, then LI is not present. The data forwarding response message also includes the starting GTP sequence number and the ending GTP sequence number of the forwarded data. The data forwarding response message also includes other ARQ context information. 1006a The source ENB starts to send the RLC SDUs to the destination ENB through the established user plane, where the meaning of the RLC SDUs is the same as in the above data forwarding method 1. 1007 After allocating resources and receiving the UP setup response message from EGGSN, the target ENB sends a "Handover Confirmation" message to the UE. The message includes the radio resource configuration, UE ID, and new cell ID allocated by the target ENB for the UE.

The data forwarding process (1004 to 1006a) of the Iur interface corresponding to the method of EGGSN notifying the source ENB to the destination ENB occurs after the UP establishment process of the Iu+ interface. Corresponding to the method in which the UE informs the destination ENB of the source ENB through a handover request message, there is no absolute sequence for the UP establishment process of the Iu+ interface and the data forwarding process of the Iur interface.

There is no absolute sequence between the data forwarding process of the Iur interface and the handover confirmation message sent by the target ENB to the UE. However, the target ENB sends the handover confirmation message to the UE after receiving the UP establishment response message in step 1103 .

1009 Release the resources allocated by the source ENB and the EGGSN for the UE and the user plane resources used for data forwarding between the source ENB and the target ENB. The process of releasing resources between the source ENB and the EGGSN may be initiated by the EGGSN, or by the source ENB or the target ENB. If the source ENB does not receive data within a period of time after forwarding the data, it can release resources, including radio resources, UE context, and user plane identifiers such as TEID. The ENB initiates a "resource release request" message to the EGGSN to request the release of resources, and the EGGSN releases the resources after receiving the message. The EGGSN can also release resources after stopping sending data to the source ENB, and send a "resource release request" message to the ENB, and the ENB releases the resources after receiving the message. The user plane resource release process for data forwarding between the source ENB and the target ENB can be initiated by the target ENB. The target ENB sends a release request to the source ENB. The source ENB receives the request message from the target ENB and releases it after the data forwarding is completed. The saved Iur interface is used for data forwarding resources. This process can also be initiated by the source ENB. After the source ENB has forwarded the data, it releases the saved resources of the Iur interface for data forwarding, and sends a release request to the destination ENB. After the destination ENB receives the request message from the source ENB, it releases the resources of the Iur interface for data forwarding. The source ENB may also include an end flag bit in the forwarded data packet to indicate the end of data forwarding. The target ENB releases the resource used for data forwarding on the Iur interface after finding that the data forwarding is completed.

In the above description of FIG. 10, the forwarding method of user data in Iur is that RLC PDUs are sent to the destination ENB through the 1005 "Data Forwarding Response" message of the control plane. RLC SDUs are sent over a user plane such as GTP-U. This is the first method of data forwarding in the present invention, that is, RLC PDUs are forwarded through the control plane, and RLC SDUs are forwarded through the user plane.

The meanings of RLC PDUs and RLC SDUs in the five data forwarding methods corresponding to Figure 10 and Figure 15 are the same as those in the various data forwarding methods in Figure 5 above.

The second method of data forwarding is that both RLC SDUs and RLC PDUs are sent through the control plane. Corresponding to this method, the signaling flow of UE moving between two ENBs will be described with reference to FIG. 10 . Here we focus on the differences from the first method, that is, the above description. Corresponding to this method, the 1006 SDU forwarding step in the figure is that the source ENB sends the RLC SDUs to the destination ENB by sending the control message "SDU data forwarding" in step 1006b. RLC SDUs of the frame. The control plane message can be an independent message, or it can be sent through the "data forwarding response" message, and the "data forwarding response" message contains the SDU container. Corresponding to this method, it needs to be specially explained that 1004 and 1005 in the figure are only used for requesting data forwarding and the process of data forwarding, and do not need to establish the user plane of the Iur interface, so the destination ENB does not need to allocate users for Iur interface user data forwarding Flat identifiers such as TEID. The request message does not include the user plane identity, and the ENB does not need to save the user plane identity allocated by the corresponding ENB.

The third method of data forwarding is that both RLC SDUs and RLC PDUs are sent through the user plane. Corresponding to this method, the signaling flow of the UE moving between two ENBs is illustrated in conjunction with Figure 10. Here we focus on the differences from the first method. RLC PDUs and RLC SDUs pass through the user plane established in steps 1004 and 1005, and forward SDUs and PDUs to the destination ENB in step 1006c. In the packet header of the data, an indicator (indication bit) is set to indicate whether it is a PDU or an SDU. RLC context information such as the SN corresponding to each RLC PDU and the SN, LI and other ARQ context information for the next PDU can be sent to the destination ENB through 1005 "Data Forwarding Response". RLC context information such as the SN corresponding to each unacknowledged RLC PDU can also be sent from the source ENB to the destination ENB through the user plane together with the data itself. Corresponding to this method, the SN field is defined in the data packet, and the data packet contains one SN and one corresponding RLC PDU in sequence, and one SN and one corresponding RLC PDU. This field is optional. This field is absent if used to transport RLC SDUs. The SN used for the next RLC PDU can also be transmitted through the user plane, so that if the user plane transmits an RLC SDU, there is an SN field in the data packet.

The fourth method of data forwarding is to forward only the RLC SDUs corresponding to the unacknowledged RLC PDU and the RLC SDUs without segmentation through the user plane. Corresponding to this method, the signaling flow of the UE moving between two ENBs is combined with Figure 10 to illustrate. Here we focus on the differences from the first method. The RLC SDUs pass through the user plane established in steps 1004 and 1005, and forward the RLC SDUs to the destination ENB in step 1006a. RLC context information such as the SN used for the next RLC PDU can be sent to the destination ENB through 1005 "Data Forwarding Response".

The fifth method of data forwarding is to forward only the RLC SDUs corresponding to the unacknowledged RLC PDU and the RLC SDUs without segmentation through the user plane. Corresponding to this method, the signaling flow of UE moving between two ENBs is combined with Figure 10 to illustrate. Here we focus on the difference from the fourth method. The RLC SDUs pass through the user plane established in steps 1004 and 1005, and forward the RLC SDUs to the destination ENB in step 1006a. The RLC context information includes which segment of the corresponding RLC SDU has been confirmed by the UE, and can also include the SN of the RLC SDU, the SN for the next RLC PDU, and other ARQ context information can be sent to the destination through 1005 "Data Forwarding Response" ENB. In this way, after the destination ENB receives the forwarded data, it does not need to resend the RLC PDUs confirmed by the UE to the UE.

In the following description of the description of the action of the node device, the first data forwarding method (RLCPDUs control plane, RLC SDUs user plane) is also used to describe. The difference between other data forwarding methods and the first one will be pointed out in particular.

Corresponding to this embodiment, the action flow of the target ENB is shown in FIG. 11 .

1101 ENB receives message. 1102 If a "handover request" message from the UE is received, 1103, according to the Qos in the request message, the ENB performs access control on the UE, and checks whether the UE can be accessed. 1104 If the unavailable ENB sends a failure response message to the UE, the failure message includes an information element reason, and the reason value may be set as insufficient resources. If the UE can access. 1105 ENB creates UE context and saves information, such as UE ID, cell ID, Qos, etc. The ENB allocates the user plane identifier such as TEID for the downlink of the Iu+ interface. 1106 ENB sends "UP Establishment Request" message to EGGSN. The message contains downlink user plane identifiers such as TEID, ENB IP address, and UE identifier. ENB waits for a response.

Corresponding to the method that the UE notifies the source ENB to the target ENB through a handover request message, the ENB may send a "data forwarding request" message to the source ENB at this time (step 1107) and wait for a response. It may also send a "Data Forwarding Request" message to the source ENB after receiving the "UP Setup Response" message from the EGGSN (step 1110) and wait for a response. Corresponding to the method of EGGSN notifying the source ENB to the target ENB, the target ENB can only send a "Data Forwarding Request" message to the source ENB after receiving the "UP Setup Response" message from the EGGSN (step 1110) and wait for a response.

Step 1108, if the ENB receives the "UP establishment response" message from the EGGSN, the 1108 ENB saves information, such as the user plane identifier such as TEID allocated by the EGGSN. 1110 The ENB may at this point send a "Data Forward Request" message to the source ENB (as described above) and wait for a response. 1111 The ENB sends a "Handover Confirmation" message to the UE, which contains the radio resource configuration, UE ID, and new cell ID allocated by the target ENB for the UE. If the ENB receives the "UP Setup Response" message from the EGGSN, it sends the "Data Forwarding Request" message to the source ENB. Then there is no absolute order in which the ENB sends the "data forwarding request" message to the ENB and the "handover confirmation" message to the UE.

Step 1112, destination ENB receives the "data forwarding response" message from source ENB, 1113 destination ENB saves RLC context information and RLC PDUs that have not been confirmed. The ENB can store RLC PDUs in the resend buffer. Corresponding to the method that RLC SDUs are sent through the control plane and also forwarded through the "Data Forwarding Response", the ENB buffers the received RLC SDUs. The ENB MAY place the RLC SDUs received from the source ENB before the data received from the EGGSN. The corresponding RLC SDUs are sent through an independent message 1006b "SDU data forwarding" on the control plane. After receiving this message, the ENB caches the received RLC SDUs. The ENB MAY place the RLC SDUs received from the source ENB before the data received from the EGGSN.

Corresponding to the third and fourth data forwarding methods, when the ENB receives the 1112 "Data Forwarding Response" message, the corresponding "Data Forwarding Response" message contains RLC context information such as the SN or the next SN method of an RLC PDU, 1113 ENB saves RLC context information such as the SN for the next RLC PDU or every SN that has not been acknowledged for the RLC PDU.

Corresponding to the fifth method of data forwarding, when the ENB receives the 1112 "Data Forwarding Response" message, the corresponding "Data Forwarding Response" message contains RLC context information such as which segment of the RLC SDU has been confirmed by the UE, and which segment of the RLC SDU SN, the SN method for the next PDU, and other ARQ context information, 1113 ENB saves the RLC context information such as which segment of the RLC SDU has been confirmed by the UE, the SN of the RLC SDU, the SN for the next RLC PDU, and others ARQ context information.

111 4ENB receives data. 1115 If the ENB receives user data from the corresponding user plane of the source ENB or EGGSN such as the GTP tunnel, 1116 the ENB caches the received data. The ENB puts the data received from the source ENB before the data received from the EGGSN. Corresponding to the method of forwarding RLC PDUs and RLC SDUs through the user plane (method 3), the ENB caches RLC PDUs and RLC SDUs respectively according to the indicator in the data packet header. The corresponding RLC context information such as the SN corresponding to each RLC PDU (or the SN used for the next RLC PDU) is sent through the user plane data packet, and the ENB saves the RLC context information. Corresponding to the method of sending RLC SDUs through the control plane, ENB only receives and caches data from the corresponding user plane of EGGSN, such as the GTP tunnel.

The processing of RLC PDUs and RLC SDUs by ENB is the same as that of the prior art (method 1 to method 4). If LI is included in the RLC context information, the destination ENB will start segmenting after the LI length of the first SDU. The process of processing the data and sending it to the UE is not the focus of the present invention, and the detailed technical description is omitted here. The emphasis here is that in method five, the destination ENB caches the RLC SDUs received from the source ENB. After segmenting the RLC SDUs, according to the RLC context information received from the source ENB, such as which segment of the RLC SDU has been confirmed by the UE, those RLC PDUs that have been confirmed by the UE are discarded, and those RLC PDUs that have not been confirmed by the UE are discarded. PDUs are sent to UE. The processing of data in the lower layer (such as the processing of MAC and physical layer) is not the focus of the present invention, and the detailed technical description is omitted here.

Corresponding to this embodiment, the action flow of the source ENB is shown in FIG. 12 .

1201 ENB receives the message. 1202 If a "data forwarding request" message from another ENB is received, 1203 ENB saves information, such as user plane identification (corresponding to the method that RLC SDUs are forwarded through the control plane, there is no user plane identification in the message). According to the UE ID in the received message, 1204, the source ENB sends a "Data Forwarding Response" message to the destination ENB. The message contains the unconfirmed RLC PDU and the corresponding SN, and may also contain the sequence number of the next RLC PDU to be sent. , can also contain LI. This information element is optional. If the first RLC SDU is complete and has no fragments, then LI is not present. It also contains other ARQ context information. The ENB can use the PDU container (container) to send the RLC PDUs that have not been acknowledged (NACK) to the destination ENB through the data forwarding response message. 1205 The ENB starts sending RLC SDUs to the destination ENB via the established user plane. Corresponding to the method of sending RLC SDUs through the control plane, the ENB sends the RLC SDUs to the destination ENB through an independent message 1006b "SDU data forwarding" on the control plane. The source ENB can also include the SDUcontainer in the "Data Forwarding Response", and the SDU container contains the RLC SDUs sent by the source ENB to the destination ENB.

Corresponding to the third method of data forwarding, the source ENB forwards RLC PDUs and RLC SDUs to the destination ENB through the established user plane in step 1205, and indicates whether it is a PDU or an SDU by setting an indicator. RLC context information such as the SN corresponding to each RLC PDU that has not been confirmed and the SN, LI and other ARQ context information for the next RLC PDU can be sent to the destination ENB in the "data forwarding response" message in step 1204. In this way, the "Data Forwarding Response" message includes the SN corresponding to each unacknowledged RLC PDU, and may also include SN, LI and other ARQ context information for the next RLC PDU. The corresponding RLC context information such as the SN corresponding to each RLC PDU or the SN of the next PDU is also sent through the user plane data packet, and the corresponding information is not included in the message.

Corresponding to the fourth method of data forwarding, the source ENB forwards the RLC SDUs corresponding to the unconfirmed RLC PDUs and the RLC SDUs without segmentation to the destination ENB through the established user plane in step 1205. The RLC context information such as the SN for the next RLC PDU is given to the destination ENB in the "Data Forwarding Response" message at step 1204. In this way, the "Data Forwarding Response" message contains the SN for the next RLC PDU, but does not contain the PDU container.

Corresponding to the fifth method of data forwarding, the source ENB forwards the RLC SDUs corresponding to the unconfirmed RLC PDUs and the RLC SDUs without segmentation to the destination ENB through the established user plane in step 1205. RLC context information such as which segment of which RLC SDUs has been confirmed by the UE, the SN of the RLC SDU, the SN for the next RLC PDU and other ARQ context information are given to the destination ENB in the "data forwarding response" message in step 1204. In this way, the "RLC context transfer" message contains which segments of which RLC SDUs have been confirmed by the UE, the SN of the RLC SDU, the SN for the next RLC PDU, and other ARQ context information.

1206. This step corresponds to the resource release process initiated by the source ENB. If the source ENB does not receive data within a period of time after forwarding the data, it can release resources, including radio resources, UE context, and user plane identifiers such as TEID. The ENB initiates a "resource release request" message to the EGGSN to request the release of resources,

Corresponding to the method of EGGSN initiating the resource release process, 1207, if the ENB receives the "resource release request" message from the EGGSN, the ENB releases resources, including radio resources, UE context, and user plane identifiers such as TEID. If the ENB receives a resource release request from the destination ENB at 1207, the ENB releases the resource.

Corresponding to this embodiment, the action flow of the EGGSN is shown in FIG. 13 .

1301 EGGSN receives the message. 1302 If the "UP establishment request" message from the ENB is received, 1303 the EGGSN updates the context information of the corresponding UE, and saves the downlink new user plane identifier allocated by the ENB such as TEID and the IP address of the ENB. 1304 The EGGSN allocates the downlink TEID for the new ENB. 1305 EGGSN sends "UP Setup Response" message to the new ENB. 1306 EGGSN stops sending data to the old ENB where the UE is located, and starts sending UE data to the new ENB.

Corresponding to the method that the EGGSN initiates to release the resources allocated by the source ENB and the EGGSN for this UE, 1307 the EGGSN releases the resources, and sends a "resource release request" message to the old ENB, which contains the UE identifier.

Corresponding to the method that the source ENB initiates to release the resources allocated by the source ENB and the EGGSN for this UE, in 1308, if the EGGSN receives a resource release request from the ENB, in 1309, the corresponding resource, such as the user plane identifier, is released according to the request message.

Corresponding to this embodiment, the action flow of the UE is shown in FIG. 14 .

Step 1401, the UE performs measurement according to the measurement configuration of the ENB. 1402 According to the measurement result, or the command received by the UE from the ENB (for example, the command that the current cell is about to be overloaded) and the measurement result, the UE switches to a new cell. 1403 The UE sends a "handover request" message to the target ENB in the new cell.

In step 1404, the UE receives the message. 1405 If the UE receives the "Handover Confirmation" message from the ENB, 1406 UE configures resources according to the radio resource conditions of the new cell in the handover confirmation. After the resource configuration is completed, 1407 UE sends and receives data in the new cell.

Fig. 15 shows the third method of moving from one ENB to another ENB when the UE is in the connected mode. The feature of this method is that the UE directly switches to a new cell, the source ENB notifies the target ENB of the Qos information required by the UE, and there is no process of preparing radio resources in advance.

Step 1501, according to the measurement result of the UE or the control command and measurement result received by the UE from the ENB, the UE switches to a new cell. The UE sends a "handover request" to the target ENB in the new cell. The handover request message includes UE identity, cell identity and source ENB IP address or source ENB identity. 1502 After the target ENB receives the handover request message, the target ENB allocates a user plane identifier such as TEID for data forwarding on the Iur interface. The destination ENB sends a "data forwarding request" message to the source ENB, and the message includes the UE identifier and the user plane identifier such as TEID used for data forwarding by the Iur interface. After receiving the data forwarding request message, the source ENB saves the user plane identifier such as TEID in the request message, and sends 1503 a "data forwarding response" message to the destination ENB. The message includes the unacknowledged RLC PDU and the corresponding SN, and may also include the sequence number for the next RLC PDU to be sent and the Qos information of the UE connection service, and may also include LI. This information element is optional. If the first RLC SDU is complete and has no fragments, then LI is not present. It also contains other ARQ context information. The ENB can use the PDU container (container) to send the RLC PDUs that have not been acknowledged (NACK) to the destination ENB through the data forwarding response message. The data forwarding response message also includes the starting GTP sequence number and the ending GTP sequence number of the forwarded data. 1504a The source ENB starts sending RLC SDUs to the destination ENB via the established user plane. The destination ENB checks the required resources. If the wireless resources can be allocated successfully, 1505 the ENB allocates the Iu+ interface downlink user plane identifier such as TEID, and the ENB sends the "UP establishment request" message to the EGGSN. The message contains downlink user plane identifiers such as TEID, ENB IP address, and UE identifier. After the EGGSN receives this message, it updates the UE context, saves the user plane identifier such as TEID, ENB IP address, and allocates the uplink user plane identifier such as TEID. 1506 EGGSN sends "UP Setup Response" message to the destination ENB. The EGGSN stops sending data to the UE's original ENB and starts sending data to the new ENB. After receiving the UP setup response, the destination ENB saves the uplink user plane identifier such as TEID. The destination ENB caches user data received from the source ENB and EGGSN. The destination ENB MAY place the RLC SDUs received from the source ENB before the data received from the EGGSN. The SDU forwarding process of 1504a and the UP establishment process of 1505 and 1506 can be performed simultaneously.

1507 After allocating resources and receiving the UP setup response message from EGGSN, the target ENB sends a "Handover Confirmation" message to the UE. The message includes the radio resource configuration, UE ID, and new cell ID allocated by the target ENB for the UE.

There is no absolute sequence between the data forwarding process of the Iur interface and the handover confirmation message sent by the target ENB to the UE. However, the target ENB sends the handover confirmation message to the UE after receiving the UP establishment response message in step 1103 .

1508 Release the resources allocated by the source ENB and the EGGSN for the UE and the user plane resources used for data forwarding between the source ENB and the target ENB. The process of releasing resources between the source ENB and the EGGSN can be initiated by the EGGSN or by the source ENB. If the source ENB does not receive data within a period of time after forwarding the data, it can release resources, including radio resources, UE context, and user plane identifiers such as TEID. The ENB initiates a "resource release request" message to the EGGSN to request the release of resources, and the EGGSN releases the resources after receiving the message. The EGGSN can also release resources after stopping sending data to the source ENB, and send a "resource release request" message to the ENB, and the ENB releases the resources after receiving the message. The user plane resource release process for data forwarding between the source ENB and the target ENB can be initiated by the target ENB. The target ENB sends a release request to the source ENB. The source ENB receives the request message from the target ENB and releases it after the data forwarding is completed. The saved Iur interface is used for data forwarding resources. This process can also be initiated by the source ENB. After the source ENB has forwarded the data, it releases the saved resources of the Iur interface for data forwarding, and sends a release request to the destination ENB. After the destination ENB receives the request message from the source ENB, it releases the resources of the Iur interface for data forwarding. The source ENB may also include an end flag bit in the forwarded data packet to indicate the end of data forwarding. The target ENB releases the resource used for data forwarding on the Iur interface after finding that the data forwarding is completed.

In the above description of FIG. 15, the forwarding method of user data in Iur is that RLC PDUs are sent to the destination ENB through the "data forwarding response" message of the control plane. RLC SDUs are sent over a user plane such as GTP-U. This is the first method of data forwarding in the present invention, that is, RLC PDUs are forwarded through the control plane, and RLC SDUs are forwarded through the user plane.

The second method of data forwarding is that both RLC SDUs and RLC PDUs are sent through the control plane. Corresponding to this method, the signaling flow of UE moving between two ENBs will be described with reference to FIG. 15 . Here we focus on the differences from the first method, that is, the above description. Corresponding to this method, the 1504 SDU forwarding step in the figure is that the source ENB sends the RLC SDUs to the destination ENB by sending the control message "SDU data forwarding" in step 1504b. The message contains the SDU container, and the SDU container contains the unused RLC SDUs of the frame. The control plane message can be an independent message, or it can be sent through the "data forwarding response" message, and the "data forwarding response" message contains the SDU container. Corresponding to this method, it needs to be specially explained that 1502 and 1503 in the figure are only used for requesting data forwarding and the process of data forwarding, and do not need to establish the user plane of the Iur interface, so the destination ENB does not need to allocate users for Iur interface user data forwarding Flat identifiers such as TEID. The request message does not include the user plane identity, and the ENB does not need to save the user plane identity allocated by the corresponding ENB.

The third method of data forwarding is that both RLC SDUs and RLC PDUs are sent through the user plane. Corresponding to this method, the signaling flow of UE moving between two ENBs is illustrated in Figure 15. Here we focus on the differences from the first method. RLC PDUs and RLC SDUs pass through the user plane established in steps 1502 and 1503, and forward SDUs and PDUs to the destination ENB in step 1504c. In the packet header of the data, an indicator (indication bit) is set to indicate whether it is a PDU or an SDU. RLC context information such as the SN corresponding to each unacknowledged RLC PDU and the SN, LI and other ARQ context information for the next RLC PDU can be sent to the target ENB through 1503 "Data Forwarding Response". RLC context information such as the SN corresponding to each unacknowledged RLC PDU can also be sent from the source ENB to the destination ENB through the user plane together with the data itself. Corresponding to this method, the SN field is defined in the data packet, and the data packet contains one SN and one corresponding RLC PDU in sequence, and one SN and one corresponding RLC PDU. This field is optional. This field is absent if used to transport SDUs. The SN used for the next RLC PDU can also be transmitted through the user plane, so that if the user plane transmits an RLC SDU, there is an SN field in the data packet.

The fourth method of data forwarding is to forward only the RLC SDUs corresponding to the unacknowledged RLC PDUs and the RLC SDUs without segmentation through the user plane. Corresponding to this method, the signaling flow of the UE moving between two ENBs is shown in Figure 15. illustrate. Here we focus on the differences from the first method. The RLC SDUs pass through the user plane established in steps 1502 and 1503, and forward the SDUs to the destination ENB in step 1504a. RLC context information such as the SN for the next RLC PDU can be sent to the destination ENB through 1503 "Data Forwarding Response".

The fifth method of data forwarding is to forward only the RLC SDUs corresponding to the unacknowledged RLC PDUs and the RLC SDUs without segmentation through the user plane. Corresponding to this method, the signaling flow of the UE moving between two ENBs is shown in Figure 15. illustrate. Here we focus on the difference from the fourth method. The source ENB forwards the RLC SDUs to the destination ENB in step 1504a through the user plane established in steps 1502 and 1503. The RLC context information includes which segment of the corresponding RLC SDU has been confirmed by the UE, and can also include the SN of the RLC SDU, the SN for the next PDU, and other ARQ context information, which can be sent to the destination ENB through 1503 "Data Forwarding Response" . In this way, after the destination ENB receives the forwarded data, it does not need to resend the RLC PDUs confirmed by the UE to the UE.

In the following description of the description of the action of the node device, the first data forwarding method (RLCPDUs control plane, RLC SDUs user plane) is also used to describe. The difference between other data forwarding methods and the first one will be pointed out in particular.

Corresponding to this embodiment, the action flow of the target ENB is shown in FIG. 16 .

1601 ENB receives message. 1602 If a "handover request" message from UE is received, 1603 ENB creates UE context and saves information, such as UE ID, cell ID, source ENB, etc. Assign the user plane identifier such as TEID to the Iur interface for data forwarding (the corresponding RLC SDUs are sent through the control plane, and the ENB does not need to assign this user plane identifier). 1604 The ENB sends a "Data Forwarding Request" message to the source ENB, and waits for a response.

1605 If the destination ENB receives the "Data Forwarding Response" message from the source ENB, 1606 the destination ENB saves the RLC context information and the RLC PDUs that have not been confirmed, and the Qos of the service connected to the UE. The ENB can store RLC PDUs in the retransmission buffer. Corresponding to the method that RLC SDUs are sent through the control plane and also forwarded through the "Data Forwarding Response", the ENB buffers the received RLC SDUs. The ENB MAY place the RLC SDUs received from the source ENB before the data received from the EGGSN. The corresponding RLC SDUs are sent through an independent message 1504b "SDU data forwarding" on the control plane. After receiving this message, the ENB caches the received RLC SDUs. The ENB MAY place the RLC SDUs received from the source ENB before the data received from the EGGSN. Corresponding to the third and fourth data forwarding methods, when the ENB receives the 1605 "Data Forwarding Response" message, if the message contains RLC context information such as the SN of each unacknowledged RLC PDU or the SN for the next RLC PDU SN, go to step 1606. Corresponding to the fifth data forwarding method, the RLC context information also includes which segments of which RLC SDUs have been confirmed by the UE. 1606 The ENB saves the RLC context information in the message.

1607 According to the Qos of the services required by the UE, the ENB performs access control on the UE, and checks whether the UE can be accessed. 1608 If it is not possible for the ENB to send a failure response message to the UE, the failure message includes an information element reason, and the reason value may be set as insufficient resources. On failure the ENB needs to release the cached information from the source ENB. If the UE can access. 1609 The ENB reserves resources, and the ENB allocates a user plane identifier such as TEID for the downlink of the Iu+ interface. 1609 ENB sends "UP establishment request" message to EGGSN. The message includes the downlink user plane identifier such as TEID, destination ENB IP address, and UE identifier. ENB waits for a response.

Step 1610, if the ENB receives the "UP establishment response" message from the EGGSN, 1108 the ENB saves information, such as the user plane identifier such as TEID allocated by the EGGSN. 1612 The ENB sends a "Handover Confirmation" message to the UE, which contains the radio resource configuration allocated by the target ENB for the UE, the UE ID, and the new cell ID.

1613 ENB receives data. 1614 If the ENB receives user data from the corresponding user plane of the source ENB or EGGSN such as the GTP tunnel, 1615 the ENB caches the received data. The ENB puts the data received from the source ENB before the data received from the EGGSN. Both RLC SDUs and RLC PDUs are sent through the control plane, and ENB only receives and caches data from the corresponding user plane of EGGSN, such as the GTP tunnel. Corresponding to the method of forwarding RLC PDUs and RLC SDUs through the user plane (method 3), the ENB caches RLC PDUs and RLC SDUs respectively according to the indicator in the packet header. Corresponding to the RLC context information, for example, the SN corresponding to each unconfirmed RLC PDU (or the SN used for the next RLC PDU) is sent through the user plane data packet, and the ENB saves the RLC context information.

The processing of RLC PDUs and RLC SDUs by ENB is the same as that of the prior art (method 1 to method 4). If LI is included in the RLC context information, the destination ENB will start segmenting after the LI length of the first SDU. The process of processing the data and sending it to the UE is not the focus of the present invention, and the detailed technical description is omitted here. The emphasis here is that in method five, the destination ENB caches the RLC SDUs received from the source ENB. After segmenting the RLC SDUs, according to the RLC context information received from the source ENB, such as which segment of the RLC SDU has been confirmed by the UE, those RLC PDUs that have been confirmed by the UE are discarded, and those RLC PDUs that have not been confirmed by the UE are discarded. PDUs are sent to UE. The processing of data in the lower layer (such as the processing of MAC and physical layer) is not the focus of the present invention, and the detailed technical description is omitted here.

Corresponding to this embodiment, the action flow of the source ENB is the same as that of the source ENB in method 2, as shown in FIG. 12 . The difference is that the "Data Forwarding Response" message sent by the source ENB to the target ENB in step 1204 also includes the Qos parameter of the UE's access service.

Corresponding to this embodiment, the action flow of the EGGSN is the same as that of the source EGGSN in method 2, as shown in FIG. 13 .

Corresponding to this embodiment, the action flow of the UE is the same as that of the UE in Method 2, as shown in FIG. 14 . The difference is that the "Handover Request" message sent by the UE to the target ENB in 1403 includes the cell ID, UE ID, IP address of the source ENB or ID of the source ENB, but does not include the Qos parameter of the UE's access service.

The above descriptions of different data forwarding modes in the process of the UE moving between two ENBs (including several different signaling procedures introduced) all use the forwarding of downlink data as an example. For the uplink, data forwarding may not be required. If a certain RLC PDU corresponding to a certain RLC SDU has not received an acknowledgment, the UE will repeatedly send the data of the entire RLC SDU.

There can also be uplink data forwarding. Method 1 of uplink data forwarding: Uplink only needs to forward confirmed RLC PDUs and the RLC SDUs corresponding to these RLC PDUs are not complete. The source ENB sends the completely received RLC SDUs to the EGGSN. In the same way as the forwarding method of the downlink RLC PDUs above, the forwarding of the uplink RLC PDUs can be forwarded through the control plane or through the user plane. If RLC PDUs are forwarded through the user plane, the corresponding SNs can be forwarded through the control plane or forwarded together with user data through the user plane. The signaling process corresponding to each method (control plane transmission, user plane transmission, and corresponding SN transmission through the control plane or user plane together with data) and the actions of the source ENB and destination ENB are similar to the above-mentioned downlink RLC The data forwarding of PDUs is the same, and the forwarding method of RLC context information is the same as that of downlink, and the detailed technical description is omitted here. If the uplink forwarded data and the downlink forwarded data are sent on the same user plane, it is necessary to define an indication bit indicating whether it is uplink or downlink in the data packet header. For example, there is a 1-bit indicator in the packet header.

Method 2 of uplink data forwarding: Forward the complete received RLC SDUs and confirmed RLC PDUs after the first RLC PDU is not received, but the RLC SDUs corresponding to these RLC PDUs are incomplete. The source ENB sends to the EGGSN the complete received RLC SDUs before the first RLC PDU not received. There are three forwarding methods for the RLC PDUs and RLC SDUs that need to be forwarded, which are the same as the above-mentioned downlink methods 1 to 3, and the forwarding methods of RLC context information such as ARQ context information are also the same as the downlink. A detailed technical description is omitted here. If the uplink forwarded data and the downlink forwarded data are sent on the same user plane, it is necessary to define an indication bit indicating whether it is uplink or downlink in the data packet header. For example, there is a 1-bit indicator in the packet header.

Uplink data forwarding method three: Forward all RLC PDUs after the first RLC PDU is not received, including the RLC PDUs corresponding to the RLC SDUs that are completely received after the first RLC PDU is not received. In the same way as the forwarding method of the downlink RLC PDUs above, the forwarding of the uplink RLC PDUs can be forwarded through the control plane or through the user plane. If RLC PDUs are forwarded through the user plane, the corresponding SNs can be forwarded through the control plane or forwarded together with user data through the user plane. The signaling process corresponding to each method (control plane transmission, user plane transmission, and corresponding SN transmission through the control plane or user plane together with data) and the actions of the source ENB and destination ENB are similar to the above-mentioned downlink RLC The PDUs data forwarding is the same, and the forwarding method of the RLC context information is the same as that of the downlink, and the detailed technical description is ignored here. If the uplink forwarded data and the downlink forwarded data are sent on the same user plane, it is necessary to define an indication bit indicating whether it is uplink or downlink in the data packet header. For example, there is a 1-bit indicator in the packet header.

Claims (93)

1. support the UE mobility method in a LTE system, wherein, UE moves between two ENB, comprises step:

Source ENB switches to the sub-district of another one purpose ENB to UE according to " measurement report " decision of receiving from UE, and sends " resource request " message to purpose ENB;

Purpose ENB sends " resource response " message and gives source ENB, and the resource of distributing is sent to source ENB;

Source ENB sends " switching command " and gives UE;

Purpose ENB receives next " switching is finished " message from UE.

2. method according to claim 1 is characterized in that described purpose ENB sending " resource response " message to behind the ENB of source, sends " UP registration " message and registers to EGGSN.

3. method according to claim 1 is characterized in that described purpose ENB after receiving the switching command message of coming from UE, sends " UP registration " message and registers to EGGSN.

4. method according to claim 1 is characterized in that described source ENB is transmitted to purpose ENB to the RLC SDUs that UE does not also handle framing.

5. method according to claim 1 is characterized in that, described source ENB sends to purpose ENB to the RLC PDUs that does not have affirmation by control plane;

6. method according to claim 1 is characterized in that, described source ENB sends to purpose ENB to the RLC SDUs that does not also handle framing by user plane.

7. method according to claim 1 is characterized in that, described source ENB by one independently " RLC context transfer " message not have the affirmation RLC PDUs and RLC contextual information send to purpose ENB.

8. method according to claim 7 is characterized in that, comprises information element in described " RLC context transfer " message and does not obtain the RLC PDUs that confirms.

9. method according to claim 7 is characterized in that, comprises the SN that information element is used for next RLC PDU in described " RLC context transfer " message.

10. method according to claim 7 is characterized in that, each does not obtain confirming the SN of RLC PDU to comprise the information element correspondence in described " RLC context transfer " message.

11. method according to claim 7 is characterized in that, comprises the GTP series number that GTP PDU that information element transmits begins in described " RLC context transfer " message.

12. method according to claim 7 is characterized in that, comprises the GTP series number of the GTP PDU end of information element forwarding in " RLC context transfer " message.

13. method according to claim 1, it is characterized in that, when source ENB decision switches to the another one sub-district to UE, source ENB by to the message " resource request " of purpose ENB application resource the RLC contextual information with there is not the RLC PDUs of affirmation to send to purpose ENB.

14. method according to claim 13 is characterized in that comprising in described " resource request " message information element and does not obtain the RLC PDUs that confirms.

15. method according to claim 13 is characterized in that comprising the SN that information element is used for next RLC PDU in described " resource request " message.

16. method according to claim 13, each does not obtain confirming the SN of RLC PDU to it is characterized in that comprising in described " resource request " message the information element correspondence.

17. method according to claim 13 is characterized in that comprising in described " resource request " message the GTP series number that GTP PDU that information element transmits begins.

18. method according to claim 13 is characterized in that comprising in described " resource request " message the GTP series number that GTP PDU that information element transmits finishes.

19. method according to claim 1 is characterized in that comprising the integrity protection information of information element cell ID, UE sign, Qos, UE, the enciphered message of UE in described " resource request " message.

20. method according to claim 1 is characterized in that comprising in described " resource request " message information element EGGSN IP address.

21. method according to claim 1, it is characterized in that comprising in described " resource request " message information element EGGSN is the user plane sign that UE distributes.

22. method according to claim 21 is characterized in that the information element EGGSN that comprises in described " resource request " message is that the user plane sign that UE distributes is TEID.

23. method according to claim 1 is characterized in that, the Iur interface that comprises information element purpose ENB distribution in the described resource response message is used for the user plane sign of data forwarding.

24. method according to claim 23 is characterized in that, comprising the user plane sign that Iur interface that information element purpose ENB distributes is used for data forwarding in the described resource response message is TEID.

25. method according to claim 1 is characterized in that, comprises information element RRC container in the described resource response message, wherein, comprises purpose ENB among the RRC container and is the configuration of UE assigned radio resource.

26. method according to claim 1 is characterized in that, the user plane that source ENB sets up by " resource request " and " resource response " process sends to purpose ENB to the RLC SDUs that does not also have framing to handle.

27. method according to claim 1 is characterized in that, described source ENB sends to purpose ENB to the RLC SDUs that does not also have framing to handle by control plane.

28. method according to claim 27 is characterized in that, described source ENB sends to purpose ENB to RLC SDUs by " SDU data forwarding " message.

29. method according to claim 28 is characterized in that, comprises the RLC SDUs that information element does not also have framing to handle in described " SDU data forwarding " message.

30., it is characterized in that the user transmits " RLC context transfer " message of RLC PDUs and " SDU data forwarding " message that the user transmits RLC SDUs can be same message according to claim 7 or 28 described methods.

31. method according to claim 1 is characterized in that, described source ENB by user plane the RLC SDUs that does not also have framing to handle with there not be the RLC PDUs of affirmation to send to purpose ENB.

32. method according to claim 31 is characterized in that, to notify purpose ENB be RLC PDU or RLC is SDU to described source ENB by an indicating bit is set in data packet head.

33. method according to claim 31 is characterized in that, source ENB sends to purpose ENB to the series number of RLC PDU correspondence by control plane.

34. method according to claim 31 is characterized in that, source ENB sends to purpose ENB to the series number of RLC PDU correspondence by user plane.

35., it is characterized in that RLC PDU and SN have relation one to one according to claim 33 and 34 described methods.

36. method according to claim 1 is characterized in that, described source ENB by user plane the RLC SDUs that does not confirm RLC PDUs correspondence with there is not the RLC SDUs of framing to send to purpose ENB.

37. method according to claim 1 is characterized in that, described source ENB by one independently " RLC context transfer " message the RLC contextual information is sent to purpose ENB.

38., it is characterized in which segmentation that comprises which RLC SDUs of information element in described " RLC context transfer " message has obtained the affirmation of UE according to the described method of claim 37.

39. according to the described method of claim 37, it is characterized in that, comprise the SN that information element is used for next RLC PDU in described " RLC context transfer " message.

40. according to the described method of claim 37, it is characterized in that, comprise the SN of the corresponding RLC SDU of information element in described " RLC context transfer " message.

41. support the UE mobility method in the LTE system, wherein, UE moves between two ENB, comprises step:

UE switches to new sub-district according to measurement result, and UE sends " handoff request " in new sub-district and gives purpose ENB;

" UP sets up request information and gives EGGSN in purpose ENB transmission;

" the data forwarding request information is given source ENB in purpose ENB transmission;

Source ENB sends " data forwarding response " message and gives purpose ENB;

Purpose ENB distribute resource and receive EGGSN " UP sets up response and " after the message, sends " switch and confirm " message and give UE.

42., it is characterized in that described " handoff request " message comprises IP address or the source ENB sign of source ENB according to the described method of claim 41.

43., it is characterized in that described purpose ENB sends that " UP sets up request information and sends that " the data forwarding request information does not have absolute sequencing for source ENB for EGGSN and purpose ENB according to claim 41 and 42 described methods.

44., it is characterized in that described " UP sets up response " message comprises IP address or the source ENB sign of source ENB according to the described method of claim 41.

45., it is characterized in that described " handoff request " message comprises the Qos information of UE institute access service according to the described method of claim 41.

46., it is characterized in that described " data forwarding response " message comprises the Qos information of UE institute access service according to the described method of claim 41.

47., it is characterized in that described purpose ENB sends that " UP sets up request information and occurs in after " data forwarding response " message that purpose ENB receives that source ENB sends to EGGSN according to claim 41 and 46 described methods.

48., it is characterized in that described " handoff request " message comprises the cell ID of UE sign and new sub-district according to the described method of claim 41.

49., it is characterized in that described source ENB is transmitted to purpose ENB to the RLC SDUs that UE does not also handle framing according to the described method of claim 41.

50., it is characterized in that described source ENB sends to purpose ENB to the RLC PDUs that does not have affirmation by control plane according to the described method of claim 41;

51., it is characterized in that described source ENB sends to purpose ENB to the RLC SDUs that does not also handle framing by user plane according to the described method of claim 41.

52., it is characterized in that described source ENB sends to purpose ENB to the RLC PDUs and the RLC contextual information that do not have to confirm by " data forwarding response " message according to the described method of claim 41.

53. according to the described method of claim 52, it is characterized in that, comprise information element in described " data forwarding response " message and do not obtain the RLC PDUs that confirms.

54. according to the described method of claim 41, it is characterized in that, comprise the SN that information element is used for next RLC PDU in described " data forwarding response " message.

55., it is characterized in that each does not obtain confirming the SN of RLC PDU to comprise the information element correspondence in described " data forwarding response " message according to the described method of claim 52

56. according to the described method of claim 52, it is characterized in that, comprise the GTP series number that GTP PDU that information element transmits begins in described " data forwarding response " message.

57. according to the described method of claim 52, it is characterized in that, comprise the GTP series number of the GTP PDU end of information element forwarding in " data forwarding response " message.

58., it is characterized in that described " comprising information element UE in the data forwarding request information identifies according to the described method of claim 41.

59. according to the described method of claim 41, it is characterized in that, describedly " comprise the user plane sign that Iur interface that information element purpose ENB distributes is used for data forwarding in the data forwarding request information.

60., it is characterized in that described " the user plane sign that the Iur interface that the purpose ENB that comprises in the data forwarding request information distributes is used for data forwarding is TEID according to the described method of claim 59.

61., it is characterized in that the user plane that source ENB sets up by " data forwarding request " and " data forwarding response " process sends to purpose ENB to the RLC SDUs that does not also have framing to handle according to the described method of claim 41.

62., it is characterized in that described source ENB sends to purpose ENB to the RLC SDUs that does not also have framing to handle by control plane according to the described method of claim 41;

63., it is characterized in that described source ENB sends to purpose ENB to RLC SDUs by " SDU data forwarding " message according to the described method of claim 62;

64. according to the described method of claim 63, it is characterized in that, comprise the RLC SDUs that information element does not have framing to handle in described " SDU data forwarding " message.

65., it is characterized in that the user transmits " data forwarding response " message of RLC PDUs and " SDU data forwarding " message that the user transmits RLC SDUs can be same message according to claim 52 or 63 described methods.

66. according to the described method of claim 41, it is characterized in that, described source ENB by user plane the RLC SDUs that does not also have framing to handle with there not be the RLC PDUs of affirmation to send to purpose ENB.

67., it is characterized in that source ENB sends to purpose ENB to the series number of RLC PDU correspondence by control plane according to the described method of claim 66.

68., it is characterized in that source ENB sends to purpose ENB to the series number of RLC PDU correspondence by user plane according to the described method of claim 66.

69., it is characterized in that RLC PDU and SN have relation one to one according to claim 67 and 68 described methods.

70., it is characterized in that to notify purpose ENB be PDU or SDU to described source ENB by an indicating bit is set according to the described method of claim 66 in data packet head.

71. according to the described method of claim 41, it is characterized in that, described source ENB by user plane the RLC SDUs that does not confirm RLC PDUs correspondence with there is not the RLC SDUs of framing to send to purpose ENB.

72., it is characterized in that described " UP sets up and comprises information element ENB IP address in the request information according to the described method of claim 41.

73., it is characterized in that described " UP sets up and comprises information element UE sign in the request information according to the described method of claim 41.

74., it is characterized in that described " UP sets up and comprises the user plane sign that the new ENB of information element distributes in the request information according to the described method of claim 41.

75., it is characterized in that described " the user plane sign that UP sets up the new ENB distribution that comprises in the request information is TEID according to the described method of claim 74.

76. according to the described method of claim 41, it is characterized in that, comprise the user plane sign that the new EGGSN of information element distributes in described " UP sets up response " message.

77., it is characterized in that the user plane sign that the new EGGSN that comprises in described " UP sets up response " message distributes is TEID according to the described method of claim 76.

78., it is characterized in that described source ENB sends to purpose ENB to the RLC contextual information by " data forwarding response " message according to the described method of claim 41.

79., it is characterized in which segmentation that comprises which RLC SDUs of information element in described " RLC context transfer " message has obtained the affirmation of UE according to the described method of claim 78.

80. according to the described method of claim 78, it is characterized in that, comprise the SN that information element is used for next RLC PDU in described " RLC context transfer " message.

81. according to the described method of claim 78, it is characterized in that, comprise the SN of the corresponding RLC SDU of information element in described " RLC context transfer " message.

82., it is characterized in that described source ENB is the also imperfect purpose ENB that is transmitted to of RLC SDUs of the RLC PDUs of the up UE of obtaining affirmation and corresponding these RLC PDUs according to claim 1 and 41 described methods.83. 2 described methods is characterized in that described source ENB sends to purpose ENB to described RLC PDUs by control plane according to Claim 8.

83. 2 described methods is characterized in that described source ENB sends to purpose ENB to described RLC PDUs by control plane according to Claim 8.

84., it is characterized in that described source ENB sends to EGGSN to the complete RLC SDUs that receives according to claim 1 and 41 described methods.

85., it is characterized in that described source ENB does not receive that the complete RLC SDUs that receives is transmitted to purpose ENB after the RLC PDU to up first according to claim 1 and 41 described methods.

86. 5 described methods is characterized in that described source ENB is transmitted to purpose ENB by the RLC SDUs shown in the control plane handle according to Claim 8.

87. 5 described methods is characterized in that described source ENB is transmitted to purpose ENB by the RLC SDUs shown in the user plane handle according to Claim 8.

88. 5 described methods according to Claim 8, but it is characterized in that described source ENB is the imperfect purpose ENB that is transmitted to of RLC SDUs of the up RLC PDUs RLC PDUs correspondence of receiving.

89. 8 described methods is characterized in that described source ENB is transmitted to purpose ENB by the RLC PDUs shown in the control plane handle according to Claim 8.

90. 8 described methods is characterized in that described source ENB is transmitted to purpose ENB by the RLC PDUs shown in the user plane handle according to Claim 8.

91. according to claim 1 and 41 described methods, it is characterized in that described source ENB does not receive all RLC PDUs after the RLC PDU to first, be included in first and do not receive that the RLC PDUs of the complete RLC of receiving SDUs correspondence is transmitted to purpose ENB after the RLC PDU.

92., it is characterized in that described source ENB is transmitted to purpose ENB by the RLC PDUs shown in the control plane handle according to the described method of claim 91.

93., it is characterized in that described source ENB is transmitted to purpose ENB by the RLC PDUs shown in the user plane handle according to the described method of claim 91.

Images