WO2007102953A1 - Procédé et appareil pour la prise en charge du transfert et procédures de relocalisation du sous-système de réseau de radiocommunication de desserte dans un système de communication sans fil basé sur un gprs à tunnel unique - Google Patents

Procédé et appareil pour la prise en charge du transfert et procédures de relocalisation du sous-système de réseau de radiocommunication de desserte dans un système de communication sans fil basé sur un gprs à tunnel unique Download PDF

Info

Publication number
WO2007102953A1
WO2007102953A1 PCT/US2007/002232 US2007002232W WO2007102953A1 WO 2007102953 A1 WO2007102953 A1 WO 2007102953A1 US 2007002232 W US2007002232 W US 2007002232W WO 2007102953 A1 WO2007102953 A1 WO 2007102953A1
Authority
WO
WIPO (PCT)
Prior art keywords
sgsn
ggsn
rnc
wtru
tunnel
Prior art date
Application number
PCT/US2007/002232
Other languages
English (en)
Inventor
Kamel M. Shaheen
Original Assignee
Interdigital Technology Corporation
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
Application filed by Interdigital Technology Corporation filed Critical Interdigital Technology Corporation
Priority to AU2007222104A priority Critical patent/AU2007222104A1/en
Publication of WO2007102953A1 publication Critical patent/WO2007102953A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node

