WO2007023177A1 - Method for dynamically including a micro mobility anchor into a user plane connection - Google Patents

Method for dynamically including a micro mobility anchor into a user plane connection Download PDF

Info

Publication number
WO2007023177A1
WO2007023177A1 PCT/EP2006/065638 EP2006065638W WO2007023177A1 WO 2007023177 A1 WO2007023177 A1 WO 2007023177A1 EP 2006065638 W EP2006065638 W EP 2006065638W WO 2007023177 A1 WO2007023177 A1 WO 2007023177A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobility
user plane
mobility anchor
functionality
node
Prior art date
Application number
PCT/EP2006/065638
Other languages
French (fr)
Inventor
Norbert Kroth
Thomas Ulrich
Alexander Vesely
Original Assignee
Nokia Siemens Networks Gmbh & Co. Kg
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 to EP05018418.3 priority Critical
Priority to EP05018418 priority
Application filed by Nokia Siemens Networks Gmbh & Co. Kg filed Critical Nokia Siemens Networks Gmbh & Co. Kg
Publication of WO2007023177A1 publication Critical patent/WO2007023177A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/02Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/12Mobility data transfer between location registers or mobility servers

Abstract

According to the invention, a method for establishing a connection in a radio communication System is proposed, wherein in a first Step, a user plane connection between nodes (CN Node, Node B) of the radio communication System is established, and wherein in a second Step, a mobility functionality is added to the user plane connection dependent on a detection of a first event requiring support of mobility of a user equipment (UE).

Description

Description

Method for dynamically including a micro mobility anchor into a user plane connection

The present invention relates to a method for dynamically including a so-called micro mobility anchor into a user plane connection, in particular for application in a mobile radio communication system according to the UMTS standard.

In mobile radio communication systems, setting up an end-to- end connection, e.g. a user-to-PLMN/PDN-connection (PDN: Packet Data Network) involves the setting up of connections between different nodes in the network. For example, in a system based on the well known UMTS (Universal Mobile Telecommunication System) standard, connections are established between GGSN and SGSN, between SGSN and RNC, and between RNC and NodeB.

On the one hand, the establishment of so-called user plane connections involving all these nodes requires relatively long setup times, i.e. for establishing the user plane connections and for initializing or resetting the functional entities associated with these nodes.

Furthermore, the mobility functionality requires:

- functional layers supporting mobility- and radio-specifics functions and protocols (e.g. MAC, RLC, combining, inter-cell control) and their implementation in physical nodes (respec- tively the association of such functions with logical nodes) ,

- appropriate geographical and/or topological distribution of these nodes,

- dynamic assignment of these nodes at connection setup, as well as - dynamic re-location of these nodes due to mobility of the users . In the framework of the 3GPP Work Item UTRAN Long Term Evolution (LTE) within the standardisation of UMTS, it is proposed to employ one particular node as a so-called micro mobility anchor. Such micro mobility anchor's task is to "hide" low- range mobility, e.g. mobility on cell level, from nodes in upper layers, e.g. nodes in the core network. In general, the functionality of such a node would be similar to today' s RNC- mobility, wherein the Iu interface is retained whilst the Iub interface may change as locations of user equipments (UE) change between NodeBs/cells . However, setting up an end-to- end connection across such micro mobility node would require additional setup time, thus causing additional latency at call setup.

According to the current 3GPP standards, user plane connections are established immediately at call setup between all involved nodes (e.g. GGSN, SGSN, RNC, NodeB) , resulting in long call setup times. However, for future systems or evolutions of the known systems such as UMTS, such delay at call setup is seen as being unacceptable due to required low control plane latency target figures.

It is thus an object of the present invention to provide a method for reducing the time needed for call setup while at the same time enabling an efficient implementation of mobility functionality in the system. This object is solved by the inventive features of independent claim 1. Further advantageous features of the invention are disclosed in dependent claims .

According to the invention, it is proposed not to employ the mobility functionality at call setup, but to add such functionality at a later stage after call establishment, resulting in significant reduction of the latency required for call setup.

