WO2008134978A1 - Procédé de réadressage, système de communication et contrôleur de réseau radio - Google Patents

Procédé de réadressage, système de communication et contrôleur de réseau radio Download PDF

Info

Publication number
WO2008134978A1
WO2008134978A1 PCT/CN2008/070848 CN2008070848W WO2008134978A1 WO 2008134978 A1 WO2008134978 A1 WO 2008134978A1 CN 2008070848 W CN2008070848 W CN 2008070848W WO 2008134978 A1 WO2008134978 A1 WO 2008134978A1
Authority
WO
WIPO (PCT)
Prior art keywords
network controller
radio network
relocation
target
source
Prior art date
Application number
PCT/CN2008/070848
Other languages
English (en)
French (fr)
Inventor
Li Chai
Jie Ma
Xiaoxiao Zheng
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN 200710126759 external-priority patent/CN101299879B/zh
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2008134978A1 publication Critical patent/WO2008134978A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/10—Reselecting an access point controller

Definitions

  • the present invention relates to a communication technology, and in particular, to a relocation method, a communication system, and a wireless network controller. Background technique
  • the core network of the Universal Mobile Telecommunications System (UMTS) (Core Net, CN) is supported by the Mobile Switching Center (MSC) and the General Packet Radio Service Service.
  • UMTS Universal Mobile Telecommunications System
  • MSC Mobile Switching Center
  • General Packet Radio Service Service The General Packet Radio Service Service.
  • the UTRAN includes a radio network controller
  • RNC Radio Network Controller
  • NodeB base station
  • RNS Wireless Network Subsystem
  • the core network is connected to the RNC through the Iu interface.
  • the RNC is connected to the RNC through the Iur port.
  • SRNC/T-RNC was generated due to the introduction of the Iur interface
  • SRNC Service RNC/Drift RNC
  • T-RNC T-RNC of the UE.
  • SRNS relocation is the process of transferring the role of a particular UE's SRNC from one RNC to another.
  • the core network controls the role transition and resource configuration between the RNCs in the network, and the required bearer resources that the SRNC sends to the T-RNC are also forwarded by the core network. Therefore, the relocation process is very complicated and redundant, which makes the relocation process time-delay and inefficient relocation.
  • Embodiments of the present invention provide a relocation method, a communication system, and a radio network controller, which can solve the problem of low relocation efficiency, thereby improving overall network performance.
  • the embodiment of the invention provides a relocation method, including:
  • the target radio network controller receives the relocation request initiated by the source radio network controller, and after receiving the relocation request, initiates a relocation procedure as the main control network element.
  • the embodiment of the invention further provides a communication system, including a target wireless network controller and a source wireless network controller,
  • the target radio network controller is configured to receive a relocation request initiated by the source radio network controller, and establish a radio between the target radio network controller and the user equipment according to the relocation request;
  • the network initiates a relocation " ⁇ " to establish an Iu bearer between the core network and the target radio network controller;
  • the source radio network controller is configured to initiate a relocation request to the target radio network controller.
  • the embodiment of the invention further provides a radio network controller, including:
  • a receiving unit configured to receive a relocation request initiated by a source radio network controller
  • a radio bearer establishing unit configured to establish a radio bearer between the radio network controller and the user equipment according to the relocation request received by the receiving unit;
  • an Iu bearer establishing unit configured to send a relocation report to the core network according to the relocation request received by the receiving unit, to establish an Iu bearer between the core network and the radio network controller.
  • the relocation process is initiated by the RNC as the master network element of the relocation process, which eliminates the steps of forwarding by the core network, thereby reducing the number of signaling interactions and reducing the relocation process.
  • the switching delay increases the success rate of relocation, making the relocation process agile and efficient.
  • Figure 1 shows a relocation process of an embodiment of the present invention
  • 2 shows a relocation process of another embodiment of the present invention
  • FIG. 3 shows a relocation process of still another embodiment of the present invention
  • Figure 4 shows a relocation process of still another embodiment of the present invention
  • Figure 5 shows a relocation process of still another embodiment of the present invention
  • Figure 6 shows a relocation process of another embodiment of the present invention.
  • Figure 7 shows the relocation process of the last embodiment of the present invention
  • Fig. 8 shows a communication system of an embodiment of the present invention. detailed description
  • the serving radio network controller determines that it needs to be relocated, directly interacts with the drift radio network controller, ie, the target RNC, for relocation.
  • the target RNC receives the relocation request initiated by the source RNC; and initiates a relocation process.
  • the target RNC initiates the establishment of the radio bearer between the target RNC and the user equipment, and initiates relocation to the core network.
  • the content of the relocation message is as described in the embodiment, and the following embodiment uses the relocation.
  • the report message is described by taking a relocation report as an example to initiate the establishment of an Iu bearer between the core network and the target RNC.
  • the source RNC determines that the timing of the relocation may be any of the following: business request, movement, and/or load sharing, and of course other factors.
  • the relocation process of the embodiment of the present invention is described below by using various embodiments. Wherein, the overall flow of the relocation process of the present invention is included; four different processes of relocating from the NodeB+ in the Evolved HSPA UTRAN network to the RNC in the UMTS network according to different relocation types; relocation processes in other different situations; The relocation process is relocated by the RNC in the UMTS network to another RNC in the UMTS network.
  • the uplink and downlink data have the following path: the data channel between the UE and the source RNC (also referred to as SRNC in this embodiment); the GTP-U (GPRS tunneling protocol user plane) channel between the SRNC and the SGSN (a tunnel).
  • the source RNC also referred to as SRNC in this embodiment
  • the GTP-U GPRS tunneling protocol user plane
  • Steps 101-102 After the source RNC decides to initiate the relocation for some reason, the RNSAP protocol is used to initiate a relocation request to the T-RNC (also referred to as the target RNC in this embodiment) via the Iur interface.
  • the RNSAP protocol is used to initiate a relocation request to the T-RNC (also referred to as the target RNC in this embodiment) via the Iur interface.
  • the relocation request will also trigger the establishment of the transport of the ALCAP (Access Link Control Application Protocol) of the data of the Iur interface.
  • ALCAP Access Link Control Application Protocol
  • the source RNC stops the uplink and downlink data transmission of the RAB (Radio Access Bearer).
  • the relocation request may include a transparent container of the source RNC to the target RNC, an identifier of the source RNC, and an identifier of the target RNC, and a RAB list to be established, and may also include handover information required by the target side, such as: information of the physical layer wireless link. , physical layer information, etc., and radio bearer resources.
  • the RAB list includes: RABID, transport layer address, user plane information, user plane requirement, PDU (protocol data unit) on the GTP-U, the serial number to be sent in the next direction, and the next step is to be sent from the UE.
  • the uplink PDCP Packet Data Convergence Protocol
  • the container may include specific RRC (Radio Resource Control) configuration information, RRC controlled lower layer radio bearers, RRC controlled transport channel configuration information, and physical layer radio link information.
  • the target RNC configures related radio bearer resources according to the information and its own capabilities, and the radio bearer resources may include mappings of RRC, RLC (Radio Link Control), MAC (Media Access Control), logical channels, and transport channels. The mapping relationship between the physical layer resource and the transport channel, and assigning a new U-RNTI (Temporary Mobile Subscriber Identity) to the UE.
  • RRC Radio Resource Control
  • Step 103-103 after the target RNC configures the mapping relationship between the RRC, the RLC, the MAC, the logical channel and the transport channel, and the mapping between the physical layer resource and the transport channel, initiates a relocation response to the source RNC to notify the source RNC.
  • These containers target RNC to source RNC transparent container
  • the source RNC starts to forward data to the target RNC according to the RAB ID list.
  • a relocation cancellation is initiated to the source RNC.
  • the target RNC may initiate a relocation cancellation to the source RNC, and carry the failure cause value in the relocation cancellation.
  • the relocation process is aborted and rolled back.
  • the parameters configured in the operation ie, still using the old configuration parameters
  • the existing Iu connections on the source RNC can still be used normally.
  • Steps 104-105 according to the type of relocation (such as UE participation, UE does not participate), the target RNC sends UTRAN mobility information to the UE, notifying the UE related UTRAN mobile information and the new U-RNTI to update The UTRAN mobile information of the UE.
  • the type of relocation such as UE participation, UE does not participate
  • the source RNC initiates a radio 7-load reconfiguration, or a physical channel reconfiguration, or transmits a 7-load reconfiguration; after the reconfiguration is completed, returns a corresponding UTRAN mobile information acknowledgement message or an air interface reconfiguration complete message to the target RNC.
  • the T-RNC After the T-RNC sends the air interface message of step 104 (UTRAN mobile information, etc.) or sends the relocation response message of step 103 to the source RNC, the T-RNC resets or reconstructs the RLC (Radio Link Control) entity.
  • the SN Serial Number
  • the UE After receiving the air interface message of the step 104, the UE starts to send the uplink user data to the target RNC; when the T-RNC receives When the UTRAN mobile information acknowledgment message is sent by the UE, the T-RNC may also send downlink data to the UE.
  • Step 106 After the target RNC receives the UTRAN mobile information acknowledgement message or other air interface reconfiguration complete message, the target RNC initiates a relocation report to notify the core network (also referred to as SGSN/MSC) to establish the required resources. Configuration.
  • the core network also referred to as SGSN/MSC
  • the message carries the established RAB list cell (including the service parameter and transport layer address corresponding to each RAB, TEID (Tunnel Terminal Identity), etc.) and the RAB list that fails to be established (including the ID and transport layer address corresponding to each RAB, TEID). Wait) .
  • Steps 107-107 after the SGSN/MSC completes the configuration of the resources required for establishing the Iu bearer, The target RNC initiates a relocation complete (Relocation Complete) and starts to enable the new lu bearer and deletes the old lu bearer. If the lu bearer fails to be established, the relocation failure message is returned, and the message carries the reason for the failure, and the RNC releases the resources configured in the relocation operation.
  • a relocation complete (Relocation Complete) and starts to enable the new lu bearer and deletes the old lu bearer. If the lu bearer fails to be established, the relocation failure message is returned, and the message carries the reason for the failure, and the RNC releases the resources configured in the relocation operation.
  • the SGSN/MSC initiates a Relocation Complete message to the target RNC and starts to enable the new lu bearer and deletes the old lu bearer, then the lu bearer between the target RNC and the SGSN/MSC is successfully established.
  • the RAB established on the RNC, the target RNC receives the downlink packets from the SGSN and the SRNC at the same time.
  • Step 108 Whether the core network initiates relocation completion to the target RNC, or initiates relocation failure, the target RNC sends a lu release command (lu release command) to the source RNC, indicating that the source RNC can release the lu connection with the core network.
  • a lu release command (lu release command)
  • Step 109 The SRNC sends a lu release completion message to the SGSN/MSC.
  • a relocation report and a relocation response need to be defined, which are sent by the target RNC to the core network to notify the core network to allocate the relocated resources:
  • the relocation report mainly includes: a list of RABs established in the drift RNC, which may include a RAB ID (Radio Access Bearer Identity), a transport layer address of the RAB, and an Iu transport association. ; related RAB parameter items; a list of RABs of the original serving RNC that are not supported in the drift RNC, which may include RAB IDs, and reasons for unsupported; integrity protection information; and encrypted information.
  • RAB ID Radio Access Bearer Identity
  • RAB ID Radio Access Bearer Identity
  • the relocation request of step 101 can be defined in the 25.423 RNSAP protocol, and the destination address of the message is modified, that is, the destination address CN is modified to be a drift RNC.
  • the contents of the relocation request are shown in Table 2.
  • Source RNC To Target M 9.2.1.28 YES Reject RNC Transparent Container (Resource RNC to target RNC
  • PDP type information (such as ⁇
  • the next downstream IE to be sent needs to be relocated.
  • the source wireless network is used.
  • the next upstream IE to be sent needs to be relocated.
  • the source wireless network is used.
  • the next downlink PDCP IE to be sent needs to be relocated.
  • the next upstream PDCP IE to be sent needs to be relocated.
  • Integrity Protection O (optional) 9.2.1.11 If the integrity protection packet YES (Yes) Ignore Information with key and allowed algorithm (ignored) integrity protection information
  • Encryption Information O (optional) 9.2.1.12 If the encrypted information contains a key YES (Yes) Ignore Encrypted information and allowed algorithms (ignored)
  • step 103 which may be defined in the 25.423 RNSAP protocol, for the target RNC to send the target RNC to the source RNC transparent container to the source RNC, so that the source RNC determines whether to send the air interface reconfiguration information to the UE:
  • step 107 which can be defined in the 25.413 RANAP protocol
  • the cell carried in the message can be unchanged, and the source address and the destination address of the message are respectively modified, that is, The source address D-RNC is modified to CN, and the destination address CN is modified to D-RNC.
  • the transmission direction of the message becomes: CN->D-RNC.
  • the relocation process is initiated by the RNC as the main control network element of the relocation process, and the RNC directly establishes a radio bearer and a radio access bearer, thereby eliminating the steps of forwarding by the core network, thereby reducing
  • the number of signaling interactions reduces the handover delay caused by the relocation process and increases the success rate of relocation, making the relocation process compact and efficient.
  • the relocation process is another embodiment of the present invention.
  • the SRNC of the UE is the NodeB+ in the Evolved HSPA UTRAN network, and the retargeting target RNC of the UE is in the UMTS network.
  • RNC where NodeB+ has a signaling connection with the circuit domain core network, and NodeB+ and RNC are connected through the Iur port.
  • the NodeB+ supports CS.
  • the traditional network of services RNC completes the relocation process. The relocation process is described below.
  • Step 201-203 When the UE initiates a CS call in the cell CELL controlled by the NodeB+, the NodeB+ may determine that the service belongs to the CS domain according to the content of the message when receiving the initial Direct Transfer message, and The CS service cannot be supported. Therefore, the NodeB+ initiates the initial UE message to the MSC through the signaling interface of the Iu-CS, and triggers the handover from the Evolved HSPA UTRAN network to the legacy network supporting the CS service. After receiving the initial UE message, the MSC will reply. SCCP connection confirmation message.
  • the uplink and downlink data has the following path: a data channel between the UE and the SRNC; a GTP-U channel between the SRNC and the SGSN, and a GTP-U channel between the SGSN and the GGSN.
  • the RNC if the RNC receives the RAB setup request message, it will cache the message content until the RNC completes the role transition and processes the message.
  • Step 204 Perform a relocation request from the Evolved HSPA UTRAN network to the traditional network supporting the CS service, and use the RNSAP protocol to send a relocation request to the target RNC via the Iur interface.
  • the relocation request carries the information of the physical layer, and sets the relocation type in the container to "undefined".
  • Steps 205-206 the RNC finds that the relocation type in the container of the relocation request is undefined; and according to its own capability, determines whether the configuration in the container in the relocation request (source RNC to the target RNC transparent container) can be accepted, if not supported. Then, the RL (Radio Link) establishment process is triggered, and the establishment process of the ALCAP transmission bearer of the data of the Iur interface of the transport layer is triggered. Then, the NodeB+, that is, the SRNC, updates the resource configuration according to the RL establishment request sent by the RNC. And send an RL establishment response to the RNC.
  • the NodeB+ in this embodiment and the following embodiments refers to the SRNC unless otherwise specified.
  • the RNC can support the configuration in the container, it only triggers the establishment process of the ALCAP transport bearer of the data of the Iur interface of the transport layer.
  • Steps 207-207 after the target RNC configures the mapping relationship between the RRC, the RLC, the MAC, the logical channel and the transport channel, and the mapping relationship between the physical layer resource and the transport channel, initiates a re-establishment to the source RNC.
  • the bit response is to inform the source RNC of these containers (target RNC to source RNC transparent container) established on the target RNC and the RAB ID list that needs to be forwarded.
  • the source RNC starts to forward data to the target RNC according to the RAB ID list.
  • the RNC finds that the relocation type in the container in the relocation request is undefined, and when responding to the NodeB+, the target RNC to the source NodeB+ container item (the target RNC to the source RNC transparent container) is set as mandatory, and in the RRC CONTAINER Add a UTRAN MOBILITY INFORMATION.
  • the target RNC cannot support SRNS relocation or an exception occurs during configuration, such as resource limitation, a relocation cancellation is initiated to the source RNC. If the RNC's capability can accept the configuration in the container in the relocation request (source RNC to the target RNC transparent container) during configuration, the UTRAN mobile information cell in the container is constructed; if not, the result is filled according to the configuration result. Radio load reconfiguration, or physical channel reconfiguration, or transmission 7-load reconfiguration.
  • Step 208-209 when the NodeB+ obtains the response of the RNC, the NodeB+ initiates UTRAN mobile information, radio bearer reconfiguration, physical channel reconfiguration, and transmission according to the content in the "target RNC to the source RNC transparent container" in the relocation response. 7
  • the RNC After the RNC initiates the relocation response, the RNC resets/reestablishes the RLC entity, and exchanges the PDCP SN (PDCP-SND, PDCP-SNU) between the RNC and the UE.
  • the RNC After the RNC receives the air interface message, the UE starts to send the uplink user data to the RNC.
  • the UE sends a UTRAN mobile information acknowledgement message or other air interface acknowledgment message (wireless 7 reconfiguration complete, physical channel reconfiguration complete, transmission 7 load reconfiguration complete), the UE may also receive downlink data sent by the RNC.
  • Step 210 After the RNC receives the UTRAN mobile information acknowledgement message or other air interface reconfiguration complete message, the target RNC initiates a relocation report by initiating a relocation report, and the process of initiating the relocation report is as shown in FIG. The description of step 106 in .
  • Steps 211-211 after the SGSN completes the configuration of the required resources for establishing the Iu bearer, initiates a relocation complete (Relocation Complete) to the target RNC, and the process of initiating the relocation is completed in the embodiment of FIG. The description of step 107.
  • relocation Complete Relocation Complete
  • Step 212 see the description of step 108 in one embodiment of FIG. Step 213:
  • the NodeB+ sends an Iu release complete message to the SGSN, and the relocation process ends.
  • Steps 214-215 the service establishment process: starting the radio access bearer establishment process of the CS service and the call establishment process of the CS service.
  • steps 208-209 it can be seen that if the content in the "target RNC to source RNC transparent container" is UTRAN mobile information, the "target RNC to source RNC transparent container” is not sent to the RNC, and The NodeB+ initiates UTRAN mobility information to the UE. The RNC then only sends three types of messages: radio bearer, or physical channel reconfiguration, or 7-carrier reconfiguration.
  • Steps 208-209" may also be: NodeB+ sends the content in the "target RNC to the source RNC transparent container" in the relocation response to the RNC; then the RNC sends four messages: UTRAN mobile information, or radio bearer weight With the allocation, or physical channel reconfiguration, or transmission bearer reconfiguration, the RNC initiates UTRAN mobility information to the UE.
  • the RNC when the relocation type in the container is "undefined", the RNC is used as the main control network element, and the radio access bearer and the radio bearer are configured in two steps, so that the handover caused by the relocation process is performed.
  • the delay is effectively reduced, and the number of signaling interactions is also greatly reduced, making the relocation process compact and efficient.
  • FIG. 3 it is a relocation process according to still another embodiment of the present invention.
  • the difference between the embodiment and the embodiment shown in FIG. 2 is:
  • This embodiment is a relocation process for the case where the relocation type is not involved by the UE. Specifically, the difference is as follows:
  • Steps 301-303 are the same as steps 201-203 of the embodiment shown in FIG. 2, and details are not described herein again.
  • Step 304 is substantially the same as step 204. The difference is that: the relocation request of step 304 carries the information of the physical layer, and sets the relocation type in the container to "undefined".
  • the relocation type in the container is UE-involved (UE INVOLVED)
  • the establishment process of the RL radio link
  • the transport bearer of the ALCAP of the data of the lur port is established at the same time;
  • the RNC may not support the functions configured by the UE on the NodeB+.
  • the RNC may establish an RL according to its own capabilities, which may be different from the configuration in the source RNC to Target RNC Transparent Container.
  • the NodeB+ sends an RL establishment request according to the RNC, updates the resource configuration, and sends an RL establishment response to the RNC.
  • the NodeB+ After receiving the response message, the NodeB+ first sends a message (this message can be called SRNS context forward) to inform the target RNC: the PDU (Protocol Data Unit) on the GTP-U, the serial number to be sent in the next direction, the next step.
  • the uplink PDCP Packet Data Convergence Protocol
  • the forwarded data is the downlink GTP-PDU received from the SGSN, and the GTP-PDU backup is also reserved on the NodeB+.
  • This forwarding is applicable to any type of migration; for the uplink decrypted data packet received from the UE It can also be forwarded, which can prevent the UE from retransmitting a lot of data.
  • the downlink data needs to be forwarded, and the uplink data may not be forwarded.
  • the data can be processed as follows: For GTP-PDUs that are not sent by the RLC layer, the GTP-PDUs are forwarded; if the GTP-PDUs are subjected to header compression, some parts of the GLC-PDUs have been sent after processing, and then Forward GTP-PDUs and/or split or concatenated RLC PDUs.
  • Steps 307-307 see the description of steps 103-103 in one embodiment of FIG.
  • Steps 308-309 if the relocation type is a relocation that the UE does not participate in, the RNC initiates a UTRAN mobile information update procedure to the UE, notifying the UE of the relevant UTRAN mobile information and the new U-RNTI. If the UE is involved in relocation, the NodeB+ determines to initiate radio bearer reconfiguration, physical channel reconfiguration, and transmission to the UE according to the content in the target RNC in the relocation response to the source RNC transparent container (the target RNC to the source RNC transparent container). Carrying reconfiguration.
  • Steps 310-315 are the same as steps 210-215, and are not described again.
  • the triggering process of the relocation of this embodiment differs from the previous embodiment in that:
  • Steps 304 are replaced by:, from the Evolved HSPA UTRAN network to the traditional network supporting the CS service, using the RNSAP protocol to initiate a relocation request to the target RNC via the Iur interface, and the process of initiating the relocation request is shown in FIG. Steps 101-102 in the embodiment;
  • the cause value (cause) carried in the relocation request is "Single Carrier controlled by two RNC”
  • the CAUSE value is The relocation type (RELOCATION TYPE) in the container is not considered; and if the cause value is "Single Carrier controlled by two RNC", the information of the physical layer is carried in the request.
  • RNC finds that the cause value notified in the relocation request is "Single Carrier controlled by two RNC", and judges whether it can accept the container in the relocation request according to its own capabilities (source RNC to target RNC transparent container) In the configuration, if it is not supported, it needs to trigger the establishment process of the RL (Radio Link) and trigger the establishment process of the ALCAP transport bearer of the data of the Iur interface of the transport layer. Then, the NodeB+ sends an RL establishment request according to the RNC. Update the resource configuration and send an RL setup response to the RNC. If the RNC can support the configuration in the container, only the establishment process of the ALCAP transport bearer of the data of the Iur interface of the transport layer may be triggered.
  • RL Radio Link
  • RNC finds that the cause value notified in the relocation request is "Single Carrier controlled by two RNC", then when the relocation response is initiated to NodeB+, if the RNC can support the configuration in the container, then Does not carry the target RNC to the source RNC transparent container, and initiates UTRAN mobility information to the UE; if not, constructs the radio bearer reconfiguration, or physical channel reconfiguration, or transmission in the target RNC to the source RNC transparent container according to the configured result. Carry reconfiguration information.
  • Steps 308-309 "Replace: When the NodeB+ receives the response from the RNC, the data is forwarded according to the RAB list that needs to be forwarded in the response. If the relocation response carries the target RNC to the source RNC transparent container, the NodeB+ is based on the container. Information determines to initiate radio bearer reconfiguration to the UE, Physical channel reconfiguration, transmission 7-load reconfiguration.
  • the target RNC resets or reconstructs the RLC (Radio Link Control) entity after transmitting the relocation response, and exchanges the SN (Serial Number) of the PDCP between the target RNC and the UE, such as PDCP- SND, PDCP-SNU;
  • the UE After receiving the air interface message, the UE starts to send uplink user data to the target RNC; when the DRNC receives the UTRAN mobile information acknowledgement message sent by the UE, the DRNC may also send downlink data to the UE.
  • the embodiments of this embodiment can implement different processes of relocating from the NodeB+ in the Evolved HSPA UTRAN network to the RNC in the UMTS network according to different relocation types; the number of signaling interactions can be reduced, the handover delay can be reduced, and the relocation can be increased.
  • the success rate makes the relocation process agile and efficient.
  • FIG. 4 it is a relocation process according to still another embodiment of the present invention.
  • a scenario in which an RNC of a UMTS network and a NodeB+ of an evolved HSPA carrier sharing network are connected through an Iur port are described. Control is the same cell. It is also assumed that the SRNC of the UE is the NodeB+ in the Evolved HSPA UTRAN network, and the T-RNC of the UE is the RNC in the UMTS network. The NodeB+ and the RNC are connected through the Iur port, and there is no Iu-cs signaling connection between the NodeB+ and the MSC.
  • the NodeB+ performs a process of relocating to the RNC of the legacy network supporting the CS service.
  • the relocation process is described below.
  • Step 601 When the UE initiates a CS call under the NodeB+ controlled cell CELL, when the NodeB+ receives the initial direct transmission message, triggering handover from the Evolved HSPA UTRAN network to the traditional network supporting the CS service.
  • Steps 602-603 first initiates a radio link setup request to the RNC, and triggers the establishment process of the ALCAP transport bearer of the data of the Iur interface of the transport layer, and the RNC initiates a radio link setup response to the NodeB+, and the RNC saves the UE.
  • the configuration parameters of the physical layer radio link do not really establish a radio link on the NodeB+ (because this radio link already exists).
  • Steps 604-605 The NodeB+ initiates a relocation request to the target RNC of the traditional network through the Iur interface.
  • NodeB+ In addition to telling the RNC source RNC to the target RNC transparent container, NodeB+ also carries the initial straight The NAS (Non-Access Stratum) PDU (Protocol Data Unit) carried in the message and the information necessary for the establishment of the CS connection.
  • the RNC will respond to the NodeB+ relocation request procedure, as described in steps 101-102 in one embodiment of FIG.
  • Steps A, B, and C After step 604, the RNC sends the initial direct transmission information to the MSC in parallel. After the MSC allocates the resource, it will reply the direct transmission message to the target RNC. If the direct transmission message is in the air interface information (UTRAN mobile information confirmation message) If the RB bearer reconfiguration completes before reaching, the RNC caches the NAS information in the direct transmission message.
  • the MSC allocates the resource
  • the RNC will reply the direct transmission message to the target RNC. If the direct transmission message is in the air interface information (UTRAN mobile information confirmation message) If the RB bearer reconfiguration completes before reaching, the RNC caches the NAS information in the direct transmission message.
  • Steps 606-607 see the description of steps 104-105 in one embodiment of FIG.
  • Step D When receiving the UTRAN mobile information acknowledgement message from the UE, the traditional RNC transition role becomes the SRNC of the UE. The RNC sends the received direct transmission information to the UE through the downlink direct transmission message.
  • the RNC initiates a relocation report message to the core network (MSC/SGSN) to notify the core network (MSC/SGSN) to configure the resources required for establishing the Iu bearer with the legacy RNC.
  • the parameters can include the RAB list to be established by the traditional RNC and the unsupported RAB list, the new transport layer address and the new Iu-association.
  • the core network first saves the resources necessary for the traditional RNC to build.
  • the RNC will then initiate a relocation command to inform NodeB+ to begin the data forwarding process.
  • Step 610 The core network will initiate relocation and use the new Iu user plane.
  • the RNC informs NodeB+ to start the data forwarding process by relocating the command message.
  • Step 611 The core network will initiate an Iu release command to the NodeB+ to release the Iu connection and related resources.
  • Steps 612-613 When the original Iu connection is released, the SRNC relocation process ends. The CS call setup will proceed normally.
  • the relocation command needs to be modified, the cell of the message remains unchanged, and the command is moved from the Iu port to the Iur port, that is, from the 25.413 RANAP protocol to the 25.423 RASAP, and the path is re-modified. Moved from CN->S-RNC to D-RNC->S-RNC.
  • the RNC when the wireless link already exists, the RNC does not need to actually establish In the wireless link on the NodeB+, the RNC is directly used as the master control network element, and the handover delay caused by the relocation process is effectively reduced by means of the two-step configuration of the radio access bearer and the radio bearer. The number of interactions is also greatly reduced, increasing the success rate of relocation, making the relocation process agile and efficient.
  • the SRNC of the UE is the NodeB+ of the Evolved HSPA UTRAN network
  • the T-RNC of the UE is the RNC of the UMTS network
  • the UE There is a PS service connection with NodeB+.
  • NodeB+ is not connected to the core network of the circuit domain.
  • the relocation process is characterized by simultaneous establishment of a radio access bearer (Iu bearer) and a radio bearer (air port bearer). The relocation process is described below.
  • Steps 701-702 The NodeB+ receives the initial direct transmission message sent by the UE, and determines to establish the CS service according to the initial direct transmission message. Since NodeB+ itself cannot support CS services, it triggers the handover from the Evolved HSPA UTRAN network to the traditional network supporting CS services.
  • the NodeB+ initiates a relocation request to the RNC through the lur interface, and the relocation request includes the content as in Embodiment 1.
  • the RNC that receives the relocation request message configures the RRC, MAC, RLC resources and channel mapping relationship according to the information carried in the relocation message.
  • Step 703 The NodeB+ initiates a relocation necessary message to the SGSN, where the relocation necessary message may include information necessary for establishing the NAS PDU and the CS connection carried in the initial direct transmission message, and does not include a transparent container of the NodeB+ to the RNC, and the SGSN receives the message. After the message, prepare a new PS connection to be established.
  • Steps 704-705 After the RNC completes the configuration, the RNC initiates a relocation report to the SGSN, notifies the SGSN to perform resource configuration required for the new Iu, and starts to establish the II bearer; on the other hand, initiates a relocation response message or lur to the NodeB+.
  • the link setup/wireless link setup response process indicates that the establishment of the transport bearer has been completed.
  • Steps 706-709 The RNC sends a UTRAN mobile information message to the UE, and notifies the UE of the relevant UTRAN mobile information and the new U-RNTI.
  • the RNC also sends initial UE information to the MSC. After receiving the initial UE information, the MSC will reply the direct message to the RNC. At this time, if the direct transmission message is When the UE arrives before the response, the RNC caches the information; when receiving the UTRAN mobile information acknowledgement message from the UE, the legacy RNC transition role becomes the SRNC of the UE.
  • Step 710 The RNC sends the received direct transmission information to the UE by using a downlink direct transmission message.
  • Step 711 The SGSN notifies the NodeB+ to start the data sending process by using a relocation command.
  • Step 712 The SGSN will initiate a lu connection release command, triggering the NodeB+ to release the lu connection and related resources.
  • Steps 713-714 When the original lu connection is released, the RNC relocation process ends. The CS call setup will proceed normally.
  • the NodeB+ when the NodeB+ is not connected to the core network of the circuit domain, the NodeB+ sends a relocation necessary message that does not include the transparent container of the NodeB+ to the RNC to the SGSN to establish a PS connection, and the RNC completes the configuration to establish a lu bearer.
  • the establishment of simultaneous radio bearer (lu bearer) and radio bearer (air bearer bearer) is realized.
  • This embodiment can reduce the number of signaling interactions, reduce the handover delay, and increase the success rate of relocation, so that the relocation process is fast and efficient.
  • the relocation procedure is another embodiment of the present invention.
  • the T-RNC of the UE is the NodeB+ of the Evolved HSPA UTRAN network
  • the SRNC of the UE is the RNC in the UMTS network
  • the relocation process is described below.
  • Steps 801-802 The RNC initiates a radio link establishment request to the target NodeB+ of the traditional network through the Iur port, and then the NodeB+ returns a radio link setup response to the RNC.
  • Step 803 After receiving the radio link setup response sent by the NodeB+, the RNC initiates a relocation request to the NodeB+ via the Iur interface by using the RNSAP protocol.
  • the NodeB+ that receives the relocation request configures the RRC, MAC, RLC resources and channel mapping relationship according to the information carried in the request, and allocates a new U-RNTI to the UE.
  • Steps 804-805 The NodeB+ sends a UTRAN mobile information message to the UE, and notifies the UE of the relevant UTRAN mobile information and the new U-RNTI. After receiving the UTRAN mobile information message, the UE records the content in the message and returns a UTRAN mobile information confirmation message to the NodeB+.
  • Steps 806-807 After the NodeB+ receives the UTRAN mobile information acknowledgement message, the exchange of the roles of the NodeB+ and the RNC has been completed, and the NodeB+ initiates a relocation report to the SGSN to notify the SGSN to configure the required resources of the Iu bearer.
  • the NodeB+ initiates a relocation report to the MSC to inform the MSC to configure the required resources for the Iu bearer. If the SGSN to which the NodeB+ is connected is not the SGSN to which the RNC is connected, the NodeB+ can still send a relocation report.
  • the message carries only the RAB list to be established, and the RAB list to be deleted is not carried, and the GTP corresponding to the uplink and downlink corresponding to the RAB is also carried. -U serial number.
  • Steps 808-809 After the SGSN and the MSC complete the configuration of the required resources for establishing the Iu bearer, respectively, the relocation is initiated to the NodeB+, and the Iu bearer between the NodeB+ and the SGSN and the Iu bearer between the NodeB+ and the MSC are established. success.
  • Step 810 The NodeB+ initiates a relocation command to the RNC, and notifies the RNC to release its Iu connection with the core network and related resources. After receiving the relocation command, the RNC starts the GTP-U forwarding. Then NodB+ will receive GTP-U data from the RNC and the core network.
  • Steps 811-812 After the data forwarding is completed, the RNC initiates the release of the Iu to the SGSN and the MSC, respectively, and releases the Iu connection and related resources. At this point, the relocation process ends.
  • This embodiment can implement the relocation process caused by the UE due to movement/load and the like.
  • the number of signaling interactions can be reduced, the handover delay can be reduced, and the success rate of relocation can be increased, so that the relocation process is efficient and efficient.
  • the relocation process is the last embodiment of the present invention; the flow of this embodiment is in addition to steps 904-905 (for convenience of description, the flowchart does not have step 906), and other steps (steps 901-903, And steps 907-915) are the same as the other steps (steps 301-303, and steps 307-315) of yet another embodiment shown in FIG.
  • step 904-905 when the NodeB+ decides to initiate the relocation, the RNSAP protocol is used to initiate a relocation request to the target RNC via the Iur interface.
  • the relocation request message is implemented in addition to one.
  • the information of the Iur link establishment may also be included. Therefore, in the present embodiment, the step of the Iur link establishment request between the NodeB and the RNC is omitted (ie, step 906).
  • the target RNC configures an embodiment other than FIG.
  • resources are also allocated for the dedicated link and user plane of the Iur port, and a response is established to the NodeB+ in response to the Iur link. If the allocation fails, the direct relocation is canceled.
  • the relocation message of this embodiment further includes the information of the Iur link establishment, so the step of the Iur link establishment request between the NodeB and the RNC is omitted, so the relocation process is further compressed; this embodiment can reduce the letter. The number of interactions is reduced, the handover delay is reduced, and the success rate of relocation is increased, so that the relocation process is efficient and efficient.
  • this embodiment describes a communication system including a target radio network controller 1, and a source radio network controller 2.
  • the target radio network controller 1 is configured to receive a relocation request initiated by the source radio network controller 2, to initiate establishment of a radio bearer between the target radio network controller and the user equipment, and initiate a relocation report to the core network, to Initiating establishment of an Iu bearer between the core network and the target radio network controller.
  • the target radio network controller 1 may specifically include: a receiving unit 11 configured to receive a relocation request initiated by the source radio network controller 2, and a radio bearer establishing unit 12 configured to establish a radio network control according to the relocation request received by the receiving unit 11
  • the Iu bearer establishing unit 13 is configured to initiate a relocation message to the core network to establish an Iu bearer between the core network and the radio network controller;
  • the first forwarding unit 15 is configured to: when receiving the Iu release command, release the resource between the radio network controller and the core network; and the data forwarding unit 16 is configured to send a relocation request to the other target radio network controller.
  • Other target radio network controllers forward intermediate data.
  • the source radio network controller 2 is configured to initiate a relocation request to the target radio network controller 1.
  • the source radio network controller 2 includes: an initiating unit 21, configured to initiate a relocation request message to other target radio network controllers; and a data forwarding unit 22, configured to forward the intermediate, second release unit 23 to other target radio network controllers, When receiving the Iu release command sent by the core network or the target wireless network control, the resources between the source radio network controller 2 and the core network are released.
  • the source radio network controller 2 is an enhanced base station or a radio network controller
  • the target radio network controller 1 is an enhanced base station or a radio network controller.
  • the main control role of the core network in the past relocation process is changed, that is, the role conversion and resource configuration between the RNCs in the core network control network, and the transparent forwarding of the SRNC to the T-RNC are required. Inefficient technology such as carrying resources.
  • the RNC is used as the main control network element (physical network element or logical network element), and the wireless access bearer and the radio bearer are configured in two steps, so that the relocation process is caused.
  • the handover delay is effectively reduced, the signaling process interaction is reduced, and the success rate is also increased.
  • the problem of complicated and redundant processes of the existing relocation process is effectively solved.
  • the relocation technology of the embodiment of the present invention is used to improve the performance of the communication network system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

重定位方法、 通信系统及无线网络控制器
技术领域
本发明涉及一种通信技术， 尤其涉及一种重定位方法、 通信系统及无 线网络控制器。 背景技术
通用移动电信系统（UMTS ) 的核心网 （Core Net, CN ) 由移动交换中 心 ( Mobile Switching Center, MSC ) 和通用分组无线业务服务支持节点
( Serving GPRS Support Node , SGSN )组成。 用户设备 ( UE )和核心网之间 由通用地面无线接入网 （UTRAN )相连。 所述 UTRAN包括无线网络控制器
( Radio Network Controller, RNC )和基站（NodeB ) ， 其中， RNC与其所控 制的 NodeB组成 RNS (无线网络子系统） 。 核心网通过 Iu接口连接到 RNC。 RNC与 RNC之间通过 Iur口相连。 由于 Iur接口的引入而产生了 SRNC/T-RNC
(服务 RNC/漂移 RNC ) 的概念， 对于某一个 UE来说， 直接与核心网相连并 对 UE的所有资源进行控制的 RNC叫该 UE的 SRNC。 而与 CN没有连接， 仅为 UE提供资源的 RNC叫该 UE的 T-RNC。 SRNS重定位就是将特定 UE的 SRNC的 角色由一个 RNC转到另外一个 RNC的过程。
在实现本发明的过程中， 发明人发现：
在现有技术的重定位过程中， 由核心网控制网络中 RNC之间角色的转换 和资源的配置， SRNC发给 T-RNC的所需的承载资源也是由核心网转发。因此， 重定位流程很是复杂和冗余， 这使得重定位的流程时延大， 重定位效率低下。
尤其是对于 HSPA+网络， 由于该网络不支持电路域（CS )业务， 当有 CS 建立时， 需要从 HSPA+网络中的 NodeB+ (增强基站， Evolved HSPA Node B , 其包括 RNC和 NodeB )重定位到 UMTS网络中的 RNC, 以通过 UMTS网络中的 RNC提供 CS业务。 又因 CS业务经常发生， 使得重定位发生频率较高， 因此， 现有技术中较低的重定位效率会严重降低整个网络性能。 发明内容
本发明的实施例提供了一种重定位方法、 通信系统及无线网络控制器， 可解决重定位效率较低的问题， 从而提高整个网络性能。
本发明实施例提供了一种重定位方法， 包括：
目标无线网络控制器接收源无线网络控制器发起的重定位请求， 并在收 到所述重定位请求后， 作为主控制网元发起重定位流程。
本发明实施例还提供了一种通信系统， 包括目标无线网络控制器和源无 线网络控制器，
所述目标无线网络控制器， 用于接收源无线网络控制器发起的重定位请 求， 根据所述重定位请求建立所述目标无线网络控制器到用户设备之间的无 线^^载； 并向核心网发起重定位"^艮告， 以建立核心网至所述目标无线网络控 制器之间的 Iu承载；
所述源无线网络控制器用于向目标无线网络控制器发起重定位请求。 本发明实施例还提供了一种无线网络控制器， 包括：
接收单元， 用于接收源无线网络控制器发起的重定位请求；
无线承载建立单元， 用于根据所述接收单元接收的重定位请求建立无线 网络控制器与用户设备之间的无线承载；
Iu承载建立单元， 用于根据所述接收单元接收的重定位请求向核心网发 起重定位报告， 以建立核心网至所述无线网络控制器之间的 Iu承载。
根据本发明的实施例， 通过 RNC作为重定位流程的主控网元发起重定位 流程， 省去了由核心网转发的步骤， 从而减少了信令交互的次数， 减少了由 重定位流程导致的切换时延， 增加了重定位的成功率， 使得重定位过程筒捷 而高效。 附图说明
图 1示出了本发明一个实施例的重定位流程; 图 2示出了本发明另一个实施例的重定位流程；
图 3示出了本发明还一个实施例的重定位流程；
图 4示出了本发明又一个实施例的重定位流程；
图 5示出了本发明再一个实施例的重定位流程；
图 6示出了本发明另外一个实施例的重定位流程；
图 7示出了本发明最后一个实施例的重定位流程；
图 8示出了本发明实施例的通信系统。 具体实施方式
为了便于本领域一般技术人员理解和实现本发明， 现结合附图描绘本发 明的实施例。
根据本发明实施例， 服务无线网络控制器， 即源 RNC确定需要进行重定 位后， 直接与漂移无线网络控制器， 即目标 RNC交互以进行重定位。 具体而 言， 目标 RNC接收源 RNC发起的重定位请求； 并发起重定位流程。 具体可以 是目标 RNC发起目标 RNC至用户设备之间无线承载的建立， 并向核心网发起 重定位 4艮告（重定位 4艮告消息的内容参见实施例中的描述， 下面实施例以重 定位报告消息来承载重定位报告为例进行描述） ， 以发起核心网至目标 RNC 之间 Iu承载的建立。 所述源 RNC确定重定位的时机可以是下列任一因素： 业 务请求、 移动和 /或负荷分担， 当然也可以是其他因素。
下面通过各个实施例描述本发明实施例的重定位流程。 其中， 包括本发 明重定位流程的总的流程； 根据不同的重定位类型由 Evolved HSPA UTRAN 网络中的 NodeB+重定位到 UMTS网络中的 RNC的四种不同流程； 其它不同情 况的重定位流程；以及由 UMTS网络中的 RNC重定位到 UMTS网络中另一 RNC 的重定位流程。
如图 1所示， 为本发明一个实施例的重定位流程； 本实施例描述本发明的 重定位过程。 在重定位前， 上下行数据存在以下路径： UE和源 RNC (在本实施例中也 称作 SRNC )之间的数据通道； SRNC和 SGSN之间的 GTP-U ( GPRS隧道协议 用户面）通道 (一种隧道 ) 。
步骤 101-102、 当源 RNC由于某种原因决定发起重定位后， 利用 RNSAP 协议经 Iur接口向 T-RNC (在本实施例中也称作目标 RNC )发起重定位请求 ( Relocation Request ) 。
如果 Iur的面向连接的链路不存在， 重定位请求还会触发 Iur口的数据的 ALCAP (接入链路控制应用协议）的传输 载的建立。 此时源 RNC停止 RAB (无线接入承载） 的上行和下行的数据传输。
所述重定位请求可以包含源 RNC到目标 RNC的透明容器、 源 RNC的标识 和目标 RNC的标识、 需要建立的 RAB列表， 还可以包括目标侧需要的切换信 息如： 物理层无线链路的信息、 物理层信息等， 和无线承载资源。 所述 RAB 列表中包括： RABID, 传输层地址， 用户面信息， 用户面的需要 GTP-U上的 PDU (协议数据单元）上下行方向下一步分别要发送的序列号， 下一步将要 从 UE上接到的上行的 PDCP (分组数据会聚协议）序列号以及将要发送给 UE 的下行 PDCP序列号。 所述容器可以包括具体的 RRC (无线资源控制）的配置 信息、 RRC控制的下层无线承载、 RRC控制的传输信道的配置信息、 物理层 无线链路的信息。 目标 RNC会根据这些信息和自身的能力来配置相关无线承 载资源， 所述无线承载资源可以包括 RRC、 RLC (无线链路控制）、 MAC (媒 体接入控制） 、 逻辑信道和传输信道的映射关系、 物理层资源和传输信道的 映射关系， 并给 UE分配一个新的 U-RNTI (临时移动用户标识 ) 。
步骤 103-103，、 当目标 RNC配置完 RRC、 RLC, MAC, 逻辑信道和传输 信道的映射关系、 物理层资源和传输信道的映射关系后， 向源 RNC发起重定 位响应， 以告知源 RNC—个目标 RNC上建立的这些容器（目标 RNC到源 RNC 透明容器）和需要进行数据转发的 RAB ID列表， 源 RNC会根据这个 RAB ID 列表开始向目标 RNC转发数据。 在本实施例中， 为了使源 RNC向目标 RNC直 接转发数据， 可以在 Iur口 U-Plane (用户面）上增加 GTP-U的协议解析。
如果目标 RNC不能支持 SRNS重定位或者在配置过程中出现了异常，如资 源受限等， 则会向源 RNC发起重定位取消。 为了实现重定位取消过程， 目标 RNC可向源 RNC发起重定位取消， 在所述重定位取消中携带失败原因值， 当 源 RNC收到重定位取消时， 中止本次重定位过程， 并回滚在操作中配置的参 数（即， 仍使用旧的配置参数） ， 源 RNC上已经存在的 Iu连接仍然可以正常 使用。
步骤 104-105，、 根据重定位的类型 （如 UE参与的、 UE不参与的） ， 由目 标 RNC向 UE发送 UTRAN移动信息，通知 UE相关的 UTRAN的移动信息和新的 U-RNTI , 以更新 UE的 UTRAN移动信息。
或由源 RNC发起无线 7 载重配， 或物理信道重配， 或传输 7 载重配； 重 配完成后，向目标 RNC返回对应的 UTRAN移动信息确认消息或空口重配完成 消息。
在 T-RNC发送步骤 104的空口消息 （UTRAN移动信息等）或者给源 RNC 发送步骤 103的重定位响应消息后， T-RNC复位或者重建 RLC ( Radio Link Control, 无线链路控制） 实体， 在目标 RNC和 UE之间交换 PDCP的 SN (序列 号） ， 该 SN如 PDCP-SND, PDCP-SNU; UE收到步骤 104的空口消息后， 开 始给目标 RNC发送上行用户数据； 当 T-RNC接收到 UE发送的 UTRAN移动信 息确认消息时， T-RNC也可以向 UE发送下行数据了。
步骤 106、 当目标 RNC收到了 UTRAN移动信息确认消息或其它空口重配 完成消息后， 目标 RNC发起重定位报告 ( Relocation Report )去通知核心网（也 称作 SGSN/MSC )建立 载所需资源的配置。
消息携带建立的 RAB列表信元（包括每个 RAB对应的业务参数和传输层 地址， TEID (隧道终端标识）等 ）和建立失败的 RAB列表（包括每个 RAB 对应的 ID和传输层地址， TEID等） 。
步骤 107-107，、 当 SGSN/MSC完成了 Iu承载的建立所需资源的配置后， 向 目标 RNC发起重定位完成（ Relocation Complete ) , 并开始启用新的 lu承载， 删除旧的 lu承载。 如果 lu承载建立失败， 则回复重定位失败消息， 消息中携带 失败原因， RNC则释放重定位操作中配置的资源。
如果 SGSN/MSC向目标 RNC发起 Relocation Complete消息，并开始启用新 的 lu承载， 删除旧的 lu承载， 则这时目标 RNC和 SGSN/MSC之间的 lu承载建立 成功， 此时， 对于需要在目标 RNC上建立的 RAB , 目标 RNC同时从 SGSN和 SRNC处接收下行包。
步骤 108、 不论核心网是否向目标 RNC发起重定位完成， 或者发起重定位 失败， 目标 RNC都要发送 lu释放命令（lu release Command )给源 RNC, 指示 源 RNC可以释放与核心网的 lu连接和相关的资源了。
步骤 109、 SRNC给 SGSN/MSC发送 lu释放完成消息。
在上述重定位流程中， 需要定义重定位报告、 重定位响应， 74议中， 其 由目标 RNC发送给核心网， 用来通知核心网分配重定位的资源：
方向： RNC CN.
重定位报告的内容如表 1所示。
表 1 重定位报告
IE/Group Name Presence Range Criticality Assigned
Criticality (信元 /组名称） (选项） (范围） (危险 (被分配
的危险程 程度） 度）
Message Type (消息类型） M (必选） YES (是） Reject
(拒绝）
ABs Setup List ( ABs 建立列表 ) O (可选） YES (是） Ignore
(忽略）
> ABs Setup Item ffis ( RABs 建立项目信元） 1至无线接入承载 3ACH (针 Reject
的最大数目 对每个） (拒绝）
» AB ID ( RAB标识） M (必选）
»Transport Layer Address (传输层地址 ) O (可选）
»Iu Transport Association ( lu传输关联 ) O (可选）
»Assigned RAB Parameter Values o (可选） YES Ignore
(忽略） (指定 RAB参数值） (是）
»Transport Layer Address (传输层地址 ) O (可选） YES Ignore
(是） (忽略）
»Iu Transport Association ( Iu传输关联 ) O (可选） YES Ignore
(是） (忽略） ABs Failed To Setup List ( ABs失败建立列 o (可选） YES Ignore 表） (是） (忽略）
> ABs Failed To Setup Item ffis ( RABs 失败建 1至无线接入承载 2ACH (针 Ignore 立项目信元） 的最大数目 对每个） (忽略）
» AB ID ( RAB标识） M (必选）
»Cause (原因） M (必选）
Chosen Integrity Protection Algorithm(冗整性保 O (可选） YES Ignore 护算法） (是） (忽略）
Chosen Encryption Algorithm (力口密算法 ) o (可选） YES Ignore
(是） (忽略）
Criticality Diagnostics (危险诊断） o (可选） YES Ignore
(是） (忽略） 如表 1所示， 重定位报告主要包括： 在漂移 RNC中建立的 RAB的列表， 其 可以包括 RAB ID (无线接入承载标识） 、 RAB的传输层地址和 Iu传输联合； 相关的 RAB参数项； 在漂移 RNC中不支持的原服务 RNC的 RAB列表， 其可以 包括 RAB ID、 和不支持的原因； 完整性保护信息； 和加密信息。 本消息可以 使用面向连接信令连接或者伴随建立面向连接的信令连接。
( 2 ) 、 步骤 101的重定位请求， 可以定义在 25.423 RNSAP协议中， 对该 消息的目的地址进行了修改， 即， 将目的地址 CN修改为漂移 RNC。 重定位请 求的内容如表 2所示。 方向： SRNC T-RNC
表 2 重定位请求
IE/Group Name(信元 /组名） Presence Range IE type Semantics description Criticality Assigned
(选项） (范围） and (语义描述） (危险程 Criticality reference 度） (被分配的 ( IE类型 危险程度） 和参考条
目 )
Message Type (消息类型） M (必选） 9.2.1.1 YES (是） Reject
(拒绝）
Permanent NAS UE Identity O (可选） 9.2.3.1 YES (是） Ignore (永久的 NAS UE标识） (忽略）
Cause (原因） M (必选） YES (是） Ignore
(忽略）
CN Domain Indicator M (必选） 9.2.1.5 YES (是） Reject ( CN域指示） (拒绝）
Source RNC To Target M (必选） 9.2.1.28 YES (是） Reject RNC Transparent Container (拒绝） (源 RNC 到目标 RNC 的
透明容器）
Physical information O (可选）
(物理层信息）
RABs To Be Setup List YES (是） Reject (需要建立的 RAB列表） (拒绝）
> ABs To Be Setup Item 1至无幾接 EACH Reject les (需要建立的 RAB项） 入承载的 (每个） (拒绝） 最大数目
» AB ID M (必选） 9.2.1.2
»NAS Synchronisation O (可选） 9.2.3.18
Indicator ( NAS同步指示）
» AB Parameters M (必选） 9.2.1.3
RAB参数
»Data Volume Reporting C - ifPS 9.2.1.17
Indication (如杲在
数据流量报告指示 PS域）
» PDP Type Information C - ifPS 9.2.1.40
PDP类型信息 (如杲在
PS域）
»User Plane Information M (必选）
用户面信息
»>User Plane Mode M (必选） 9.2.1.18
用户面模式
»>UP Mode Versions M (必选） 9.2.1.19 用户面模式版本
»>GTP-ND O (可选） 如果本消息中未携带此
下一个要发送的下行 IE, 则需要在得到重定位
GTP-U序号 响应之后， 使用源无线网
络控制器的上下文转发
»>GTP-NU o (可选） 如果本消息中未携带此
下一个要发送的上行 IE, 则需要在得到重定位
GTP-U序号 响应之后， 使用源无线网
络控制器的上下文转发
»>PDCP-SND 如果本消息中未携带此
下一个要发送的下行 PDCP IE, 则需要在得到重定位
序号 响应之后， 使用源无线网
络控制器的上下文转发
»>PDCP-SNU 如果本消息中未携带此
下一个要发送的上行 PDCP IE, 则需要在得到重定位
序号 响应之后， 使用源无线网
络控制器的上下文转发
»Transport Layer Address M (必选） 9.2.2.1
传输层地址
»Iu Transport Association M (必选） 9.2.2.2
Iu传输关联
»Service Handover O (可选） 9.2.1.41
服务切换
» Alternative AB O (可选） 9.2.1.43 YES (是） Ignore Parameter Values (忽略） 可选的 RAB参数值
Integrity Protection O (可选） 9.2.1.11 如果完整性保护信息包 YES (是） Ignore Information 含密钥和允许的算法 (忽略） 完整性保护信息
Encryption Information O (可选） 9.2.1.12 如果加密信息包含密钥 YES (是） Ignore 加密信息 和允许的算法 (忽略）
Iu Signalling Connection M (必选） 9.2.1.38 YES (是） Ignore
Identifier (忽略）
Iu连接标识
Global CN-ID O (可选） 9.2.1.46 YES (是） Reject 全球 CN-ID (拒绝）
( 3 ) 、 步骤 103的重定位响应， 其可定义在 25.423 RNSAP协议中， 用来 目标 RNC向源 RNC发送目标 RNC到源 RNC透明容器， 以便源 RNC判断是否向 UE发送空口重配信息： 方向： 目标 RNC→ 源 RNC; 信令类型： 面向连接。
重定位响应的内容如表 3所示。
表 3 重定位响应 (Relocation Response)
Figure imgf000012_0001
( 4 ) 、 步骤 107的重定位完成 (Relocation Complete), 其可定义在 25.413 RANAP协议中， 消息中携带的信元可以不变， 对该消息的源地址和目的地 址分别进行了修改， 即， 将源地址 D-RNC修改为 CN , 将目的地址 CN修改为 D-RNC, 换句话说， 该消息的传输方向变为： CN->D-RNC。
根据本实施例重定位流程， 通过 RNC作为重定位流程的主控网元发起重 定位流程， RNC之间直接交互建立无线承载和无线接入承载， 省去了由核心 网转发的步骤， 从而减少了信令交互的次数， 减少了由重定位流程导致的切 换时延， 增加了重定位的成功率， 使得重定位过程筒捷而高效。
如图 2所示， 为本发明另一个实施例的重定位流程； 在本实施例中， 殳设 UE的 SRNC为 Evolved HSPA UTRAN网络中的 NodeB+, UE的重定位的目标 RNC为 UMTS网络中的 RNC,其中， NodeB+与电路域核心网之间有信令连接， NodeB+与 RNC通过 Iur口相连。 当 UE发起建立 CS业务时， 该 NodeB+支持 CS 业务的传统网络的 RNC完成的重定位过程。 下面描述该重定位过程。
步骤 201-203、 当 UE在 NodeB+控制的小区 CELL下发起了 CS呼叫， NodeB+接收到初始直传（ Initial Direct Transfer ) 消息时， 可根据该消息内容 确定该业务是属于 CS域的， 而自身又无法支持 CS业务， 于是 NodeB+通过 Iu-CS的信令接口向 MSC发起初始 UE消息的同时， 触发从 Evolved HSPA UTRAN网络向支持 CS业务的传统网络的切换， MSC收到初始 UE消息后， 会 回复 SCCP连接确认消息。
此时， 上下行数据有以下路径： UE和 SRNC之间的数据通道； SRNC和 SGSN之间的 GTP-U通道， SGSN和 GGSN之间的 GTP-U通道。
在这个过程中，如果 RNC收到 RAB的建立请求消息，会緩存该消息内容， 直到 RNC完成角色转换后， 处理该消息。
步骤 204、 从 Evolved HSPA UTRAN网络向支持 CS业务的传统网络的切 换， 利用 RNSAP协议经 Iur接口向目标 RNC发起重定位请求。
所述发起重定位请求的过程以及相关处理参见对图 1一个实施例的步骤 101-102的描述。 另夕卜， 在本实施例中， 重定位请求（ Relocation Request ) 中 要携带物理层的信息， 并设置容器中重定位类型为 "未定义" （undefined ) 。
步骤 205-206、 RNC发现重定位请求的容器中重定位类型为未定义； 便依 据自身的能力判断可否接受重定位请求中的容器（源 RNC到目标 RNC透明容 器） 中的配置， 如果不支持， 则需要触发 RL (无线链路） 的建立过程， 同时 触发传输层的 Iur口的数据的 ALCAP传输承载的建立过程， 然后， NodeB+即 SRNC会根据 RNC发来的 RL建立请求， 更新资源配置， 并向 RNC发出 RL建立 响应。 本实施例及下述实施例中的 NodeB+如无特别说明， 均指 SRNC。
如果 RNC可以支持容器中的配置， 则仅触发传输层的 Iur口的数据的 ALCAP传输承载的建立过程即可。
步骤 207-207，、 当目标 RNC配置完 RRC、 RLC、 MAC, 逻辑信道和传输 信道的映射关系、 物理层资源和传输信道的映射关系后， 向源 RNC发起重定 位响应， 以告知源 RNC—个目标 RNC上建立的这些容器（目标 RNC到源 RNC 透明容器）和需要进行数据转发的 RAB ID列表， 源 RNC会根据这个 RAB ID 列表开始向目标 RNC转发数据。 RNC发现重定位请求中容器中重定位类型为 未定义， 则在向 NodeB+响应的时候， 将目标 RNC到源 NodeB+的容器项 （目 标 RNC到源 RNC透明容器）设为必选项， 并在 RRC CONTAINER中增加一项 UTRAN移动信息 ( UTRAN MOBILITY INFORMATION ) 。
如果目标 RNC不能支持 SRNS重定位或者在配置过程中出现了异常，如资 源受限等， 则会向源 RNC发起重定位取消。 如果配置过程中， RNC的能力可 以接受重定位请求中的容器（源 RNC到目标 RNC透明容器）中的配置， 则构 造 container中的 UTRAN移动信息信元； 如果不支持， 则根据配置的结果填写 无线 载重配、 或物理信道重配、 或传输 7?载重配。
步骤 208-209"，、 当 NodeB+得到 RNC的响应时， NodeB+根据重定位响应 中的"目标 RNC 到源 RNC透明容器"中的内容分别发起 UTRAN移动信息， 无 线 载重配， 物理信道重配， 传输 7|载重配。
在 RNC发起重定位响应后， RNC复位 /重建 RLC实体， 在 RNC和 UE之间 交换 PDCP的 SN ( PDCP-SND, PDCP-SNU ) ； RNC收到空口消息后， UE开 始给 RNC发送上行用户数据； 当 UE发送 UTRAN移动信息确认消息或其他空 口确认消息 （无线 7?载重配完成， 物理信道重配完成， 传输 7?载重配完成） 后时， UE也可以接收 RNC发来的下行数据了。
步骤 210、 当 RNC收到了 UTRAN移动信息确认消息或其它空口重配完成 消息后， 目标 RNC通过发起重定位报告 ( Relocation Report ) , 所述发起重定 位才艮告的过程参见对图 1一个实施例中的步骤 106的描述。
步骤 211-211，、 当 SGSN完成了 Iu承载的建立所需资源的配置后， 发起重 定位完成（ Relocation Complete )给目标 RNC, 所述发起重定位完成的过程参 见对图 1一个实施例中的步骤 107所述的描述。
步骤 212、 参见对图 1一个实施例中的步骤 108的描述。 步骤 213、 NodeB+给 SGSN发送 Iu释放完成消息， 重定位过程结束。
步骤 214-215、业务建立过程： 开始进行 CS业务的无线接入承载建立过程 和 CS业务的呼叫建立过程。
在上述步骤中， 根据步骤 208-209"，可知： 如果 "目标 RNC到源 RNC透明 容器" 中的内容是 UTRAN移动信息， 则不把 "目标 RNC到源 RNC透明容器" 发给 RNC,并且由 NodeB+向 UE发起 UTRAN移动信息。则 RNC只发三种消息： 无线 载重配， 或物理信道重配， 或传输 7?载重配。
步骤 208-209"，还可以为： NodeB+把重定位响应中的 "目标 RNC到源 RNC 透明容器" 中的内容， 全都发给 RNC; 则 RNC发送四种消息： UTRAN移动信 息， 或无线承载重配， 或物理信道重配， 或传输承载重配， 由 RNC向 UE发起 UTRAN移动信息。
本发明实施例针对容器中重定位类型为 "未定义" 的情况， 采用由 RNC 作为主控网元， 利用无线接入承载和无线承载分两步配置的手段， 使得由重 定位流程导致的切换时延有效减少， 信令交互的次数也大大减少， 使得重定 位过程筒捷而高效。
如图 3所示，为本发明还一个实施例的重定位流程。对于其中一个实施例， 本实施例与图 2所示实施例的区别在于： 本实施例是针对重定位类型为 UE不 参与的情况的重定位过程， 具体地， 区别如下：
步骤 301-303与图 2所示实施例的步骤 201-203相同， 在此不再赘述。 、 步骤 304与步骤 204大致相同， 其区别在于： 步骤 304的重定位请求中要携 带物理层的信息， 并设置容器中重定位类型为 "未定义" （undefined ) 。
步骤 305-306、 如果容器中重定位类型为 UE不参与的 （ UE NOT INVOLVED ) , 并且 lur的面向连接的链路不存在， 重定位请求还会触发 lur 口的数据的 ALCAP 的传输承载的建立。
如果容器中重定位类型为 UE参与的（ UE INVOLVED ) ,则会触发 RL (无 线链路）的建立过程， 同时建立起 lur口的数据的 ALCAP的传输承载； 由于传 统 RNC可能不支持 UE在 NodeB+上配置的功能， RNC根据自己的能力建立 RL, 可能和 SRNC告知的容器（ Source RNC to Target RNC Transparent Container ) 中的配置不相同。 此时， NodeB+会根据 RNC发来 RL建立请求， 更新资源配 置， 并向 RNC发出 RL建立响应。 NodeB+收到该响应消息后， 先发送一条消 息（该消息可以叫做 SRNS context forward )通知目标 RNC: GTP-U上的 PDU (协议数据单元）上下行方向下一步分别要发送的序列号， 下一步将要从 UE 上接到的上行的 PDCP (分组数据会聚协议）序列号以及将要发送给 UE的下 行 PDCP序列号。 然后开始向 RNC转发数据。 转发的数据是从 SGSN收到的下 行 GTP-PDU, 同时在 NodeB+上也保留 GTP-PDU的备份， 这个转发对于任何 一种迁移类型都适用； 对于从 UE收到的上行的已经解密的数据包也可以进行 转发， 这样可以避免 UE重传很多数据。 需要转发下行数据， 可以不转发上行 数据。 下行转发数据的时候还可以这样处理： 对于没有进行 RLC层发送的 GTP-PDU, 就转发 GTP-PDU; 如果 GTP-PDU经过头压缩， RLC层处理以后， 已经发送了其中的一部分，这时要转发 GTP-PDU和 /或分割或者级联后的 RLC PDU。
步骤 307-307，、 参见对图 1一个实施例中步骤 103- 103，的描述。
步骤 308-309"，、 如果重定位的类型是 UE不参与的重定位， RNC向 UE发 起 UTRAN移动信息更新过程，通知 UE相关的 UTRAN的移动信息和新的 U-RNTI。 如果重定位的类型是 UE参与的重定位， 则由 NodeB+根据重定位响 应中的目标 RNC至源 RNC透明容器（目标 RNC到源 RNC透明容器） 中的内容 确定向 UE发起无线承载重配， 物理信道重配， 传输承载重配。
在 RNC发送空口消息后或者发起重定位响应以后， RNC复位 /重建 RLC实 体， 在 RNC和 UE之间交换 PDCP的 SN ( PDCP-SND, PDCP-SNU ) ； RNC收 到空口消息后， UE开始给 RNC发送上行用户数据； 当 UE发送 UTRAN移动信 息确认消息或其他空口确认消息 （无线承载重配完成， 物理信道重配完成， 传输承载重配完成）后时， UE也可以接收 RNC发来的下行数据了。 步骤 310-315与步骤 210-215相同， 不再赘述。
对于其中另一个实施例， 如图 3所示， 本实施例重定位的触发过程与上一 个实施例的区别在于：
将步骤 304替换为： 、从 Evolved HSPA UTRAN网络向支持 CS业务的传统 网络的切换， 利用 RNSAP 协议经 Iur接口向目标 RNC发起重定位请求 ( Relocation Request ) , 发起重定位请求的过程参见图 1一个实施例中步骤 101-102; 另外， 在本实施例中， 所述重定位请求中携带的原因 （cause )值为 "Single Carrier controlled by two RNC (两个 RNC控制同一承载） "， 此 CAUSE 值存在时不考虑容器中重定位类型 （ RELOCATION TYPE ) ； 并约定如果此 cause值为 "Single Carrier controlled by two RNC"时， 请求中要携带物理层的信 息。
将步骤 305-306替换为： RNC发现重定位请求中告知的 cause值为" Single Carrier controlled by two RNC", 便依据自身的能力判断可否接受重定位请求 中的容器（源 RNC到目标 RNC透明容器） 中的配置， 如果不支持， 则需要触 发 RL (无线链路） 的建立过程， 同时触发传输层的 Iur口的数据的 ALCAP传 输承载的建立过程， 然后， NodeB+会根据 RNC发来 RL建立请求， 更新资源 配置， 并向 RNC发出 RL建立响应； 如果 RNC可以支持容器中的配置， 则仅触 发传输层的 Iur口的数据的 ALCAP传输承载的建立过程即可。
将步骤 307-307，替换为： RNC发现重定位请求中告知的 cause值为" Single Carrier controlled by two RNC", 则在向 NodeB+发起重定位响应的时候， 如果 RNC可以支持容器中的配置， 则不携带目标 RNC到源 RNC透明容器， 并向 UE 发起 UTRAN移动信息； 如果不支持， 则根据配置的结果构造目标 RNC到源 RNC透明容器中的无线承载重配、 或物理信道重配、 或传输承载重配信息。
将步骤 308-309， "替换为： 当 NodeB+得到 RNC的响应时， 根据响应中需 要转发的 RAB列表开始进行数据的转发。 如果重定位响应中携带目标 RNC到 源 RNC透明容器， NodeB+根据容器中的信息确定向 UE发起无线承载重配、 物理信道重配、 传输 7 载重配。
对于顺序交付的 RAB, 目标 RNC发送重定位响应之后复位或者重建 RLC ( Radio Link Control, 无线链路控制）实体， 在目标 RNC和 UE之间交换 PDCP 的 SN (序列号） ， 该 SN如 PDCP-SND, PDCP-SNU; UE收到空口消息后， 开 始给目标 RNC发送上行用户数据；当 DRNC接收到 UE发送的 UTRAN移动信息 确认消息时， DRNC也可以向 UE发送下行数据了。
本实施例的实施例能够实现根据不同的重定位类型由 Evolved HSPA UTRAN网络中的 NodeB+重定位到 UMTS网络中的 RNC的不同流程；能够减少 信令交互的次数， 减少切换时延， 增加重定位的成功率， 使得重定位过程筒 捷而高效。
如图 4所示， 为本发明又一个实施例的重定位流程； 在本实施例中， 描述 了一个 UMTS网络的 RNC和演进的 HSPA的载波共享网络的 NodeB+通过 Iur口 相连接的场景， 它们控制的是同一个小区。 同样假设 UE的 SRNC为 Evolved HSPA UTRAN网给中的 NodeB+, UE的 T-RNC为 UMTS网给中的 RNC。 其中， NodeB+与 RNC通过 Iur口相连， 在 NodeB +与 MSC之间没有 Iu-cs的信令连接。 当 UE发起建立 CS业务时， 该 NodeB+向支持 CS业务的传统网络的 RNC进行重 定位的过程。 下面描述该重定位过程。
步骤 601、 当 UE在 NodeB+控制的小区 CELL下发起了 CS呼叫， 当 NodeB+ 接收到初始直传消息时， 触发从 Evolved HSPA UTRAN网络向支持 CS业务的 传统网络的切换。
步骤 602-603、 NodeB+首先向 RNC发起了无线链路建立请求， 同时触发 传输层的 Iur口的数据的 ALCAP传输承载的建立过程， RNC向 NodeB+发起无 线链路建立响应， RNC保存了该 UE的物理层无线链路的配置参数， 不会真正 的去建立一条无线链路在 NodeB+上（因为这个无线链路已经存在了） 。
步骤 604-605、 NodeB+通过 Iur口向传统网络的目标 RNC发起重定位请求。 NodeB+除了告知 RNC 源 RNC到目标 RNC透明容器外， 还携带了包含初始直 传消息中携带的 NAS (非接入层） PDU (协议数据单元）和 CS连接建立所必 需的信息。 RNC会响应 NodeB+的重定位请求过程， 如图 1一个实施例中的步 骤 101-102的描述。
步骤 A、 B、 C在步骤 604后， RNC会并行的向 MSC发送初始直传信息， MSC分配资源后， 会向目标 RNC回复直传消息， 如果直传消息在空口信息 (UTRAN移动信息确认消息、 RB承载重配完成)之前到达， 则 RNC緩存直传消 息中的 NAS信息。
步骤 606-607、 参见对图 1一个实施例中步骤 104-105，描述的内容。
步骤 D、 当从 UE收到这个 UTRAN移动信息确认消息时，传统 RNC转变角 色成为该 UE的 SRNC。 RNC会把收到直传信息通过下行直传消息发给 UE。
步骤 608-609、 同时， RNC发起重定位报告消息给核心网（ MSC/SGSN ) , 去通知核心网 （MSC/SGSN )进行和传统 RNC之间的 Iu承载的建立所需资源 的配置。 参数可以包括传统 RNC的要建立的 RAB列表和不支持的 RAB列表， 新的传输层地址和新的 Iu-association,核心网首先保存和传统 RNC建立 载 所必需的资源。随后， RNC将发起重定位命令通知 NodeB+开始数据传输（data forwarding )过程。
步骤 610、 核心网将发起重定位完成， 同时使用新的 Iu用户面。 RNC通过 重定位命令消息通知 NodeB+开始 data forwarding过程。
步骤 611、核心网将向 NodeB+发起 Iu释放命令， 以释放 Iu连接和相关的资 源。
步骤 612-613、 当原有的 Iu连接释放完毕， SRNC重定位过程结束。 CS呼 叫建立将正常进行。
在上述重定位流程中， 还需要修改重定位命令， 消息的信元保持不变， 将该命令从 Iu口移到 Iur口， 即， 从 25.413 RANAP协议移到 25.423 RASAP , 重 新修改了路径也就从 CN->S-RNC移到了 D-RNC->S-RNC。
本发明实施例在无线链路已经存在的情况下， RNC就不需要真正去建立 在 NodeB+上的无线链路了， RNC直接作为主控网元， 利用无线接入承载和无 线承载分两步配置的手段， 使得由重定位流程导致的切换时延有效减少， 本 实施例信令交互的次数也大大减少， 增加了重定位的成功率， 使得重定位过 程筒捷而高效。
如图 5所示， 为本发明再一个实施例的重定位流程； 在本实施例中， 殳设 UE的 SRNC为 Evolved HSPA UTRAN网络的 NodeB+ , UE的 T-RNC为 UMTS网 络中的 RNC, UE与 NodeB+存在一个 PS业务连接。 NodeB+与电路域的核心网 没有连接。 当 UE发起 CS业务时， 会引起 NodeB+向 RNC的重定位过程。 本重 定位过程的特点是同时进行无线接入承载（Iu承载）与无线承载（空口承载） 的建立。 下面描述该重定位过程。
步骤 701-702、 NodeB+接收 UE发送的初始直传消息， 根据初始直传消息 确定建立 CS业务。由于 NodeB+自身无法支持 CS业务，便触发从 Evolved HSPA UTRAN网络向支持 CS业务的传统网络的切换。 NodeB+通过 lur口向 RNC发起 重定位请求， 所述重定位请求包括内容同实施例一。 接收到重定位请求消息 的 RNC会根据重定位消息所携带的信息来配置 RRC、 MAC, RLC资源和信道 映射关系。
步骤 703、 NodeB+向 SGSN发起重定位必需消息， 所述重定位必需消息可 以包括初始直传消息中携带的 NAS PDU和 CS连接建立所必需的信息，不包括 NodeB+到 RNC的透明容器， SGSN收到该消息后， 准备新的 PS连接建立。
步骤 704-705、 RNC完成配置后， 一方面向 SGSN发起重定位报告， 通知 SGSN进行新的 Iu所需的资源配置， 并且开始建立 II !载； 另一方面向 NodeB+ 发起重定位响应消息或 lur链路建立 /无线链路建立响应过程，表示已完成传输 载的建立。
步骤 706-709、 RNC向 UE发出 UTRAN移动信息消息， 通知 UE相关的 UTRAN的移动信息和新的 U-RNTI。 RNC同时还向 MSC发送初始 UE信息， MSC收到初始 UE信息后， 会向 RNC回复直传消息， 这时， 如果直传消息在 UE响应之前到达， 则 RNC緩存该信息； 当从 UE收到 UTRAN移动信息确认消 息时， 传统 RNC转变角色成为 UE的 SRNC。
步骤 710、 RNC把收到直传信息通过下行直传消息发给 UE。
步骤 711、 SGSN通过重定位命令通知 NodeB+开始数据发送过程。
步骤 712、 SGSN将发起 lu连接释放命令， 触发 NodeB+释放 lu连接和相关 的资源。
步骤 713-714、 当原有的 lu连接释放完毕， RNC重定位过程结束。 CS呼叫 建立将正常进行。
本发明实施例在 NodeB+与电路域的核心网没有连接的情况下， 通过 NodeB+向 SGSN发送不包括 NodeB+到 RNC的透明容器的重定位必需消息来 建立 PS连接， 并且 RNC完成配置后建立 lu承载， 实现了同时进行无线承载（lu 承载）和无线承载（空口承载）的建立。 本实施例能够减少信令交互的次数， 减少切换时延， 增加了重定位的成功率， 使得重定位过程筒捷而高效。
如图 6所示， 为本发明另外一个实施例的重定位流程； 在本实施例中， 假 设 UE的 T-RNC为 Evolved HSPA UTRAN网络的 NodeB+, UE的 SRNC为 UMTS 网络中的 RNC, UE因移动 /负荷等原因， 会引起由 RNC的转移到 NodeB+控制 的重定位过程。 下面描述该重定位过程。
步骤 801-802、 RNC通过 Iur口向传统网络的目标 NodeB+发起无线链路建 立请求， 然后 NodeB+向 RNC返回无线链路建立响应。
步骤 803、 当 RNC接收到 NodeB+发来的无线链路建立响应后， 就利用 RNSAP协议经 Iur接口向 NodeB+发起重定位请求。 接收到重定位请求的 NodeB+根据请求中携带的信息来配置 RRC、 MAC、 RLC资源和信道映射关系， 并给 UE分配一个新的 U-RNTI。
步骤 804-805、 NodeB+向 UE发出 UTRAN移动信息消息， 通知 UE相关的 UTRAN的移动信息和新的 U-RNTI。 UE收到 UTRAN移动信息消息后， 记录 该消息中内容， 并向 NodeB+返回 UTRAN移动信息确认消息。 步骤 806-807、 当 NodeB+收到了 UTRAN移动信息确认消息后， NodeB+ 和 RNC的角色的互换已经完成， NodeB+向 SGSN发起重定位报告， 以通知 SGSN配置 Iu承载的所需资源。 NodeB+向 MSC发起重定位报告， 以通知 MSC 配置 Iu承载的所需资源。 如果 NodeB+所连接的 SGSN并非 RNC连接的 SGSN, NodeB+仍可以发送重定位报告， 消息中只携带需要建立的 RAB列表， 不再携 带要删除的 RAB列表， 还携带 RAB对应的上下行将要发送的 GTP-U序号。
步骤 808-809、 当 SGSN和 MSC完成了 Iu承载建立所需资源的配置后， 分 别发起重定位完成给 NodeB+, 这时， NodeB+和 SGSN之间的 Iu承载和 NodeB+ 和 MSC之间的 Iu承载建立成功。
步骤 810、 NodeB+发起重定位命令给 RNC , 通知 RNC可以释放它与核心 网的 Iu连接和相关的资源。 RNC在收到重定位命令以后， 开始进行 GTP-U的 转发。 于是 NodB+就会收到来自 RNC与核心网的 GTP-U数据。
步骤 811-812、 在数据转发完毕之后， RNC分别给 SGSN和 MSC发起 Iu释 放完成并且释放 Iu连接和相关资源。 至此重定位过程结束。
本实施例能够实现 UE因移动 /负荷等原因引起的重定位过程。本实施例能 够减少信令交互的次数， 减少切换时延， 增加重定位的成功率， 使得重定位 过程筒捷而高效。
如图 7所示， 为本发明最后一个实施例的重定位流程； 本实施例的流程除 步骤 904-905外（为描述方便，本流程图没有步骤 906 ) ,其它步骤（步骤 901-903, 及步骤 907-915 )与图 3所示还一个实施例的其它步骤（步骤 301-303 , 及步骤 307-315 )相同。
在步骤 904-905中， 当 NodeB+决定发起重定位时， 利用 RNSAP协议经 Iur 接口向目标 RNC发起重定位请求（ Relocation Request ) , 与实施例一不同的 是， 这条重定位请求消息除了实施一所述内容外， 还可以包括 Iur链路建立的 信息， 因此， 在本实施例中， 就省去了 NodeB至 RNC之间的 Iur链路建立请求 的步骤（即步骤 906 ) 。 目标 RNC收到重定位请求后， 配置除图 1一个实施例 所述的空口资源分配外， 还为 Iur口的专用链路和用户面分配资源， 并向 NodeB+回应 Iur链路建立响应。 如果分配失败， 直接回重定位取消。
本实施例的重定位消息还包括 Iur链路建立的信息， 因此省去了 NodeB至 RNC之间的 Iur链路建立请求的步骤， 因此重定位流程得到进一步的筒化； 本 实施例能够减少信令交互的次数， 减少切换时延， 增加重定位的成功率， 使 得重定位过程筒捷而高效。
如图 8所示， 本实施例描述一种通信系统， 包括目标无线网络控制器 1、 源无线网络控制器 2。
目标无线网络控制器 1用于接收源无线网络控制器 2发起的重定位请求， 以发起所述目标无线网络控制器到用户设备之间无线承载的建立， 并向核心 网发起重定位报告， 以发起核心网至所述目标无线网络控制器之间 Iu承载的 建立。 目标无线网络控制器 1具体可以包括： 接收单元 11 , 用于接收源无线网 络控制器 2发起的重定位请求； 无线承载建立单元 12, 用于根据接收单元 11 接收的重定位请求建立无线网络控制器与用户设备之间的无线承载； Iu承载 建立单元 13 , 用于向核心网发起重定位 4艮告， 以建立核心网至所述无线网络 控制器之间的 Iu承载； 发起单元 14, 用于向其它目标无线网络控制器发起重 定位请求； 第一释放单元 15 , 用于接收 Iu释放命令时， 释放所述无线网络控 制器与核心网之间的资源； 数据转发单元 16, 用于向其它目标无线网络控制 器转发中间数据。
源无线网络控制器 2用于向目标无线网络控制器 1发起重定位请求。 源无 线网络控制器 2包括： 发起单元 21 , 用于向其它目标无线网络控制器发起重定 位请求消息； 数据转发单元 22, 用于向其它目标无线网络控制器转发中间， 第二释放单元 23 , 用于接收核心网或目标无线网络控制发送的 Iu释放命令时， 释放源无线网络控制器 2与核心网之间的资源。
源无线网络控制器 2为增强基站或无线网络控制器， 目标无线网络控制器 1为增强基站或无线网络控制器。 根据本发明实施例， 改变了既往的重定位过程中核心网的主控角色， 即， 核心网控制网络中 RNC之间角色的转换和资源的配置， 透明转发 SRNC发给 T-RNC的所需的承载资源等低效技术。 在本发明实施例中， 采用由 RNC作为 主控网元（物理的网元或是逻辑的网元） ， 利用无线接入承载和无线承载分 两步配置的手段， 使得由重定位流程导致的切换时延有效减少， 信令流程交 互减少， 成功率也增加。 有效地解决了现有重定位过程的流程复杂、 冗余的 问题。 尤其是对于 R8系列 HSPA+网络， 采用本发明实施例的重定位技术， 会 提高通信网络系统的性能。
虽然通过实施例描绘了本发明， 但本领域普通技术人员知道， 在不脱 离本发明的精神和实质的情况下， 就可使本发明有许多变形和变化， 本发 明的范围由所附的权利要求来限定。

Claims

权 利 要 求
1、 一种重定位方法， 其特征在于， 包括：
目标无线网络控制器接收源无线网络控制器发起的重定位请求， 并在收 到所述重定位请求后， 作为主控制网元发起重定位流程。
2、 根据权利要求 1所述的方法， 其特征在于， 所述发起重定位流程具体 包括：
所述目标无线网络控制器发起所述目标无线网络控制器与用户设备之间 无线承载的建立；
所述目标无线网络控制器发起核心网至所述目标无线网络控制器之间 Iu 载的建立。
3、 根据权利要求 2所述的方法， 其特征在于， 所述目标无线网络控制器 接收源无线网络控制器发起的重定位请求之前或之后， 所述方法还包括： 在 所述源无线网络控制器与所述目标无线网络控制器之间建立链路。
4、 根据权利要求 2所述的方法， 其特征在于， 所述目标无线网络控制器 接收源无线网络控制器发起的重定位请求之前或之后， 所述方法还包括： 如 果在所述源无线网络控制器与所述目标无线网络控制器之间不存在面向连接 的链路， 建立所述源无线网络控制器与所述目标无线网络控制器之间数据的 接入链路控制应用协议的传输承载。
5、 根据权利要求 1或 2所述的方法， 其特征在于， 在所述源无线网络控制 器发起重定位请求之后， 所述方法还包括： 源无线网络控制器停止无线接入 承载的上行和下行的数据传输，并通知目标无线网络控制器在 GPRS隧道协议 用户面上的协议数据单元上下行方向下一步分别要发送的序列号， 下一步将 要从用户设备上接到的上行的分组数据会聚协议序列号以及将要发送给用户 设备的下行分组数据会聚协议序列号。
6、 根据权利要求 2所述的方法， 其特征在于， 所述无线承载的建立 具体包括： 目标无线网络控制器根据重定位请求配置无线承载资源， 所述无线承载 资源包括无线资源控制资源、 无线链路控制资源、 媒体接入控制资源和信道 的映射关系， 并给用户设备分配临时移动用户标识；
目标无线网络控制器根据重定位类型向用户设备发起带有所述临时移动 用户标识的通用地面无线接入网移动信息， 或者通知源无线网络控制器向用 户设备发起无线承载重配、 物理信道重配或传输承载重配。
7、 根据权利要求 6所述的方法， 其特征在于， 当所述目标无线网络控制 器根据重定位请求配置无线承载资源之后， 所述方法还包括：
若配置成功， 所述目标无线网络控制器向所述源无线网络控制器发起重 定位响应； 否则， 所述目标无线网络控制器向所述源无线网络控制器发起重 定位取消。
8、 根据权利要求 7所述的方法， 其特征在于， 当所述目标无线网络控制 器向所述源无线网络控制器发起重定位响应后， 还接收源无线网络控制器根 据所述重定位响应转发的数据；
和 /或， 当所述目标无线网络控制器向所述源无线网络控制器发起重定位 取消后， 所述源无线网络控制器中止本次重定位过程， 仍使用旧的配置参数。
9、 根据权利要求 6所述的方法， 其特征在于， 在所述目标无线网络控制 器根据重定位类型向用户设备发起带有所述临时移动用户标识的通用地面无 线接入网移动信息之后，
还包括： 所述目标无线网络控制器复位或者重建无线链路控制实体， 并 在目标无线网络控制器和用户设备之间的上下行分别交换分组数据会聚协议 的序列号
和 /或， 还包括： 用户设备记录所述通用地面无线接入网移动信息， 并向 目标无线网络控制器发送通用地面无线接入网移动信息确认消息。
10、 根据权利要求 2所述的方法， 其特征在于， 所述目标无线网络控制器 通过向核心网发起重定位报告而发起核心网至所述目标无线网络控制器之间 Iu7?载的建立。
11、 根据权利要求 10所述的方法， 其特征在于， 在所述目标无线网络控 制器向核心网发起重定位报告之后， 所述方法还包括：
核心网根据所述目标无线网络控制器发起的重定位报告建立 Iu承载， 若建立成功， 向目标无线网络控制器发起重定位完成， 并启用建立的 Iu 承载， 删除所述核心网至源无线网络控制器之间的 Iu承载；
和 /或， 若建立失败， 则所述核心网向目标无线网络控制器回复重定位失 败消息， 指示目标无线网络控制器释放重定位操作中配置的资源。
12、 根据权利要求 11所述的方法， 其特征在于， 所述方法还包括： 目标无线网络控制器向源无线网络控制器发送 Iu释放命令， 指示源无线 网络控制器释放所述源无线网络控制器至核心网之间的 Iu承载；
和 /或， 所述目标无线网络控制器向所述源无线网络控制器发起重定位命 令， 使所述源无线网络控制器向所述目标无线网络控制器传输中间数据， 以 及，
核心网向所述源无线网络控制器发送 Iu释放命令， 以释放所述源无线网 络控制器与核心网之间的资源。
13、 根据权利要求 2所述的方法， 其特征在于， 所述方法还包括： 在 Iur 口用户面上增加 GPRS隧道协议用户面的协议解析。
14、 根据权利要求 1所述的方法， 其特征在于， 在所述目标无线网络控制 器接收源无线网络控制器发起的重定位请求中， 当所述源无线网络控制器为 增强基站， 且由电路域业务触发重定位时， 所述重定位请求还携带物理层信 息， 重定位类型被设置为 "未定义" 。
15、 根据权利要求 14所述的方法， 其特征在于， 当所述目标无线网络控 制器支持接受重定位请求中的源无线网络控制器到目标无线网络控制器透明 容器中的配置时，
则构造目标无线网络控制器到源无线网络控制器透明容器中的通用地面 无线接入网移动信息信元， 否则， 目标无线网络控制器配置目标无线网络控 制器到源无线网络控制器透明容器的无线承载重配、 物理信道重配或传输承 载重配。
和 /或， 则向用户设备发起通用地面无线接入网移动信息， 否则， 目标无 线网络控制器配置目标无线网络控制器到源无线网络控制器透明容器的无线 载重配、 物理信道重配或传输 7|载重配。
16、 根据权利要求 15所述的方法， 其特征在于还包括： 所述源无线网络 控制器根据重定位响应中的目标无线网络控制器到源无线网络控制器透明容 器中的配置， 向用户设备发起通用地面无线接入网移动信息、 无线承载重配、 物理信道重配或传输 7|载重配。
17、 根据权利要求 7所述的方法， 其特征在于， 所述重定位响应包括目标 无线网络控制器到源无线网络控制器的容器项， 并在无线资源控制容器中增 加通用地面无线接入网移动信息。
18、 根据权利要求 1所述的方法， 其特征在于， 在所述目标无线网络控制 器接收源无线网络控制器发起的重定位请求中， 当所述源无线网络控制器为 增强基站， 由电路域业务触发重定位时， 所述重定位请求还携带物理层信息， 及原因值为 "两个无线网络控制器控制同一承载" 。
19、 根据权利要求 18所述的方法， 其特征在于， 若所述目标无线网络控 制器支持接受重定位请求中的源无线网络控制器到目标无线网络控制器透明 容器中的配置时， 则在重定位响应中不携带目标无线网络控制器到源无线网 络控制器透明容器， 并向用户设备发起通用地面无线接入网移动信息， 否贝' J , 所述目标无线网络控制器根据配置的结果构造目标无线网络控制器到源无线 网络控制器透明容器中的无线承载重配、 物理信道重配、传输承载重配信息， 所述重定位响应包括目标无线网络控制器到源无线网络控制器的容器项。
20、 根据权利要求 2所述的方法， 其特征在于， 在目标无线网络控制器和 电路域核心网之间没有电路域的信令连接的情况下， 所述重定位请求还携带 了包含初始直传消息中的非接入层协议数据单元和电路域连接建立所需的信 息。
21、 根据权利要求 20所述的方法， 其特征在于， 目标无线网络控制器向 核心网发送初始直传信息， 并接收核心网发送的直传消息， 如果所述直传消 息在空口响应信息之前到达， 则目标无线网络控制器緩存所述直传消息非接 入信息， 当接收到所述空口响应信息时， 目标无线网络控制器将所述非接入 信息通过下行直传消息发给用户设备。
22、 根据权利要求 2所述的方法， 其特征在于， 在目标无线网络控制器和 电路域核心网之间没有电路域信令连接的情况下， 源无线网络控制器向核心 网发起的重定位必需消息中携带了初始直传消息中的非接入层协议数据单元 和电路域连接建立所必需的信息、 没有源无线网络控制器到目标无线网络控 制器透明容器； 源无线网络控制器向目标无线网络控制器发起重定位请求。
23、 根据权利要求 1所述的方法， 其特征在于， 所述重定位请求， 包括目 标侧需要的切换信息和无线承载资源。
24、 一种通信系统， 其特征在于， 包括目标无线网络控制器和源无线网 络控制器，
所述目标无线网络控制器， 用于接收源无线网络控制器发起的重定位请 求， 根据所述重定位请求建立所述目标无线网络控制器到用户设备之间的无 线^^载； 并向核心网发起重定位"^艮告， 以建立核心网至所述目标无线网络控 制器之间的 Iu承载；
所述源无线网络控制器用于向目标无线网络控制器发起重定位请求。
25、 根据权利要求 24所述的通信系统， 其特征在于， 所述源无线网络控 制器为增强基站或无线网络控制器， 所述目标无线网络控制器为增强基站或 无线网络控制器。
26、 一种无线网络控制器， 其特征在于， 包括：
接收单元， 用于接收源无线网络控制器发起的重定位请求； 无线承载建立单元， 用于根据所述接收单元接收的重定位请求建立无线 网络控制器与用户设备之间的无线承载；
Iu承载建立单元， 用于根据所述接收单元接收的重定位请求向核心网发 起重定位报告， 以建立核心网至所述无线网络控制器之间的 Iu承载。
27、 根据权利要求 26所述的无线网络控制器， 其特征在于， 所述无线网 络控制器还包括发起单元和 /或数据转发单元，
所述发起单元， 用于向其它目标无线网络控制器发起重定位请求。
28、 根据权利要求 24或 25所述的无线网络控制器， 其特征在于， 所 述无线网络控制器还包括： 释放单元， 用于接收 Iu释放命令， 释放所述无 线网络控制器与核心网之间的资源。
PCT/CN2008/070848 2007-04-30 2008-04-29 Procédé de réadressage, système de communication et contrôleur de réseau radio WO2008134978A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200710103669.3 2007-04-30
CN200710103669 2007-04-30
CN200710126759.4 2007-06-20
CN 200710126759 CN101299879B (zh) 2007-04-30 2007-06-20 重定位方法、通信系统及无线网络控制器

Publications (1)

Publication Number Publication Date
WO2008134978A1 true WO2008134978A1 (fr) 2008-11-13

Family

ID=39943136

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070848 WO2008134978A1 (fr) 2007-04-30 2008-04-29 Procédé de réadressage, système de communication et contrôleur de réseau radio

Country Status (1)

Country Link
WO (1) WO2008134978A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020046625A (ko) * 2000-12-15 2002-06-21 박종섭 Ｉｍｔ-2000 시스템에서의 핸드오프시 ｓｒｎｃ 재할당 방법
CN1741671A (zh) * 2004-08-26 2006-03-01 中兴通讯股份有限公司 通过Iu口实现小区更新和注册区域更新的方法
WO2006062338A1 (en) * 2004-12-09 2006-06-15 Samsung Electronics Co., Ltd. Method and system for relocating serving radio network controller in a network sharing system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020046625A (ko) * 2000-12-15 2002-06-21 박종섭 Ｉｍｔ-2000 시스템에서의 핸드오프시 ｓｒｎｃ 재할당 방법
CN1741671A (zh) * 2004-08-26 2006-03-01 中兴通讯股份有限公司 通过Iu口实现小区更新和注册区域更新的方法
WO2006062338A1 (en) * 2004-12-09 2006-06-15 Samsung Electronics Co., Ltd. Method and system for relocating serving radio network controller in a network sharing system

Similar Documents

Publication Publication Date Title
US20070213058A1 (en) Method and apparatus for supporting handoff and serving radio network subsystem relocation procedures in a single tunnel gprs-based wireless communication system
US10075880B2 (en) Method and apparatus for non-access stratum message processing during handover in evolved network
JP4834162B2 (ja) イントラＥ−ＵＴｒａｎのハンドオーバのための方法及びシステム
WO2017118225A1 (zh) 双连接中实现重配置的方法、主服务基站及辅服务基站
US9113455B2 (en) Method and device relating to replay technique
US7664503B2 (en) Method for multimedia broadcast/multicast service signaling bearer connection on Iu interface
US20070213060A1 (en) Method and apparatus for supporting handoff in an lte gtp based wireless communication system
US20080188223A1 (en) Method, a system and a network element for performing a handover of a mobile equipment
EP2033468B1 (en) Improvements in an ehspa architecture
WO2010111814A1 (zh) 用于以最小包损失移动wcdma移动台的装置和方法
US11647432B2 (en) Anchor relocation
WO2009140917A1 (zh) 建立用户面单隧道的方法、系统及其基站子系统
WO2004043024A1 (en) Method for supporting multicast broadcast/multicast service to employ shared iu signaling connection
WO2007102953A1 (en) Method and apparatus for supporting handoff and serving radio network subsystem relocation procedures in a single tunnel gprs-based wireless communication system
WO2011113210A1 (zh) 多基站间本地交换的方法及装置
WO2012167648A1 (zh) 一种进行lipa承载接入控制的方法、系统和设备
WO2008134978A1 (fr) Procédé de réadressage, système de communication et contrôleur de réseau radio
KR100628743B1 (ko) 무손실 에스알엔에스 재배치 방법
WO2013000289A1 (zh) 直连隧道的移动性管理方法、网元及系统
WO2003045088A1 (en) Method for recovering from an abnormal release in a umts network
EP2009942A1 (en) Method and system for optimized relocation in a mobile network
WO2010130103A1 (zh) 实现高速分组接入业务本地交换的方法、设备及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08734206

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08734206

Country of ref document: EP

Kind code of ref document: A1