Definitions

  • Tlie present invention is related to a wireless communication system. More particularly, the present invention is related to a method and apparatus for supporting handoff and serving radio network subsystem (SRNS) relocation procedures in a single tunnel general packet radio service (GPRS)- based wireless communication system.
  • SRNS radio network subsystem
  • GPRS general packet radio service
  • FIG. 1 shows a conventional GPRS/third generation (3G) wireless communication system architecture 100 that shows various interfaces/protocols as well as user data transfer interfaces between various network entities.
  • the wireless communication system 100 includes at least one serving GPRS support node (SGSN) 105 and at least one gateway GPRS support node (GGSN) 110.
  • the wireless communication system 100 further comprises a universal terrestrial radio access network (UTRAN) 115 which includes one or more radio access networks (RANs), base station systems (BSSs) and radio network controllers (RNCs), (not shown).
  • the system 100 also comprises a plurality of wireless transmit/receive units (WTRUs) 120, each including a terminal equipment (TE) 125 coupled to a mobile terminal (MT) 130.
  • WTRUs wireless transmit/receive units
  • the mobility in the wireless conmiunication system 100 is facilitated by anchoring an Internet Protocol (IP) session at the GGSN 110 and allowing for multi-level mobility by supporting mobility management (MM) protocols for IP and non-IP traffic/services provided by the SGSN 105.
  • IP Internet Protocol
  • MM mobility management
  • FIG. 2A shows how dual tunnels are established in the conventional wireless communication system 100 of Figure 1 to provide IP connectivity for user plane traffic.
  • a GPRS tunnelling protocol (GTP) user plane (GTP-U) tunnel 220 is established between a GGSN 205 and an SGSN 210, and a second user plane tunnel 225 is established between the SGSN 210 and a radio network controller (RNC) 215. Both tunnels are dedicated to the same user.
  • the GTP tunnel 220 has a user plane and a control plane.
  • the user tunnel 225 is an IP tunnel having a user plane and a RAN application part (RANAP) control plane used for control messaging.
  • RANAP RAN application part
  • the SGSN 210 switches the tunnel from an old RNC to a new RNC,.
  • a combined hard handover and SRNS relocation procedure is used to move the RAN to core network (CN) connection point at the RAN side from the source serving RNC (SRNC) to the target RNC, while performing a hard handover decided by the RAN.
  • the Iu links are relocated. If the target RNC is connected to the same SGSN as the source SRNC, an intra-SGSN SRNS relocation procedure is performed. If the routing area is changed, this procedure is followed by an intra- SGSN routing area update procedure.
  • the SGSN detects that it is an intra- SGSN routing area update by noticing that it also handles the old routing area. In this case, the SGSN has the necessary information about the WRTU and there is no need to inform the HLR about the new WTRU location. [0008] If the target RNC is connected to a different SGSN than the source
  • a routing area update is used to minimize the paging traffic within a wireless communication system that is grouped into clusters. Each cluster includes a group of cells (Node-Bs). Each cluster is defined by a unique identifier, (i.e., routing area identifier (ID)). Those WTRUs in the wireless communication system that travel across boundaries of the clusters have to perform a registration process called a routing area update. In the RAU, the WTRU informs the core network regarding which area of the system it is operating in.
  • ID routing area identifier
  • the core network pages the WTRU in the last known routing area. This eliminates the need to send a paging message for the WTRU throughout the entire system, which in turn significantly reduces the amount of signalling across the system. Thus, more processing power is allocated to user traffic.
  • the RAU may require the establishment of a new connection between a GGSN and a new RNG. New processes and message formats are needed for a single tunnel approach as compared to those existing in a two tunnel approach.
  • the present invention is related to a serving radio network subsystem (SRNS) relocation method which is implemented in a wireless communication system including at least one WTRU, a source RNC, a target RNC, an old SGSN, a new SGSN and a GGSN.
  • SRNS serving radio network subsystem
  • An old GTP-U tunnel is established between the source RNC and the GGSN.
  • the source RNC sends a relocation required message to the old SGSN.
  • the old SGSN sends a forward relocation request message to the new SGSN.
  • the new SGSN sends a relocation request message to the target RNC which indicates a single tunnel operation, a tunnel endpoi ⁇ t identity (TEID) of the GGSN, an identification number of the WTRU and the packet data protocol (PDP) address of the WTRU.
  • the new SGSN sends an update PDP context request message to the GGSN which indicates a single tunnel operation and the TEID of the target RNC.
  • the GGSN updates a binding of the target RNC TEID with the PDP address and the identification number of the WTRU.
  • a new GTP-U tunnel is established between the target RNC and the GGSN, and the old GTP-U tunnel is released.
  • Figure 1 shows a conventional GPRS and 3G wireless communication system
  • Figure 2A shows the conventional establishment of dual tunnels
  • Figure 2B shows the establishment of a single tunnel in accordance with the present invention
  • Figure 3 shows a prior art tunnel protocol stack
  • Figure 4 shows a single tunnel protocol stack configured in accordance with the present invention
  • FIG. 5 shows a single tunnel establishment procedure, (packet data protocol (PDP) context activation), which is implemented in accordance with the present invention
  • Figure 6 shows a system configuration before implementing SRNS relocation and routing area update using a single tunnel approach in accordance with the present invention
  • Figure 7 shows a system configuration after implementing an SRNS relocation procedure and routing area update using a single tunnel approach in accordance with the present invention
  • Figure 8 is a signaling diagram of an SRNS relocation procedure in accordance with the present invention.
  • Figure 9 shows a system configuration before implementing a single tunnel combined hard handover and SRNS relocation and routing area update procedure in accordance with the present invention
  • Figure 10 shows a system configuration after implementing a single tunnel combined hard handover and SRNS relocation and routing area update procedure in accordance with the present invention.
  • FIG 11 is a signaling diagram of a single tunnel combined hard handover and SRNS relocation, procedure in accordance with another embodiment of the present invention.
  • WTRU wireless transmit/receive unit
  • UE user equipment
  • PDA personal digital assistant
  • base station includes but is not limited to a Node-B, a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment.
  • the features of the present invention may be incorporated into an integrated circuit (IC) or be configured in a circuit comprising a multitude of interconnecting components.
  • the mobility in GPRS, (3G . or beyond), systems is facilitated by anchoring the IP session at the home GGSN and allowing for multi-level mobility, and by supporting existing MM protocols for non-IP traffic/services provided, by the SGSN.
  • FIG. 2B shows a single user-plane tunnel approach in accordance with the present invention.
  • a single user plane tunnel 230 is used to reduce the delay and processing power of an SGSN 210'.
  • the SGSN 210 terminates both the GTP tunnel 220 and a user plane tunnel 225 to the RNC 215, which means that the SGSN 210 decodes the packets traveling in both directions and translates them into the different protocol formats of the two tunnels 220 and 225.
  • the SGSN 210' In a single tunnel approach shown in Figure 2B, the SGSN 210' only establishes a tunnel between the GGSN 205' and the RNC 215' via two separate interfaces/protocols, (RANAP-C and GTP-C). In the single tunnel approach, the SGSN 210' is no longer involved in the user plane traffic. Thus, the user traffic passes through the SGSN 210' unchanged, (i.e., unaltered), in both directions. The SGSN 210' is no longer involved in the user plane processing. Only the RNC 215' and the GGSN 205' are allowed to perform/act on the user plane traffic.
  • RANAP-C and GTP-C two separate interfaces/protocols
  • the SGSN 210' only manages the control traffic, including MM, RAU, and the like, associated with the user and its IP based traffic.
  • the SGSN 210' connects an RNC 215' and a GGSN 205' using a GTP control plane to communicate with the GGSN 205' and a RANAP control plane to communicate with the RNC 215'.
  • the SGSN 210' is responsible for providing the GGSN 205' with the new RNC TEID information and the establishment of the single tunnel 230.
  • Figure 3 shows a prior art tunnel protocol stack according to existing GPRS protocol.
  • a GTP-U tunnel transfers, (i.e., tunnels), user data between a UTRAN (which includes RANs, BSSs and RNCs) and a 3G-SGSN, and between the 3G-SGSN and a 3G-GGSN.
  • Figure 4 shows a user plane in the single tunnel protocol stack in accordance with the present invention, in which the user plane tunnel from the UTRAN does not terminate at the 3G-SGSN. Instead, the UTRAN terminates at the 3G-GGSN.
  • the IP Tunnel shown in UTRAN and GGSN can be GTP based or any generic IP-Tunnel. In a preferred embodiment, the GTP-U tunnel is used as an IP tunnel.
  • FIG. 5 is a signaling diagram of a process for single tunnel establishment in accordance with the present invention.
  • the single tunnel functionality reduces the delay and processing power at the SGSN by reducing the need for protocol translation between the RNC and GGSN interfaces, and by enabling direct user plane tunnel between the RAN/RNC and the GGSN within the packet switched (PS) domain.
  • PS packet switched
  • the single tunnel approach will not eliminate the need for the SGSN to manage control traffic for IP based traffic.
  • the SGSN is still needed for the control plane signalling, MM and call/session management, and makes a decision when to establish a single tunnel rather than establishing dual tunnels.
  • the SGSN should connect the
  • the SGSN is responsible for updating and providing the GGSN with new RNC TEID information and the establishment of the single tunnel.
  • FIG. 5 shows a single tunnel establishment procedure, (packet data protocol (PDP) context activation), which is implemented in a wireless communication system including a WTRU 505, a radio access network (RAN)/radio network controller (RNC) 510, an SGSN 515 and a GGSN 520 in accordance with the present invention.
  • the WTRU 505 sends an activate PDP context request to the SGSN 515 that includes PDP type, PDP address, APN, quality of service (QoS) data and the like), (step 525).
  • the SGSN 515 validates the activate PDP context request, selects an APN), and maps the APN to the GGSN 520 (step 530).
  • the SGSN 515 determines if a single tunnel is supported and/or requested, and notes the existence of an RNC TEID (step 530).
  • the SGSN 515 creates a PDP context request that includes PDP Type, PDP Address, APN, a single tunnel request, an RNC TEID, QoS and the like), (step 535).
  • the GGSN 520 creates a PDP context response that includes PDP Type, PDP Address, APN, an indicator that the single tunnel is granted, GGSN TEID, QoS and the like (step 540).
  • the WTRU 505 and the RAN/RNC 510 establish a radio access bearer (RAB) (step 545).
  • RAB radio access bearer
  • the SGSN 515 and the RAN/RNC 510 exchange tunnel setup signaling that includes a mobile station international subscriber directory number (MSISDN), a PDP address and a GGSN TEID, and the SGSN 515 sends tunnel establishment information to the RAN/RNC 510 after receiving an indication of acceptance from the GGSN to establish the tunnel.
  • MSISDN mobile station international subscriber directory number
  • PDP address a PDP address
  • GGSN TEID a packet data convergence protocol
  • the SGSN 515 sends tunnel establishment information to the RAN/RNC 510 after receiving an indication of acceptance from the GGSN to establish the tunnel.
  • the SGSN 515 sends an update PDP context request to the GGSN 520 (step 560) to establish the new tunnel by informing the GGSN 520 of the RNC TEID associated with the request, and the GGSN 520 sends an update PDP context response to the SGSN 515 (step 565) confirming/rejecting the establishment of the tunnel and the associated attributes, (RNC TEID, PDP type, PDP address, user ID, and the like).
  • the SGSN 515 inserts the GGSN address in its PDP context, sends the PDP address received from the GGSN (step 570) and prepares for the response to be sent down to the WTRU 505.
  • the SGSN 515 updates the PDP context in the GGSN 520 to reflect any changes in the QoS attributes resulting from the RAB establishment of step 545.
  • Tunnel establishing signaling is exchanged between the RAN/RNC 510 and the GGSN 520 including the MSISDN, PDP address, RNC TEID and GGSN TEID (step 575).
  • the SGSN 515 sends an activate PDP context accept signal to the WTRU 505 that indicates the presence of a single tunnel (step 580).
  • Figure 6 shows a system configuration before implementing a handover procedure in accordance with the present invention.
  • Figure 7 shows a system configuration after implementing a handover procedure that uses SRNS relocation and routing area update using a single tunnel approach in accordance with the present invention.
  • the single tunnel between the GGSN and the source RNC, (when the source RNC takes the role of a serving RNC (SRNC)) shown in Figure 6 is switched to a new single tunnel between the GGSN and the target RNC during a handover procedure, (when the target RNC takes the role of an SRNC), as shown in Figure 7 after performing the SRNS relocation and routing area update of Figure 8.
  • SRNC serving RNC
  • Figure 8 is a signaling diagram of an SRNS relocation procedure using a single tunnel approach implemented in a wireless communication system including a WTRU 805, a source RNC 810, a target RNC 815, an old SGSN 820, a new SGSN 825 and a GGSN 830 in accordance with one embodiment of the present invention.
  • step 832 an old tunnel is established between the source RNC
  • step 834 the source RNC 810 decides to perform/initiate SRNS relocation.
  • both uplink and downlink user data flows via at least one of the following tunnels: a radio bearer between the WTRU 805 and the source RNC 810, (data flows via the target RNC 815, which acts as a drift RNC); GTP user plane tunnel(s) between the source RNC 810 and the old SGSN 820; and GTP user plane tunnel(s) between the old-SGSN 820 and the GGSN 830.
  • the source RNC 810 sends a relocation required message, (including relocation type, cause, source ID, target ID, source RNC to target RNC transparent container), to the old SGSN 820.
  • the source RNC 810 sets the relocation type to "WTRU not involved".
  • the source RNC to target RNC transparent container includes the necessary information for relocation coordination, security functionality and radio resource control (RRC) protocol context information, (including WTRU capabilities).
  • RRC radio resource control
  • the old SGSN 820 determines from the target ID if the SRNS relocation is an intra-SGSN SRNS relocation or an inter-SGSN SRNS relocation.
  • the old SGSN 820 initiates the relocation resource allocation procedure by sending a forward relocation request message, (IMSI, TEID signaling, MM context, PDP context, target identification, RAN transparent container, RANAP cause) to the new SGSN 825 (step 838).
  • IMSI forward relocation request message
  • the old SGSN 820 may, (if it provides intra domain connection of RAN nodes to multiple CN nodes), have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN 820 will select one of them to become the new SGSN 825.
  • the PDP context contains a GGSN address for user plane and uplink TEID for data, (to this GGSN address and uplink TEID, for data the old SGSN 820 and the new SGSN 825 send uplink packets).
  • a timer is started on the MM and PDP contexts in the old SGSN 820.
  • the forward relocation request message of step 838 is applicable only in the case of inter-SGSN SRNS relocation.
  • step 840 the new SGSN 825 sends a relocation request message
  • NAS non-access stratum
  • the relocation request message also indicates a single tunnel operation, the TEID of the GGSN 830 and the association between both the MSISDN of the WTRU 805 and its PDP address with the TEID of the GGSN 830
  • step 842 RABs are established and a tunnel setup at the target
  • RNC 815 is established in accordance with the present invention. Only the Iu bearers of the RABs are setup between the target RNC 815 and the new SGSN 825, since the existing RABs will be reallocated between the WTRU 805 and the
  • the RAB 's information elements may contain information such as RAB ID, RAB parameters, transport layer address and Iu transport association.
  • the RAB ID information element contains the network layer service access point identifier (NSAPI) value, and the RAB parameters information element provides the quality of service (QoS) profile.
  • the transport layer address is the SGSN address for user data, and the Iu transport association corresponds to the uplink TEID data.
  • the target RNC 815 sends a relocation request acknowledge message, (RABs setup, RABs failed to setup), to the new SGSN 825 (step 844).
  • RABs setup RABs failed to setup
  • Each RAB to be setup is defined by a transport layer address, which is the address of the target RNC 815 for user data, and an Iu transport association, which corresponds to the downlink TEID for user data.
  • the target RNC 815 may receive simultaneously downlink user packets both from the source RNC 810 and from the new SGSN 825.
  • a forward relocation response message (cause, RANAP cause, and RAB setup information), is sent from the new SGSN 825 to the old SGSN 820 (step 846).
  • the forward relocation response message indicates that the target RNC 815 is ready to receive from source RNC 810 the forwarded downlink PDUs, (i.e., the relocation resource allocation procedure is terminated successfully).
  • the RANAP cause is information from the target RNC 815 to be forwarded to the source RNC 810.
  • the RAB setup information contains the RNC TEID and the RNC IP address for data forwarded from the source RNC 810 to the target RNC 815. If the target RNC 815 or the new SGSN 825 failed to allocate resources, the RAB setup information element contains only NSAPI indicating that the source RNC 810 shall release the resources associated with the NSAPI.
  • the forward relocation response message of step 846 is applicable only in case of inter-SGSN SRNS relocation. [0049]
  • the old SGSN 820 continues the relocation of SRNS by sending a relocation command message, (RABs to be released, and RABs subject to data forwarding), to the source RNC 810 (step 848).
  • the old SGSN 820 determines the RABs to be subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding.
  • the information element shall contain an RAB ID, transport layer address, and Iu transport association. These are the same transport layer address and Iu transport association that the target RNC 815 had sent to the new SGSN 825 in the relocation request acknowledge message of step 844, and these are used for forwarding of downlink PDUs from the source RNC 810 to the target RNC 815.
  • the source RNC 810 is now ready to forward downlink user data directly to the target RNC 815 over the Iu interface. This forwarding is performed for downlink user data only.
  • the source RNC 810 may, according to the QoS profile, begin the forwarding of data to the target RNC 815 for the RABs to be subject for data forwarding.
  • the data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between the source RNC 810 and the target RNC 815 are duplicated in the source RNC 810 and routed at IP layer towards the target RNC 815.
  • the GTP-PDUs related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target RNC 815 together with their related downlink PDCP sequence numbers.
  • the source RNC 810 continues transmitting duplicates of downlink data and receiving uplink data. Before the role of the serving RNC is not yet taken over by the target RNC 815, and when downlink user plane data starts to arrive at the target RNC 815, the target RNC 815 may buffer or discard arriving downlink GTP-PDUs according to the related QoS profile. [0051] It should be noted that the order of steps 850-876 of the SRNS relocation procedure shown in Figure 8 does not necessarily reflect the order of events and may be performed in a different order or simultaneously. For instance, the source RNC 810 may start data forwarding in step 850 and send a relocation commit message (step 852) almost simultaneously except in the delivery order required case where step 850 triggers step 852.
  • the target RNG 815 may send a relocation detect message (step 854) and a RAN mobility information message (step 856) at the same time.
  • the target RNC 815 may receive a RAN mobility information confirm, message (step 858) while data forwarding (step 850) is still underway, and before the new SGSN 825 receives an update PDP context response message (step 862).
  • the source RNC 810 Before sending the relocation commit message at step 852 for the uplink and downlink data transfer in the source RNC 810, the source RNC 810 is suspended for RABs, which require delivery order.
  • the source RNC 810 shall start the data-forwarding timer.
  • the source RNC 810 triggers the execution of relocation of SRNS by sending a relocation commit message, (SRNS contexts), to the target RNC 815 over the Iur interface (step 852).
  • SRNS contexts relocation commit message
  • the purpose of this procedure is to transfer SRNS contexts from the source RNC 810 to the target RNC 815, and to move the SRNS role from the source RNC 810 to the target RNC 815.
  • SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP-PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the WTRU 805.
  • the sequence numbers of the GTP-PDUs next to be transmitted are not used by the target RNC 815.
  • PDCP sequence numbers are only sent by the source RNC 810 for radio bearers, which used lossless PDCP. The use of lossless PDCP is selected by the source RNC 810 when the radio bearer is set up or reconfigured.
  • step 854 the target RNC 815 sends a relocation detect message to the new SGSN 825 when the relocation execution trigger is received.
  • the relocation execution trigger is the reception of the relocation commit message at step 852 from the Iur interface.
  • the target RNC 815 shall start SRNC operation.
  • the target RNC 815 sends a RAN mobility information message that contains WTRU information elements and CN information elements.
  • the WTRU information elements include, among others, a new SRNC identity and a subscriber radio network temporary identity (S-RNTI).
  • the CN information elements contain, among others, location area identification and routing area identification. The procedure is coordinated in all Iu signaling connections existing for the WTRU 805.
  • the target RNC 815 establishes and/or restarts the RLC, and exchanges the PDCP sequence numbers, (PDCP sequence number (SNU), PDCP sequence number downlink (SND)), between the target RNC 815 and the WTRU 805.
  • the PDCP SND is the PDCP sequence number for the next expected in- sequence downlink packet to be received in the WTRU 805 per radio bearer, which used lossless PDCP in the source RNC 810.
  • the PDCP SND confirms all mobile-terminated packets successfully transferred before the SRNC relocation. If the PDCP SND confirms reception of packets that were forwarded from the source RNC 810, the target RNC 815 shall discard these packets.
  • the PDCP SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source RNC 810.
  • the PDCP SNU confirms all WTRU originated packets successfully transferred before the SRNC relocation. If PDCP SNU confirms reception of packets that were received in the source RNC 810, the WTRU 805 shall discard these packets.
  • the WTRU 805 may start sending uplink user data to the target RNC 815.
  • the WTRU 805 has reconfigured itself, it sends ,a RAN mobility information confirm message to the target RNC 815 at step 858. This indicates that the WTRU 805 is also ready to receive downlink data from the target RNC 815.
  • the new SGSN 825 sends an update PDP context request message to the GGSN 830 at step 860 which indicates a single tunnel configuration and the TEID of the target RNC 815 in accordance with the present invention.
  • the GGSN 830 updates the binding of the TEID of the target RNC 815 with the PDP address and the MSISDN of the WTRU 805.
  • SGSN 825 sends the name of the new connection that data will be forwarded to by the GGSN 830.
  • the GGSN 830 updates the information pertaining to this tunnel, (i.e., new destination).
  • the target RNC 815 starts uplink reception of data and start transmission of uplink GTP-PDUs towards the new SGSN 825, and the target RNC 815 starts processing the already buffered and the arriving downlink GTP-PDUs and starts downlink transmission towards the WTRU 805.
  • the CN may switch the user plane from the source RNC 810 to the target RNC 815. If the SRNS relocation is an inter-SGSN SRNS relocation, the new SGSN 825 sends update PDP context request messages, (new SGSN address, SGSN TEID, QoS negotiated), to the GGSNs concerned.
  • the GGSNs update their PDP context fields and return an update PDP context response (GGSN TEID) at step 862.
  • a new GTP user plane tunnel is then established between the target RNC 815 and the GGSN 830 at step 864 in accordance with the present invention.
  • the new SGSN 825 If the new SGSN 825 has already received the update PDP context response message from the GGSN 830, the new SGSN 825 forwards the uplink user data to the GGSN 830 over the new GTP user plane tunnel. Otherwise, the new SGSN 825 forwards the uplink user data to the IP address of the GGSN 830 and TEID(s), which the new SGSN 825 had received earlier by the forward relocation request message at step 838.
  • the target RNC 815 When the target RNC 815 receives the RAN mobility information confirm message at step 858, (i.e., the ID of the target RNC 815 and an S-RNTI are successfully exchanged with the WTRU 805 by the radio protocols), the target RNC 815 initiates a relocation complete procedure by sending a relocation complete message to the new SGSN 825 at step 866.
  • the purpose of the relocation complete procedure is to indicate by the target RNC 815 the completion of the SRNS relocation to the CN. If the user plane has not been switched at relocation detect and upon reception of relocation complete, the CN switches the user plane from the source RNC 810 to the target RNC 815. If the SRNS relocation is an inter-SGSN SRNS relocation, the new SGSN 825 signals to the old SGSN 820 the completion of the SRNS relocation procedure by sending a forward relocation complete message at step 868.
  • Figure 10 shows a system configuration after implementing a single tunnel combined hard handover and SRNS relocation and routing area update procedure in accordance with the present invention.
  • Figure 11 is a signaling diagram of a single tunnel combined hard handover and SRNS relocation procedure implemented in a wireless communication system including a WTRU 1105, a source RNC 1110, a target RNC 1115, an old SGSN 1120, a new SGSN 1125 and a GGSN 1130 in accordance with another embodiment of the present invention.
  • the procedure of Figure 11 is applicable to both intra-SGSN SRNS relocation and inter-SGSN SRNS relocation.
  • the signaling flow is applicable to BSS to RNS relocation and vice-versa, as well as BSS to BSS relocation.
  • step 1132 an old tunnel is established between the source RNC
  • the source RNC 1110 decides to perform/initiate a combined hard handover and SRNS relocation.
  • both uplink and downlink user data flows via at least one of the following tunnels: a radio bearer between the WTRU 1105 and the source RNC 1110, (no drift RNC available); GTP user plane tunnel(s) between the source RNC 1110 and the old SGSN 1120; and GTP user plane tunnel(s) between the old-SGSN 1120 and the GGSN 1130.
  • the source RNC 1110 sends a relocation required message, (including relocation type, cause, source ID, target ID, source RNC to target RNC transparent container), to the old SGSN 1120.
  • the source RNC 1110 sets the relocation type to "WTRU involved".
  • the source RNC to target RNC transparent container includes the necessary information for relocation coordination, security functionality and RRC protocol context information, (including WTRU capabilities).
  • the old SGSN 1120 determines from the target ID if the SRNS relocation is an intra-SGSN SRNS relocation or an inter ⁇ SGSN SRNS relocation.
  • the old SGSN 1120 initiates the relocation resource allocation procedure by sending a forward relocation request message, (IMSI, TEID signaling, MM context, PDP context, target identification, RAN transparent container, RANAP cause) to the new SGSN 1125 (step 1138).
  • IMSI forward relocation request message
  • the old SGSN 1120 may, (if it provides intra domain connection of RAN nodes to multiple CN nodes), have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN 1120 will select one of them to become the new SGSN 1125.
  • the PDP context contains a GGSN address for user plane and uplink TEID for data, (to this GGSN address and uplink TEID, for data the old SGSN 1120 and the new SGSN 1125 send uplink packets).
  • a timer is started on the MM and PDP contexts in the old SGSN 1120.
  • the forward relocation request message of step 1138 is applicable only in the case of inter-SGSN SRNS relocation.
  • the new SGSN 1125 sends a relocation request message, (including a permanent non-access stratum (NAS) WTRU identity, cause, CN domain indicator, source RNC to target RNC transparent container, RABs to be setup),to the target RNC 1115.
  • NAS non-access stratum
  • the old SGSN 1120 may, if it provides intra domain connection of RAN nodes to multiple CN nodes, have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN 1120 will select one of them to become the new SGSN 1125.
  • PDP context contains a GGSN address for user plane and uplink TEID for data, (to this GGSN address and uplink TEID for data.
  • the old SGSN 1120 and the new SGSN 1125 send uplink packets).
  • a timer is started on the MM and PDP contexts in the old SGSN 1120.
  • the forward relocation request message is applicable only for inter-SGSN SRNS relocation.
  • the relocation request message also indicates a single tunnel operation, the TEID of the GGSN 1130 and the association between both the MSISDN of the WTRU 1105 and its PDP address with the TEID of the GGSN 1130.
  • step 1142 RABs are established and a tunnel setup at the target
  • RNC 1115 is established in accordance with the present invention. Only the Iu bearers of the RABs are setup between the target RNC 1115 and the new SGSN 1125, since the existing RABs will be reallocated between the WTRU 1105 and the target RNC 1115 when the target RNC 1115 takes the role of an SRNC.
  • the RAB's information elements may contain information such as RAB ID, RAB parameters, transport layer address and Iu transport association.
  • the RAB ID information element contains the network layer service access point identifier (NSAPI) value, and the RAB parameters information element provides the quality of service (QoS) profile.
  • the transport layer address is the SGSN address for user data, and the Iu transport association corresponds to the uplink TEID data.
  • the target RNC 1115 sends a relocation request acknowledge message, (RABs setup, RABs failed to setup), to the new SGSN 1125 (step 1144).
  • RABs setup RABs failed to setup
  • Each RAB to be setup is defined by a transport layer address, which is the address of the target RNC 1115 for user data, and an Iu transport association, which corresponds to the downlink TEID for user data.
  • the target RNC 1115 may receive simultaneously downlink user packets both from the source RNC 1110 and from, the new SGSN 1125.
  • a forward relocation response message (cause, RAN transparent container, RANAP cause, target-RNC information), is sent from the new SGSN 1125 to the old SGSN 1120 (step 1146).
  • the forward relocation response message indicates that the target RNC 1115 is ready to receive from the source RNC 1110 the forwarded downlink PDUs, (i.e., the relocation resource allocation procedure is terminated successfully).
  • the RAN transparent container and the RANAP cause are information from the target RNC 1115 to be forwarded to the source RNC 1110.
  • the target RNC information contains the RNC TEID and the RNC IP address for data forwarded from the source RNC 1110 to the target RNC 1115.
  • the forward relocation response message of step 1146 is applicable only for inter-SGSN SRNS relocation.
  • the old SGSN 1120 continues the relocation of SRNS by sending a relocation command message, (RABs to be released, and RABs subject to data forwarding), to the source RNC 1110 (step 1148).
  • the old SGSN 1120 determines the RABs to be subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding.
  • the information element shall contain an RAB ID, transport layer address, and Iu transport association.
  • the source RNC 1110 may, according to the QoS profile, begin the forwarding of data to the target RNC 1115 for the RABs to be subject for data forwarding.
  • the data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data (GTP-PDUs) exchanged between the source RNC 1110 and the target RNC 1115 are duplicated in the source RNC 1110 and routed at the IP layer towards the target RNC 1115.
  • the GTP-PDUs related to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target RNC 1115 together with their related downlink PDCP sequence numbers.
  • PDCP lossless packet data convergence protocol
  • the source RNC 1110 continues transmitting duplicates of downlink data and receiving uplink data.
  • the target RNC 1115 may buffer or discard arriving downlink GTP-PDUs according to the related QoS profile.
  • steps 1150-1184 of the single tunnel combined hard handover and SRNS relocation procedure shown in Figure 11 does not necessarily reflect the order of events and may be performed in a different order or simultaneously.
  • the source RNC 1110 may start data forwarding in step 1150, send an RRC message to the WTRU 1105 (step 1152) and forward SRNS context message to the old SGSN (step 1154) almost simultaneously.
  • the uplink and downlink data transfer is suspended in the source RNC 1110 for RABs, which require delivery order.
  • the RRC message is, for example, physical channel reconfiguration for RNS to EJSTS relocation, or intersystem to UTRAN handover for BSS to RNS relocation, or handover from UTRAN command for BSS relocation, or handover command for BSS to BSS relocation.
  • the source RNC 1110 triggers the execution of relocation of SRNS by sending to the WTRU 1105 the RRC message provided in the target RNC 1115 to source RNC 1110 transparent container, e.g., a physical channel reconfiguration (WTRU information elements, CN information elements) message (step 1152).
  • WTRU information elements e.g., a physical channel reconfiguration (WTRU information elements, CN information elements) message
  • WTRU information elements include, among others, a new SRNC identity and S-RNTI.
  • CN information elements contain, among others, location area identification and routing area identification.
  • the source RNC 1110 continues the execution of relocation of SRNS by sending a forward SRNS context (RAB contexts) message to the target RNC 1115 via the old SGSN 1120 and the new SGSN 1125 (steps 1154, 1156 and 1160).
  • the forward SRNS context message is acknowledged by a forward SRNS context acknowledge message, from new SGSN 1125 to the old SGSN 1120 (step 1158).
  • SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the WTRU 1105.
  • PDCP sequence numbers are only sent by the source RNC 1110 for the radio bearers which used lossless PDCP. The use of lossless PDCP is selected by the source RNC 1110 when the radio bearer is set up or reconfigured.
  • the sequence numbers of the GTP-PDUs next to be transmitted are not used by the target RNC 1115.
  • delivery order is required (QoS profile)
  • consecutive GTP-PDU sequence numbering shall be maintained throughout the lifetime of the PDP context(s). Therefore, during the entire SRNS relocation procedure for the PDP context(s) using delivery order required (QoS profile), the responsible GTP-U entities (the RNCs 1110 and 1115, and the GGSN 1130) shall assign consecutive GTP-PDU sequence numbers to user packets belonging to the same PDP context uplink and downlink, respectively.
  • the target RNC 1115 establishes and/or restarts the RLC and exchanges the PDCP sequence numbers, (PDCP-SNU, PDCP-SND), between the target RNC1115 and the WTRU 1105.
  • PDCP-SND is the PDCP sequence number for the next expected in-sequence downlink packet to be received by the WTRU 1105 per radio bearer, which used lossless PDCP in the source RNC 1110.
  • PDCP-SND confirms all mobile terminated packets successfully transferred before the SRNC relocation. If PDCP-SND confirms reception of packets that were forwarded from the source RNC 1110, then the target RNC 1115 shall discard these packets.
  • PDCP-SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received in the RNC per radio bearer, which used lossless PDCP in the source RNC 1110.
  • PDCP-SNU confirms all mobile originated packets successfully transferred before the SRNC relocation. If PDCP-SNU confirms reception of packets that were received in the source RNC 1110, the WTRU 1105 discards these packets.
  • the target RNC 1115 sends a relocation detect message to the new
  • the relocation execution trigger may be received from the Uu interface; (i.e., when the target RNC 1115 detects the WTRU 1105 on the lower layers (step 1162)).
  • the relocation detect message is sent at step 1164, the target RNC 1115 starts SRNC operation.
  • the new SGSN 1125 sends an update PDP context request message to the GGSN 1130 which indicates a single tunnel configuration and the TEID of the target RNC 1115 in accordance with the present invention.
  • the GGSN 1130 updates the binding of the TEID of the target RNC 1115 with the PDP address and the MSISDN of the WTRU 1105.
  • the target RNC 1115 starts uplink reception of data and start transmission of uplink GTP-PDUs towards the new SGSN 1125, and the target RNC 1115 starts processing the already buffered and the arriving downlink GTP-PDUs and starts downlink transmission towards the WTRU 1105.
  • the CN may switch the user plane from the source RNC 1110 to the target RNC 1115.
  • the new SGSN 1125 sends update PDP context request messages, (new SGSN address, SGSN TEID, QoS negotiated), to the GGSNs concerned.
  • the GGSNs update their PDP context fields and return an update PDP context response (GGSN TEID) at step 1170.
  • a new GTP user plane tunnel is the established between the target RNC 1115 and the GGSN 1130 at step 1174 in accordance with the present invention.
  • the new SGSN 1125 If the new SGSN 1125 has already received the update PDP context response message from the GGSN 1130, the new SGSN 1125 forwards the uplink user data to the GGSN 1130 over the new GTP user plane tunnel. Otherwise, the new SGSN 1125 forwards the uplink user data to the IP address of the GGSN 1130 and TEID(s), which the new SGSN 1125 had received earlier by the forward relocation request message at step 1138.
  • the WTRU 1105 When the WTRU 1105 has reconfigured itself, it sends an RRC message, (e.g., a physical channel reconfiguration complete message), to the target RNC 1115 (step 1168). If a forward SRNS context message with the sequence numbers is received at step 1160, the exchange of packets with the WTRU 1105 may start. If this message is not yet received, the target RNC 1115 may start the packet transfer for all RABs, which do not require maintaining the delivery order.
  • RRC message e.g., a physical channel reconfiguration complete message
  • the target RNC 1115 When the target RNC 1115 receives the RRC message at step 1168, the target RNC 1115 initiates a relocation complete procedure by sending a relocation complete message to the new SGSN 1125 at step 1172.
  • the purpose of the relocation complete procedure is to indicate by the target RNC 1115 the completion of the SRNS relocation to the CN. If the user plane has not been switched at relocation detect and upon reception of relocation complete, the CN switches the user plane from the source RNC 1110 to the target RNC 1115. If the SRNS relocation is an inter-SGSN SRNS relocation, the new SGSN 1125 signals to the old SGSN 1120 the completion of the SRNS relocation procedure by sending a forward relocation complete message at step 1176.
  • the old SGSN 1120 Upon receiving the forward relocation complete message, or if an inter-SGSN SRNS relocation is taking place, the old SGSN 1120 sends a forward relocation complete acknowledge message to the new SGSN at step 1178, and the old SGSN 1120 sends an Iu release. command message to the source RNC 1110 at step 1180. When the RNC data-forwarding timer expires, the source RNC 1110 responds with an Iu release complete message at step 1182. [0093] After the WTRU 1105 has finished the reconfiguration procedure and if the new routing area identification is different from the old one, the WTRU 1105 initiates a routing area update procedure at step 1184. [0094] Embodiments
  • a serving radio network subsystem (SRNS) relocation method implemented in a wireless communication system including at least one wireless transmit/receive unit (WTRU), a source radio network controller (RNC), a target RNC, a first serving general packet radio service (GPRS) support node (SGSN), a second SGSN and a gateway GPRS support node (GGSN), wherein a first GPRS tunnelling protocol (GTP) user plane (GTP-U) tunnel is established between the source RNC and the GGSN, the method comprising:
  • the second SGSN sending a relocation request message to the target RNC which indicates a single tunnel operation, a tunnel endpoint identity (TEID) of the GGSN, an identification number of the WTRU and the packet data protocol (PDP) address of the WTRU;
  • TEID tunnel endpoint identity
  • PDP packet data protocol
  • the method of embodiment 1 further comprising: (f) the second SGSN sending an update PDP context request message to the GGSN which indicates a single tunnel operation and the TEID of the target RNC.
  • step (g) the GGSN updating a binding of the target RNC TEID with the PDP address of the WTRU and the identification number of the WTRU prior to executing step (d).
  • a wireless communication system for implementing a serving radio network subsystem (SRNS) relocation procedure comprising:
  • WTRU wireless transmit/receive unit
  • GGSN gateway GPRS support node
  • SGSN a first serving general packet radio service (GPRS) support node (SGSN);
  • GPRS general packet radio service
  • a second SGSN that sends a relocation request message to the target RNC in response to receiving a forward relocation request message sent by the first SGSN, the relocation request message indicating a single tunnel operation, a tunnel endpoint identity (TEID) of the GGSN, an identification number of the WTRU and the packet data protocol (PDP) address of the WTRU;
  • TEID tunnel endpoint identity
  • PDP packet data protocol
  • a source radio network controller (RNC) that sends a relocation required message to the first SGSN;
  • a first GPRS tunnelling protocol (GTP) user plane (GTP-U) tunnel that is established between the source RNC and the GGSN, wherein a second GTP-U tunnel is established between the target RNC and the GGSN and the first GTP-U tunnel is released when the SRNS relocation procedure is implemented.
  • GTP GPRS tunnelling protocol
  • GTP-U GPRS tunnelling protocol
  • a wireless communication system for implementing a single tunnel combined hard handover and serving radio network subsystem (SRNS) relocation procedure comprising:
  • WTRU wireless transmit/receive unit
  • GGSN gateway GPRS support node
  • SGSN a first serving general packet radio service (GPRS) support node (SGSN);
  • GPRS general packet radio service
  • a second SGSN that sends a relocation request message to the target RNC in response to receiving a forward relocation request message sent by the first SGSN, the relocation request message indicating a single tunnel operation, a tunnel endpoint identity (TEID) of the GGSN, an identification number of the WTRU and the packet data protocol (PDP) address of the WTRU;
  • TEID tunnel endpoint identity
  • PDP packet data protocol
  • a source radio network controller that sends a radio resource control (RRC) message to the WTRU, and sends a forward SRNS content message to the target RNC via the first SGSN and the second SGSN;
  • GTP GPRS tunnelling protocol
  • GTP-U GPRS tunnelling protocol user plane
  • SRNS relocation method implemented in a wireless communication system including at least one wireless transmit/receive unit (WTRU), a source radio network controller (RNC), a target RNC, a first serving general packet radio service (GPRS) support node (SGSN), a second SGSN and a gateway GPRS support node (GGSN), wherein a first GPRS tunnelling protocol (GTP) user plane (GTP-U) tunnel is established between the source RNC and the GGSN, the method comprising:
  • the second SGSN sending a relocation request message to the target RNC which indicates a single tunnel operation, a tunnel endpoint identity (TEID) of the GGSN, an identification number of the WTRU and the packet data protocol (PDP) address of the WTRU;
  • TEID tunnel endpoint identity
  • PDP packet data protocol
  • step (h) the GGSN updating a binding of the target RNC TEID with the PDP address of the WTRU and the identification number of the WTRU prior to executing step (e).
  • step (e) the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention.
  • the methods or flow charts provided in the present invention may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor.
  • Examples of computer- readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto- optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto- optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host computer.
  • WTRU wireless transmit receive unit
  • UE user equipment
  • RNC radio network controller
  • the WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) module.
  • modules implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emit