According to a first aspect of the invention, the mobility functionality is employed if an event requiring mobility sup- port, e.g. a handover or a relocation of the user equipment, is detected.

According to a further aspect of the invention, the mobility functionality is realised by a micro mobility anchor, wherein, according to another aspect of the invention, such micro mobility anchor is realised in a node in the radio access network (RAN) of the radio communication system.

Advantages of the present inventions are the following:

First, the invention enables fast user plane connection setup because initially, only two network nodes are involved. Second, a direct user plane connection between a core network (CN) node ,e.g. a SGSN, and a NodeB in case of nomadic mobil- ity, i.e. a user equipment switches on and remains at site until it switches off again, would reduce the load at the micro mobility anchor (e.g. RAN node) due to the fact that not all user connections would need to be routed via this node, thus increasing the transmission efficiency for those low mo- bility (nomadic mobility) user equipments due to a reduced distance as well as reducing transmission delays for these user equipments and enabling the support of higher quality of service (QoS) . Third, the use of a micro mobility anchor would substantially reduce the load at the macro mobility an- chor located at a core network node (e.g. SGSN) .

According to another aspect of the invention, the mobility functionality realised by a micro mobility anchor may also be removed again from the user plane connection. The removal may be triggered by the event of e.g. a lapsed timer which indicates that within a predefined time interval, the user equipment has not been handovered to another Node B, or it may also be triggered when detecting that the user equipment has significantly reduced its velocity, i.e. its mobility.

According to a further aspect of the invention, the micro mobility anchor is relocated within the radio access network dependent on the current load. By a relocation of the micro mobility anchor, the load may efficiently be balanced in the system.

Another criterion for relocating the micro mobility anchor may be a current distance of the user equipment to the node, for which the mobility functionality was employed for thfirst time. I.e. the location of the micro mobility anchor is not changed if the user equipment is handovered from one NodeB to another NodeB, both being attached to the same controller, but only if the connection is handovered to a NodeB attached to a different controller or even different core network.

The present invention will become more apparent from the description and embodiments given herein below and from the ac- companying drawings which are given by way of information only, and thus are not limitative of the present invention, and wherein:

FIG 1 depicts a communications system wherein the inventive technique is applicable,

FIG 2 depicts a further inventive step in the communication system of FIG 1,

FIG 3 depicts a further inventive step in the communication system,

FIG 4 depicts a further inventive step in the communication system,

FIG 5 depicts a system architecture,

FIG 6 depicts a system architecture for deployment in urban area,

FIG 7 depicts a topology of a deployment-scenario for urban area,

FIG 8 depicts a system architecture for deployment in rural area, shows a with optional mobility anchor, and FIG 9 depicts a topology of a deployment-scenario for rural area. An example of the method according to the present invention is shown in FIG 1 to 4, i.e. an initial user plane connection setup in FIG 1; a dynamic user plane connection modification in preparation of a due handover of the user equipment and preparation of the micro mobility anchor in FIG 2; a dynamic user plane connection modification at the execution of the handover, and switching the connection from "direct" to "via micro mobility anchor" in FIG 3; and a dynamic user plane connection modification at the execution of a subsequent handover, and switching the connection without involving nodes above the micro mobility anchor node in FIG 4.

In FIG 2 to 4, a control plane connection between radio controller and the micro mobility anchor is depicted. Such con- nection would not necessarily be required, but the change of the micro mobility anchor could e.g. also be performed by explicitly forcing the NodeB to effect a so-called Routing-Address-Update for Mobile IPv6 for the NodeB to CN Node (Core Network Node) connection.

It should be noted that usually, a micro mobility anchor may be topologically associated with a NodeB and/or a radio controller covering a certain area, e.g. a number of cells. Moreover, such micro mobility anchor may be realised co-lo- cated to such a component of the radio access network or even integrated in it. Nevertheless, the micro mobility anchor may also serve adjacent areas or even areas at greater distances, e.g. in situations of overload or periods of maintenance of the originally served area. This would of course require the possibility of routing connections to such remote areas.