Landscapes

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

Abstract

Un procédé de relocalisation du sous-système de réseau de radiocommunication de desserte (SRNS) est mis en oeuvre dans un système de communication sans fil. Lorsqu'un ancien noeud de support de service général de radiocommunication à commutation de paquets de desserte (GPRS) (SGSN) indique qu'un RNC source demande une relocalisation du SRNS, le nouveau SGSN envoie un message de demande de relocalisation au RNC source en indiquant une opération de tunnel unique, une identité de point d'extrémité du tunnel (TEID) d'un noeud de support de GPRS inter-réseau (GGSN), le numéro d'identification d'une unité d'émission/réception sans fil (WTRU) et l'adresse du protocole de données par paquet (PDP) de la WTRU. Le nouveau SGSN envoie un message de demande de contexte PDP au GGSN en indiquant une opération de tunnel unique et la TEID du RNC. Le GGSN met à jour une liaison de la TEID du RNC avec l'adresse PDP de la WTRU et le numéro d'identification. Un nouveau tunnel est établi entre le RNC cible et le GGSN et un ancien tunnel entre le RNC source et le GGSN est libéré.
PCT/US2007/002232 2006-03-08 2007-01-25 Procédé et appareil pour la prise en charge du transfert et procédures de relocalisation du sous-système de réseau de radiocommunication de desserte dans un système de communication sans fil basé sur un gprs à tunnel unique WO2007102953A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2007222104A AU2007222104A1 (en) 2006-03-08 2007-01-25 Method and apparatus for supporting handoff and serving radio network subsystem relocation procedures in a single tunnel GPRS-based wireless communication system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US78023306P 2006-03-08 2006-03-08
US60/780,233 2006-03-08
US88637207P 2007-01-24 2007-01-24
US60/886,372 2007-01-24