In addition to a pure mobility functionality, the micro mobility anchor may also perform additional functions like e.g. header compression (IP-ROHC: Internet Protocol-Robust Header Compression) or segmentation/concatenation or multiplexing in downlink (for soft combining in the user equipment DL SHO (Downlink Soft Handover)) or macro diversity combining (for soft handover in the network UL SHO (Uplink Soft Handover) . For such functionalities, relocations of states would be required, e.g. the current state of the ROHC-entity would need to be transferred from the old location (macro mobility anchor or another micro mobility anchor or even another NodeB) to the new micro mobility anchor. In this case, as depicted in FIG 2 to 4 a control plane connection between the controller and the micro mobility anchor would be necessary for configuring the additional functionalities.

It should also be noted that the functionality of e.g. combining may also be performed for a number of different radio technologies (e.g. UMTS, WiMAX etc.) within the same physical node .

In the following description including references to additional figures, further new aspects are discussed with respect to the current state of the 3GPP standardisation. These discussed issues may contain aspects of relevance for the present invention. All mentioned standard documents are thus included into the description of the invention below.

1. Introduction

One of the main targets of the Study Item "UTRAN Long Term

Evolution" is significant reduction of user plane latency. At 3GPPRAN2-Ad Hoc on LTE (20th - 21st June 2005, Sophia Antipo- lis, France) and at 3GPPRAN3-SA2-Joint-Ad Hoc one LE/SAE (28th - 30th June, Montreal, Canada) there were contributions on placement of complete MAC functionality in eNodeB, on necessity of a separate RLC Layer (e.g. R2-051760 and conve- nor' s summary in R2-051759) and on placement of Header Compression and Encryption (SRJ-050085) .

The present contribution continues discussing the location of user plane functionality in the evolved system. Main emphasis is put on the questions:

• Should user plane functions move out of the RAN into the CN? • How can Macro Diversity Combing (MDC) or Soft-Handoff

(SHO) be supported in case RAN WGl proposes to do this?

• How can MBMS-like services be efficiently supported?

2. Terminology

The present contribution assumes the existence of an Iu-like interface between a RAN (characterised by managing radio resources including radio bearers) and a CN (characterised by managing services and subscriber data, including Authentica- tion, Authorisation and Accounting) . This interface, named elu in this contribution, is assumed to follow the paradigm of separation into control plane and user plane (a paradigm valid for Iu since Release 99 of the UMTS standard) .

At the current state of discussions, there is no final decision whether there will be one or two nodes in RAN or CN (RAN: "NodeB and RNC" or "NodeB only"; CN: "SGSN and GGSN" or "GSN only") . For this reason, the term eGSN resembles that node in the CN which handles user plane data and is closest to RAN.

The term eNodeB resembles a node similar to today' s NodeB, but supporting the evolved Air Interface.

3. Retransmission, Encryption and Header Compression 3.1 Retransmission

As presented and discussed in RAN2 (R2-051760) retransmission functionality of MAC (Medium Access Control) and RLC (Radio Link Control) may be relocated towards the air interface.

From an architectural perspective, placement of retransmission functions close to the air interface makes a lot of sense, as all delays up to the retransmission point are multiplied by the number of repeated transmissions. The optimum ratio of "immediately successful transmissions" to "transmissions requiring repetition" depends on the coding used. Thus, details of ARQ (Automatic Repeat Request) are not treated further . Due to the optimisation of LTE/SAE (Long Term Evolution/System Architecture Evolution) for broadband packet services, it can be assumed that applications requiring secured transmissions will use terminal-based retransmission procedures, e.g. by employing TCP. This fact supposes to minimize the number of retransmission layers (i.e. ARQ layers) in LTE/SAE, as every retransmission layer will incur additional delay and negatively impact the performance of terminal-based retransmission scheme (e.g. TCP stall).

Consequently, it is proposed to locate all 3GPP retransmission functionality for user plane data in eNodeB.

3.2 Header Compression and Encryption

This section is focussing on the Encryption/Decryption functionality of the RLC and on the Header compression/Decompression functionality of PDCP. In the following, these two functions are referred to by the term HC/Encryption, independent of the actual direction of data flow.

Note: IP-header transmission requires a minimum level of transport security, i.e. there is a limitation of the maximum acceptable Bit Error Rate/Block Error rate (BER/BLER) . However, in contrast to existing UTRAN it is expected that all services (even such services expecting no QoS (Quality of Service) at all) are using IP headers. Thus, the maximum tolerable BER/BLER will e.g. depend on the maximum BER/BLER tol- erable by ROHC and not on the maximum BER/BLER tolerable by the service.

The following arguments suppose to move HC/Encryption towards CN side, i.e. away from the air interface, i.e. into that node called eGSN in this contribution: • Trunking gains :

HC/Encryption is a processing-intensive task. If it is performed in a more central place for a high number of users, statistics will provide a continuous constant load for the corresponding hardware, enabling economic use of the installed equipment (CAPEX (capital expenditure) saving) . • Relocation of State Machines:

Even for long-living connections with infrequent data traffic, the HC/Encryption state can be kept in a single point without the need for relocation. Reduced relocation frequency will save C-plane (control plane) traffic (OPEX (operational expenditure) saving) and reduce processing requirements (CAPEX saving) . Depending on the to-be-decided scenario that CN will be a constant anchor point for multiple RATs (Radio Access Technologies) (e.g. iWLAN, WiMAX), encryption could even remain intact at RAT change.

• Encryption for NAS-messages in RRC containers and for user plane can be handled in the same node: UE and SGSN/GSN.

• HC/Encryption does not require retransmissions between the terminating entities. Thus, there is no harmful influence of transport delays on the HC/Encryption functionality and consequently no need for placement close to the air interface.

• Connection UE <-> SGSN/GSN coherently encrypted in the user plane.

• Termination point for security is moved further back into the network to SGSN/GSN, usually placed in well secured locations.

• The complete distance UE <-> SGSN/GSN benefits from HC by reduced load (e.g. calculations claim more than 50% bandwidth saving for VoIP (Voice over Internet Protocol) ) on the terrestrial lines (OPEX savings) .

• Simplified initialisation of encryption functionality, as keys are only required in UE and SGSN/GSN. • No key-exchange or key-update with RAN nodes required, neither at initialisation nor at RAN-related relocation/mobility. Note: C-Plane encryption may be re-initialised at node change, thus completely avoiding the need for user-key- transfer in RAN

4. Soft Handover (SHO) /Macro Diversity Combining (MDC) and Mobility

4.1 Mobility Anchor

Today, RNC functionality can hide UE mobility from the CN. In order to ensure scalability and use of even large CN nodes, this functionality might be required in RAN. In other words, the RAN should provide a mobility anchor for RAN mobility, independent from the CN mobility management.

However, today' s transport networks can inherently provide mobility mechanisms. One example is Mobile IPv6 (IETF RFC3775) and also multicast as supported by Ethernet (IEEE

802.x) can be exploited for mobility handling. Usage of such Λavailable' mobility mechanisms in the TNL would