Publications (1)

Publication Number Publication Date
WO2007102953A1 true WO2007102953A1 (fr) 2007-09-13

Family

ID=38057596

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/002232 WO2007102953A1 (fr) 2006-03-08 2007-01-25 Procédé et appareil pour la prise en charge du transfert et procédures de relocalisation du sous-système de réseau de radiocommunication de desserte dans un système de communication sans fil basé sur un gprs à tunnel unique

Country Status (5)

Country Link
AR (1) AR059275A1 (fr)
AU (1) AU2007222104A1 (fr)
DE (1) DE202007001269U1 (fr)
TW (2) TW200735681A (fr)
WO (1) WO2007102953A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101959314A (zh) * 2009-06-23 2011-01-26 财团法人资讯工业策进会 基站及其附接方法
CN101754304B (zh) * 2008-12-09 2012-11-28 中兴通讯股份有限公司 实现跨基站切换的用户面数据反传方法
CN102858008A (zh) * 2011-06-28 2013-01-02 中兴通讯股份有限公司 直连隧道的移动性管理方法、网元及系统
EP3029992A3 (fr) * 2013-07-04 2016-07-20 NEC Corporation Système, procédé et appareil de communication
EP3373620A4 (fr) * 2015-11-04 2019-04-24 LG Electronics Inc. Procédé de relocalisation de noeud de desserte dans un système de communication sans fil, et dispositif associé

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2283600B1 (fr) * 2008-05-30 2018-05-09 InterDigital Patent Holdings, Inc. Procédé et appareil pour acheminer une notification de retransmission de strate non-accès

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030003919A1 (en) * 2001-06-29 2003-01-02 Per Beming Relocation of serving network radio network controller ( SRNC) which has used direct transport bearers between SRNC and base station
WO2004043021A1 (fr) * 2002-11-05 2004-05-21 Samsung Electronics Co., Ltd. Procede de signalisation d'une connexion porteuse d'un service de diffusion/multidiffusion multimedia sur une interface iu

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030003919A1 (en) * 2001-06-29 2003-01-02 Per Beming Relocation of serving network radio network controller ( SRNC) which has used direct transport bearers between SRNC and base station
WO2004043021A1 (fr) * 2002-11-05 2004-05-21 Samsung Electronics Co., Ltd. Procede de signalisation d'une connexion porteuse d'un service de diffusion/multidiffusion multimedia sur une interface iu

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101754304B (zh) * 2008-12-09 2012-11-28 中兴通讯股份有限公司 实现跨基站切换的用户面数据反传方法
CN101959314A (zh) * 2009-06-23 2011-01-26 财团法人资讯工业策进会 基站及其附接方法
US8442049B2 (en) 2009-06-23 2013-05-14 Institute For Information Industry Base station and attaching method thereof
CN101959314B (zh) * 2009-06-23 2014-07-16 财团法人资讯工业策进会 基站及其附接方法
CN102858008A (zh) * 2011-06-28 2013-01-02 中兴通讯股份有限公司 直连隧道的移动性管理方法、网元及系统
EP3029992A3 (fr) * 2013-07-04 2016-07-20 NEC Corporation Système, procédé et appareil de communication
US9883440B2 (en) 2013-07-04 2018-01-30 Nec Corporation System, method, and apparatus for establishing a connection between a terminal and a network node
EP3373620A4 (fr) * 2015-11-04 2019-04-24 LG Electronics Inc. Procédé de relocalisation de noeud de desserte dans un système de communication sans fil, et dispositif associé
US10624004B2 (en) 2015-11-04 2020-04-14 Lg Electronics Inc. Serving node relocating method in wireless communication system and device for same

Also Published As

Publication number Publication date
DE202007001269U1 (de) 2007-08-02
AU2007222104A1 (en) 2007-09-13
AR059275A1 (es) 2008-03-19
TWM320260U (en) 2007-10-01
TW200735681A (en) 2007-09-16

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
US20070213060A1 (en) Method and apparatus for supporting handoff in an lte gtp based wireless communication system
CN107548127B (zh) 支持数据传输的方法和设备
US20070248064A1 (en) Method and apparatus for supporting routing area update procedures in a long term evolution general packet radio service tunneling protocol-based system
US9185595B2 (en) Method, apparatus and system for moving wireless terminals in mobility management serving node pool
CN101925042B (zh) 控制隧道标识分配的方法、装置和系统
CN112911726B (zh) 一种用户平面承载建立的方法及装置
US20080013553A1 (en) Activation of multiple bearer services in a long term evolution system
US20070213057A1 (en) Method and apparatus for supporting routing area update procedures in a single tunnel gprs-based wireless communication system
CN106941733A (zh) 双连接中实现重配置的方法、主服务基站及辅服务基站
WO2004089020A1 (fr) Procede de gestion de la mobilite d'un materiel utilisateur et systeme de communication s'y rapportant
CN101370261B (zh) 从cs域向ps域切换的资源准备方法及通信设备
CN101005692A (zh) 减少终端在lte和3g接入技术间切换的信令的方法
WO2010111814A1 (fr) Appareil et procédé pour déplacer une station mobile wcdma avec le moins de perte de paquets
WO2012122670A1 (fr) Procédé et dispositif relatifs à une technique de relais
KR20090055668A (ko) 이동통신 시스템 및 그 터널관리방법
CN101272604B (zh) 信令跟踪方法及设备
CN101588570B (zh) 建立用户面单隧道的方法、系统及其基站子系统
WO2007102953A1 (fr) Procédé et appareil pour la prise en charge du transfert et procédures de relocalisation du sous-système de réseau de radiocommunication de desserte dans un système de communication sans fil basé sur un gprs à tunnel unique
EP2713674A1 (fr) Procédé, dispositif et système de transmission de données
US9271313B2 (en) Service frequency based 3GDT
WO2008008145A2 (fr) Activation de services multi-porteuses dans un système d'évolution à long terme
CN102413584B (zh) 一种pdn连接的管理方法和设备
KR100628743B1 (ko) 무손실 에스알엔에스 재배치 방법
CN103079189A (zh) 控制隧道标识分配的方法、装置和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 193939

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 2007222104

Country of ref document: AU

Ref document number: 200780008214.1

Country of ref document: CN

Ref document number: 2008558267

Country of ref document: JP

Ref document number: PI 20083468

Country of ref document: MY

Ref document number: 7605/DELNP/2008

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2007222104

Country of ref document: AU

Date of ref document: 20070125

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: JP

122 Ep: pct application non-entry in european phase

Ref document number: 07717071

Country of ref document: EP

Kind code of ref document: A1