• Reduce standardisation effort in 3GPP,

• Enable independent implementation of 3GPP functions and mobility functions,

• Provide new opportunities for mobile-network operators and fixed-network operators (e.g. having mobility support as part of Service Level Agreement) .

From a standardisation perspective, a non-3GPP-specific mobility anchor is characterised by the fact that U-plane (user plane) interfaces of such node have the same data format, independent of whether an interface accepts incoming data or provides an outgoing data flow. In other words, a mobility anchor is fully transparent for user plane traffic in both directions .

As a consequence, involvement of such transparent node is purely optional and operators may even decide to skip instal- lation of RAN mobility anchors during initial rollout of Evolved-UTRAN (reduced rollout CAPEX) .

4.2 Soft-Handoff Support for DL Multicast Channels When DL Point-to-Multipoint (PtM) transmission was introduced to RAN for MBMS in Release 6 of the UMTS standard, synchronised data distribution over the air promised significant reduction of required DL transmission power. As efficient sup- port for MBMS (Multimedia Broadcast Multicast Service) is also a requirement for LTE/SAE, data forking in DL will be required. As data rates for MBMS are typically high, forking should be located close to the air interface, similar to location of combining for UL-MDC.

From a standardisation perspective, there is no need for interacting with the data format between the single, incoming DL data stream and the multiple, outgoing DL data streams. Consequently, the transmitting eNodeB will not be affected by the question whether an additional "DL multicast box" is employed (in our example, only the TNL (Transport Network Layer) address will be different from the TNL address of the eGSN) .

As some TNL technologies inherently or explicitly support multicast, there would again be the option not to standardise specific 3GPP functionality for support of DL multicast. This would again be reflected by the fact that single interfaces of such multicast box are "the same" in 3GPP logic.

Note: For an efficient combining of MBMS PDUs (Packet Data Units) from different cells/eNodeBs, UEs may require knowledge of a PDU counter (similar to today's RLC numbering) . This numbering can be provided by eGSN, independent whether a "DL multicast box" is configured in between eGSN and eNodeB.

4.3 Soft-Handoff Support for DL Dedicated Channels From discussions during the introduction of the HSDPA (High Speed Downlink Packet Access) feature in Release 5 of the UMTS standard, it is known that gains from DL soft-handoff may be compensated by other means (e.g. fast scheduling) . It is therefore expected that similar results will make DL SHO questionable for LTE. However, if DL SHO would be preferred by RANl (Radio Access Network Layer 1) and as long as no fast inter-eNodeB-communi- cation is required (e.g. no inter-eNodeB-coordinated DL scheduling), similar DL multicast schemes as for MBMS (see above) can be applied.

A final decision is subject to RANl proposals, however it is strongly recommended to avoid any fast inter-NodeB communica- tion during DL SHO, as this would contribute significant network traffic with a high QoS requirement and consequently incur substantial operational expenses (OPEX) .

4.4 Macro-Diversity Combining (MDC) for UL Dedicated Channels In the uplink, the situation is more complicated as redundant PDUs can be received from different eNodeBs for Macro-Diversity combining. Selection of PDUs is a functionality which is typically not provided by existing TNL technologies, thus 3GPP-specific functionality is required.

Despite the technical complexity and the n-fold amount of network traffic during SHO situation, some initial RANl calculations show considerable improvement of Air-Interface throughput and possible cell-sizes. Thus, decision to rule out UL MDC seems to be hard at the moment.

However, looking at the "same interface" principle described for DL above, one solution would be to make UL MDC "optional" from an architectural perspective. Such an "optional UL MDC functionality" can be provided under the following conditions :

• Same incoming user plane data format from NodeB as outgoing user plane data format towards eGSN (typically, just the number of block errors in the outgoing data to- wards eGSN would be lower than in each of the incoming interfaces) , and

• eNodeBs are in the position to autonomously detect and decode air-interface PDUs, i.e. there is no requirement to have fast inter-NodeB information exchange about the allowed/scheduled UL data formats.

Again, according to 3GPP logical node concepts, the "same user plane interface" would incur the fact that such UL MDC node is optional by definition.

5. Overview on the Resulting Network Architecture

FIG 5 discloses an overview on that architecture resulting from considerations above. Optional nodes are confined by dotted lines. Some of the functions which can be provided by non-3GPP nodes are e.g the DL Multicast. Naming of nodes and interfaces is according to the terminology section above.

Despite the following description focusses on handling of user plane traffic, control plane functions are depicted for the sake of completeness.

FIG 5 shows an example of a resulting system architecture with optional MDC/SHO/mobility-Anchor functionality

6. Deployment Scenarios

The approach that MDC/SHO/mobility-Anchor functionality is optional provides new flexibility for operators when rolling out Evolved-UTRA networks.

As a baseline for every deployment, the assumption that NodeBs are located according to Radio-Planning Tools should not require any further debate (even if the location is not selected according to radio planning for LTE, but according to radio planning for legacy systems) . The location and dimensioning of Core Network Nodes (eGSN) , however, may be guided by even concurring design guidelines:

• Reuse of existing SGSN/GGSN locations and their interconnectivity facilities (Gi, Gn, IMS, HSS) ,

• Change in traffic demands for eGSN (PS only, increase of total traffic) , • Change in traffic sources/sinks (Wide-Distance Traffic, Traffic to centralised servers; Peer-to-Peer Traffic for Data Services like Data Exchange, Peer-to-Peer Traffic for VoIP including local calls) , and/or • Change in network topology (deployment or acquisition of additional broadband connections like fibre channels etc. )

6.1 Deployment in Urban Area FIG 6 shows a functional view of a possible deployment in an urban area, where SHO/MDC is deemed negligible due to high inter-cell attenuation. The optional mobility anchor can be omitted at initial deployment (as long as the eGSN can handle the number of cell changes) .

In addition to what is depicted in FIG 6, the operator may decide to add support for DL Multicast if he puts emphasis on MBMS in his business plan.

FIG 7, in contrast, shows a topological view of an exemplary deployment-scenario for Urban Area with optional mobility anchor .

6.2 Deployment in Rural Area FIG 8 discloses a functional view of an exemplary deployment scenario for rural area, in which SHO/MDC is deemed important for coverage reasons, but may be co-located with the eGSN. Hiding mobility functionality is not deemed important as cell change is infrequent due to cell size and reduced traffic, nevertheless, mobility anchoring may be performed by an existing TNL concentrator (e.g. router / switch).

FIG 9 shows a topological view of an exemplary deployment scenario for Rural Area with SHO/MDC support.

7. Proposals

It is thus furthermore proposed: • To move Header Compression & Encryption into the CN

(here: eGSN) and to capture this agreement in 3GPP TR 23.882,

• To locate PDU numbering for support of Soft-Combining for DL Multicast Services in CN (here: eGSN),

• To locate PDU numbering for support of Soft-Combining for DL Unicast Services in CN (here: eGSN),

• To provide guidance to RANl to take methods into account, which enable optional MDC/SHO units and avoid de- manding inter-eNodeB traffic, when discussing MDC/SHO gains and schemes, and

• To provide guidance to RAN3 about employing non-3GPP methods (TNL methods) for support of mobility handling.

Claims

Patent claims
1. Method for establishing a connection in a radio communication system, wherein in a first step, a user plane connection between nodes (CN Node, Node B) of the radio communication system is established, and in a second step, a mobility functionality is added to the user plane connection dependent on a detection of a first event requiring support of mobility of a user equipment (UE) .
2. Method according to claim 1, wherein the detected event is a due handover and/or relocation of the user equipment (UE) .
3. Method according to claim 1 or 2, wherein the mobility functionality is realised by a micro mobility anchor .
4. Method according to any of the preceding claims, wherein the micro mobility anchor is relocated within the system dependent on a current load.
5. Method according to any of the preceding claims, wherein the mobility functionality is removed from the user plane connection dependent on a detection of a second event.
6. Method according to claim 5, wherein the second event is a lapse of a predetermined timer and/or a reduced movement of the user equipment (UE) .
7. Radio communication system, comprising means for realising the method according to any of the preceding claims.
PCT/EP2006/065638 2005-08-24 2006-08-24 Method for dynamically including a micro mobility anchor into a user plane connection WO2007023177A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05018418.3 2005-08-24
EP05018418 2005-08-24

Publications (1)

Publication Number Publication Date
WO2007023177A1 true WO2007023177A1 (en) 2007-03-01

Family

ID=37459494

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/065638 WO2007023177A1 (en) 2005-08-24 2006-08-24 Method for dynamically including a micro mobility anchor into a user plane connection

Country Status (1)

Country Link
WO (1) WO2007023177A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008105716A1 (en) * 2007-02-28 2008-09-04 Telefonaktiebolaget Lm Ericsson (Publ) Private mobility management enhancements
WO2008154212A1 (en) * 2007-06-07 2008-12-18 Qualcomm Incorporated Mobility management mode selection in multiple access wireless networks
EP2293643A1 (en) * 2008-08-05 2011-03-09 Huawei Technologies Co., Ltd. Node, method and system for a mobile network high speed accessing to a public network

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002019615A2 (en) * 2000-08-31 2002-03-07 Nortel Networks Limited Methods and apparatus for supporting mobility within a radio access network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002019615A2 (en) * 2000-08-31 2002-03-07 Nortel Networks Limited Methods and apparatus for supporting mobility within a radio access network

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP GROUP SERVICES AND SYSTEM ASPECTS: "3GPP TR 23.882 V0.3.0:"Report on TEchnical Options and Conclusions Release 7", 3GPP, July 2005 (2005-07-01), Sophia Antipolis, XP002415834, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Specs/html-info/23882.htm> [retrieved on 20070119] *
3GPP GROUP SERVICES AND SYSTEM ASPECTS: "TR 22.978 V7.1.0: ALL-IP Network (AIPN) feasibility study (Release 7)", 3GPP, June 2005 (2005-06-01), Sophia Antipolis, XP002415832, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Specs/html-info/22978.htm> [retrieved on 20070119] *
USKELA S.: "Mobility Management in Mobile Internet", IEE: 3G MOBILE COMMUNICATION TECHNOLOGIES, no. 489, May 2002 (2002-05-01), XP002415833, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/iel5/8025/22164/01032001.pdf?isnumber=&arnumber=1032001> [retrieved on 20070119] *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008105716A1 (en) * 2007-02-28 2008-09-04 Telefonaktiebolaget Lm Ericsson (Publ) Private mobility management enhancements
US8009628B2 (en) 2007-02-28 2011-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Private mobility management enhancements
WO2008154212A1 (en) * 2007-06-07 2008-12-18 Qualcomm Incorporated Mobility management mode selection in multiple access wireless networks
US8619668B2 (en) 2007-06-07 2013-12-31 Qualcomm Incorporated Mobility management mode selection in multiple access wireless networks
EP2293643A1 (en) * 2008-08-05 2011-03-09 Huawei Technologies Co., Ltd. Node, method and system for a mobile network high speed accessing to a public network
EP2293643A4 (en) * 2008-08-05 2011-09-07 Huawei Tech Co Ltd Node, method and system for a mobile network high speed accessing to a public network

Similar Documents

Publication Publication Date Title
TWI377818B (en) Method of transmitting uplink data and buffer status reports in a wireless communications system, wireless device for implementing such method
US9060311B2 (en) Enterprise level management in a multi-femtocell network
US7480272B2 (en) Soft handoff in IP-based CDMA networks by IP encapsulation
CN100493238C (en) MBMS point to point channel and point to multipoint channel switching mehtod
US8699461B2 (en) Optimized home evolved NodeB (eNB) handover in an LTE network
Banerjee et al. Analysis of SIP-based mobility management in 4G wireless networks
CN1956591B (en) Use station device for handoff in a broadcast communication system
US9560514B2 (en) Method for establishing connection by HNB
EP2222117B1 (en) Means and method for assisting handover of integrated radio access networks
US9775073B2 (en) Gateway configured to provide a handover, converting and routing function
EP2407001B1 (en) Device-to-device communication
KR100874152B1 (en) Simultaneous data service device and method using a plurality of different types of wireless networks
EP1867195B1 (en) Method and apparatus for flow control at cell change for high speed downlink packet access
US8929331B2 (en) Traffic management in a hybrid femtocell/WLAN wireless enterprise network
EP2465322B1 (en) Link aggregation in a heterogeneous communication system
EP1647127B1 (en) Method for soft handoff across different networks assisted by an end-to-end application protocol, and user agent, network application gateway and computer-readable medium program
JP2012529206A (en) QoS multiplexing over the interface between base station and relay node
EP1875763B1 (en) Internetworking of cellular radio networks and wireless data networks
US7346023B2 (en) Reconfigurable wireless communication access system and method
EP3537842A1 (en) Transmitting data packets in multi-rat networks
DE60208382T2 (en) Hybrid umts / wlan telecommunication system
CN100499401C (en) An uplink common channel for sending feedback information
US20060233137A1 (en) Wireless Router and Method for Processing Traffic in a Wireless Communications Network
US20130163424A1 (en) System and method for load based optimization in communication networks
JP6348517B2 (en) Long term evolution wireless access network

Legal Events

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

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06792981

Country of ref document: EP

Kind code of ref document: A1